Uber基於Apache Hudi構建PB級數據湖實踐

1. 引言

從確保準確預計到達時間到預測最佳交通路線，在Uber平台上提供安全、無縫的運輸和交付體驗需要可靠、高性能的大規模數據存儲和分析。2016年，Uber開發了增量處理框架Apache Hudi，以低延遲和高效率為關鍵業務數據管道賦能。一年後，我們開源了該解決方案，以使得其他有需要的組織也可以利用Hudi的優勢。接着在2019年，我們履行承諾，進一步將其捐贈給了Apache Software Foundation，差不多一年半之後，Apache Hudi畢業成為Apache Software Foundation頂級項目。為紀念這一里程碑，我們想分享Apache Hudi的構建、發布、優化和畢業之旅，以使更大的大數據社區受益。

2. 什麼是Apache Hudi

Apache Hudi是一個存儲抽象框架，可幫助組織構建和管理PB級數據湖，通過使用upsert和增量拉取等原語，Hudi將流式處理帶到了類似批處理的大數據中。這些功能通過統一的服務層（幾分鐘左右即可實現數據延遲），幫助我們更快，更新鮮地獲取服務數據，從而避免了維護多個系統的額外開銷。更靈活地，Apache Hudi還可以在Hadoop分佈式文件系統（HDFS）或雲存儲上運行。

Hudi在數據湖上啟用原子性、一致性、隔離性和持久性（ACID）語義。 Hudi的兩個最廣泛使用的功能是upserts和增量拉取，它使用戶能夠捕獲變更數據並將其應用於數據湖，為了實現這一點，Hudi提供了可插拔索引機制，以及自定義索引實現。Hudi具有控制和管理數據湖中文件布局的能力，這不僅能克服HDFS NameNode節點和其他雲存儲限制，而且對於通過提高可靠性和查詢性能來維護健康的數據生態系統也非常重要。另外Hudi支持多種查詢引擎，例如Presto，Apache Hive，Apache Spark和Apache Impala。

圖1. Apache Hudi通過在表上提供不同的視圖來攝取變更日誌、事件和增量流，以服務於不同的應用場景

從總體上講，Hudi在概念上分為3個主要組成部分：需要存儲的原始數據；用於提供upsert功能的索引數據以及用於管理數據集的元數據。內核方面，Hudi維護在不同時間點在表上執行的所有動作的時間軸，在Hudi中稱為即時，這提供了表格的即時視圖，同時還有效地支持了按序到達的數據檢索，Hudi保證時間軸上的操作是原子性的，並且基於即時時間，與數據庫中進行更改的時間是一致的。利用這些信息，Hudi提供了同一Hudi表的不同視圖，包括用於快速列式文件性能的讀優化視圖，用於快速數據攝取的實時視圖以及用於將Hudi表作為變更日誌流讀取的增量視圖，如上圖1所示。

Hudi將數據表組織到分佈式文件系統上基本路徑（basepath）下的目錄結構中。 表分為多個分區，在每個分區內，文件被組織成文件組，由文件ID唯一標識。 每個文件組包含幾個文件切片，其中每個切片包含在某個特定提交/壓縮（commit/compaction）瞬間生成的基本數據文件（*.parquet），以及包含對基本數據文件進行插入/更新的一組日誌文件（*.log）。Hudi採用了Multiversion Concurrency Control（MVCC），其中壓縮操作將日誌和基本文件合併以生成新的文件片，而清理操作則將未使用的/較舊的文件片去除，以回收文件系統上的空間。

Hudi支持兩種表類型：寫時複製和讀時合併。 寫時複製表類型僅使用列文件格式（例如，Apache Parquet）存儲數據。通過寫時複製，可以通過在寫過程中執行同步合併來簡單地更新版本並重寫文件。

讀時合併表類型使用列式（例如Apache Parquet）和基於行（例如Apache Avro）文件格式的組合來存儲數據。 更新記錄到增量文件中，然後以同步或異步壓縮方式生成列文件的新版本。

Hudi還支持兩種查詢類型：快照查詢和增量查詢。 快照查詢是從給定的提交或壓縮操作開始對錶進行"快照"的請求。利用快照查詢時，寫時複製表類型僅暴露最新文件片中的基本/列文件，並且與非Hudi表相比，可保證相同的列查詢性能。寫入時複製提供了現有Parquet表的替代品，同時提供了upsert/delete和其他功能。對於讀時合併表，快照查詢通過動態合併最新文件切片的基本文件和增量文件來提供近乎實時的數據（分鐘級）。對於寫時複製表，自給定提交或壓縮以來，增量查詢將提供寫入表的新數據，並提供更改流以啟用增量數據管道。

