如何建立可擴展且具成本效益的 Lakehouse 資料平台

過去十年間,我們已從僵化的資料倉儲轉向靈活的資料湖,最近又轉向承諾結合兩者優勢的湖倉架構。

然而,從一代資料平台遷移到下一代被證明比預期更困難。那些已經踏上這段旅程的人正在發現挑戰,並因將舊有設計模式帶入新系統而重複犯錯。

在幫助多個組織設計和擴展現代資料平台後,我發現成功不取決於工具,而取決於紀律。本文是一份實用指南,說明如何有效轉型、應避免什麼,以及如何將技術選擇轉化為可衡量的業務價值。

為何大數據的純粹歷史不再有用

回顧過去,大數據運動始於無限儲存和無盡實驗的夢想。在2010年代中期左右,企業開始收集所有可能的日誌、點擊和交易,深信僅憑數量就能帶來洞察。實際上,這種信念只創造了更多複雜性。資料湖作為倉儲的時尚繼任者出現,但大多數很快就變成了資料沼澤,資訊很容易進入但很少以可用形式返回的地方。

到2022年,產業已經成熟,問題也開始改變。團隊不再詢問他們能儲存多少資料,而是如何信任和使用他們已經擁有的資料。今天真正的挑戰不是容量而是治理,不是擷取而是解釋。

這裡的關鍵教訓很簡單。收集更多資料並不能使公司成為資料驅動型企業。真正重要的是理解資料、維護適當的治理,並有效使用它。

我建議為每個資料集定義所有權,設定明確的保留和品質政策,並將工程工作重點放在直接支持業務決策的資料上。沒有這個基礎,即使是最先進的湖倉最終也會變成現代沼澤。

湖倉作為轉折點

湖倉的興起正好反映了這種轉變。湖倉模型不是在效能和靈活性之間做出選擇,而是將兩者結合。其核心使用廉價的雲端儲存,格式如Delta或Iceberg,並豐富了元資料和交易保證。結果是一個成本與資料湖一樣低,但在查詢時表現得像倉儲的系統。

這對業務領導者很重要,因為它消除了歷史資料廉價儲存和即時分析昂貴系統之間的持續權衡。我總是建議將湖倉定位為一個共享基礎,而不是所有其他系統的替代品,它能在一個環境中同時支援傳統分析和機器學習。

在湖倉中,同一個環境可以支援財務長的儀表板、預測客戶行為的機器學習模型,以及產品分析師的臨時查詢。資料不再跨系統重複,這使治理更簡單,並讓成本優化自然發生。

資料湖倉採用中的結構和治理挑戰

當企業從傳統資料倉儲或資料湖轉向更靈活的湖倉架構時,轉型很少順利。許多團隊在未重新思考其目的的情況下,將舊倉儲的現有結構複製到新環境中。結果是資料孤島的出現,換句話說就是碎片化。一個版本的資料存在於倉儲中,另一個在湖中,第三個在兩者之間。透過從頭開始重新設計湖倉的結構來避免這種情況。根據存取模式和消費者需求來建模資料,而不是遵循舊有倉儲邏輯。

另一個反覆出現的問題是正規化。我的意思是什麼?倉儲建立在嚴格、深度正規化的結構上,擁有數十個相互連接的表。當這些被直接複製到湖中時,每個查詢都需要大量的聯接。效能崩潰,工程師責怪基礎設施,專案失去可信度。相反,在有助於效能的地方進行反正規化,並將相關實體放置得更近以最小化資料移動。將效能設計視為資料建模的一部分,而不是後期優化。

治理和控制至關重要。在資料湖中,通常缺乏監督,因為團隊直接處理檔案。在倉儲中,適用嚴格規則,如列級安全性、基於角色的存取和詳細的稽核追蹤。湖倉必須在確保開放性的同時不失去問責制之間取得平衡。您應該從一開始就實施基於角色的存取和血緣追蹤。當治理與平台一起成長並成為信任的基礎時,效果最好。

效能也取決於智慧設計。傳統倉儲依賴自動索引,但在湖倉中,效率來自分區或液態群集、快取,以及為分析選擇正確的檔案格式。我建議將分區策略和檔案佈局視為架構中的一級公民。

成本優化是湖倉的另一個關鍵承諾,但它不會自動實現。雖然雲端儲存便宜且分析可以根據需要擴展或縮減,但這些優勢往往被糟糕的資料設計和不受控制的增長所抵消。您必須積極管理資料集的生命週期並移除未使用的副本。如果忽略這個過程,雲端成本將隨著時間悄悄增加。

