簡介：本文整理自 DataFunCon 2021大會上，阿里云數據湖構建云產品研發陳鑫偉的分享，主要介紹了 Lakehouse 的架構解析與云上實踐。

作者簡介：陳鑫偉（花名熙康），阿里云開源大數據-數據湖構建云產品研發

內容框架

• Lakehouse 概念與特性
• Lakehouse 架構與實現
• 云上 Lakehouse 架構與實踐
• 案例分享及未來展望

Lakehouse 概念與特性

數據架構的演進

1980年后期，以 Teradata、Oracle 等產品為代表的數據倉庫，主要用于解決 BI 分析和報表的數據采集與計算需求。通過內置存儲系統，對上層提供數據抽象，數據經過清洗和轉化，以已定義的schema結構寫入，強調建模和數據管理以提供更好的性能和數據一致性，具備細粒度的數據管理和治理能力；支持事務、版本管理；數據深度優化，和計算引擎深度集成，提升了對外的 SQL 查詢性能。然而，隨著數據量的增長，數據倉庫開始面臨若干挑戰。首先是存儲和計算耦合，需要根據兩者峰值采購，導致采購成本高、采購周期長；其次越來越多的數據集是非結構化的，數據倉庫無法存儲和查詢這些數據；此外，數據不夠開放，導致不易用于其他高級分析（如 ML ）場景。

隨著 Hadoop 生態的興起，以 HDFS、S3、OSS 等產品為代表，統一存儲所有數據，支持各種數據應用場景，架構較為復雜的數據湖開始流行。以基于 HDFS 存儲、或者基于云上的對象存儲這種相對低成本、高可用的統一存儲系統，替換了原先的底層存儲。可以存儲各種原始數據，無需提前進行建模和數據轉化，存儲成本低且拓展性強；支持半結構化和非結構化的數據；數據更加開放，可以通過各種計算引擎或者分析手段讀取數據，支持豐富的計算場景，靈活性強且易于啟動。不過隨著十年來的發展，數據湖的問題也逐漸暴露。數據鏈路長/組件多導致出錯率高、數據可靠性差；各個系統間不斷的數據遷移同步給數據一致性和時效性帶來挑戰；湖里的數據雜亂無章，未經優化直接訪問查詢會出現性能問題；整體系統的復雜性導致企業建設和維護成本高等。

為了解決上述問題，結合數據湖和數據倉庫優勢的 LakeHouse 應運而生。底層依舊是低成本、開放的存儲，上層基于類似 Delta lake/Iceberg/Hudi 建設數據系統，提供數據管理特性和高效訪問性能，支持多樣數據分析和計算，綜合了數據倉庫以及數據湖的優點形成了新的架構。存算分離架構可以進行靈活擴展；減少數據搬遷，數據可靠性、一致性和實時性得到了保障；支持豐富的計算引擎和范式；此外，支持數據組織和索引優化，查詢性能更優。不過，因為 LakeHouse 還處于快速發展期，關鍵技術迭代快且成熟的產品和系統少。在可借鑒案例不多的情況下，企業如果想采用 LakeHouse，需要有一定技術投入。

數據架構的對比

上圖從多維度對數據倉庫、數據湖、LakeHouse 進行了對比，可以明顯看到 LakeHouse 綜合了數據倉庫和數據湖的優勢，這也是 LakeHouse 被期待為“新一代數據架構基本范式”的原因。

Lakehouse 架構與實現

Lakehouse 架構圖

Lakehouse = 云上對象存儲 + 湖格式 + 湖管理平臺

訪問層

• 元數據層查詢和定位數據
• 對象存儲支持高吞吐的數據訪問
• 開放的數據格式支持引擎直接讀取
• Declarative DataFrame API 利用SQL引擎的優化和過濾能力

優化層

• Caching、Auxiliary data structures（indexing and statistics）、data layout optimization，Governance

事務層

• 實現支持事務隔離的元數據層，指明每個Table版本所包含的數據對象

• ? ?
  ? ?

存儲層

• 云上對象存儲，低成本，高可靠性，無限擴展，高吞吐，免運維
• 通用的數據格式，Parquet / Orc 等

Lakehouse 實現核心--湖格式

本文主要圍繞 Delta Lake、IceBerg 兩種湖格式展開介紹 Lakehouse 的特性。

Delta Lake

Delta Lake

關鍵實現：事務日志 – Single Source of Truth

