Uber 2019 年數據平臺建設實踐

對 Uber 來講，2019 是繁忙的一年，包括：迎來了第十億單 Uber 外賣訂單；在平臺上，自行車和兩輪電動車的外賣騎手覆蓋了 2400 萬英里；以及前往帝國大廈、埃菲爾鐵塔和金門大橋等熱門景點的旅行。然而，在全部這些活動的背後，都有一個關於數據的故事，以及咱們爲支持平臺服務而對數據基礎設施進行的創新。

在咱們現有的規模和全球範圍內，對 Uber 平臺的全天候支持意味着高達數拍字節（petabytes，PB）級別的數據在咱們的基礎設施中流動。咱們不只要使用這些數據向人們展現外賣騎手的位置或 最新的餐廳菜單，還要不斷分析彙總的、匿名的趨勢以瞭解咱們的服務在哪些方面還能夠運行得更順暢。

譯註：拍字節或拍它字節（Petabyte、PB）是一種信息計量單位，現今一般在標示網絡硬盤總容量，或具備大容量的保存媒介之保存容量時使用。1PB = 1,000 TB （兆) = 1,000,000 GB （十億)，因此中文的全稱是：1 千兆。

咱們發現一個頗有但願提升效率的領域是，將 數據科學 的實踐應用到咱們的基礎設施中，使咱們可以計算最優的數據存儲和硬件使用率。爲了更好地管理咱們數據，在持續增加的狀況下，可以保持數據的新鮮度和質量，爲此，咱們在內部啓動了新項目。咱們創建了一個新的分析平臺，這樣，咱們就能夠在短短几秒鐘內得到關鍵的業務洞見。

雖然這些項目並不是咱們 2019 年數據平臺工做的所有，但它們表明了關鍵的冰山一角。

利用數據科學優化數據平臺

創建有效的數據基礎設施遠不止是創建數據庫並向其填充數據那麼簡單。對於咱們的一些用例，天天每時每刻都有新的數據出現，記錄須要不斷地更新。而在其餘狀況下，數據到達的節奏較慢，須要的更新也較少。一樣，咱們的一些分析須要實時數據，而另外一些分析則依賴於歷史數據模式。

這些不一樣的用例爲經過數據科學、計算成本函數和其餘肯定數據最佳存儲方式的方法進行優化打開了大門。在 一個這樣的優化項目 中，咱們的數據科學和數據倉庫團隊一塊兒分析了數據倉庫中表的效用，肯定哪些表須要對咱們的低延遲分析引擎中保持可用，哪些表能夠轉移到成本較低的選項上。

咱們的數據科學家開發的模型考慮了各類因素，如查詢的數量和單個表的用戶數量、維護成本以及表之間的依賴關係等。卸載低效用的特定表可使數據庫成本下降 30%，咱們的團隊目前正在考慮如何應用人工智能來進一步推動這項工做。

一樣，咱們的團隊也在考慮如何 優化 Vertica，這是 Uber 正在使用的一個流行的交互式數據分析平臺。隨着咱們需求的發展，最直接的解決方案將涉及在咱們的基礎設施中複製 Vertica 集羣。可是，這種解決方案並不具備成本效益。

取而代之的是，咱們設計了一種方法來部分複製 Vertica 集羣，以更有效的方式在它們之間分發數據。咱們的數據科學團隊提出了一個成本函數，用於展現部分複製是如何工做的，而數據倉庫團隊構建了組件來讓解決方案在生產環境中實現無縫工做。這個解決方案可以顯著下降 30% 以上的整體磁盤使用量，同時繼續提供相同級別的計算可伸縮性和數據庫可用性。

在咱們這種規模的數據基礎設施中，即便是很小的優化也能夠帶來巨大的收益，在加快查詢速度的同時須要更少的資源，並最終使 Uber 的服務運行更加平穩。

數據管理

爲多個不一樣的業務線提供服務，如促進承運人和託運人之間貨物運輸的 Uber Freight，以及鏈接騎手、餐廳和食客的 Uber Eats 外賣系統，一樣也須要不一樣的數據。理解數據的整個生命週期，從數據的來源、各類轉換到最終目的地，對於保證數據質量和保真度都是相當重要的。

咱們的內部產品 uLineage，能夠追蹤數據的來源、去向和轉換方式。這個綜合系統從數據經過 Uber 服務進入的那一刻起，當數據由 Apache Kafka 傳輸時，以及當數據存儲在 Apache Hive 中時，都會維護信息。uLineage 傳播數據新鮮度和質量信息，同時支持高級搜索和圖形設置。

圖 1，uLineage 展現了一段數據所在的存儲區及其所經歷的轉換

咱們還 爲大型 Apache Hadoop 表啓動了一個全局索引，這是咱們的大數據基礎設施的另外一部分，範圍雖然更有限，但對咱們的運營來講具備同等價值。咱們的全局索引充當簿記組件（bookkeeping component），顯示存儲特定數據片斷的服務，以便它們能夠進行更新或顯示查詢結果。將 Apache HBase（一種非關係型分佈式數據庫）做爲全局索引，能夠確保高吞吐量、強一致性和水平伸縮性。

咱們爲 Apache Hadoop 數據湖構建了另外一個組件：DBEvents，做爲變動數據捕獲系統。咱們圍繞三個原則來設計 DBEvents：數據新鮮度、數據質量和效率。DBEvents 在從 MySQL、Apache Cassandra 和 Schemaless 等來源獲取數據期間捕捉數據，從而更新咱們的 Hadoop 數據湖。這個解決方案經過標準化的變動日誌來管理拍字節級的數據，確保服務對可用數據有着統一的理解。

高效分析經過咱們的平臺或任何其餘服務來分析有關拼車、自行車和兩輪電動車騎行的數據，既能夠排除故障，又能夠主動改進。例如，若是數據顯示客戶等待騎手的時間，比等待司機夥伴的平均時間還要長，咱們就能夠實時分析問題，看看咱們的運營團隊是否可以提供幫助。咱們還能夠分析有關咱們服務的歷史數據，並開發新的功能來改進它們，例如，讓乘客更容易在擁擠的接送區域找到司機夥伴。

圖 2：咱們新的分析平臺爲內部用戶提供了基於實時數據的業務關鍵洞見

咱們對及時且可用的分析需求，促使咱們構建了一個新的平臺，該平臺目前支持多個關鍵業務級儀表板提供支持。這個平臺的儀表板如圖 2 所示，它將現有的實時分析系統（包括 AresDB 和 Apache Pinot）整合到一個統一的自助平臺中，容許內部分析用戶經過 Presto 提交查詢，Presto 是一個 由咱們的工程師支持 的開源分佈式 SQL 查詢引擎。

因爲對 SQL 查詢的支持，新平臺還使咱們的內部用戶可以更容易地進行數據分析，從而做出關鍵業務決策。一樣重要的是，它還可以以低延遲來交付結果，讓咱們可以快速處理問題。

爲將來而建

維護一個可靠支持質量和新鮮度的數據基礎設施是 Uber 將來的重要組成部分。數據必須儘量準確、及時，以支持咱們平臺上的服務。過去幾年來，咱們一直努力構建能夠擴至咱們全球全天候運營的基礎設施。咱們當前工做的一個關鍵部分是，使咱們的基礎設施高效運行，並支持咱們全部的內部用戶。

咱們的工程師在 2019 年取得了巨大的進步，遠遠超過本文記載的部分。咱們期待在新的一年裏，可以進一步優化咱們的數據基礎設施，讓 Uber 的平臺服務更上一層樓。