100+PB資料分鐘級延遲：Uber大資料平臺介紹
點選“藍字”關注我們
文章來源 | Uber官方部落格
作者 | Reza Shiftehfar
翻譯 | 歐高炎
Uber致力於在全球市場提供更安全和可靠的交通服務。為實現這一目標，Uber在各個層面都依靠資料驅動的決策，從高流量事件期間的乘客需求預測到司機簽約流程中的瓶頸識別和解決。Uber逐漸需要在基於Hadoop的大資料平臺上以最低的延遲對超過100PB的資料進行清洗、儲存和服務，以便獲得更豐富的洞察。從2014年開始開發大資料解決方案，確保資料可靠性、可擴充套件性和易用性。如今，Uber專注於提高大資料平臺的響應速度和執行效率。
在本文中，將對Uber的Hadoop平臺進行全面解析，並討論Uber下一步如何對這個豐富而複雜的生態系統進行擴充套件。
第1代：Uber的大資料開始
在2014年之前，Uber擁有的資料量還可以通過傳統的聯機事務處理過程資料庫（例如MySQL和PostgreSQL）來處理。工程師必須單獨訪問每個資料庫或表，通過編寫程式碼來整合不同資料庫中的資料。當時，Uber還沒有儲存的所有資料的全域性檢視。實際上，Uber的資料分散在不同的OLTP資料庫中，總的資料級為若干TB，訪問這些資料的延遲非常低（通常是亞分鐘級）。下面的圖1概述了2014年之前的資料架構。
圖1：2014年之前，Uber儲存的資料總量較小，可以使用傳統OLTP資料庫進行管理。沒有資料的全域性檢視，直接查詢對應資料庫處理資料，資料訪問速度很快。
隨著Uber的業務呈指數級增長（運營城市/國家數量和乘客/司機數量），傳入資料量也隨之增加。在同一個平臺處理和分析資料的需求推動我們建立第一代分析資料倉庫。為了使Uber儘可能地基於資料驅動來決策，需要確保分析師在同一個地方訪問資料。為實現這一目標，首先將資料使用者分為以下三大類：
1.城市運營團隊（數千名使用者）：這些實地工作人員管理和擴充套件Uber在每個市場的運輸網路。隨著Uber的業務擴充套件到新城市，有成千上萬的城市運營團隊定期訪問這些資料，以響應與司機和乘客相關的問題。
2.資料科學家和資料分析師（數百名使用者）：這些分析師和科學家分佈在不同的功能組中，幫助Uber為使用者提供最佳的交通工具和乘車體驗。例如，預測乘車人需求以提供前瞻性的服務。
3.工程團隊（數百名使用者）：整個公司的工程師專注於構建自動資料應用，例如欺詐檢測和司機適職平臺。
Uber的第一代分析資料倉庫專注於將所有資料集中在同一個地方以及統一資料訪問。對於前者，Uber決定使用Vertica作為我們的資料倉庫軟體，因為它快速，可擴充套件性高和麵向列的儲存設計。Uber還開發了多個專用的ETL作業從不同的來源（即AWS S3，OLTP資料庫，服務日誌等）將資料複製到Vertica中。為了實現後者，Uber將SQL確定為我們的標準化介面，並構建了一個線上查詢服務來接受使用者查詢並將它們提交給底層查詢引擎。圖2描述了這個分析資料倉庫：
圖2：Uber第一代大資料平臺將資料集中到一起並提供標準的SQL介面來訪問資料。
第一代資料倉庫服務的釋出對整個公司的工程師來說都是一個巨大的成功。使用者第一次擁有全域性檢視，可以在一個地方訪問所有資料。大量新團隊使用資料分析作為其技術和產品決策的基礎。在幾個月內，Uber的分析資料量增長到數十TB，使用者數量增加到數百。
使用SQL作為簡單的標準介面，讓城市運營者能夠輕鬆地與資料互動，而無需瞭解底層技術。此外，不同的工程團隊開始針對使用者需求構建基於資料的服務和產品（例如uberPool，前期定價等）提供資訊。Uber也組建了新的團隊以更好地使用和提供這些資料（例如我們的機器學習和實驗團隊）。
侷限性
另一方面，Uber對資料倉庫和接入資料的廣泛使用也暴露出一些侷限性。由於資料是通過專用ETL作業提取的，因而缺乏正式的模式通訊機制，因此資料可靠性成為一個問題。Uber的大多數源資料都是JSON格式，並且資料提取作業對生產者程式碼的更改沒有彈性。
隨著公司的發展，擴充套件資料倉庫的代價越來越昂貴。為了降低成本，Uber開始刪除舊的和過時的資料，以釋放空間儲存新資料。其次，Uber的大資料平臺大部分無法進行水平擴充套件。這是因為平臺的主要目標是為關鍵業務解決集中資料訪問或查詢的需求，根本沒有足夠的時間來確保平臺的所有部分都是水平可擴充套件的。Uber的資料倉庫實際上被用作資料湖，堆積所有原始資料以及執行所有資料建模和服務資料。
此外，由於生成資料的服務與下游資料消費者之間缺乏正式的約定，將輸入匯入資料倉庫的ETL作業也非常脆弱（使用靈活的JSON格式導致源資料缺少模式保證）。相同的資料可能會被提取多次，如果使用者在提取資料時對資料進行了不同的轉換。這對我們的上游資料來源（即線上資料儲存）造成了額外的壓力，並對服務質量產生負面影響。此外，這導致資料倉庫需要儲存幾乎相同的資料的多個副本，進一步增加了儲存代價。因為ETL作業是專用和源依賴的，且會對資料進行對映和轉換，一旦資料質量存在問題，回填會非常耗時耗力。由於資料提取工作缺乏標準化，因此很難提取新的資料集和型別。
第2代：Hadoop的到來
為了突破這些侷限性，Uber圍繞Hadoop生態系統重構了大資料平臺。更具體地說，我們引入了一個Hadoop資料湖，原始資料僅從線上資料儲存中提取一次，並且在提取期間沒有轉換。這種設計轉變顯著降低了線上資料儲存的壓力，Uber能夠從專用提取作業轉變為可擴充套件的提取平臺。為了讓使用者能夠訪問Hadoop中的資料，引入了Presto來實現互動式使用者專用查詢。Apache Spark提供原始資料（同時支援SQL和non-SQL格式）的程式設計訪問，Apache Hive用來支援超大查詢任務。使用者可以根據其需要來選擇最合適的查詢引擎，平臺變得更加靈活和易於訪問。
為了保持平臺的高可擴充套件性，確保所有資料建模和轉換僅在Hadoop中進行，從而在出現問題時實現快速回填和恢復。只有最關鍵的建模表（即城市運營者實時利用這些表來執行純粹快速的SQL查詢）才被轉移到我們的資料倉庫。這大大降低了執行資料倉庫的運營成本，同時還將使用者引導到基於Hadoop的查詢引擎，這些查詢引擎的設計考慮了他們的特定需求。
Uber還利用了Apache Parquet的標準列式檔案格式，通過提供列式訪問和分析查詢，提高了壓縮率和計算資源收益，從而節省了儲存空間。此外，Parquet與Apache Spark的無縫整合使該解決方案成為訪問Hadoop資料的流行選擇。圖3總結了第二代大資料平臺的架構：
圖3：第二代大資料平臺利用Hadoop實現水平擴充套件。結合Parquet，Spark和Hive等技術，提供數十PB資料的提取、儲存和服務。
除了引入Hadoop資料湖之外，該生態系統中所有資料服務都可以水平擴充套件，從而提高了Uber的大資料平臺的效率和穩定性。這種通用的水平可擴充套件性可以滿足直接的業務需求，使Uber能夠集中精力構建不僅僅支援特定問題的下一代資料平臺。
Uber的第一代大資料平臺容易受上游資料格式更改的影響，第二代大資料平臺允許對所有資料進行模式化。從JSON過渡到Parquet，將資料模式和資料同時儲存。為此，Uber構建了一箇中央模式服務來支援模式收集、儲存和服務。同時提供不同的客戶端庫將不同的服務整合到此中央模式服務中。脆弱的專用資料提取作業被替換為標準平臺，將原始巢狀格式源資料傳輸到Hadoop資料湖中。對資料的所有操作和轉換都在資料提取後，通過Hadoop平臺上的水平可擴充套件的批作業來完成。
隨著Uber的業務持續快速發展，Uber很快就擁有了數十PB的資料。每天都有數十TB的新資料被新增到資料湖中，大資料平臺增長到超過10,000個vcores，每天執行的批處理作業超過100,000個。Hadoop資料湖成為所有分析Uber資料的核心事實來源。
侷限性
隨著公司不斷擴充套件，Uber的生態系統中儲存了數十PB的資料，Uber又面臨著一系列新的挑戰。
首先，儲存在HDFS檔案系統中的大量小檔案（由於更多資料被提取以及更多使用者編寫的專用批處理作業生成更多的輸出資料）給HDFS的名位元組點（NameNode）帶來增加額外的壓力。此外，資料延遲仍然遠遠無法滿足業務需求。使用者只能每24小時訪問一次新資料，這對於實時決策來說太慢了。將ETL和建模轉移到Hadoop使得這個過程更具可擴充套件性，但依然存在瓶頸，因為ETL作業在每次執行中重新建立整個建模表。除此之外，新資料的提取和相關派生表的建模都基於建立整個資料集的新快照並交換舊錶和新表以向用戶提供對新資料的訪問。提取作業必須返回源資料儲存區，建立新快照，並在每次執行期間將整個資料集提取或轉換為列式的Parquet檔案。隨著資料儲存量的增長，在1000個節點的Spark叢集上，這些作業可能需要超過20個小時才能執行完成。
每個作業的大部分工作在從最新快照中轉換歷史資料和新資料。雖然每個表每天只新增100GB左右的新資料，但提取作業都必須轉換整個100 TB的資料表。對於在每次執行中重新建立新派生表的ETL和建模作業也是如此。這些作業必須依賴基於快照的源資料提取，因為歷史資料的更新比例很高。從本質上講，我們的資料包含許多更新操作（例如乘客和司機評分或支援訂單完成的數小時或數天內的票價調整）。由於HDFS和Parquet不支援資料更新，提取作業需要從更新的源資料建立新快照、將新快照存到Hadoop、轉換成Parquet格式、交換輸出表以檢視新資料。圖4總結了這些基於快照的資料如何通過我們的大資料平臺移動：
圖4：雖然Hadoop支援PB級的資料儲存，新資料的延遲仍然超過一天，這是由於基於快照的大型上游源表提取需要花費數小時來處理。
第3代：為長期計劃重建Uber的大資料平臺
到2017年初，Uber的大資料平臺被整個公司的工程和運營團隊使用，使他們能夠在同一個地方訪問新資料和歷史資料。使用者可以通過同一個UI門戶輕鬆訪問Hive，Presto，Spark，Vertica，Notebook等平臺中的資料。Uber的計算叢集中有超過100 PB的資料和100000個vcores。每天支援100,000個Presto查詢，10,000個Spark作業，以及20,000個Hive查詢。Uber的Hadoop分析架構遇到了可擴充套件性限制，許多服務受到高資料延遲的影響。
幸運的是，Uber的底層基礎架構可以水平擴充套件以滿足當前的業務需求。因此有足夠的時間研究資料內容，資料訪問模式和使用者特定需求，以便在構建下一代之前確定最緊迫的問題。研究揭示了四個主要的痛點：
1.HDFS可擴充套件性限制：許多依賴HDFS擴充套件其大資料基礎架構的公司都面臨著這個問題。根據設計，NameNode容量是HDFS的瓶頸，因此儲存大量小檔案會顯著影響效能。當資料量超過10PB時這種影響會發生；當資料量超過50-100PB時，問題會十分嚴重。有一些相對簡單的解決方案可以將HDFS從幾十PB擴充套件到幾百PB，例如利用ViewFS和使用HDFS NameNode聯盟。通過控制小檔案的數量並將資料的不同部分移動到單獨的叢集（例如HBase和Yarn應用程式日誌移動到單獨的HDFS叢集中），能夠減輕此HDFS限制。
2.Hadoop中更快的資料：Uber的業務實時運營，因此，Uber的服務需要訪問儘可能新鮮的資料。因此，對於許多用例而24小時的資料延遲太慢了，因此對更快的資料傳輸存在巨大需求。Uber的第二代大資料平臺中的基於快照的提取方法效率低下，無法以較低的延遲提取資料。為了加快資料分發速度，不得不重新設計流水線，以便增量提取更新資料和新資料。
3.Hadoop和Parquet中的更新和刪除支援：Uber的資料包含很多更新，從數天（例如乘客或司機調整最近行程價格）到數週（乘客對上一次行程進行評分）甚至數月（由於業務需要的資料回填和歷史資料更新）。在基於快照的資料提取中，每24小時提取一次源資料的新副本。換句話說，Uber一次提取所有更新，每天進行一次。但是，由於需要更新的資料和增量提取，解決方案必須能夠支援現有資料的更新和刪除操作。但是，由於大資料儲存在HDFS和Parquet中，因此無法直接支援對現有資料的更新操作。另一方面，資料包含非常寬的表（大約1000列的表），使用者查詢中往往包含5層或以上的巢狀查詢，這些查詢只涉及寬表中的少數列。這讓Uber很難高效處理非列式格式資料。為了使大資料平臺應對長期的資料增長，必須找到一種方法來解決HDFS檔案系統中的這種限制，以便可以支援更新/刪除操作。
4.更快的ETL和建模：與原始資料提取類似，ETL和建模作業都是基於快照的，使得Uber的平臺在每次執行中都要重建派生表。為減少建模表的資料延遲，ETL作業也需要支援增量操作。這要求ETL作業逐步從原始源表中提取已更改的資料，並更新先前派生的輸出表，而不是每隔幾小時重建整個輸出表。
介紹Hudi
為了滿足上述要求（突破HDFS水平擴充套件限制、加快Hadoop資料處理速度、在Hadoop和Parquet中支援資料更新和刪除、實現更快的ETL和建模），Uber構建Hudi（HadoopUpserts andIncremental）。Hudi是一個開源Spark庫，在HDFS和Parquet之上提供一個抽象層來支援更新和刪除操作。Hudi可以在任何Spark作業中使用，可以水平擴充套件，並且其執行只依賴於HDFS。因此，Hudi可以對任意大資料平臺進行擴充套件，以支援對歷史資料的更新和刪除操作。
Hudi使Uber能夠在Hadoop中更新、插入和刪除現有的Parquet資料。此外，Hudi允許資料使用者增量地提取更新的資料，顯著提升了查詢效能，同時支援對派生建模表的增量更新。
Uber的Hadoop生態系統中的原始資料是根據時間劃分的，任何舊分割槽都可能在以後接收更新請求。因此，對於依賴於這些原始源資料表的資料使用者或ETL作業，瞭解哪個日期分割槽包含更新資料的唯一方法是掃描整個源表並根據已有知識來過濾資料。更加麻煩的是，這些計算代價昂貴的查詢操作的執行頻率還非常高。
有了Hudi，使用者可以簡單地傳遞最近檢查點時間戳，並檢索該時間戳之後更新的資料，而無需執行掃描整個源表的昂貴查詢。更新的資料包括新增到最近日期分割槽的新記錄和對舊資料的更新（例如，今天發生的新行程和對6個月前某個行程資料的更改）。
使用Hudi庫，Uber的資料提取模式從基於源資料快照的模式轉換到增量的提取的模式，資料延遲從24小時減少到不到1小時。圖5描述了集成了Hudi的大資料平臺：
圖5：第三代大資料平臺採取了更快的增量資料提取模式（使用開源Marmaray框架）和更高效的儲存和資料服務（使用開源Hudi庫）。
通用資料提取
Hudi並不是Uber第三代大資料平臺的唯一補充。Uber還通過ApacheKafka處理儲存和大資料團隊之間對上游資料庫的更改。上游資料庫事件（以及不同應用和服務的傳統日誌訊息）使用統一的Avro編碼（包括標準的全域性源資料頭資訊，例如時間戳、行鍵、版本、資料中心資訊和發起主機）流入Kafka。Streaming團隊和大資料團隊都使用這些儲存更改日誌事件作為其源輸入資料以進行進一步處理。
Uber的資料提取平臺Marmaray以小批量執行並從Kafka提取上游儲存更改日誌，使用Hudi庫在Hadoop的現有資料上執行更改。前面已經提到，Hudi支援upsert操作，允許使用者新增新記錄並更新或刪除歷史資料。Spark上的提取作業每10-15分鐘執行一次，Hadoop中原始資料延遲約為30分鐘（考慮到1-2個提取作業失敗或者重啟）。為避免因多次將相同的源資料提取到Hadoop而導致效率低下，禁止在提取期間對資料進行任何轉換。Uber的原始資料提取框架實際上成了EL平臺，而不是傳統的ETL平臺。在此模型下，鼓勵使用者在上游資料以其原始巢狀格式到達後，在Hadoop中以批處理的模式進行轉換操作。
自從對Uber的大資料平臺實施這些更改以來，由於避免了不必要和低效的提取操作，我們節省了大量的計算資源。因為現在可以避免在提取過程中易於出錯的轉換，原始資料的可靠性也得到了顯著提高。現在，使用者可以在原始源資料的上層通過任何大資料引擎進行資料轉換。此外，如果出現任何問題，使用者可以重新執行其轉換。同時可以通過使用更多計算資源和更高的程度並行性來更快地完成批轉換作業，以滿足使用者服務協議。
增量資料建模
考慮到需要從上游資料儲存中提取大量資料進Hadoop（截至2017年超過3,000個原始Hadoop表），Uber還構建了一個通用提取平臺。在這個平臺中，以統一和可配置的方式將原始資料提取到Hadoop中。大資料平臺增量地更新Hadoop表，能夠快速地訪問源資料（資料延遲為10-15分鐘）。但是，為了確保建模表也具有低延遲，必須避免建模的ETL作業中的低效操作（例如完全派生表複製或完整掃描原始資料資料表）。實際上，Hudi允許ETL作業僅從原始表中提取已更改的資料。建模作業僅僅需要在每一步迭代執行過程中給Hudi傳入一個檢查點時間戳，就可以從原始表中獲取新的或更新的資料流（不用管日期分割槽資料實際儲存在哪裡）。
在ETL作業中使用Hudi寫入器（Hudi Writer），可以直接在派生建模表直接對舊分割槽和表進行更新，而無需重新建立整個分割槽或表。因此，建模ETL作業使用Hudi讀取器增量地從源表中提取已更改的資料，並使用Hudi寫入器增量地更新派生的輸出表。現在，ETL作業可以在30分鐘內完成，Hadoop中的所有派生表都僅有1小時以內的端到端延遲。
為了向Hadoop表的資料使用者提供訪問所有資料/新資料/更新資料的多種選項，使用Hudi儲存格式的Hadoop原始表提供了兩種不同的讀取模式：
1.最新模式檢視。提供特定時間點Hadoop表的整體檢視。此檢視包括所有記錄的最新合併值以及表中的所有現有記錄。
2.增量模式檢視。從特定Hadoop表中提取給定時間戳以後的新記錄和更新記錄。此檢視僅返回自最近檢查點以來最近插入或已更新的行。此外，如果特定行自上一個檢查點以來被多次更新，則此模式將返回所有這些中間更改的值（而不是僅返回最新的合併行）
圖6描述了所有以Hudi檔案格式儲存的Hadoop表的這兩個讀取檢視：
圖6：通過Hudi寫入器更新的原始表有兩種不同的讀取模式：最新模式檢視返回所有記錄的最新值；增量模式檢視僅返回自上次讀取後更新的記錄。
使用者通常根據需要在這兩種表檢視之間進行切換。使用專用查詢基於最新狀態分析資料時，他們會採用最新模式檢視（例如提取美國每個城市的每週總旅行次數）。另一方面，當用戶有一個迭代作業或查詢僅僅需要獲取自上次執行後的更新資料或新資料時，他們會使用增量模式檢視。對於所有的Hadoop表，上面兩種檢視都是隨時可用的，使用者可以根據需要在兩種模式之間進行切換。
標準化資料模型
除了提供同一個表的不同檢視外，Uber還對資料模型進行了標準化。對所有原始Hadoop資料，提供以下兩種型別的表：
1.更改日誌歷史記錄表。包含為特定上游表收到的所有更改日誌的歷史記錄。此表使使用者能夠掃描給定表的更改歷史記錄，並且可以按鍵合併以提供每行的最新值。
2.合併快照表。包含上游表的最新合併檢視。此表包含每一個鍵接受的所有歷史更改日誌的壓縮合並檢視。
圖7描述瞭如何使用給定更改日誌流為特定上游源資料生成不同的Hive原始表：
圖7：對Hive資料模型的標準化大大改善了整個大資料生態系統的資料質量。此模型包含一個合併的快照表，其中包含每個row_key的最新值和每個row_key的歷史變更記錄。
然而，更新日誌流可能不包含給定鍵的整個行（所有列）。雖然合併的快照表始終提供特定鍵的所有列，更新日誌歷史表則可能是稀疏的，因此可以通過避免傳送整行來提高效率。如果使用者希望從更新日誌歷史記錄表中提取更改的值並將其與合併的快照表連線以建立完整的資料行，還會在更新日誌歷史記錄表中的合併快照表中包含相同鍵的日期分割槽。
圖8顯示了Uber的大資料平臺的不同元件之間的關係：
圖8：構建更具可擴充套件性的資料傳輸平臺使我們能夠在一種服務下以標準方式輕鬆聚合所有資料流水線，並支援資料來源和資料接收器之間的多對多連線。
第4代：下一步是什麼？
自2017年推出第三代大資料平臺以來，整個公司的使用者可以快速可靠地訪問Hadoop中的資料。但是依然還有進一步提升的空間。下面介紹一下在改進Uber的大資料平臺方面Uber正在做的努力，包括提高資料質量、降低資料延遲、提高效率、增強可擴充套件性和提高可靠性。
資料質量
為了提高資料質量，Uber確定了兩個關鍵的改進方向。首先，儘量避免非模式確認的資料。例如如果某些上游資料倉庫在儲存之前沒有強制執行或檢查資料模式時（例如儲存值為JSON塊的鍵值對），導致不良資料進入Hadoop生態系統，從而影響所有依賴此資料的下游使用者。為了防止不良資料的湧入，我們正在將對上游資料內容執行強制性模式檢查，並在資料存在任何問題（例如未經過模式確認）時拒絕資料記錄。
第二個方向是改善資料內容本身的質量。使用模式檢查能確保資料包含正確的資料型別，但它們不檢查實際資料值（例如整數而不是[0,150]之間的正數）。為了提高資料質量，Uber正在擴充套件其架構服務以支援語義檢查。這些語義檢查（Uber特定的資料型別）允許Uber在基本結構型別檢查之外對資料內容新增額外約束。
資料延遲
Uber的目標是將Hadoop中的原始資料延遲減少到五分鐘以內，將建模表的資料延遲減少到十分鐘以內。這將允許更多用例從流處理轉向使用Hudi的增量資料拉取進行更高效的小批量處理。
Uber還在擴充套件Hudi專案，以支援其他檢視模式，包括現有的讀取優化檢視，以及新的實時檢視（分鐘級別的資料延遲）。這個實時檢視依賴於我們的的開源解決方案（Hudi的一部分），稱之為Merge-On-Read或Hudi 2.0。
資料效率
為了提高資料效率，Uber正在努力避免我們的服務依賴於專用硬體，且將服務儘量docker化。此外，Uber統一了Hadoop生態系統內部和外部的資源排程，以儘量橋接公司的Hadoop和非資料服務之間的鴻溝。這允許所有作業和服務以統一的方式進行排程，而不用管它們具體在什麼媒介上執行。隨著Uber的發展，資料本地化將成為Hadoop應用的一大問題，成功的統一資源管理器可以將所有現有的排程程式集中在一起（例如Yarn、Mesos和Myriad）。
可擴充套件性和可靠性
作為改善平臺可擴充套件性和可靠性的努力的一部分，Uber確定了幾個極端的情況下的問題。雖然資料提取平臺是以通用可插拔的模式開發的，實際上游資料提取仍然包括許多依賴於源的流水線配置。這使得提取流水線變得脆弱且提高了運營成千上萬這類流水線的維護成本。
為了確保對任意資料來源的統一提取，Uber大資料團隊和資料儲存團隊合作啟動了一個專案，以統一所有上游資料來源更新日誌的內容、格式和元資料，而不管其具體技術架構。該專案將確保與這些特定上游技術相關的資訊只是作為額外的元資料被新增到實際更新日誌值中（而不用針對不同的資料來源設計完全不同的更新日誌內容）。無論上游源是什麼，都可以統一進行資料提取。
Uber的Hudi的新版本將允許數分鐘內為所有資料來源生成更大的Parquet檔案（從當前的128MB提高到1GB）。它還將消除當前版本對更新與插入比率的敏感性。Hudi 1.0依賴於一種名為copy-on-write的技術，只要有更新的記錄，它就會重寫整個源Parquet檔案。這顯著增加了寫入放大，特別是當更新與插入的比率增加時。並且妨礙了在HDFS中建立大的Parquet檔案。Hudi的新版本正在克服上述限制。具體方法是將更新的記錄儲存在單獨的增量檔案中，然後通過某種協議非同步合併到Parquet檔案中（當有足夠數量的更新資料時再重寫大的Parquet檔案，以此來分攤寫入開銷）。將Hadoop資料儲存在較大的Parquet檔案中以及更可靠的源獨立資料提取平臺將使Uber的分析資料平臺在未來幾年隨著業務的蓬勃發展而繼續改進。
-FIN-
福利
人工智慧應用挑戰賽【能力提升培訓第三場】直播回放來啦！
關注【智領雲科技】公眾號，後臺回覆關鍵字！
回覆【培訓3】，即可獲取視訊回放
回覆【PPT3】，獲取培訓課件PPT
掃描新增小編微信，備註“姓名+公司職位”，加入【大資料學習交流群】，和志同道合的朋友們共同打卡學習！
更多精彩推薦
????更多智領雲科技詳細內容，點選“閱讀原文”