分享嘉宾：陈鑫伟 阿里巴巴 技术专家
出品平台：DataFunTalk
导读：本文整理自DataFunCon 2021大会上陈鑫伟老师的分享，Lakehouse目前已经是大数据领域里非常热门的话题，自从Databricks公司在2019年的论文里首次阐述相关概念之后，随着Delta lake/ Hudi/ Iceberg等数据湖技术的兴起，各大互联网公司都纷纷开始投入建设Lakehouse模式的大数据系统。本文重点从Lakehouse的起源、架构范式、技术实现、云上实践等几个角度，对Lakehouse做一次探讨。
1. 数据架构的演进
1980年后期，以 Teradata、Oracle 等产品为代表的数据仓库，主要用于解决 BI 分析和报表的数据采集与计算需求。通过内置存储系统，对上层提供数据抽象，数据经过清洗和转化，以已定义的schema结构写入，强调建模和数据管理以提供更好的性能和数据一致性，具备细粒度的数据管理和治理能力；支持事务、版本管理；数据深度优化，和计算引擎深度集成，提升了对外的 SQL 查询性能。然而，随着数据量的增长，数据仓库开始面临若干挑战。首先是存储和计算耦合，需要根据两者峰值采购，导致采购成本高、采购周期长；其次越来越多的数据集是非结构化的，数据仓库无法存储和查询这些数据；此外，数据不够开放，导致不易用于其他高级分析（如 ML ）场景。
随着 Hadoop 生态的兴起，以 HDFS、S3、OSS 等产品为代表，统一存储所有数据，支持各种数据应用场景，架构较为复杂的数据湖开始流行。以基于 HDFS 存储、或者基于云上的对象存储这种相对低成本、高可用的统一存储系统，替换了原先的底层存储。可以存储各种原始数据，无需提前进行建模和数据转化，存储成本低且拓展性强；支持半结构化和非结构化的数据；数据更加开放，可以通过各种计算引擎或者分析手段读取数据，支持丰富的计算场景，灵活性强且易于启动。不过随着十年来的发展，数据湖的问题也逐渐暴露。数据链路长/组件多导致出错率高、数据可靠性差；各个系统间不断的数据迁移同步给数据一致性和时效性带来挑战；湖里的数据杂乱无章，未经优化直接访问查询会出现性能问题；整体系统的复杂性导致企业建设和维护成本高等。
为了解决上述问题，结合数据湖和数据仓库优势的 Lakehouse 应运而生。底层依旧是低成本、开放的存储，上层基于类似 Delta lake/ Iceberg/ Hudi 建设数据系统，提供数据管理特性和高效访问性能，支持多样数据分析和计算，综合了数据仓库以及数据湖的优点形成了新的架构。存算分离架构可以进行灵活扩展；减少数据搬迁，数据可靠性、一致性和实时性得到了保障；支持丰富的计算引擎和范式；此外，支持数据组织和索引优化，查询性能更优。不过，因为 Lakehouse 还处于快速发展期，关键技术迭代快且成熟的产品和系统少。在可借鉴案例不多的情况下，企业如果想采用 Lakehouse，需要有一定技术投入。
2. 数据架构的对比
上图从多维度对数据仓库、数据湖、Lakehouse 进行了对比，可以明显看到 Lakehouse 综合了数据仓库和数据湖的优势，这也是 Lakehouse 被期待为“新一代数据架构基本范式”的原因。
1. Lakehouse 架构图
Lakehouse架构的简单抽象：Lakehouse = 云上对象存储 + 湖格式 + 湖管理平台
访问层：提供对上层引用的访问接口和协议
元数据层查询和定位数据
对象存储支持高吞吐的数据访问
开放的数据格式支持引擎直接读取
Declarative DataFrame API 利用SQL引擎的优化和过滤能力
优化层：通过数据分布、索引、辅助数据等方式提供高性能访问和高质量数据
Caching、Auxiliary data structures ( indexing and statistics )、data layout optimization，Governance
事务层：提供ACID隔离性、多版本、时间旅行等数仓管理特性
实现支持事务隔离的元数据层，指明每个Table版本所包含的数据对象
存储层：统一的存储层
云上对象存储，低成本，高可靠性，无限扩展，高吞吐，免运维
通用的数据格式，Parquet / Orc 等
2. Lakehouse 实现核心——湖格式
下面主要围绕 Delta Lake、Iceberg 两种湖格式展开介绍 Lakehouse 的特性。
① Delta lake
Delta lake：
关键实现：事务日志 – Single Source of Truth
事务日志以事务提交为粒度，按序记录了所有对表的操作 串行化隔离写操作，写操作保证原子性，MVCC+乐观锁控制并发冲突 快照隔离读操作，支持读历史版本数据，实现时间旅行 文件级别数据更新重新，实现局部数据更新和删除 基于增量日志的数据处理
Delta Lake on EMR：
针对 Delta Lake 开源版本的不足之处，阿里云 EMR 团队做了如下功能开发：
支持Zorder重新布局数据，结合dataskipping加速查询 实现高效的Zorder执行，7.8亿数据，2个字段，20分钟完成 支持Optimize，解决小文件问题，并支持自动compact
② Iceberg
Iceberg：
关键实现：
基于 Snapshot 的元数据层
Snapshot 中记录表当前版本的所有文件
每次写操作提交一个新的版本
基于 Snapshot 的读写隔离
基于snapshot差异做增量数据消费
阿里云在 Iceberg 上做的贡献：
Optimize：结合 JindoFS 提供缓存加速；自动小文件合并事务。
阿里云云生态对接：原生接入 OSS 对象存储；原生接入 DLF 元数据。
开源社区投入：1位Iceberg PMC，1位Iceberg Committer；贡献和维护 Iceberg 与 Flink 的集成模块；主导并设计社区的MOR流式 upsert 功能。
中文社区运营：维护国内最大的 Apache Iceberg数据湖技术社区（成员1250+）；国内最活跃的Apache Iceberg布道师之一；组织举办Apache Iceberg深圳站、Apache Iceberg上海站。
3. 选型参考
Databricks 在推出 Lakehouse 的概念后，就把公司的介绍改成了 The Databricks Lakehouse Platform。如下方的架构图所示，底层是云的基础设施（其中阿里云跟 Databricks 也有合作推出 Databricks 数据洞察）；数据入湖之后，在开放的数据存储之上，是结合了 Delta Lake 数据湖格式的数据管理和治理层（Data Management and Governance）。
1. 数据湖构建、管理、与分析过程
在具体介绍阿里云上相关架构之前，我们快速过一下一个数据湖的构建、管理和分析的几个阶段。
数据入湖与清洗：来自各个数据源的数据，以全量、增量、实时、ETL、数据迁移、元数据注册等方式入湖并清洗。 数据存储与管理：元数据管理与服务、权限控制与审计、数据质量控制、湖表管理与优化、存储管理与优化。 数据分析与训练：覆盖数据建模与开发、离线分析、实时计算、交互式分析、机器学习和算法等场景。 数据服务与应用：将训练分析后的数据同步到需求对应产品进行深度分析或进一步处理；直接对接商业智能、实时监控、数据科学、数据可视化等数据应用。
2. 阿里云 Lakehouse 架构
阿里云的Lakehouse架构，主要包括数据层、计算层、平台层，是在云原生数据湖架构之上，增加了Delta Lake / Hudi /Iceberg三个湖格式的支持，以及以DLF为主的数据湖管理模块。通过湖格式组件的特性，在数据湖的存储之上，支持ACID事务、多版本控制、数据分布、索引等管理特性和性能优化手段；通过DLF平台的数据管理和优化能力，自动化对湖内数据做分层、合并、索引等优化。
下面从统一元数据、CDC入湖、湖格式管理等几个方面重点介绍平台层面的主要功能和技术方案。
① DLF 统一元数据服务与治理
完全兼容 HMS 协议，支持多引擎访问 多引擎统一权限控制 利用云上 KV 存储提供高扩展性、高性能服务 支持 Delta lake/ Hudi/ Iceberg 元数据同步，统一视图
统一元数据目前已经是云上数据湖方案的标配，起核心价值主要是两个方面：一是为数据的使用者（人或者系统）提供湖内数据的统一的视图；二是泛Hadoop生态的系统基本都都对HMS有依赖，统一元数据服务解决了HMS的可用性、扩展性等问题，提供更稳定、扩展性更强的系统，更好服务生态内的其他组件。
多形态Spark：DLF 数据探索、Databrick Spark、Maxcompute Serverles Spark 实时计算：Flink（对接中） EMR 交互式分析：Trino、Impala EMR Hive ：阿里云贡献给社区的Delta Connector，完全开源
基于历史数据的元数据分析和管理
成本分析与优化、冷热分析与性能优化
② CDC 入湖产品化
模板+配置 => Spark任务 入湖工厂，自动生成 Spark SQL / Dataframe Code
Mysql、Kafka、Log Service、 TableStore 等实时写入 Hudi 数据湖
结合 Flink CDC，支持全托管和半托管Flink实时写入 Hudi 数据湖并同步元数据到 DLF，供其他引擎进一步分析。
阿里云贡献 Spark SQL 和 Flink SQL 读写 Hudi
实现 MERGER INTO 等 CDC 常用算子
③ 数据湖治理
数据湖内存放着大量的数据，对于数据的分析、管理和优化是保证数据湖不退化为数据沼泽，同时降低拥有成本、提高使用效率的必备手段。我们将对数据的治理分为三种类型：分析、管理和优化。通过一些离线或实时的分析，对用户当前数据的存储量、冷热分布、重要等级、过期/脏数据等做全面的分析，相当于给数据做一次全面的体检。然后提供一些管理和优化的手段，一方面可以根据具体问题让用户手动触发优化，另一方面，可以通过推荐合适的规则方案，由系统自动检测与优化。
所有的数据分析、管理和优化动作，都可以抽象为在数据集上的Workload，由DLF内部的Workload生成和调度平台统一构建和调度运行，基于底层K8s的统一资源池，可以提供最高效和低成本的运行环境。
1. 全托管数据湖方案
大数据平台架构：
在上云之前，客户的大数据部署在 IDC 机房，基于 CDH 自建的 Hadoop 集群。因为自建 IDC 机房安全性和稳定性没有保障，容灾能力差。客户决定将大数据平台迁移上云。
用户原先自建的平台上，用了非常多的Hadoop生态组件，运维挑战很大，不敢随意扩容与增删组件。同时研发对于具体的任务使用哪些组件来完成也比较困惑，研发效率和代码管理都比较混乱。在选型的过程中，客户希望能够尽量减少使用的组件，且降低运维的负担。所以最终选择了基于OSS+DLF+DDI的全托管数据湖方案，几乎没有运维的负担，同时将计算的组件收拢到Spark上。此外，基于OSS+DLF的数据具有非常高的扩展性，后续如果要接入其他分析类型（如基于Presto做交互式分析），直接拉起集群就可以做分析。这也正是存算分离+统一元数据最大的优势。
案例详细介绍：https://developer.aliyun.com/article/800210
全托管数据湖方案：
以 RDS 关系型数据库为例。
数据可以通过 Spark 进行 ETL 后入湖，或者通过在 DLF 上托管的 CDC 增量入湖/ Batch 全量入湖导入到对象存储 OSS中，在统一的元数据管理之下：
基于 Spark Streaming 做实时分析，进行实时报表/监控的展现
通过阿里云上 Databricks 数据洞察进行 ETL 任务，进行数据建模和进一步处理
拉起 EMR Presto 集群，以满足交互式分析场景
在这套方案中，除了半托管的 EMR Presto，其余组件都是全托管的。无论是底层存储，还是元数据或者 Spark 引擎的管理，无需用户自行管理，也不需要进行组件的维护和升级。提升使用体验的同时，大大降低了运维成本。
2. 存算分离实时数据湖
这是一个存算分离的实时数据湖案例。用户本来使用的是存算一体架构，Hive 元数据信息存储在 Hive MetaStore，数据存储在 HDFS 中，经常会出现坏盘的情况，给运维带来麻烦的同时增加了成本。另一方面 Hive Metastore 在数据量到达一定程度后，比如 Partition 分区数到了10万级别后，性能上会受到很大挑战。所以用户决定进行存算一体到存算分离架构的迁移。
3. Lakehouse 未来展望
湖格式能力会不断增强，接近数仓/数据库的能力：
多表事务（AWS Governed Table）
Optimize 功能越来越丰富（Caching，Clustering，Z-Ording...）
三种湖格式能力不断追平
湖格式与存储/计算集成度越来越高，以获得更高的性能：
存储层会出现面向湖格式的定制 API（如内置的Compaction API，目录级别的footer读）
为计算层提供更多面向性能优化的方案（二级索引，Column statistics）
湖管理平台能力越来越丰富和智能化：
统一元数据服务成为标配，Meta 托管化、服务化（Hudi Timeline Server）
治理和优化成为平台基础能力，并对用户不可见
综上，无论是从 Lakehouse 的特性来看，或是从各个厂商在 Lakehouse、在湖格式上的探索及建设来看，Lakehouse 很可能成为新一代大数据架构。
更多精彩内容可以关注我们的公众号：
今天的分享就到这里，谢谢大家。
在文末分享、点赞、在看，给个3连击呗~
分享嘉宾：
电子书下载
《大数据典藏版合集》电子书目录如上，感兴趣的小伙伴，欢迎识别二维码，添加小助手微信，回复『大数据典藏版合集』，即可下载。
关于我们：
🧐分享、点赞、在看，给个3连击呗！👇
