通用資料湖倉一體架構正當時

這篇博文中提出的建議並不新鮮。事實上許多組織已經投入了數年時間和昂貴的資料工程團隊的工作，以慢慢構建這種架構的某個版本。我知道這一點，因為我以前在Uber和LinkedIn做過這樣的工程師。我還與數百個組織合作，在開源社群中構建它並朝著類似的目標邁進。

早在 2011 年 LinkedIn 上，我們就開始使用專有資料倉儲[1]。隨著像“你可能認識的人[2]”這樣的資料科學/機器學習應用程式的構建，我們穩步轉向Apache Avro上的資料湖[3]，Apache Pig可以訪問MapReduce作為分析、報告、機器學習和資料應用程式的事實來源。幾年後，我們在Uber[4]也面臨著同樣的挑戰，這一次是交易資料和真正的實時業務，天氣或交通可以立即影響定價或預計到達時間。我們透過構建 Apache Hudi 構建了一個事務性資料湖，作為 Parquet、Presto、Spark、Flink 和 Hive 上所有資料的入口點，然後它甚至在那個術語被創造出來之前就提供了世界上第一個資料湖倉一體。

如今企業面臨的架構挑戰不是選擇一種正確的格式或計算引擎。主要的格式和引擎可能會隨著時間的推移而變化，但這種底層資料架構經受住了時間的考驗，因為它在各種用例中具有通用性，允許使用者為每個用例選擇正確的選擇。這篇博文敦促讀者主動考慮將這種不可避免的架構作為組織資料戰略的基礎。

雲資料架構被打破

根據我的經驗，一個組織的雲資料之旅遵循今天熟悉的情節。獎章架構[5]提供了一種很好的方法來概念化這一點，因為資料會針對不同的用例進行轉換。典型的“現代資料棧”是透過使用點對點資料整合工具將運算元據複製到雲資料倉儲上的“青銅”層而誕生的。然後這些資料隨後被清理，質量稽核，並準備成“銀”層。然後，一組批處理 ETL 作業將這些銀資料轉換為事實、維度和其他模型，最終建立一個“黃金”資料層，為分析和報告提供支援。

組織也在探索新的用例，例如機器學習、資料科學和新興的 AI/LLM應用程式。這些用例通常需要大量資料，因此團隊將新增新的資料來源，如事件流(例如點選流事件、GPS 日誌等)，其規模是現有資料庫複製規模的 10-100 倍。

支援高吞吐量事件資料引入了對廉價雲端儲存和資料湖的大規模水平計算可擴充套件性的需求。但是，雖然資料湖支援僅追加工作負載(無合併)，但它幾乎不支援處理資料庫複製。當涉及到高吞吐量的可變資料流(如 NoSQL 儲存、文件儲存或新時代的關聯式資料庫)時，當前的資料基礎架構系統都沒有足夠的支援。

由於每種方法都有特定於某些工作負載型別的優勢，因此組織最終會同時維護資料倉儲和資料湖。為了在源之間整合資料，它們將定期在資料倉儲和資料湖之間複製資料。資料倉儲具有快速查詢功能，可服務於商業智慧 (BI) 和報告用例，而資料湖支援非結構化儲存和低成本計算，可服務於資料工程、資料科學和機器學習用例。

維持如圖 2 所示的架構具有挑戰性、成本高昂且容易出錯。在湖和倉庫之間定期複製資料會導致資料過時且不一致。治理成為所有相關人員頭疼的問題，因為訪問控制在系統之間是分散的，並且必須在資料的多個副本上管理資料刪除(GDPR)。更不用說團隊對這些不同的管道中的每一個都處於困境，所有權很快就會變得模糊不清。這給組織帶來了以下挑戰：

o• 供應商鎖定：高價值運營資料的真實來源通常是專有資料倉儲，這會建立鎖定點。

o• 昂貴的引入和資料準備：雖然資料倉儲為可變資料提供了合併功能，但對於上游資料庫或流資料的快速增量資料引入，它們的效能很差。倉庫中針對黃金層計算進行了最佳化的昂貴高階計算引擎，例如針對星型架構最佳化的 SQL 引擎，甚至用於青銅層(資料引入)層和銀牌(資料準備)層，它們不會增加價值。隨著組織規模的擴大，這通常會導致青銅層和銀層的成本不斷膨脹。

o• 浪費的資料複製：隨著新用例的出現，組織會重複他們的工作，在用例中跨冗餘的銅牌和銀牌層浪費儲存和計算資源。例如，引入/複製相同的資料一次用於分析，一次用於資料科學，浪費了工程和雲資源。考慮到組織還預配多個環境(如開發、暫存和生產)，整個基礎架構的複合成本可能令人震驚。此外，GDPR、CCPA 和資料最佳化等合規性法規的執行成本在透過不同入口點流入的相同資料的多個副本中多次產生。

