Uber推出Databook平台：自動收集元數據並轉化為大數據洞見

作者|陸璐莉等。翻譯|吳明編輯|黛博拉指數業務（和數據）增長自2016年以來，優步已為該平台增加了幾項新服務，包括優步吃，優步貨運和跳躍自行車。如今，優步平台每天產生1500萬筆交易，每月活躍用戶超過7500萬。

圖1為了更容易發現和探索數據集，我們開發了數據手冊。數據手冊可用於管理和呈現優步數據集的元數據，使優步員工能夠在優步探索，發現和有效利用這些數據。數據手冊確保數據的上下文（數據的含義，質量等）對成千上萬試圖分析它們的人有意義。

圖2Databook將多個源作為輸入，存儲相關元數據，並通過RESTfulAPI輸出此信息。DatabookUI也使用這些API。在設計數據手冊之初，我們必須做出一個重大決定：是收集存儲的元數據還是按需收集？我們的服務需要支持高吞吐量和低延遲讀取。如果我們將操作委託給元數據源，則所有源都支持高吞吐量和低延遲讀取，這將導致更高的複雜性和更高的風險。

圖3以這種方式隔離了兩層，減少了副作用。例如，數據收集爬網程序可能會使用更多系統資源，從而影響請求服務層API的SLA。此外，數據收集層對中斷的敏感度低於Databook的請求服務層，並且如果數據收集層關閉，則可以提供過時的元數據，從而最大限度地減少對用戶的影響。基於事件的收集和調度收集我們的下一個挑戰是決定如何最有效地從幾個不同的數據源收集元數據。

圖4的體系結構允許我們的系統以編程方式觸發其他微服務，並近乎實時地啟動與數據用戶的通信。我們仍然使用爬蟲來執行其他任務，例如收集（或刷新）樣本數據，限制目標資源請求以及一些不需要收集的元數據（某些事件會自動觸發其他系統，例如數據集使用統計信息）。除了近乎實時地輪詢和收集元數據之外，數據手冊UI還從數據集使用者和生成者收集語義信息，例如表和列的描述。

圖7存儲選擇MySQL最初用於支持數據手冊的後端，因為它開發速度快，可以通過優步的基礎架構門戶自動配置。然而，當談到多個數據中心時，共享MySQL集群並不理想，原因有三：單個主節點：首先，Uber僅支持單個主節點，導致其他數據中心寫入速度變慢（每次寫入增加）約70毫秒）。手動切換主節點：其次，當時不支持主節點的自動切換。

圖8中的下一章Databook有一個Databook，優步的元數據比以往更加通用和實用，但我們仍在努力通過構建更強大的功能來擴展我們的範圍。我們希望添加的內容包括使用機器學習模型來生成數據洞察並創建高級問題檢測，預防和緩解機制。本文來自AI前線，創業家族授權發布，略有編輯和修改，版權歸作者所有，內容僅代表作者的獨立觀點。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！