Uber 的外賣服務 (Uber Eats) 自 2015 年 12 月在多倫多推出以來，已經在全球超過 40 個國家 400 個城市上線並持續快速發展。再加上其他業務，就構成了如此龐大的業務，如果 Uber 的數據平臺做不到信息智能化，很難想象如何支撐起這樣龐大規模的業務。今天，InfoQ 翻譯並分享 Uber 是如何做到數據平臺智能化的。
對 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 傳播數據新鮮度和質量信息，同時支持高級搜索和圖形設置。
我們還爲大型 Apache Hadoop 表啓動了一個全局索引，這是我們的大數據基礎設施的另一部分，範圍雖然更有限，但對我們的運營來說具有同等價值。我們的全局索引充當簿記組件（bookkeeping component），顯示存儲特定數據片段的服務，以便它們可以進行更新或顯示查詢結果。將 Apache HBase（一種非關係型分佈式數據庫）作爲全局索引，可以確保高吞吐量、強一致性和水平伸縮性。
我們爲 Apache Hadoop 數據湖構建了另一個組件：DBEvents，作爲變更數據捕獲系統。我們圍繞三個原則來設計 DBEvents：數據新鮮度、數據質量和效率。DBEvents 在從 MySQL、Apache Cassandra 和 Schemaless 等來源獲取數據期間捕捉數據，從而更新我們的 Hadoop 數據湖。這個解決方案通過標準化的變更日誌來管理拍字節級的數據，確保服務對可用數據有着統一的理解。
高效分析
通過我們的平臺或任何其他服務來分析有關拼車、自行車和兩輪電動車騎行的數據，既可以排除故障，又可以主動改進。例如，如果數據顯示客戶等待騎手的時間，比等待司機夥伴的平均時間還要長，我們就可以實時分析問題，看看我們的運營團隊是否能夠提供幫助。我們還可以分析有關我們服務的歷史數據，並開發新的功能來改進它們，例如，讓乘客更容易在擁擠的接送區域找到司機夥伴。
我們對及時且可用的分析需求，促使我們構建了一個新的平臺，該平臺目前支持多個關鍵業務級儀表板提供支持。這個平臺的儀表板如圖 2 所示，它將現有的實時分析系統（包括 AresDB 和 Apache Pinot）整合到一個統一的自助平臺中，允許內部分析用戶通過 Presto 提交查詢，Presto 是一個由我們的工程師支持的開源分佈式 SQL 查詢引擎。
由於對 SQL 查詢的支持，新平臺還使我們的內部用戶能夠更容易地進行數據分析，從而作出關鍵業務決策。同樣重要的是，它還能夠以低延遲來交付結果，讓我們能夠快速處理問題。
爲未來而建
維護一個可靠支持質量和新鮮度的數據基礎設施是 Uber 未來的重要組成部分。數據必須儘可能準確、及時，以支持我們平臺上的服務。過去幾年來，我們一直努力構建可以擴至我們全球全天候運營的基礎設施。我們當前工作的一個關鍵部分是，使我們的基礎設施高效運行，並支持我們所有的內部用戶。
我們的工程師在 2019 年取得了巨大的進步，遠遠超過本文記載的部分。我們期待在新的一年裏，能夠進一步優化我們的數據基礎設施，讓 Uber 的平臺服務更上一層樓。
作者介紹：
Nikhil Joshi 是 Uber 數據平臺團隊的產品經理。 Viv Keswani 是 Uber 產品平臺團隊的技術總監。
原文鏈接：