4年數(shù)據(jù)漲萬倍，Uber大數(shù)據(jù)平臺四次變遷揭秘
2018-10-31 來源：raincent
作者：|Reza Shiftehfar
譯者：陳亮芬
編輯：Debra
導讀：Uber 致力于在全球市場上提供更安全、更可靠的交通工具。為了實現(xiàn)這一目標，Uber 非常依賴于各個層面的數(shù)據(jù)驅(qū)動決策，從在高流量事件期間預測乘客需求，到識別和解決合作司機們在注冊過程中的瓶頸。隨著時間的推移，想要獲取更多見解的需求產(chǎn)生了超過 100PB 的分析數(shù)據(jù)，這些數(shù)據(jù)需要通過基于 Hadoop 的大數(shù)據(jù)平臺以最小的延遲來清理、存儲并提供服務。自 2014 年以來，我們一直致力于開發(fā)一種大數(shù)據(jù)解決方案，以確保數(shù)據(jù)的可靠性、可伸縮性和易用性，目前我們正致力于提高平臺的速度和效率。
在本文中，我們將深入了解 Uber 的 Hadoop 平臺，并討論下一步如何擴展這個豐富而復雜的生態(tài)系統(tǒng)。
第一代：Uber 大數(shù)據(jù)的開端在
2014 年之前，我們有限的數(shù)據(jù)量可以塞進一些傳統(tǒng)的聯(lián)機事務處理 (OLTP) 數(shù)據(jù)庫中(例如 MySQL 和 PostgreSQL)。為了利用這些數(shù)據(jù)，我們的工程師必須單獨訪問每個數(shù)據(jù)庫或表，如果用戶想將不同數(shù)據(jù)庫的數(shù)據(jù)組合起來，需要自己編寫代碼。當時，我們還沒有對所有存儲的數(shù)據(jù)進行全局訪問的需求，也沒有這些數(shù)據(jù)的全局視圖。事實上，我們的數(shù)據(jù)分散在不同的 OLTP 數(shù)據(jù)庫中，總數(shù)據(jù)大小約為幾 TB，訪問這些數(shù)據(jù)的延遲非常短 (通常不到一分鐘)。圖 1 是我們在 2014 年之前的數(shù)據(jù)架構(gòu)概覽:
隨著 Uber 業(yè)務量呈指數(shù)級增長(業(yè)務量包括 Uber 運營的城市 / 國家數(shù)量和每個城市使用該服務的乘客 / 司機數(shù)量)，傳入數(shù)據(jù)量跟著也增加了，我們需要建立第一代分析數(shù)據(jù)倉庫，以滿足訪問和分析一個地方所有數(shù)據(jù)的需求。為了讓 Uber 盡可能接近數(shù)據(jù)驅(qū)動，我們需要確保分析師可以在同一個地方訪問分析數(shù)據(jù)。為實現(xiàn)這一目標，我們首先將數(shù)據(jù)用戶分為三大類：
城市運營團隊(數(shù)千人)：這些現(xiàn)場工作人員負責管理和擴展每個市場的運輸網(wǎng)絡。隨著業(yè)務擴展到新的城市，就有成千上萬個城市運營團隊需要定期訪問這些數(shù)據(jù)，以便對司機與乘客的問題做出響應。
數(shù)據(jù)科學家和分析師(數(shù)百人)：這些分析師和科學家分布在不同的功能組中，他們需要利用數(shù)據(jù)來幫助我們?yōu)橛脩籼峁┳罴训倪\輸和交付體驗，例如通過預測乘客需求來提供及時的服務。
工程師團隊(數(shù)百人)：整個公司的工程師都專注于構(gòu)建自動數(shù)據(jù)應用程序，比如欺詐檢測和新司機準入平臺。
我們的第一代分析數(shù)據(jù)倉庫專注于將 Uber 的所有數(shù)據(jù)聚合在一個地方以及簡化數(shù)據(jù)訪問。對于前者，我們決定使用 Vertica 作為我們的數(shù)據(jù)倉庫軟件，因為它速度快、可擴展，而且是面向列的。我們還開發(fā)了多個臨時 ETL 作業(yè)，這些作業(yè)將來自不同數(shù)據(jù)源(即 AWS S3、OLTP 數(shù)據(jù)庫、服務日志等)的數(shù)據(jù)復制到 Vertica 中。為了實現(xiàn)后者，我們將 SQL 作為我的解決方案接口，同時構(gòu)建了一個聯(lián)機查詢服務來處理用戶查詢，并將這些查詢需求提交給底層查詢引擎。圖 2 描述了我們的分析數(shù)據(jù)倉庫：
第一個數(shù)據(jù)倉庫服務的發(fā)布是一個巨大的成功。這個服務使得數(shù)據(jù)用戶第一次擁有了全局視圖，可以從一個地方訪問所有數(shù)據(jù)。這一新的突破使得大量新團隊使用數(shù)據(jù)分析作為其技術和產(chǎn)品決策的基礎。在幾個月內(nèi)，我們的分析數(shù)據(jù)量增長到數(shù)十 TB，用戶數(shù)量增加到數(shù)百個。
SQL 作為簡單的標準接口來使用，使城市運營者們能夠輕松地實現(xiàn)數(shù)據(jù)交互，無需了解底層技術。此外，不同的工程師團隊開始構(gòu)建針對用戶個性化需求定制的服務和產(chǎn)品，這些服務和產(chǎn)品通過這些數(shù)據(jù)(即 uberPool、前期定價等)得到所需信息。與此同時，陸續(xù)組建新的團隊以便更好地使用和提供這些數(shù)據(jù)(即我們的機器學習和實驗團隊)。
限制
另一方面，隨著數(shù)據(jù)倉庫和傳入數(shù)據(jù)的廣泛使用，我們也逐漸看到了一些限制。由于數(shù)據(jù)是通過臨時 ETL 作業(yè)攝取的，而我們?nèi)狈φ降哪Ｊ酵ㄐ艡C制，這導致數(shù)據(jù)可靠性成為一個問題。我們的大多數(shù)源數(shù)據(jù)都是 JSON 格式，并且攝取作業(yè)無法彈性應對生產(chǎn)者的代碼變更。
隨著公司的發(fā)展，數(shù)據(jù)倉庫擴展變得越來越昂貴。為了降低成本，我們開始刪除過時的數(shù)據(jù)，以釋放出空間留給新數(shù)據(jù)。除此之外，我們大數(shù)據(jù)平臺的很大一部分不能水平擴展，因為我們之前的主要目標是滿足對集中數(shù)據(jù)的訪問，根本沒有足夠的時間來確保所有部分都是水平可擴展的。我們的數(shù)據(jù)倉庫實際上被用作數(shù)據(jù)湖，堆積所有原始數(shù)據(jù)，執(zhí)行數(shù)據(jù)建模和提供數(shù)據(jù)。
此外，由于生成數(shù)據(jù)的服務與下游數(shù)據(jù)消費者之間缺乏正式合約，將數(shù)據(jù)攝入至數(shù)據(jù)倉庫的 ETL 作業(yè)非常不穩(wěn)定(使用靈活的 JSON 格式導致源數(shù)據(jù)缺乏模式約束)。如果不同的用戶在攝取期間執(zhí)行不同的轉(zhuǎn)換，可能會多次攝取同一批數(shù)據(jù)。這對上游數(shù)據(jù)源(即聯(lián)機存儲數(shù)據(jù))造成了額外的壓力，也影響了它們的服務質(zhì)量。另外，這導致我們的倉庫中存儲了相同數(shù)據(jù)的幾個副本，進一步增加了存儲成本。至于數(shù)據(jù)質(zhì)量，由于 ETL 作業(yè)是臨時的，并且依賴數(shù)據(jù)源，而且數(shù)據(jù)投射和轉(zhuǎn)換是在攝取期間進行的，所以回填非常耗費時間和精力。由于攝取工作缺乏標準化，我們也很難攝取任何新的數(shù)據(jù)集和類型。
第二代：Hadoop 的到來
為了解決這些限制，我們圍繞 Hadoop 生態(tài)系統(tǒng)重新構(gòu)建了大數(shù)據(jù)平臺。具體來說，我們引入了一個 Hadoop 數(shù)據(jù)湖，所有的原始數(shù)據(jù)僅需要從不同的聯(lián)機數(shù)據(jù)存儲中攝取一次，并且在攝取期間沒有進行轉(zhuǎn)換。這種設計轉(zhuǎn)變明顯降低了聯(lián)機數(shù)據(jù)存儲的壓力，讓我們從臨時攝取作業(yè)轉(zhuǎn)變?yōu)榭蓴U展的攝取平臺。為了讓用戶能夠訪問 Hadoop 中的數(shù)據(jù)，我們引入了 Presto 來實現(xiàn)交互式臨時用戶查詢，引入 Apache Spark 來促進對原始數(shù)據(jù)(包括 SQL 和非 SQL 兩種格式)的編程訪問，并將 Apache Hive 作為主力來應對非常大的查詢。這些不同的查詢引擎讓用戶可以獲得最能滿足其需求的工具，這也使得我們的平臺變得更加靈活和易于訪問。
為了保持平臺的可擴展性，我們確保所有數(shù)據(jù)建模和轉(zhuǎn)換僅在 Hadoop 中進行，從而在出現(xiàn)問題時能夠進行快速的回填和恢復。只有最關鍵的建模表(城市運營者們實時利用這些表來實現(xiàn)快速的 SQL 查詢)才被轉(zhuǎn)移到我們的數(shù)據(jù)倉庫中。這大大降低了數(shù)據(jù)倉庫的運營成本，同時還將用戶引導到基于 Hadoop 的查詢引擎。
我們還利用了 Apache Parquet 這個標準的列式文件格式，提高了壓縮率，從而節(jié)省了存儲空間，同時因為分析查詢采用了列式訪問，從而獲得了計算資源收益。此外，Parquet 與 Apache Spark 的無縫集成使得該解決方案成為訪問 Hadoop 數(shù)據(jù)的流行選擇。圖 3 總結(jié)了我們的第二代大數(shù)據(jù)平臺的架構(gòu)：
除了整合 Hadoop 數(shù)據(jù)湖之外，我們還讓生態(tài)系統(tǒng)中的所有數(shù)據(jù)服務都可以水平擴展，從而提高了大數(shù)據(jù)平臺的效率和穩(wěn)定性。這種通用的水平可擴展性可以滿足直接的業(yè)務需求，讓我們能夠集中精力構(gòu)建下一代數(shù)據(jù)平臺，而不是解決臨時問題。
與第一代平臺不同的是，數(shù)據(jù)管道易受上游數(shù)據(jù)格式變更影響的問題將不復存在，我們的第二次迭代使得我們可以對所有數(shù)據(jù)進行模式化，從 JSON 轉(zhuǎn)換到 Parquet，將模式和數(shù)據(jù)存儲在一起。為此，我們構(gòu)建了一個集中模式服務來收集、存儲和提供模式，還提供了不同的客戶端庫，用于將不同的服務與這個集中式服務集成在一起。不穩(wěn)定的臨時數(shù)據(jù)攝取作業(yè)被標準平臺替換，以便將原始嵌套格式的源數(shù)據(jù)傳輸?shù)?Hadoop 數(shù)據(jù)湖中。
隨著 Uber 的業(yè)務繼續(xù)以閃電般的速度擴展，我們很快就擁有了數(shù)十 PB 的數(shù)據(jù)。而且每天都有數(shù)十 TB 的新數(shù)據(jù)被添加到數(shù)據(jù)湖中，我們的大數(shù)據(jù)平臺增長到超過 10000 個 vcore，任何一天都有超過 100000 個批處理作業(yè)。這也使得我們的 Hadoop 數(shù)據(jù)湖成為所有分析 Uber 數(shù)據(jù)的事實來源。
限制
隨著公司的不斷擴展，我們的生態(tài)系統(tǒng)中存儲了數(shù)十 PB 的數(shù)據(jù)，我們不得不面臨一系列新的挑戰(zhàn)。
首先，由于需要攝取更多數(shù)據(jù)以及有更多用戶編寫臨時批處理作業(yè)(生成更多輸出數(shù)據(jù))，存儲在 HDFS 中的大量小文件開始給 HDFS NameNode 帶來額外的壓力。最重要的是，數(shù)據(jù)延遲仍然遠遠滿足不了我們的業(yè)務需求。用戶 24 小時內(nèi)只能訪問一次新數(shù)據(jù)，這對于需要做出實時決策的用戶來說太慢了。雖然將 ETL 和建模遷移到 Hadoop 使得處理過程更具可擴展性，但因為這些 ETL 作業(yè)每次運行時都必須重新創(chuàng)建整個建模表，處理過程仍然存在瓶頸。除此之外，新數(shù)據(jù)的攝取和相關派生表的建模都基于整個數(shù)據(jù)集的快照，然后通過交換舊表和新表讓用戶能夠訪問新數(shù)據(jù)。攝取作業(yè)必須返回源數(shù)據(jù)存儲，創(chuàng)建新快照，然后在每次運行期間將整個數(shù)據(jù)集攝取或轉(zhuǎn)換為可消費的 Parquet 文件。隨著我們的數(shù)據(jù)存儲量的增長，運行 1000 個多 Spark 作業(yè)可能需要 20 多個小時。
每個作業(yè)的很大一部分都涉及將最新的快照轉(zhuǎn)換為歷史數(shù)據(jù)和新數(shù)據(jù)。雖然每個表每天只添加 100 多 GB 新數(shù)據(jù)，但攝取作業(yè)每次在運行時都必須轉(zhuǎn)換 100 多 TB 的數(shù)據(jù)集。對于每次運行時都會重新創(chuàng)建新派生表的 ETL 和建模作業(yè)來說也是如此。由于歷史數(shù)據(jù)的更新比例很高，這些作業(yè)必須依賴基于快照的源數(shù)據(jù)攝取。從本質(zhì)上講，我們的數(shù)據(jù)包含許多更新操作(例如乘客和司機評級、支持在行程結(jié)束后的幾個小時甚至幾天內(nèi)的票價調(diào)整)。由于 HDFS 和 Parquet 不支持數(shù)據(jù)更新，所有攝取作業(yè)都需要從更新的源數(shù)據(jù)創(chuàng)建新快照，再將新快照攝取到 Hadoop 中，并轉(zhuǎn)換為 Parquet 格式，然后交換輸出表以查看新數(shù)據(jù)。圖 4 總結(jié)了這些基于快照的攝取在我們的大數(shù)據(jù)平臺中是如何流轉(zhuǎn)的。
第三代：長期重建我們的大數(shù)據(jù)平臺
到 2017 年初，整個公司的工程和運營團隊都在使用我們的大數(shù)據(jù)平臺，讓他們能夠從一個地方訪問新數(shù)據(jù)或歷史數(shù)據(jù)。用戶可以通過 UI 門戶(根據(jù)他們的個性化需求進行定制)輕松訪問 Hive、Presto、Spark、Vertica、Notebook 和其他數(shù)據(jù)倉庫中的數(shù)據(jù)。我們的 HDFS 中有 100 多 PB 的數(shù)據(jù)，計算集群中有 100000 多 vcore，每天有 100000 個 Presto 查詢，10000 個 Spark 作業(yè)，以及 20000 個 Hive 查詢，我們的 Hadoop 架構(gòu)因此遇到了擴展瓶頸，很多服務受到了數(shù)據(jù)延遲的影響。
幸運的是，由于我們的底層基礎設施可以水平擴展，以滿足當前的業(yè)務需求，因此我們有足夠的時間來研究數(shù)據(jù)內(nèi)容、數(shù)據(jù)訪問模式和用戶特定需求，以便在構(gòu)建下一代數(shù)據(jù)平臺之前找出亟待解決的問題。我們發(fā)現(xiàn)了以下四個主要的痛點：
• HDFS 可擴展性限制：很多依賴 HDFS 擴展其大數(shù)據(jù)基礎設施的公司都面臨這個問題。從設計上來看，HDFS 的瓶頸是 NameNode 容量，因此存儲大量小文件會對性能產(chǎn)生顯著影響。當數(shù)據(jù)大小超過 10PB 時就會遇到擴展瓶頸，當數(shù)據(jù)大小超過 50-100PB 以后這個限制將會成為一個真正的問題。幸運的是，有一些相對簡單的解決方案可以將 HDFS 從幾十個 PB 擴展到幾百個 PB，例如利用 ViewFS 和 HDFS NameNode Federation。通過控制小文件的數(shù)量，并將數(shù)據(jù)的不同部分移動到單獨的集群(例如將 HBase 和 Yarn 的應用程序日志移動到一個單獨的 HDFS 集群中)，HDFS 的可擴展性問題得到了一定緩解。
• Hadoop 中更快的數(shù)據(jù)： Uber 的業(yè)務是實時運營的，所以我們的服務需要訪問盡可能新鮮的數(shù)據(jù)。因此，在很多實際運營場景中，24 小時的數(shù)據(jù)延遲太慢了，這些實際場景對更快的數(shù)據(jù)傳輸存在巨大需求。我們的第二代大數(shù)據(jù)平臺所采用的基于快照的攝取方法效率低下，導致我們不能以較低的延遲攝取數(shù)據(jù)。為了加快數(shù)據(jù)交付速度，我們不得不重新設計管道，以便只進行更新數(shù)據(jù)和新數(shù)據(jù)的增量攝取。
• 支持 Hadoop 和 Parquet 的更新和刪除： Uber 的數(shù)據(jù)包含很多更新，變化范圍從過去幾天(例如乘客或者合作司機調(diào)整最近一次行程的價格)到過去幾周(例如乘客開啟新一次行程前對上一次行程進行打分)甚至過去幾個月不等(例如由于業(yè)務需要回填或調(diào)整過去的數(shù)據(jù))。通過基于快照的數(shù)據(jù)攝取，我們每 24 小時攝取一次源數(shù)據(jù)的新副本。換句話說，我們一次攝取所有更新，每天攝取一次。但是，由于需要攝取更新的數(shù)據(jù)和增量，我們的解決方案必須能夠支持現(xiàn)有數(shù)據(jù)的更新和刪除操作。然而，由于我們的數(shù)據(jù)存儲在 HDFS 和 Parquet 中，無法直接支持對現(xiàn)有數(shù)據(jù)的更新操作。另一方面，我們的數(shù)據(jù)包含非常寬的表(每個表大約有 1000 個列)，這些表有五個及五個以上級別的嵌套，而用戶查詢通常只需接觸其中一些列，這導致我們不能以高效的方式使用非列式格式。為了使我們的大數(shù)據(jù)平臺能夠?qū)崿F(xiàn)長期增長，我們必須找到一種方法來解決 HDFS 文件系統(tǒng)的這種限制，讓它也可以支持更新 / 刪除操作。
• 更快的 ETL 和建模：與原始數(shù)據(jù)攝取類似，ETL 和建模作業(yè)也基于快照，需要我們的平臺在每次運行時重建派生表。為減少建模表的數(shù)據(jù)延遲，ETL 作業(yè)也需要利用增量。這要求 ETL 作業(yè)只需從原始源表中逐步地提取已更改的數(shù)據(jù)，并更新先前派生的輸出表，而不是每隔幾小時重建整個輸出表。
引入 Hudi
考慮到上述要求，我們構(gòu)建了 Hadoop Upserts anD Incremental (Hudi)，這是一個開源的 Spark 庫，在 HDFS 和 Parquet 之上提供抽象層，以支持所需的更新和刪除操作。Hudi 可以被用在任意的 Spark 作業(yè)中，可以水平擴展，并且只依賴 HDFS。因此，任何需要支持歷史數(shù)據(jù)更新 / 刪除操作的大數(shù)據(jù)平臺都可以使用 Hudi。
Hudi 使我們能夠在 Hadoop 中更新、插入和刪除現(xiàn)有的 Parquet 數(shù)據(jù)。此外，Hudi 使得數(shù)據(jù)用戶可以只需逐步提取更改的數(shù)據(jù)，顯著提升了查詢效率，實現(xiàn)派生建模表的增量更新。
我們 Hadoop 生態(tài)系統(tǒng)中的原始數(shù)據(jù)是根據(jù)時間劃分的，任何舊日期分區(qū)的數(shù)據(jù)都可能在之后接收到更新。因此，對于依賴這些原始源數(shù)據(jù)表的數(shù)據(jù)用戶或 ETL 作業(yè)，了解哪個日期分區(qū)包含更新數(shù)據(jù)的唯一方法是掃描整個源表，并根據(jù)一些已知的時間概念來過濾不需要的記錄。這涉及了計算成本非常高昂的查詢，需要完全掃描源表，而且不能頻繁地運行 ETL 作業(yè)。
使用 Hudi，用戶很容易知道他們的最后一個檢查點時間戳，并獲取所有已更新的記錄，無論這些更新是添加到最近日期分區(qū)的新記錄，還是對舊數(shù)據(jù)的更新，都無需運行昂貴的查詢來掃描整個源表。
使用 Hudi 庫，我們能夠從基于快照的原始數(shù)據(jù)攝取轉(zhuǎn)換成增量攝取建模，這一轉(zhuǎn)換使我們能夠?qū)?shù)據(jù)延遲從 24 小時減少到一小時之內(nèi)。圖 5 描述了整合 Hudi 后的大數(shù)據(jù)平臺：
通用數(shù)據(jù)攝取
Hudi 并不是第三代大數(shù)據(jù)平臺的唯一變化。我們還通過 Apache Kafka 實現(xiàn)了存儲和大數(shù)據(jù)團隊之間的上游數(shù)據(jù)存儲變更的交接。上游數(shù)據(jù)存儲事件(以及來自不同應用程序和服務的日志消息)使用統(tǒng)一的 Avro 編碼流入 Kafka，包括附加的標準全局元數(shù)據(jù)頭部信息(比如時間戳、row key、版本、數(shù)據(jù)中心信息和源主機)。數(shù)據(jù)流團隊和大數(shù)據(jù)團隊都使用這些存儲變更日志事件作為其源輸入數(shù)據(jù)以進行進一步處理。
我們的數(shù)據(jù)攝取平臺 Marmaray 以小批量的方式運行，并從 Kafka 獲取上游的存儲變更日志，通過 Hudi 庫將這些日志應用在 Hadoop 的現(xiàn)有數(shù)據(jù)上。如之前所述，Hudi 支持更新插入操作，允許用戶添加新記錄和更新或刪除歷史數(shù)據(jù)。Spark 攝取作業(yè)每 10-15 分鐘運行一次，在 Hadoop 中提供 30 分鐘的原始數(shù)據(jù)延遲(具有 1-2 個攝取作業(yè)失敗或重試的余量)。為避免因多次將相同的源數(shù)據(jù)攝取到 Hadoop 而導致效率低下，我們不允許在原始數(shù)據(jù)攝取期間進行任何轉(zhuǎn)換，所以我們決定將原始數(shù)據(jù)提取框架變成 EL 平臺，而不是傳統(tǒng)的 ETL 平臺。這個模型鼓勵用戶在上游數(shù)據(jù)以原始嵌套格式流入后，在 Hadoop 中以批處理模式執(zhí)行所需的轉(zhuǎn)換操作。
自從對我們的大數(shù)據(jù)平臺實施這些更改以來，我們通過避免不必要或低效的攝取操作有效地節(jié)省了大量的計算資源。由于我們現(xiàn)在可以避免在攝取過程中進行容易出錯的轉(zhuǎn)換，原始數(shù)據(jù)的可靠性也得到了顯著提升�，F(xiàn)在，用戶可以使用任何大數(shù)據(jù)處理引擎在原始源數(shù)據(jù)上運行轉(zhuǎn)換。此外，一旦出現(xiàn)任何問題，用戶可以再次重新運行轉(zhuǎn)換，并通過使用更多計算資源和更高程度的并行性來更快地完成批轉(zhuǎn)換作業(yè)，從而保證 SLA。
增量數(shù)據(jù)建模
考慮到需要將大量上游數(shù)據(jù)存儲攝入到 Hadoop 中(截至 2017 年有超過 3000 個原始 Hadoop 表)，我們還構(gòu)建了一個通用的攝取平臺，以便以統(tǒng)一和可配置的方式將原始數(shù)據(jù)攝入到 Hadoop 中�，F(xiàn)在，我們的大數(shù)據(jù)平臺以增量的方式逐步更新原始 Hadoop 表，數(shù)據(jù)延遲為 10-15 分鐘，實現(xiàn)了對源數(shù)據(jù)的快速訪問。但是，為了確保建模表也具有低延遲，我們必須避免建模 ETL 作業(yè)中的低效率操作(比如避免完全重新創(chuàng)建派生表或進行完整的源原始表掃描)。實際上，Hudi 允許 ETL 作業(yè)僅從源表中獲取已更改的數(shù)據(jù)。建模作業(yè)只需要在每次迭代運行期間告知 Hudi 閱讀器檢查點時間戳，就可以從原始源表 (不管實際記錄存儲在哪個日期分區(qū)) 接收到一組新的或更新過的記錄。
在 ETL 作業(yè)期間使用 Hudi Writer 使我們能夠更新派生建模表中的舊日期分區(qū)，而無需重新創(chuàng)建整個分區(qū)和表。因此，我們的建模 ETL 作業(yè)使用 Hudi Reader 逐步從源表中獲取已更改的數(shù)據(jù)，并使用 Hudi Writer 逐步更新派生的輸出表。現(xiàn)在，ETL 作業(yè)也能在不到 30 分鐘內(nèi)完成，Hadoop 的所有派生表的端到端延遲減少到一個小時以內(nèi)。
為了向 Hadoop 表的用戶提供訪問所有數(shù)據(jù)或僅訪問新數(shù)據(jù)或更新數(shù)據(jù)的不同選項，使用 Hudi 存儲格式的 Hadoop 原始表提供了兩種不同的讀取模式：
• 最新模式視圖：在當前時間點提供整個 Hadoop 表的整體視圖。這個視圖包括所有記錄的最新合并值以及表中的所有現(xiàn)有記錄。
• 增量模式視圖：僅根據(jù)給定時間戳從特定 Hadoop 表中獲取新記錄和更新記錄。這個視圖僅返回自最近檢查點以來最近插入的以及已更新的行。此外，如果特定行自上一個檢查點以來被多次更新，則將返回更新過程中所有更改的值(而不是僅返回最新的合并行)
圖 6 描述了所有 Hadoop 表(以 Hudi 文件格式存儲) 的這兩個讀取視圖：
標準化數(shù)據(jù)模型
除了提供同一個表的不同視圖外，我們還標準化了數(shù)據(jù)模型，為所有原始 Hadoop 數(shù)據(jù)提供兩種類型的表：
• 變更日志歷史記錄表：包含特定上游表的所有變更日志歷史記錄。這個表讓用戶能夠掃描給定表的變更歷史記錄，并且可以按照 key 進行合并，以提供每一行的最新值。
• 快照合并表：包含最新的上游表的合并視圖。這個表包含所有歷史變更日志的壓縮合并視圖。
圖 7 描述了如何使用給定變更日志流為特定上游源數(shù)據(jù)存儲生成不同的 Hive 原始表：
但是，變更日志流不一定包含給定 key 的整個行(所有列)。雖然合并的快照表始終提供特定 key 的所有列，但如果變更日志的上游流僅提供部分行變更日志，變更日志歷史表可能就比較稀疏。如果用戶希望從變更日志歷史記錄表中獲取更改的值，并將其與合并的快照表相連以創(chuàng)建完整的數(shù)據(jù)行，我們還會在變更日志歷史記錄表的合并快照表中包含相同 key 的日期分區(qū)。通過避免合并快照表的完整表掃描，使得兩個表能夠更有效地進行跨分區(qū)連接。
圖 8 總結(jié)了我們大數(shù)據(jù)平臺的不同組件之間的關系：
第四代：下一步該怎樣優(yōu)化?
自 2017 年推出第三代大數(shù)據(jù)平臺以來，整個公司的用戶已經(jīng)可以快速可靠地訪問 Hadoop 中的數(shù)據(jù)，但仍然有提升的空間。我們正在努力增強我們的大數(shù)據(jù)平臺，以改善數(shù)據(jù)質(zhì)量、數(shù)據(jù)延遲，提升效率、可擴展性和可靠性等。
數(shù)據(jù)質(zhì)量
為了提高數(shù)據(jù)質(zhì)量，我們確定了兩個需要改進的關鍵領域。首先，當某些上游數(shù)據(jù)存儲沒有強制執(zhí)行或檢查數(shù)據(jù)模式時(比如值為 JSON blob 的鍵值對)，我們希望能夠避免出現(xiàn)非相容模式的數(shù)據(jù)。不然不良數(shù)據(jù)會進入到我們的 Hadoop 生態(tài)系統(tǒng)，從而影響所有依賴這些數(shù)據(jù)的下游用戶。為了防止不良數(shù)據(jù)的流入，我們正在轉(zhuǎn)換所有上游數(shù)據(jù)存儲，對數(shù)據(jù)內(nèi)容執(zhí)行強制性模式檢查，并在數(shù)據(jù)出現(xiàn)任何問題時拒絕數(shù)據(jù)進入(比如未經(jīng)模式的確認)。
我們發(fā)現(xiàn)的第二個問題是實際數(shù)據(jù)內(nèi)容的質(zhì)量。雖然使用模式可以確保數(shù)據(jù)包含正確的數(shù)據(jù)類型，但它們不會檢查實際的數(shù)據(jù)值 (比如一個整數(shù)，但不是 0 到 150 之間的正數(shù))。為了提高數(shù)據(jù)質(zhì)量，我們正在擴展模式服務以支持語義檢查。這些語義檢查 (也就是指 Uber 特定數(shù)據(jù)類型) 使得我們能夠在基本結(jié)構(gòu)類型檢查之外對實際數(shù)據(jù)內(nèi)容添加額外的限制。
數(shù)據(jù)延遲
我們的目標是將 Hadoop 中的原始數(shù)據(jù)延遲減少到五分鐘，將建模表的數(shù)據(jù)延遲減少到十分鐘。這將使得更多用例從流式處理轉(zhuǎn)向使用 Hudi 增量數(shù)據(jù)攝取的更有效的小批量處理。
同時，我們還在擴展我們的 Hudi 項目，以支持其他視圖模式，其中包括現(xiàn)有的讀取優(yōu)化視圖，以及顯示數(shù)據(jù)延遲僅幾分鐘的實時視圖。這個實時視圖依賴于我們稱之為 Merge-On-Read 或 Hudi 2.0 的開源解決方案(也是 Hudi 的一部分)。
數(shù)據(jù)效率
為了提高數(shù)據(jù)效率，我們不再依賴專用硬件來實現(xiàn)任何服務，轉(zhuǎn)向了服務容器化。此外，我們統(tǒng)一了所有資源調(diào)度程序和 Hadoop 生態(tài)系統(tǒng)，在整個公司內(nèi)部搭建 Hadoop 和非數(shù)據(jù)服務之間的橋梁。這樣我們就可以統(tǒng)一調(diào)度所有作業(yè)和服務，不用管它將運行在什么樣的介質(zhì)中。隨著 Uber 的發(fā)展，數(shù)據(jù)位置將成為 Hadoop 應用程序的一大關注點，一個成功的統(tǒng)一資源管理器可以將所有現(xiàn)有的調(diào)度程序集中在一起(比如 Yarn、Mesos 和 Myriad)。
可擴展性和可靠性
在努力改善平臺可擴展性和可靠性的過程中，我們發(fā)現(xiàn)了與可能的邊界情況相關的幾個問題。雖然我們的攝取平臺是基于通用的可插拔模型，但實際攝取上游數(shù)據(jù)仍然包括了許多依賴于源的管道配置，使得攝取管道并不穩(wěn)定，并且增加了維護這數(shù)千個管道的成本。
為了確保我們可以在不用管數(shù)據(jù)來源的情況下統(tǒng)一數(shù)據(jù)攝取，我們與 Uber 的數(shù)據(jù)存儲團隊合作啟動了一個項目，在不管技術構(gòu)成的情況下，統(tǒng)一所有上游數(shù)據(jù)源的變更日志的內(nèi)容、格式和元數(shù)據(jù)。該項目將確保有關這些特定上游技術的信息只是添加到實際變更日志值的附加元數(shù)據(jù)(而不是產(chǎn)生形成不同的變更日志內(nèi)容或不同數(shù)據(jù)源的元數(shù)據(jù))，并且確保無論上游源是什么，都要進行數(shù)據(jù)攝取。
最后，下一版 Hudi 將幫助我們在幾分鐘內(nèi)為所有數(shù)據(jù)源生成更大的 Parquet 文件(相比于我們當前的 128MB 來說，將超過 1GB)。它還將消除更新與插入的比值帶來的任何敏感性。Hudi 1.0 依賴 copy-on-write 技術，只要有更新的記錄，它就會重寫整個源 Parquet 文件。這明顯增大了寫入量，特別是當更新與插入比率增加，阻止在 HDF 中創(chuàng)建更大的 Parquet 文件時。Hudi 的新版本旨在克服這個限制，將更新的記錄存儲在單獨的增量文件中，并基于給定策略將其與基礎 Parquet 文件異步合并。如果將 Hadoop 數(shù)據(jù)存儲在較大的 Parquet 文件中以及更可靠的源獨立數(shù)據(jù)攝取平臺，我們的分析數(shù)據(jù)平臺將在未來幾年隨著業(yè)務的發(fā)展而繼續(xù)增長。
英文原文：
https://eng.uber.com/uber-big-data-platform/
標簽： Mysql 安全 大數(shù)據(jù) 大數(shù)據(jù)處理 大數(shù)據(jù)基礎 大數(shù)據(jù)平臺 代碼 數(shù)據(jù)分析 數(shù)據(jù)庫 通信 網(wǎng)絡
版權(quán)申明：本站文章部分自網(wǎng)絡，如有侵權(quán)，請聯(lián)系：west999com@outlook.com
特別注意：本站所有轉(zhuǎn)載文章言論不代表本站觀點！
本站所提供的圖片等素材，版權(quán)歸原作者所有，如需使用，請與原作者聯(lián)系。