• 事務日志以事務提交為粒度，按序記錄了所有對表的操作
• 串行化隔離寫操作，寫操作保證原子性，MVCC+樂觀鎖控制并發沖突
• 快照隔離讀操作，支持讀歷史版本數據，實現時間旅行
• 文件級別數據更新重新，實現局部數據更新和刪除
• 基于增量日志的數據處理

Delta Lake on EMR

針對 Delta Lake 開源版本的不足之處，阿里云 EMR 團隊做了如下功能開發：

Optimize& Zorder

• 支持Zorder重新布局數據，結合dataskipping加速查詢
• 實現高效的Zorder執行，7.8億數據，2個字段，20分鐘完成
• 支持Optimize，解決小文件問題，并支持自動compact

SavePoint

• 支持創建/刪除/查詢SAVEPOINT，永久保留指定版本的數據

Rollback

• 回退到歷史某版本，用于修復數據

自動同步元數據到MetaStore

• 無需額外操作，將完整表信息和分區信息自動同步到metastore，用于Hive/Presto查詢等；

多引擎查詢支持

• 支持 Hive / Trino / Impala / 阿里云 MaxCompute 查詢

Iceberg

Iceberg

關鍵實現：基于 Snapshot 的元數據層

• Snapshot 中記錄表當前版本的所有文件
• 每次寫操作提交一個新的版本
• 基于 Snapshot 的讀寫隔離

基于snapshot差異做增量數據消費

Iceberg on EMR

阿里云在 Iceberg 上做的貢獻：

Optimize

• 結合 JindoFS 提供緩存加速
• 自動小文件合并事務

阿里云云生態對接

• 原生接入 OSS 對象存儲
• 原生接入 DLF 元數據

開源社區投入

• 1位 IcebergPMC，1位 Iceberg Committer
• 貢獻和維護 Iceberg 與 Flink 的集成模塊
• 主導并設計社區的 MOR 流式 upsert 功能

中文社區運營

• 維護國內最大的 Apache Iceberg 數據湖技術社區（成員1250+）。
• 國內最活躍的 Apache Iceberg 布道師之一:
• 組織舉辦 Apache Iceberg 深圳站、Apache Iceberg 上海站

選型參考

云上 Lakehouse 架構與實踐

Databricks 在推出 Lakehouse 的概念后，就把公司的介紹改成了 The Databricks Lakehouse Platform。如下方的架構圖所示，底層是云的基礎設施（其中阿里云跟 Databricks 也有合作推出 Databricks 數據洞察）；數據入湖之后，在開放的數據存儲之上，是結合了 Delta Lake 數據湖格式的較為重點的數據管理和治理層（Data Management and Governance）。

數據湖構建、管理、與分析過程

• 數據入湖與清洗

來自各個數據源的數據，以全量、增量、實時、ETL、數據遷移、元數據注冊等方式入湖并清洗

• 數據存儲與管理

• 元數據管理與服務
• 權限控制與審計
• 數據質量控制
• 湖表管理與優化
• 存儲管理與優化
• 數據分析與訓練

覆蓋數據建模與開發、離線分析、實時計算、交互式分析、機器學習和算法等場景

• 數據服務與應用

• 將訓練分析后的數據同步到需求對應產品進行深度分析或進一步處理
• 直接對接商業智能、實時監控、數據科學、數據可視化等數據應用

阿里云 Lakehouse 架構

• 數據層（數據湖核心能力）
• 計算層（彈性計算引擎）
• 平臺層（數據開發與治理）

DLF 統一元數據服務與治理

• 統一元數據與統一權限

• 完全兼容 HMS 協議，支持多引擎訪問
• 多引擎統一權限控制
• 利用云上 KV 存儲提供高擴展性、高性能服務
• 支持 Delta lake/Hudi/Iceberg 元數據同步，統一視圖
• 以 Delta lake 支持多引擎訪問為例
• 多形態Spark：DLF 數據探索、Databrick Spark、Maxcompute Serverles Spark
• 實時計算：Flink（對接中）
• EMR 交互式分析：Trino、Impala
• EMR Hive ：阿里云貢獻給社區的Delta Connector，完全開源
• 湖元數據治理
• 基于歷史數據的元數據分析和管理
• 成本分析與優化、冷熱分析與性能優化

CDC 入湖產品化

• 多種數據源0代碼構建數據流

