01
数据分析架构从 Hive 到 Lakehouse
旧的数据分析架构如 Hive、Hadoop、HDFS、MapReduce、HiveSQL、Hive 存储等，如今国内外的各大企业都在逐步转向 Lakehouse 架构，即 Spark、Flink、Presto，底层的湖存储格式：Iceberg、Delta、Hudi，以及下面数据存储在 HDFS、对象存储 OSS 或 S3。
1.1 Lakehouse 架构的优势
之所以进行架构的转变与迁移，是因为湖仓架构为数据分析与存储带来了诸多益处。
- 实现了计算存储分离
旧的架构 Hadoop 计算存储都在一个集群中，若要扩容，就要计算与存储部分同时扩容，但目前，各行各业都会有庞大的数据，却不一定可以匹配足够的计算，行业现状催生了计算存储分离的需求。如此，可以实现存储变大的同时，计算资源基本维持不变，当落到 OSS 对象存储上之后，计算存储分离变得非常简单。
- 实现了存储冷热分层
这是对象存储带来的独特优势。对于对象存储，我们可以利用它的冷存，因为其价格相对低廉，但其冷存访问成本会上升，因此，不常使用的数据可以使用冷存，从而大大降低成本。
- 操作更加灵活
前面提到的两点实际上 Hive 存储也可以实现，但相较而言，Lakehouse 操作更加灵活，因为湖存储格式提供了更多的 ACID，包括 DELETE、UPDATE 之类的语法，可以让数仓的操作更加方便，而不像 Hive 只能 INSERT OVERWRITE。
- 查询速度更快
因为湖存储带来的 Meta 上的 skipping 可使得数据根据 Filter 条件做出更多的下推，查询性能更高。
- 时效性到分钟级
或许前面四点对许多企业来说没有足够的吸引力，而且旧的 Hive 非常稳定，这可能会导致企业数据分析架构的迁移动力大大降低。但是，除前面提到的四点之外，Lakehouse 架构真正给业务带来价值的是可以使得时效性从 T+1 降低到分钟级。在这个方面，Flink 是当之无愧的专家。真正能打动企业迁移湖仓架构的关键是，能否将 Flink 融入湖仓架构中。
时效性是业务迁移的核心动力，而 Flink 是降低时效性的核心计算引擎，如下图所示：
首先是从 Hive 架构到 Lakehouse 架构的转变来看，Lakehouse 具有许多优势，它可以让计算更加方便，可以让部分时效性有一定程度的降低。
接下来是最右侧展示的是实时数仓 Flink + Kafka + OLAP 系统，它可以将时效性给降低到每秒级。Flink 也希望将它的时效性融入离线数仓中。
但是，目前 Lakehouse 与 Flink 实时数仓两者之间是割裂的，也对应到批计算和流计算，它们是完全割裂的两套，玩法大幅不同。
那是否能有一个中间的架构将 Flink 融入到 Lakehouse，把 Streaming 和 Lakehouse 的技术做一定的结合，解锁出样新的 Streaming Lakehouse 架构，实现整条链路的实时流动，达到分钟级的延时。此外，实现所有数据的沉淀可查，数据沉淀到 Lakehouse 中。
这套架构是完全的流批一体，它是通过结合 Flink 的 Streaming 计算和 Lakehouse 实现的。
综上，Lakehouse 架构一旦实现，将会对企业产生巨大的吸引力。但是这个融合并不容易，它的运行伴随着非常多的挑战。其面临的最大的挑战来自于湖格式。因为流技术与流当中产生的大量更新对湖存储格式带来了非常巨大的挑战。
02
Apache Paimon
2.1 Flink + Lakehouse 架构的探索
这部分分享包括 Flink 社区、阿里云在 Flink + Lakehouse 架构上的探索。
2023 年我们在 Lakehouse 做了很多改进。但早在 2020 年，阿里云就试图把 Flink 融入 Iceberg 中，在 Iceberg 中做了很多 Flink 的集成。Iceberg 是一种非常优秀的湖存储格式，它的架构非常简单，生态非常开放，设计非常简单。在把 Flink 融入 Iceberg 后，Iceberg 就有了 Flink 流读流写的能力，也在 Iceberg 社区推动方面支持更新能力。
但在使用过程中，我们也逐渐发现了一些问题，Iceberg 整体是针对离线设计的，它必须保持很简单的架构设计来面向各种计算引擎，这也对流更新过程中对其内核的改进带来了阻碍。因此，目前 Flink 写入 Iceberg，并不能太实时，我们更推荐在 1 小时左右的更新 SLA 保障。
在 Iceberg 中遇到困难之后，我们也在 Flink + Hudi 做了很多集成，许多企业也对这种架构进行过尝试。Hudi 原本面向 Spark，它是在 Spark 上增强其 Upsert 更新能力的 Format。Flink 在接入之后，Hudi Spark 的更新时延从小时级降低到 10 分钟。但是，在后续的进一步探索过程中也遇到了较多的问题，因为 Hudi 本身是面向 Spark，面向批计算设计的，它在架构上不符合流计算及更新的架构设计，同时 Hudi 历时已久，它有大量的 Future，这会给后面的设计带来很多架构上的挑战。所以对于 Flink + Hudi，我们更推荐 10 分钟的 SLA 保障。
我们需要更实时的湖格式。因此，在总结了 Iceberg 和 Hudi 遇到的架构上的挑战之后，我们重新设计了新的流式数据湖格式，即 Apache Paimon，其前身是 Flink Table Store，他有着湖存储 + LSM 原生的设计，面向流更新而设计，与 Flink、Spark 都有的较好集成。
从一开始就面向两套引擎设计：Flink 的流与 Spark 的批，重新设计 Paimon 使其架构能与 Flink、Spark 集成效果都优良。它有着强大的流读流写支持，给流式湖存储带来仅 1-5 分钟的延迟。
2.2 Apache Paimon
■ 2.2.1 架构
下图展示了 Apache Paimon 的架构图：
Paimon 是流批一体的湖存储格式，首先它只是一个文件格式，只是一堆代码将数据存储在 OSS 或者 HDFS 上，没有任何的服务。
可以使用 Flink CDC 来一键入湖到 Paimon 中，也可以通过 Flink SQL 或 Spark SQL 来批写、流写到 Paimon 当中。Paimon 也支持主流开源引擎，包括几乎现在所有的开源引擎。最后，Paimon 也可以被 Flink 或 Spark 流读，这也是它作为流式数据湖的特有能力之一。
目前，Paimon 有以下典型使用场景：
- CDC 更新入湖，可被准实时查询，并大幅简化入湖架构。
- 支持 Partial-Update 能力，基于相同的主键可以各个流实时地打宽，在 Paimon 当中能被分钟级给下游各种计算引擎查询。
- 支持流入的数据生成变更日志，给下游更好的流计算。简化流计算链路。
- Paimon 作为湖存储格式，有很强的 Append 处理，并给 Append 表上多了流读流写、Z-Order 排序后加速查询的能力。
■ 2.2.2 Apache Paimon 社区发展
2022 年 1 月，Flink Table Store 诞生，其实两年前 Flink Forward 时，就设想过要建设新的存储，直到 Flink Table Store 第一行代码在 Flink 社区诞生；孵化一年后，2023 年 1 月份产生了正式 0.3 的版本，之后我们决定从 Flink 和社区迁到 Apache 社区，并改名为 Apache Paimon，加强了生态，不再是 Flink 存储，而是面向社区所有计算引擎的存储；同年 9 月、12 月，随着版本的相继发布，Paimon 取得了巨大的进步；今年 12 月发布 0.6 版本，更新表和 Append 表都已达到完全生产可用的状态。
整体来看，目前有来自社区各行各业的 120 个 Contributers，大家把 Paimon 做得更好，Star 达到 1.5k。
在 Flink Forward Asia 里，有包括来自阿里云、同程旅行、汽车之家、联通，平安等企业关于 Paimon 的实践。
03
用户对话环节：Paimon 企业实践分享
下面通过同程旅行、汽车之家、联通数字科技有限公司用户的对话，让大家更加直接地了解基于 Flink + Paimon 构建 Streaming Lakehouse 的应用实践，以及选用 Flink + Paimon 黄金组合带来的业务收益。
3.1 同程旅行基于 Apache Paimon 的湖仓应用实践
■ 对话嘉宾
李劲松｜阿里云智能开源表存储负责人，Founder of Paimon，Flink PMC 成员
吴祥平｜同程旅行大数据专家，Apache Hudi & Paimon Contributor
■ 用户对话环节 1 - 精彩回顾
▼ 用户对话环节 1「视频回顾」▼
，时长09:33
吴祥平从事同程旅行大数据计算、湖仓相关的工作。
李劲松：早在 Flink Table Store 时期，同程旅行就已经使用了 Flink Table Store，从 Flink Table Store 生产应用上反馈了很多功能，可以分享一下同程旅行是如何发现 Flink Table Store 的？是经过了怎样的进化路线最终应用到 Paimon 的呢？
吴祥平：同程旅行实时湖仓，发展历程大概有三个：
- Spark + Apache Kudu
最开始，同程旅行与其他厂商一样，都是基于 Hive 做离线数仓，但随着实时需求的增多，引入了 Apache Kudu 组件。这条链路的特点，包括把原先发往 Hive ODS 层的数据，再发一份到 Apache Kudu 中，让一些依赖较少的项目在 Apache Kudu 上做应用。在此基础上，调起离线的 Spark 任务，使用 10 分钟或者 1 小时的调度去基于 Kudu 的原始表产生一些中间数据。
这个链路满足了一部分的需求，但我们在实践过程中也发现了很多问题，整个 Kudu 是基于 Spark 的离线调度，时延约为 10 分钟-1 小时，无法满足业务的时效性；同时 ODS 的数据一部分存在了 Hive 中，一部分存在 Kudu 中，两份数据有一定的重复，不太好复用；此外，Kudu 的维护性对数仓人员有一定难度；最后，整个 Kudu 是基于 SSD 构建的，因此整个数仓构建的成本相对较高。
- Flink + Apache Hudi
基于以上痛点，同程旅行在 2022 年引入了 Flink + Apache Hudi 的模式，基于此解决了一部分原先 Kudu 流式数仓的问题。首先数据复用性，我们基于 Hudi 实时更新了整个 ODS 层的表，这些表不仅可以做实时更新，在下游也可以使用。同时，也迸发出了基于 Hudi 做流读的需求。
随着实践的深入，我们发现该链路也有些问题，首先是 Hudi的同步效率，如 10+G 的表要同步 10+小时，同时同步资源也随着表的数据量加大，资源消耗也很大；其次是整个数据的一致性；此外查询效率也无法满足我们的应用场景。
- Flink + Paimon
因此，在今年 6 月甚至更早的时候就开始调研 Paimon。我们基于 Flink + Paimon 的实践解决了在 Hudi 上遇到的问题，包括全链路实时实践，提升了数据的读写效率，同时得益于 Paimon 的优秀设计，整个湖仓一体以及其更简单的状态管理，保障了最终数据的一致性，以及较全的表格式、主键更新等。
李劲松：目前，Paimon 在同程内部大致有多少生产作业？大约有多大的规模呢？
吴祥平：同程旅行目前已将原有基于 Hudi 的湖仓切换了约 80%到 Paimon 中，其中约有 500+任务，也基于整个 Paimon 的全链路实时化场景构建了 10+个场景，还基于 Paimon 的 Lookup 引擎做“批”，也有 10+个场景，数据量在 100TB 左右。整体的数据条数是 1000 亿左右。
李劲松：您可以分享一下整体的架构和具体的收益吗？
吴祥平：同程旅行目前主要是以联邦的 HDFS 做存储底座，中间采用全新的湖仓架构，基于 Paimon 做实时和离线的混合湖仓，使用 Paimon 不同的表引擎，上层基于 Flink、Spark、Trino、StarRocks 做查询引擎。使用这套架构之后，整个 ODS 层的同步资源节省了 30%左右，读写性能也有很大的提升，写入约提升三倍，部分查询有七倍左右的提升，效果非常明显；其次，基于 tag 能力，因为可以复用大部分重复数据，所以在导出场景上也节省了 40%左右的存储；另外，由于整个中间数据可复用，指标开发人员可以基于中间可复用的数据，开发效率提升约 50%，原先要花两个小时甚至一天的时间，现在很快就可以开发出来。
李劲松：可以看出，Paimon 对生产实践有很大的业务价值，可以再分享一下未来的规划吗？
吴祥平：首先，随着整个 Paimon 应用的发展，我们发现其实湖仓与原先的 Hive 有很大区别，包括一些额外的管理服务、清理服务、合并服务等，我们还希望用户能够像使用 Hive 一样使用湖仓表，所以未来会把管理服务做更好的集成；此外，我们会把现有的 Hive 数仓逐步往 Paimon 上转换，把存量的尽量都往 Lakehouse 架构上转；同时，我们也会跟进整个社区的流式血缘和数据修复能力；最后，在基于 Paimon 的流式湖仓上面更快速地构建链路。
3.2 汽车之家基于 Apache Paimon 的流式湖仓应用
■ 对话嘉宾
李劲松｜阿里云智能开源表存储负责人，Founder of Paimon，Flink PMC 成员
邸星星｜汽车之家大数据计算平台负责人
■ 用户对话环节 2 - 精彩回顾
▼ 用户对话环节 2「视频回顾」▼
，时长10:14
邸星星来自汽车之家大数据计算平台，汽车之家涵盖了看车、买车、用车、换车全生命周期，致力于帮助用户省心省时省钱。本人在大数据行业从事了九年的工作，是 Flink 较早的深度用户，在大数据方向上和开源社区有较多的互动。
李劲松：可以分享一下汽车之家的大数据的架构吗？以及 Flink 和 Paimon 在其中主要发挥了哪些作用？
邸星星：与前面老师分享的架构类似，同样也分了几层，如下图：
- 在接入层，业务数据主要分为两部分，一部分主要来自于关系数据库，其中包括 SQLServer、MySQL 和 TiDB；另一部分来自日志数据，其中日志数据有端上的，如点击流的数据，也有各种应用日志。
- 在传输层，也是通过 AutoKafka，根据不同的业务划分出很多的集群。
- 在计算层，以 Flink 引擎为基础，其底层运行在 YARN 或 K8S 上。
- 在存储层我们支持各类应用场景，如关系数据库，KV 存储（特征工程或线上业务)，日志检索场景的 Elasticsearch、OLAP 场景的 StarRocks、还有今天的主角 Paimon。Flink 是实时计算引擎的底座，同样的我们把 Paimon 看做是湖格式的底座，Flink + Paimon 承载了流式湖仓的能力。
李劲松：汽车之家为什么要选用 Paimon 呢？Paimon 为汽车之家解决了什么问题呢？Flink + Paimon + StarRocks 这个铁三角具体解决什么问题呢？
邸星星：其实汽车之家与前面的老师都有过类似的经历，如同程旅行，不同的是汽车之家其实是从 Iceberg 切换到 Paimon 的。因为汽车之家在 2021 年与 Iceberg 社区有比较深度的合作，当时我们也在讨论如何做湖格式的落地，最终认为 Iceberg 在流式计算上支持效果不好，在更新场景下其写吞吐能力非常高，但在数据查询效率上有一些问题，需要额外的任务把数据合并之后才能达到较好的性能。因此，汽车之家当时也是出于在流方面支持的角度选择了 Paimon。因为 Paimon 在流上支持更完备，与 Flink 有深度的集成，包括流式的读取，数据在写到 Paimon 中后，下游还可以用 Flink 再去消费 Paimon 的增量数据，同时能保证数据的有序性。还有在社区支持方面，Iceberg 是外国人的主导的社区，而 Paimon 包括 Flink 社区，与国内的人交流沟通成本低，效率高。
邸星星：关于铁三角，我们前面介绍了 Flink，Flink 是实时计算的底座，Paimon 是湖格式的底座，他们本身解决了数据的时效性问题。时效性的问题是我们最大的痛点，在很多场景下，前面曹操出行的老师也提到，高层的经营决策分析，包括一线的运营，其实不一定要实现秒级时效性，5 分钟的时效性完全满足其分析的需求。可以说大部分的分析场景无需纯实时的方案，而 Flink+Paimon 构建的流式湖仓，时效性方面刚好可以做到批和流的中间状态，实现流批一体。
而数据的应用效率方面，不得不提到 StarRocks，数据近实时地写到 Paimon 后，还可以基于 StarRocks 做查询的加速。我们内部的各个系统已经把 Paimon + StarRocks 整个应用链路都打通了，比如 IDE 开发平台、报表系统、多维分析等系统。
总之，Flink + Paimon 解决了数据时效性的问题，Paimon + StarRocks 解决了数据分析效率的问题。
李劲松：那关于上面提到的这些，汽车之家在哪些场景有相关的应用呢？
邸星星：因为 Paimon 的功能在湖格式中比较全面的，汽车之家的场景与前面大家提到的类似，如支持模型训练的实时样本，今年我们把推荐的训练样本从原来的 T+1、H+1 提升到了分钟级的时效性，主要用到了 Paimon 的部分更新能力。因为标签的拼接就是一个 Join 的操作，用传统的方式 Join，会保存大量的状态数据，如说多个流间 Join 较复杂，资源占用较高，开发成本较高。使用 Paimon 的 Partial-Update 能力，提前定义主键，然后每个流里写自己的数据，开发成本大幅降低，逻辑也比较简单。另外在一些时效性要求较高的分析、报表场景也在应用。
3.3 联通基于 Apache Paimon 的流式数据湖应用实践
■ 对话嘉宾
李劲松｜阿里云智能开源表存储负责人，Founder of Paimon，Flink PMC 成员
王云朋｜联通数科大数据高级技术专家，Apache Paimon Contributor
■ 用户对话环节 3 - 精彩回顾
▼ 用户对话环节 3「视频回顾」▼
，时长07:19
王云朋来自联通数字科技有限公司，今天主要介绍 Paimon 在联通的一些实践和应用。中国联通 2021 年初将原本的五家专业子公司合并成立了联通数字科技有限公司，全面整合了云计算、大数据、物联网、AI、区块链、安全等一些基础能力，打造综合的数字化产品和运营体系，来更好的赋能千行百业。我从事数据研发工作多年，目前服务于数据智能事业部的数据计算研发团队，主要负责公司的万亿级实时计算平台和流式湖仓的建设工作。
李劲松：联通是怎么开始使用 Paimon 的呢？以前的架构是怎样的演化过程呢？
王云朋：联通引入 Paimon 是在实时计算平台的演进中产生了一些数据关联、融合的需求，进而引进 Paimon 来解决。大家可以看到早期平台的实时处理技术是通过使用 Spark Streaming 进行微批的处理，此时主要问题是时延较高，状态支持不好。后来为了提高时效性，实现有状态的流计算，就引入了 Flink 作为计算框架。但最初的业务主要是基于事件的规则匹配它的数据的关联性比较低，随着业务的发展，有一些流流关联、流批关联、流批融合场景出现。我们当时实现的方案主要是通过使用 Flink 的状态来实现数据的关联和融合。还有一种依赖外部数据库，如 HBase Redis，因为联通的数据量级非常大，单表数据量也很大，会导致一些大状态的问题，对外部数据库的依赖也无法实现海量数据的处理。最根本的问题是在存储层面流批数据割裂，导致了数据冗余，数据一致性也难以保证，整个处理的链路非常复杂，就需要把流数据、批数据融合。后来我们希望通过使用 Flink + Paimon 架构，利用 Paimon 的流批一体读写的特性和高效实时更新能力，在流式湖仓实践方面进行探索，希望能够达到流批一体的存储、计算，简化处理架构的效果。
李劲松：刚刚您提到了数据量很大，那么具体有多少呢？
王云朋：联通的数据体量非常大，目前在流平台上面运行的流任务总数近 700 个，日增数据量约为 1000TB，日处理量的在万亿级别。目前 Paimon 表 100 多张，主要是一些主键表，单表的主键数一般在 8 亿左右，最大的表的主键数是 170 亿，写入的流量最大的一张 Paimon 表约为每天写入 1000 亿的运营商数据。
李劲松：联通目前大致的大数据的架构和应用场景能简单分享一下吗？
王云朋：在联通中，一般针对分钟级时延要求的业务，并且实时数据和离线数据有关联和融合的业务，我们会使用 Paimon 来实现。下面时比较典型的场景，即建设以用户为中心的全景视图：
它要将用户相关的一些基本信息、使用信息、行为信息进行关联整合、实时更新，统一支撑上层的实时订阅、实时特征、实时安全等业务。我们的建设思路是：存储层是使用 Paimon 表作为存储，数据处理层使用 Flink，数据源主要包括数据库的变更日志、用户的行为数据、最新位置、上网偏好等。数据源接入之后，ODS 先入湖，在湖上进行分层建设，建设主题湖表，主要是一些关联打宽的操作，简单的关联使用 Paimon 和 Flink 在存储层实现关联，减少状态量，实现流批一体的存储，保证了数据的一致性，处理架构也简化了很多。
据实践经验，主机资源减少了 50%左右，包括数据的订正、批量的分析，以及中间结果的实时查询都有了更好的支持。此外，社区很活跃，使用过程中遇到的问题会很快得到解决。
总结
综上所述，Paimon 真正实现了流批一体，把流和批融合到了一起，加上 Flink 和流批一体的计算、存储，真正融合了流和批的架构。