3. Apache Hudi在Uber的使用

在Uber，我們在各種場景中都使用到了Hudi，從在Uber平台上提供有關行程的快速、準確的數據，從檢測欺詐到在我們的UberEats平台上提供餐廳和美食推薦。為了演示Hudi的工作原理，讓我們逐步了解如何確保Uber Marketplace中的行程數據在數據湖上是最新的，從而改善Uber平台上的騎手和駕駛員的用戶體驗。行程的典型生命周期始於騎手提出的行程，然後隨着行程的進行而繼續，直到行程結束且騎手到達最終目的地時才結束。 Uber的核心行程數據以表格形式存儲在Uber的可擴展數據存儲Schemaless中。行程表中的單個行程條目在行程的生命周期中可能會經歷許多更新。在Uber使用Hudi之前，大型Apache Spark作業會定期將整個數據集重新寫入HDFS，以獲取上游在線表的插入、更新和刪除，從而反映出行程狀態的變化。就背景而言，在2016年初（在構建Hudi之前），一些最大的任務是使用1000個executors並處理超過20TB的數據，此過程不僅效率低下，而且難以擴展。公司的各個團隊都依靠快速、準確的數據分析來提供高質量的用戶體驗，為滿足這些要求，我們當前的解決方案無法擴展進行數據湖上的增量處理。使用快照和重新加載解決方案將數據移至HDFS時，這些低效率的處理正在寫到到所有數據管道，包括使用此原始數據的下游ETL，我們可以看到這些問題只會隨着規模的擴大而加劇。

在沒有其他可行的開源解決方案可供使用的情況下，我們於2016年末為Uber構建並啟動了Hudi，以構建可促進大規模快速，可靠數據更新的事務性數據湖。Uber的第一代Hudi利用了寫時複製表類型，該表類型每30分鐘將作業處理速度提高到20GB，I/O和寫入放大減少了100倍。到2017年底，Uber的所有原始數據表都採用了Hudi格式，運行着地球上最大的事務數據湖之一。

圖2. Hudi的寫時複製功能使我們能夠執行文件級更新，從而大大提高數據的新鮮度

4. 改進Apache Hudi

隨着Uber數據處理和存儲需求的增長，我們開始遇到Hudi的寫時複製功能的局限性，主要是需要繼續提高數據的處理速度和新鮮度，即使使用Hudi"寫時複製"功能，我們的某些表收到的更新也分散在90％的文件中，從而導致需要重寫數據湖中任何給定的大型表的數據，重寫數據量大約為100TB。由於寫時複製甚至為單個修改的記錄重寫整個文件，因此寫複製功能導致較高的寫放大和損害的新鮮度，從而導致HDFS群集上不必要的I/O以及更快地消耗磁盤空間，此外，更多的數據表更新意味着更多的文件版本，以及HDFS文件數量激增，反過來，這些需求導致HDFS Namenode節點不穩定和較高的計算成本。

為了解決這些日益增長的擔憂，我們實現了第二種表類型，即"讀時合併"。由於讀時合併通過動態合併數據來使用近實時的數據，為避免查詢端的計算成本，我們需要合理使用此模式。"讀時合併"部署模型包括三個獨立的作業，其中包括一個攝取作業，包括由插入、更新和刪除組成的新數據，一個次要的壓縮作業，以異步方式主動地壓縮少量最新分區的更新/刪除內容，以及一個主要的壓縮作業，該作業會緩慢穩定地壓縮大量舊分區中的更新/刪除。這些作業中的每一個作業都以不同的頻率運行，次要作業和提取作業的運行頻率比主要作業要高，以確保其最新分區中的數據以列格式快速可用。通過這樣的部署模型，我們能夠以列式為數千個查詢提供新鮮數據，並將我們的查詢側合併成本限制在最近的分區上。使用讀時合併，我們能夠解決上面提到的所有三個問題，並且Hudi表幾乎不受任何對數據湖的更新或刪除的影響。現在，在Uber，我們會根據不同場景同時使用Apache Hudi的寫時複製和讀時合併功能。

圖3. Uber的Apache Hudi團隊開發了一種數據壓縮策略，用於讀時合併表，以便頻繁將最近的分區轉化為列式存儲，從而減少了查詢端的計算成本

