- 前言
- 第一代數據架構 – Data Warehouse
- 第二代數據架構 – Data Lake + Data Warehouse
- 最新的數據架構 – Data Lakehouse
- Data Lakehouse 仍然有優化的空間
- 結論
- 個人感想
- 參考資料
前言
最近對於 Data Lakehouse 滿感興趣也很看好它，覺得 Data Lakehouse 有機會成為將來數據架構的主流，而最早提出 Data Lakehouse 這個專有名詞的目前看起來是 2020~2021 年 Databricks, UC Berkeley 和 Stanford University 所共同撰寫的一篇論文「Lakehouse: A New Generation of Open Platforms that Unify Data Warehousing and Advanced Analytics」，因此這次文章我整理了論文中提到的數據架構變遷歷史與原因，以及 Data Lakehouse 究竟有哪些優缺點、解決了哪些現在各大企業所面臨的問題。
第一代數據架構 – Data Warehouse
特色
- 從關聯式資料庫中取得「結構化資料」
- 屬於 schema-on-write（寫入時就得先定義好欄位）
缺點
- 計算和儲存兩者一體，且可能是僅有一台地端機器，導致資料管理困難、費用高昂
- 僅能儲存結構化資料，影片及音訊等數據無法儲存和查詢
隨著資料集的規模與類型快速增長，第一代數據架構已漸漸無法負荷，於是業界出現了第二代的 Two-tier 數據架構「Data Lake + Data Warehouse」。
第二代數據架構 – Data Lake + Data Warehouse
特色
- 解決了儲存大量「非結構化資料」的需求
- Data Lake 中主要儲存的格式為 Parquet, AVRO, ORC…等 Open File Formats
- 屬於 schema-on-read 架構（讀取資料時才需要注意欄位）
- 目前美國 Fortune 500 的企業都是採用此設計
缺點
- 可靠性不足
- Data Lake, Data warehouse 之間難以維持資料一致
- ETL 會增加了錯誤風險，越多層 ETL 越容易出錯
- ETL bugs 導致數據品質降低
- 資料陳舊
- 資料新鮮度取決於資料的更新頻率，若使用 ETL 將資料從 Lake 抓到 Warehouse ， 則 Warehouse 的資料一定就會比 Lake 的舊
- 很多系統會很依賴即時新鮮的資料，例如：推薦系統、客服系統
- 資料陳舊的問題，相較於第一代數據架構來說是一種退步（當時數據可以立即進行查詢）
- 調查顯示：
- 86% 的分析師使用過時的資料
- 62% 的人每月需要多次等候工程資源
- 花費高、維護成本高
- Data Lake 和 Warehouse 可能多數資料是重複的
- 中間越多 ETL 就需要越多計算費用與資源
- ETL Pipeline 需要大量人力和時間來維護
綜合以上，新的數據架構需要滿足三個重點
- 將 Data Lakes 變成一個 High-performance 系統
- 保留 Data Warehouses 的效能，並且易於管理
- 可以快速直接的取用，供機器學習等進階數據分析場景使用
➡️ 於是誕生了最新的數據架構：「Data Lakehouse」！
最新的數據架構 – Data Lakehouse
看似很簡單，但其實中間會依靠 Metadata 和各種現有的 API 來實現，可以參考下圖，綠色的部分就是 Data Lakehouse 架構設計中的關鍵元素。
Data Lakehouse 的優點
Metadata 提升資料管理
- 具有 ACID transactions 特性
- 因為有了 Metadata 就可以儲存 Insert, Update 等 Transactions log 資訊儲存，所以讓原本的 Data Lake 具備了 ACID 特性，也同時有數據版本控管、時光回溯的功能
- 現有的 Data Lake 能無痛升級為 Data Lakehouse
- e.g. Delta Lake 可以將現有的 Parquet 文件目錄轉換為 Delta Lake 表，而不需要進行任何數據複製
- 提升數據品質
- 減少 ETL 次數，避免錯誤
- 可以控管 Data 匯入時的 Schema，例如：「國家」欄位的資料只能是國家清單中的其中一個值
- 提升數據治理
- metadata layers 可以設定 access control 以及查看編輯記錄，例如：可以判斷一個 user 有沒有權限讀取某張表
Metadata 提升 SQL Performance
- Caching
- metadata layer 讓 Data Lakehouse 可以快取 Cloud Objects，提升查詢速度
- 添加輔助性的資料
- 針對資料增加輔助的額外資料，例如某個欄位的 Min, Max, Index 等
- 可提升查詢效能、Filter 篩選速度
- Data layout
- 從 metadata 可以做資料排序，讓某些資料 cluster 在一起，降低查詢資料的難度
- 針對不同型態的數據做不同的壓縮方式
Data Lakehouse 仍然有優化的空間
- 數據湖的文件格式限制
- 目前 Data Lakehouse 限制在開放、可直接訪問的標準文件格式上 （如 Parquet 或 ORC）可能是一個限制
- 性能優化
- 透過對常使用或常被查詢的「熱數據」做快取（caching），以及對不常被取用的「冷數據」進行數據佈局優化（data layout optimization），才能讓 Lakehouse 達到與傳統 Warehouse 相當的效能。
結論
- Data Lakehouse 就是綜合了 Data Lake 的低成本 + Warehouse 的高效能 & 管理功能
=> Lakehouse 是當前數據平台所面臨的挑戰的有效解決方案 - 由於許多公司已經有大量數據在 Data Lake 中
=> Lakehouse 不僅能讓企業無縫接軌，也有望極大簡化企業數據架構 - 作者認為業界將來會漸漸趨向採用 Lakehouse 的架構設計
個人感想
近幾年數據量的成長速度越來越快，依賴多次 ETL 的數據架構我也覺得已經有點不堪負荷，經常聽到很多 Data Team 的人每天都在忙著修 Data Pipeline，沒有其他時間可以做更高價值或更創新的工作，加上 Lake & Warehouse 之間存在很多重複資料的問題，也是造成 Data team 花費成本一直低不下來的原因之一，所以我個人是非常看好 Data Lakehouse 這個架構，我覺得可以解決很大一部分各大企業目前所面臨的問題。
過去我也寫過一篇 關於 Data Lakehouse 的崛起與主流框架，有興趣的讀者也可以參考看看！
JumpingCode 資料科學手記 
[…] Data Lakehouse 數據架構的演變：從 Data Warehouse 到 Data Lake 再進化到最新的 Data&n… […]
讚讚