o• 資料質量差：單個團隊經常重新設計基礎資料基礎架構，以便以零碎的方式攝取、最佳化和準備資料。由於缺乏資源，這些努力令人沮喪地減慢了投資回報率或完全失敗，使整個組織的資料質量面臨風險，因為資料質量的強弱取決於最薄弱的資料管道。

資料湖倉一體興起

在我領導 Uber 資料平臺團隊期間親身感受到了這種破碎架構的痛苦。在湖和倉庫之間複製資料的大型、緩慢的批處理作業將資料延遲到 24 小時以上，這減慢了我們的整個業務速度。最終隨著業務的增長，架構無法有效擴充套件，我們需要一個更好的解決方案，可以增量處理資料。

2016 年，我和我的團隊建立了 Apache Hudi，它最終使我們能夠將資料湖的低成本、高吞吐量儲存和計算與倉庫的合併功能相結合。資料湖倉一體(或我們當時稱之為事務性資料湖)誕生了。

資料湖倉一體為雲端儲存中的資料湖新增了事務層，使其具有類似於資料倉儲的功能，同時保持了資料湖的可擴充套件性和成本狀況。現在可以使用強大的功能，例如支援使用主鍵的更新插入和刪除的可變資料、ACID 事務、透過資料聚類和小檔案處理進行快速讀取的最佳化、表回滾等。

最重要的是它最終使將所有資料儲存在一箇中心層中成為可能。資料湖倉一體能夠儲存以前存在於倉庫和湖中的所有資料，無需維護多個資料副本。在Uber這意味著我們可以毫不拖延地執行欺詐模型，實現當日向司機付款。我們可以跟蹤最新的交通情況，甚至天氣模式，以實時更新預計到達時間的預測。

然而實現如此強大的結果不僅僅是選擇表格格式或編寫作業或 SQL 的練習;它需要一個平衡良好、經過深思熟慮的資料架構模式，並考慮到未來。我將這種架構稱為“通用資料湖倉一體”。

通用資料湖倉一體架構

通用資料湖倉一體架構將資料湖倉一體置於資料基礎架構的中心提供快速、開放且易於管理的商業智慧、資料科學等事實來源。

透過採用通用資料湖倉一體架構，組織可以克服以前無法克服的脫節架構的挑戰，該架構在湖和倉庫之間不斷複製資料。數以千計同時使用資料湖和資料倉儲的組織可以透過採用此架構獲得以下好處：

統一資料

通用資料湖倉一體體系結構使用資料湖倉一體作為組織雲帳戶中的事實來源，並以開源格式儲存資料。此外湖倉一體可以處理複雜的分散式資料庫的規模，而這些資料庫以前對於資料倉儲來說過於繁瑣。

確保資料質量

這個通用資料層在資料流中提供了一個方便的入口點，用於執行資料質量檢查、對半結構化資料進行架構化以及在資料生產者和使用者之間強制執行任何資料協定。資料質量問題可以在青銅層和銀層中得到遏制和糾正，從而確保下游表始終建立在新鮮的高質量資料之上。這種資料流的簡化簡化了體系結構，透過將工作負載遷移到經濟高效的計算來降低成本，並消除了資料刪除等重複的合規性工作。

降低成本

由於來自資料庫的運算元據和大規模事件資料都在單個青銅層和銀層中儲存和處理，因此引入和資料準備可以在低成本計算上執行一次。我們已經看到了令人印象深刻的例子，透過將 ELT 工作負載遷移到資料湖倉一體上的此架構，雲資料倉儲成本節省了數百萬美元。以開放格式儲存資料，可以在所有三個層中分攤所有資料最佳化和管理成本，從而為資料平臺節省大量成本。

更快的效能

通用資料湖倉一體透過兩種方式提高效能。首先它專為可變資料而設計，可快速攝取來自變更資料捕獲 (CDC)、流資料和其他來源的更新。其次它開啟了一扇門，將工作負載從大型臃腫的批處理轉移到增量模型，以提高速度和效率。Uber 透過使用 Hudi 進行增量 ETL，節省了 ~80% 的總體計算成本。它們同時提高了效能、資料質量和可觀測性。

讓客戶自由選擇計算引擎

與十年前不同，今天的資料需求並不止於傳統的分析和報告。資料科學、機器學習和流資料是財富 500 強公司和初創公司的主流和無處不在。新興的資料用例(如深度學習)LLMs正在帶來各種新的計算引擎，這些引擎具有針對每個工作負載獨立最佳化的卓越效能/體驗。預先選擇一個倉庫或湖引擎的傳統做法拋棄了雲提供的所有優勢;藉助通用資料湖倉一體可以輕鬆地為每個用例按需啟動合適的計算引擎。