• 模板+配置 => Spark任務
• 入湖工廠，自動生成Spark SQL / Dataframe Code
• 多種數據源 CDC 入湖，自動同步元數據

以 Hudi 為例

• Mysql、Kafka、Log Service、 TableStore 等實時寫入 Hudi 數據湖
• 結合 Flink CDC，支持全托管和半托管Flink實時寫入 Hudi 數據湖并同步元數據到 DLF，供其他引擎進一步分析。
• Hudi社區貢獻
• 阿里云貢獻 Spark SQL 和 Flink SQL 讀寫 Hudi
• 實現 MERGER INTO 等 CDC 常用算子

數據湖治理

• 基于平臺提供自動化的治理服務

以 Iceberg 為例

• Compact / Merge / Optmize
• Expire-snapshot / Vacuum
• Caching（基于JindoFS）

• 自動數據冷熱分析及分層歸檔
• Serverless Spark提供低成本托管資源池務

案例分享及未來展望

案例分享1：全托管數據湖方案

大數據平臺架構：

在上云之前，客戶的大數據部署在 IDC 機房，基于 CDH 自建的 Hadoop 集群。因為自建 IDC 機房安全性和穩定性沒有保障，容災能力差。客戶決定將大數據平臺遷移上云。

案例詳細介紹：百草味基于“ EMR+Databricks+DLF ”構建云上數據湖的最佳實踐-阿里云開發者社區

全托管數據湖方案：

以 RDS 關系型數據庫為例

數據可以通過 Spark 進行 ETL 后入湖，或者通過在 DLF 上托管的 CDC 增量入湖/ Batch 全量入湖導入到對象存儲 OSS中，在統一的元數據管理之下：

• 基于 Spark Streaming 做實時分析，進行實時報表/監控的展現
• 通過阿里云上 Databricks 數據洞察進行 ETL 任務，進行數據建模和進一步處理
• 拉起 EMR Presto 集群，以滿足交互式分析場景

• 批流一體，鏈路簡單清晰

• Delta lake + Spark 實現實時計算和離線分析

• 全托管服務，免運維

• OSS存儲托管
• DLF元數據和入湖任務托管
• DDI Spark引擎托管

• 數據開放

• 快速接入Presto做交互式分析

在這套方案中，除了半托管的 EMR Presto，其余組件都是全托管的。無論是底層存儲，還是元數據或者 Spark 引擎的管理，無需用戶自行管理，也不需要進行組件的維護和升級。提升使用體驗的同時，大大降低了運維成本。

案例分享2：存算分離實時數據湖

這是一個存算分離的實時數據湖案例。用戶本來使用的是存算一體架構，Hive 元數據信息存儲在 Hive MetaStore，數據存儲在 HDFS 中，經常會出現壞盤的情況，給運維帶來麻煩的同時增加了成本。另一方面 Hive Metastore 在數據量到達一定程度后，比如 Partition 分區數到了10萬級別后，性能上會受到很大挑戰。所以用戶決定進行存算一體到存算分離架構的遷移。

• 存算一體—> 存算分離

• HDfs運維困難 -> OSS免運維
• HDFS云盤成本高 -> OSS成本低
• HMS擴展性差 -> DLF元數據擴展性高
• Flink實時入湖，Spark/Hive分析
• Flink -> Hudi高效實時寫入能力
• DLF元數據天然打通Spark/Hive
• Hbase服務和數據分離

Lakehouse 未來展望

• 湖格式能力會不斷增強，接近數倉/數據庫的能力

• 多表事務（AWS Governed Table）
• Optimize 功能越來越豐富（Caching，Clustering，Z-Ording。。。）
• 三種湖格式能力不斷追平
• 湖格式與存儲/計算集成度越來越高，以獲得更高的性能
• 存儲層會出現面向湖格式的定制 API
• 為計算層提供更多面向性能優化的方案（二級索引，Column statistics）
• 湖管理平臺能力越來越豐富和智能化
• 統一元數據服務成為標配，Meta 托管化、服務化（Hudi Timeline Server）
• 治理和優化成為平臺基礎能力，并對用戶不可見

綜上，無論是從 Lakehouse 的特性來看，或是從各個廠商在 Lakehouse、在湖格式上的探索及建設來看，Lakehouse 很可能成為新一代大數據架構。

原文鏈接

本文為阿里云原創內容，未經允許不得轉載。

總結

以上是生活随笔為你收集整理的Lakehouse 架构解析与云上实践的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。