共计 4889 个字符，预计需要花费 13 分钟才能阅读完成。
简介：本文整顿自 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 机房安全性和稳定性没有保障，容灾能力差。客户决定将大数据平台迁徙上云。
案例具体介绍：https://developer.aliyun.com/…
全托管数据湖计划：
以 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 很可能成为新一代大数据架构。
原文链接
本文为阿里云原创内容，未经容许不得转载。