通用資料湖倉一體架構使資料可以跨所有主要資料倉儲和資料湖查詢引擎進行訪問，並與任何目錄整合，這與之前將資料儲存與一個計算引擎相結合的方法發生了重大轉變。這種架構能夠使用最適合每個獨特工作的引擎，在BI和報告、機器學習、資料科學和無數更多用例中無縫構建專門的下游“黃金”層。例如 Spark 非常適合資料科學工作負載，而資料倉儲則經過傳統分析和報告的實戰考驗。除了技術差異之外，定價和向開源的轉變在組織採用計算引擎的過程中起著至關重要的作用。

例如沃爾瑪在 Apache Hudi 上構建了他們的湖倉一體，確保他們可以透過以開源格式儲存資料來輕鬆利用新技術。他們使用通用資料湖倉一體架構，使資料使用者能夠使用各種技術(包括 Hive 和 Spark、Presto 和 Trino、BigQuery 和 Flink)查詢湖倉一體。

奪回資料的所有權

所有真實資料來源資料都以開源格式儲存在組織雲端儲存桶的青銅層和銀層中。

資料的可訪問性不是由供應商鎖定的不透明第三方系統決定。這種架構能夠靈活地在組織的雲網路內(而不是在供應商的帳戶中)執行資料服務，以加強安全性並支援高度監管的環境。

此外可以自由地使用開放資料服務或購買託管服務來管理資料，從而避免資料服務的鎖定點。

簡化訪問控制

由於資料使用者在湖倉一體中對青銅和白銀資料的單個副本進行操作，訪問控制變得更加易於管理和實施。資料沿襲已明確定義，團隊不再需要跨多個不相交的系統和資料副本管理單獨的許可權。

為工作負載選擇合適的技術

雖然通用資料湖倉一體架構非常有前途，但一些關鍵技術選擇對於在實踐中實現其優勢至關重要。

當務之急是儘快在銀層提供攝取的資料，因為任何延遲現在都會阻礙多個用例。為了實現資料新鮮度和效率的組合，組織應選擇非常適合流式處理和增量處理的資料湖倉一體技術。這有助於處理棘手的寫入模式，例如在青銅層引入期間的隨機寫入，以及利用更改流以增量方式更新銀牌表，而無需一次又一次地重新處理青銅層。

雖然我可能持有一些偏見，但我和我的團隊圍繞這些通用資料湖倉一體原則構建了 Apache Hudi。Hudi 經過實戰考驗，通常被認為是最適合這些工作負載的，同時還提供豐富的開放資料服務層，以保留構建與購買的可選性。此外 Hudi 在資料湖之上解鎖了流資料處理模型，以大幅減少執行時間和傳統批處理 ETL 作業的成本。我相信在未來的道路上通用資料湖倉一體架構也可以建立在為這些需求提供類似或更好的支援的未來技術之上。

最後 Onetable 是通用資料湖倉一體架構的另一個構建塊。它透過簡單的目錄整合實現了跨主要湖倉一體表格式(Apache Hudi、Apache Iceberg 和 Delta Lake)的互操作性，允許跨計算引擎自由設定資料，並以不同格式構建下游黃金層。這些好處已經得到了沃爾瑪[6]等財富 10 強企業的驗證。

下一步

在這篇部落格中介紹了通用資料湖倉一體作為構建雲資料基礎設施的新方式。在此過程中我們只是給數百家組織(包括通用電氣、TikTok、亞馬遜和沃爾瑪、迪士尼、Twilio、Robinhood、Zoom 等大型企業)使用資料湖倉一體技術(如 Apache Hudi)構建的資料架構並概述了這些架構。這種方法比許多公司目前維護的混合架構更簡單、更快速、成本更低。它實現了儲存和計算的真正分離，同時支援在資料中使用同類計算引擎的實用方法。在未來幾年我們相信在對資料的需求不斷增長的推動下，它只會越來越受歡迎，包括 ML 和 AI 的增長、雲成本的上升、複雜性的增加以及對資料團隊的需求不斷增加。

雖然我堅信“在相同資料上為正確的工作負載提供正確的引擎”原則，但今天以客觀和科學的方式做出這一選擇並非易事。這是由於缺乏標準化的功能比較和基準測試、缺乏對關鍵工作負載的共同理解以及其他因素。在本系列的後續部落格文章中，我們將分享 Universal Data Lakehouse 如何跨資料傳輸模式(批處理、CDC 和流式處理)工作，以及它如何以“更好地協同工作”的方式與不同的計算引擎(如 Amazon Redshift、Snowflake、BigQuery 和 Databricks)協同工作。

Onehouse 提供的託管雲服務提供交鑰匙體驗以構建本部落格中概述的通用資料湖倉一體架構。像 Apna 這樣的使用者已經將資料新鮮度從幾小時提高到幾分鐘，並透過削減他們的資料整合工具並用 Onehouse 取代倉庫來儲存他們的青銅和白銀資料，從而顯著降低了成本。藉助通用資料湖倉一體架構，他們的分析師可以繼續使用倉庫對湖倉一體中儲存的資料進行查詢。