通用數據湖倉一體架構正當時

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

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

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

雲數據架構被打破

根據我的經驗,一個組織的雲數據之旅遵循今天熟悉的情節。獎章架構提供了一種很好的方法來概念化這一點,因爲數據會針對不同的用例進行轉換。典型的“現代數據棧”是通過使用點對點數據集成工具將操作數據複製到雲數據倉庫上的“青銅”層而誕生的。然後這些數據隨後被清理,質量審覈,並準備成“銀”層。然後,一組批處理 ETL 作業將這些銀數據轉換爲事實、維度和其他模型,最終創建一個“黃金”數據層,爲分析和報告提供支持。

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

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

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

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

  • 供應商鎖定:高價值運營數據的真實來源通常是專有數據倉庫,這會創建鎖定點。
  • 昂貴的引入和數據準備:雖然數據倉庫爲可變數據提供了合併功能,但對於上游數據庫或流數據的快速增量數據引入,它們的性能很差。倉庫中針對黃金層計算進行了優化的昂貴高級計算引擎,例如針對星型架構優化的 SQL 引擎,甚至用於青銅層(數據引入)層和銀牌(數據準備)層,它們不會增加價值。隨着組織規模的擴大,這通常會導致青銅層和銀層的成本不斷膨脹。
  • 浪費的數據複製:隨着新用例的出現,組織會重複他們的工作,在用例中跨冗餘的銅牌和銀牌層浪費存儲和計算資源。例如,引入/複製相同的數據一次用於分析,一次用於數據科學,浪費了工程和雲資源。考慮到組織還預配多個環境(如開發、暫存和生產),整個基礎架構的複合成本可能令人震驚。此外,GDPR、CCPA 和數據優化等合規性法規的執行成本在通過不同入口點流入的相同數據的多個副本中多次產生。
  • 數據質量差:單個團隊經常重新設計基礎數據基礎架構,以便以零碎的方式攝取、優化和準備數據。由於缺乏資源,這些努力令人沮喪地減慢了投資回報率或完全失敗,使整個組織的數據質量面臨風險,因爲數據質量的強弱取決於最薄弱的數據管道。

數據湖倉一體興起

在我領導 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)的互操作性,允許跨計算引擎自由設置數據,並以不同格式構建下游黃金層。這些好處已經得到了沃爾瑪等財富 10 強企業的驗證。

下一步

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

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

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

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章