成本優化作為第一原則

我想更詳細地關注成本優化,因為它是湖倉架構的關鍵優勢之一。

湖倉架構降低成本的關鍵方式之一是最小化資料移動,即系統或處理節點之間的資料移動。為了實現這一點,始終設計您的資料,使相關實體儲存在一起。

透過將所有資料保存在一個地方並將相關實體儲存在一起,湖倉消除了過度聯接和資料傳輸的需要。當我們執行分析時,例如為客戶分析建立機器學習模型時,我們可以使用歷史和真實交易資料,而無需在系統之間複製或移動它。

實現成本優化的另一個關鍵原則是儲存和運算的解耦。資料儲存和資料處理根據實際需求獨立擴展。我們只為使用的資源付費,而不是維護大型固定容量系統。儲存保持便宜且可擴展,運算能力可以根據需要增加或減少。這種靈活性導致較低的基礎設施成本和更有效率的資料操作。始終從小規模開始,讓自動擴展發揮作用。在承諾預留容量之前,監控使用情況並了解您的工作負載模式。

自動擴展叢集進一步幫助控制成本。機器學習工作負載需要雲端中的運算資源,具有記憶體和處理能力的虛擬機器,類似於普通電腦。過去,企業提前購買或租賃實體伺服器,並在該固定容量上執行流程。在雲端中,我們根據實際使用情況為運算付費,按時間單位和資源量計費。我強烈建議從最小叢集大小開始,觀察擴展行為,並設定上限以防止成本失控。

選擇正確的架構方法

讓我們談談湖倉架構。在許多方面,其設計取決於我們如何建構資料模型。最常見和有效的方法是分層或獎章架構,其中每一層都有特定目的並支援不同類型的使用者和工作負載。

— 第一層,通常稱為原始層或青銅層,是來源資料的直接副本。它主要服務於技術需求,僅保留短時間以允許在需要時快速重新處理。應將其視為臨時儲存。

— 第二層或正規化層,包含清理和結構化的資料,有時與其他表(如使用者和訂單)聯接。這是通常訓練機器學習模型的地方。在此階段自動化資料驗證和結構描述執行是最佳實務。維護一致性比處理大量資料更有價值。

— 最後一層,稱為黃金層,是聚合資料所在的地方。儀表板和BI工具(如Tableau或Power BI)通常連接到此層以存取準備好的指標和視覺化。不過,並非所有內容都可以預先計算。

每一層都有其目的,它們共同允許機器學習和商業智慧蓬勃發展。

您應該將分層策略與消費模式對齊。資料科學家通常使用銀層工作,而高階主管期望從黃金層獲得答案。靈活性是湖倉的真正優勢,能夠服務多個受眾而無需建立和維護多個獨立系統。

來自實務的見解

如果我從頭開始設計,我會做一些與產業過去處理資料方式不同的事情。

以下是我從實際實施中學到的經驗以及我現在的建議。

1. 從小規模開始,快速交付

一次遷移所有內容並不總是最佳選擇。企業經常嘗試將數TB的資料提升並轉移到新系統中,結果卻發現沒人使用它。更好的途徑是從提供明確業務價值的單一使用案例開始,例如推薦引擎、動態定價或客戶留存模型。在該領域的成功既提供了可信度,也提供了擴展的藍圖。

1. 盡早轉換業務需求

我會盡早將業務需求轉換為技術需求。如果報告需要按區域篩選,該需求意味著在儲存層級按區域分區。如果分析師期望近即時更新,這會驅動關於索引或快取的決策。沒有這種轉換,技術會偏離業務目標,信任會被侵蝕。

1. 使技術與組織能力相匹配

我總是會使技術與組織的能力相匹配。擁有強大工程文化的公司可能偏好開源元件和最大控制權。技術資源有限的企業可能更適合使用向分析師公開SQL介面的託管服務。沒有通用解決方案,重要的是將雄心與能力對齊。

最後,我會挑戰湖倉只是更好的湖的假設。實際上,它是一個不同的範式。它繼承了湖和倉儲的一些特性,但並不是每個使用案例的替代品。例如,高頻率交易工作負載可能仍然需要專門的系統。認識到這些界限可以防止失望,並確保湖倉在真正擅長的地方被使用。