有了Hudi，Uber每天向超過150PB數據湖中插入超過5,000億條記錄，每天使用30,000多個core，超過10,000多個表和數千個數據管道，Hudi每周在我們的各種服務中提供超過100萬個查詢。

5. Apache Hudi經驗總結

Uber在2017年開源了Hudi，為其他人帶來了該解決方案的好處，該解決方案可大規模提取和管理數據存儲，從而將流處理引入大數據。當Hudi畢業於Apache軟件基金會下的頂級項目時，Uber的大數據團隊總結了促使我們構建Hudi的各種考慮因素，包括：

• 如何提高數據存儲和處理效率？


• 如何確保數據湖包含高質量的表？


• 隨着業務的增長，如何繼續大規模有效地提供低延遲的數據？


• 在分鐘級別的場景中，我們如何統一服務層？

如果沒有良好的標準化和原語，數據湖將很快成為無法使用的"數據沼澤"。這樣的沼澤不僅需要花費大量時間和資源來協調、清理和修復表，而且還迫使各個服務所有者構建複雜的算法來進行調整、改組和交易，從而給技術棧帶來不必要的複雜性。

如上所述，Hudi通過無縫地攝取和管理分佈式文件系統上的大型分析數據集來幫助用戶控制其數據湖，從而彌補了這些差距。建立數據湖是一個多方面的問題，需要在數據標準化、存儲技術、文件管理實踐，數據攝取與數據查詢之間折衷性能等方面進行取捨。在我們建立Hudi時與大數據社區的其他成員交談時，我們了解到這些問題在許多工程組織中普遍存在。我們希望在過去的幾年中，開源和與Apache社區的合作，在Hudi基礎上發展可以使其他人在不同行業對大數據運營有更深入的了解。 在Uber之外，Apache Hudi已在多家公司用於生產，其中包括阿里雲，騰訊雲，AWS、Udemy等。

6. 未來計劃

圖4. Apache Hudi場景包括數據分析和基礎架構運行狀況監視

Hudi通過對數據集強制schema，幫助用戶構建更強大、更新鮮的數據湖，從而提供高質量的見解。

在Uber，擁有全球最大的事務數據湖之一為我們提供了各種Apache Hudi用例場景的機會，由於以這種規模解決問題並提高效率可能會產生重大影響，因此有直接的動機促使我們更加深入。在Uber，我們已經使用了先進的Hudi原語，如增量拉取來幫助建立鏈式增量流水線，從而減少了作業的計算空間，而這些作業本來會執行大型掃描和寫入。我們根據特定的用例場景和要求調整讀時合併表的壓縮策略。 自從我們將Hudi捐贈給Apache基金會以來，最近幾個月，Uber貢獻了一些功能，例如嵌入式時間軸服務以實現高效的文件系統訪問，刪除重命名以支持雲友好的部署並提高增量拉取性能。

在接下來的幾個月中，Uber計劃為Apache Hudi社區貢獻更多新功能。其中一些功能可通過優化計算使用量以及改善數據應用程序的性能來幫助降低成本，我們還將更深入地研究如何根據訪問模式和數據應用程序需求來改善存儲管理和查詢性能。

有關我們如何計劃實現這些目標的更多信息，您可以閱讀一些RFC，包括支持列索引和O(1)查詢計劃的智能元數據，將Parquet表高效引導到Hudi，記錄級別索引支持更快速插入，這些RFC由Uber的Hudi團隊向Apache社區提出。

隨着Apache Hudi畢業成為Apache頂級項目，我們很高興為該項目雄心勃勃的路線圖做出貢獻。Hudi使Uber和其他公司可以使用開放源文件格式，在未來證明其數據湖的速度，可靠性和交易能力，從而消除了許多大數據挑戰，並構建了豐富而可移植的數據應用程序。

Apache Hudi是一個成長中的社區，具有令人興奮且不斷髮展的發展路線圖。 如果您有興趣為這個項目做貢獻，可點擊這裏。

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※網頁設計公司推薦不同的風格，搶佔消費者視覺第一線

※廣告預算用在刀口上，台北網頁設計公司幫您達到更多曝光效益

※自行創業缺乏曝光? 網頁設計幫您第一時間規劃公司的形象門面

※南投搬家公司費用需注意的眉眉角角，別等搬了再說!

※教你寫出一流的銷售文案?

---

Orignal From: Uber基於Apache Hudi構建PB級數據湖實踐