共计 5679 个字符，预计需要花费 15 分钟才能阅读完成。
摘要：本文整顿自阿里云开源大数据表存储团队负责人，阿里巴巴高级技术专家李劲松（之信），在 Streaming Lakehouse Meetup 的分享。内容次要分为四个局部：
- 流计算邂逅数据湖
- Paimon CDC 实时入湖
- Paimon 不止 CDC 入湖
- 总结与生态
点击查看原文视频 & 演讲 PPT
一、流计算邂逅数据湖
流计算 1.0 实时预处理
流计算 1.0 架构截止到当初也是十分支流的实时数仓中的一个实时预处理的性能，能够通过流计算把音讯队列中的数据（比方：日志数据，CDC 数据等等），通过音讯队列将数据读过来，通过流计算，进行数据预处理，最终把后果写到 MySQL 中。
这个零碎的典型特点是，它能够面向在线服务的实时查问，这就意味着用户能够把数据通过在线服务查问集成到在线业务中，而后整条链路相当于为每个业务定制的 Pipeline，满足在线业务。这个零碎的毛病是，灵活性比拟低，面向业务要定制化开发。
流计算 2.0 实时数仓
为了解决灵活性的问题，这就要介绍上流计算 2.0 实时数仓了。
随着计算的倒退，越来越多的具备高性能的 OLAP 零碎诞生进去，比方 Hologres 等等。它们最大的特点是能够把数据通过结构化的形式落到 OLAP 零碎中，能够让业务依据本人灵便的需要来查问这些结构化数据。这样做的益处是，数据落进来之后，数据可能保留比拟原始的或通过简略预处理的状态，可能比拟灵便的提供给业务方进行实时查问。
查问性能高，向量化计算 +SSD 存储，实现毫秒响应返回；灵便度适中，比起之前齐全的预处理保留了更多的数据和更简单结构化的模式。然而因为 OLAP 零碎老本不低，不能把所有数据都保留到零碎中，只将近期的或最重要的数据保留。
流计算 3.0 实时湖仓
基于以上 2.0 的状况，咱们引入了流计算的第三个场景——流计算 3.0 实时湖仓。当用户不想再看到实时数据受到限制，灵活性足够大的时候，就能够把离线数仓的数据通过实时化的形式搬到这样一个反对实时化的存储上。把所有实时数据落到存储外面，所有的数据都能够被实时查问。这就是实时湖仓可能解决的问题。
实时湖仓最大限度的解决了灵便度的问题，它能够把所有数据积淀到湖中，通过实时伎俩做到业务可查问数据。然而它也带来了一些毛病，它的查问是不如 OLAP 引擎甚至不如在线服务的。所以说，实时湖仓尽管带来了灵活性，然而损失了一些查问的效率。
将来的倒退方向是，实时湖仓能够通过更多的 Index 和 DataSkipping 减速查问。这也是 Apache Paimon 诞生的起因。Apache Paimon 就是一个专门为 CDC 解决、流计算而生的数据湖，心愿为用户带来难受、主动湖上流解决体验。
上面将通过一个案例介绍 Apache Paimon 在实时入湖方面做的工作。
二、Paimon CDC 实时入湖
在介绍 Paimon CDC 实时入湖之前，先来看下传统 CDC 入仓是怎么做的。
置信运维过数仓的工程师都理解传统数仓的架构。它在解决 CDC 数据的时候，往往是通过上图中全量表加增量表的形式。这种形式是指，每天的增量数据都会落到一个 Hive 增量表中，同时另外保护一个 Hive 的全量表，而后每天增量表的数据就绪后，就把增量表数据和之前的全量表数据进行一次合成，生成一个新的 Hive 全量表。
这种形式的长处是能够实现离线数仓查问每天的全量数据，毛病是全量表每天都会保留一个全量，而增量表每天也会保留当日的增量，所以存储的老本会十分高，同时计算的老本也不低。
另外一个问题是，这种传统的 CDC 入仓形式的提早性十分大，岂但须要 T+1 能力读到昨天的数据，而且还要通过合并提早，这就对数据湖存储来讲是个很大的挑战。
实时数据湖的根底就是按主键更新，须要有实时更新的能力。Paimon CDC 入湖是怎么的流程呢？如下图所示。
比起上文提到的 Hive 全量表 + 增量表的形式，Paimon 不再须要定义分区表，只须要定义一个主键表即可。这样这个主键表能够通过 Flink CDC 或是 CDC 数据实时 Streaming Sync 到表中，并且在这个根底上，能够每天晚上零点之后打一个 Tag，这个 Tag 能够保护这张表过后的状态，每个 Tag 对应离线的一个分区。
这样一整套架构带来的益处是一张表能够三用而且提早低，它能够被实时查问、离线查问，也能够通过增量查问的形式，查问两个 Tag 之间的增量数据。
一键 CDC 入湖是 Paimon 专门为实时更新而生的，它能够实现高性能的入湖，并且通过这样的形式，相较于之前的入仓，存储老本大大降低，因为它是基于 LSM 复用文件来实现的。
接下来介绍下 Paimon CDC 简略的数据集成。
Paimon 集成的 Flink CDC 在开源社区提供了十分不便一键入湖，能够将 Flink CDC 数据同步到 Paimon 中，也能够通过整库同步作业把整个库成千盈百的表通过一个作业同步到多个 Paimon 表中。
如上图右侧图表可见，Paimon 在开源社区做的 CDC 入湖不只是有 CDC 入湖单表同步和整库同步，也有 Kafka 单表同步和整个同步。如果这些还不能满足，用户如果有本人的音讯队列和本人的格局，也能够通过 RichCdcRecord 这种编程形式达到入湖的成果。
接下来介绍下 Paimon 高性能入湖调优指南。
Paimon 在入湖方面，提供了灵便参数，让用户在写入性能、查问性能和存储空间中衡量。举个例子，当用户通晓作业反压了，能够选用 Paimon 的动静 Bucket 模式，也能够通过业务测出一个适合的 Bucket。如果这个时候还反压，能够调整 Checkpoint Interval，或是通过参数指定 Paimon Compaction 实现其永远不阻塞，让写入优先。
总而言之，Paimon 在这里提供了非常灵活的参数，能够让用户在流读、批读和更新场景当中做到相应的衡量。
上文提及 Paimon 是一张没有分区的表，Paimon 如何提供离线视图呢？
家喻户晓，离线数仓有个十分重要的货色，就是它须要数据有一个不可变的视图，不然两次计算出的后果就不一样了。所以 Paimon 提供了一个十分重要的性能，即 Create Tag，它能够在 Paimon 中指定一些 Tag，让这些 Tag 永不删除，永远可读。如上图左侧的示意。
第二局部最初一块内容介绍 Paimon LSM 文件存储的复用。
前文提及 Paimon 在这种场景下较之以前的数仓，文件存储会升高数倍甚至升高数十倍或数百倍。为什么它能够达到这样的成果呢？
如上图右侧 LSM 文件示意。LSM 有个特点是，它增量数据来了，不肯定须要合并到最底层的数据，也就是说最底层的这些文件，可能两个 Tag 之间齐全复用这些文件。因为增量数据不足以让最底层的数据参加合并，这样能达到的成果是两个 Tag 甚至一个月的 Tag，最底层的 LSM 树都没有产生过合并，意味着最底层的文件是全复用的。所以多个 Tag 之间，文件能够齐全复用，这样能达到最大的复用成果。
三、Paimon 不止 CDC 入湖
自从 Paimon 进入 Apache 孵化器后，多了十分多的贡献者，这对整个开源社区来讲都是一个飞跃的停顿。
当初 Paimon 有超过 83 位贡献者，造成一个十分凋敝的生态体系，他们不只是来源于阿里巴巴，也有来自其余公司贡献者。通过这些贡献者的奉献，让 Paimon 领有如上图右侧的全副性能。
Paimon 生态这边获得了比拟大的停顿。Paimon 之前次要是 Flink、Spark 等，当初还包含 StarsRocks、Doris 和 PrestoSQL 等等。这些都能在它们的计算上查问到 Paimon 的数据。
元数据蕴含 Hive Partitioned Table，能够通过这个把元数据保留到 HMS 上。用户也能够在 Hive 的 HMS 中查问到 Paimon 有哪些分区。
其余对于合并、内核、入湖等相干内容，能够去官网理解详情：https://paimon.apache.org/
接下来分享三个场景。
数据打宽在之前的施行中可能用 Flink 双流 join，离线中间接 join。这种形式在施行过程中有个难点就是不实用所有场景，而且老本比拟高。
所以 Paimon 这边做了很多工作，包含 Paimon 能够当做 Flink lookup join 的一张表来进行 join，包含 Paimon 的 Partial Update 能够反对同组件的打宽，而且能够定义 sequence-group，让各个字段能够有不同的笼罩形式。
上图中所示意的三种形式简略介绍下。
- 第一种是 Flink 双流 join 的形式，须要保护两边比拟大的 state，这也是老本比拟高的起因之一。
- 第二种是通过 Flink lookup join 的形式 lookup 到 Paimon 的数据，毛病是维表的更新不能更新到曾经 join 的数据上。
- 第三种是通过 Partial Update 的形式，即同组件的打宽的形式。举荐大家应用这种形式，它不仅具备高吞吐，还能带来近实时级别的提早。
除了以上三种，将来 Paimon 还将争取在外键打宽的能力上投入精力。外键打宽是通过分钟级延时的形式来升高整体实时 join 的打宽老本。
上面介绍两个 Paimon 另外两个能力，即 Paimon 音讯队列代替和 Paimon 离线表代替。
既然 Paimon 面向的是实时，不免有些人就会拿 Paimon 和 Kafka 架构进行比照。Paimon 这边做了很多工作，比方它反对 Append-only 表，即你能够不定义主键，只定义 Bucket number。当定义 Bucket number 的时候，bucket 就相似 Kafka 的 partition 概念，做到了严格保序，跟 Kafka 的音讯程序是截然不同的，而且也反对 Watermark 且对齐。在写入的过程中，可能主动合并小文件，也反对 Consumer ID 生产。
Paimon 在提供音讯队列能力的同时，也积淀了所有的历史数据，而不是像 Kafka 一样只能保留最近几天的数据。
所以通过业务图的形式能够看出，它的整体架构是想通过 Paimon 这种形式让用户在某些实时场景上替换 Kafka。Kafka 真正的能力是提供秒级延时，当业务不须要秒级延时的时候，能够思考应用 Paimon 来代替音讯队列。
Paimon 是一个数据湖，数据湖最常见的利用是离线表。Paimon 也领有这样的能力。
在 Append 表定义的时候，把 Bucket 表定义为 -1，那么 Paimon 就会认为这张表是一张离线表。Paimon 作为一张离线表能够代替原有的 Hive 数仓，比方 Paimon 反对批读批写，反对 INSERT OVERWRITE，也反对流读流写。而且 Paimon 能够主动合并小文件，也反对湖存储个性 ACID、Time Travel、Z-Order 排序减速查问和 Delete、Update 等等。
综上所述，Paimon 基本上能做到大部分离线表的能力。
四、总结与生态
通过前三局部的整体介绍，论断是：Paimon 根本成熟，是 Streaming Lake 的优选。
上面介绍下 Streaming Lakehouse 的生态阵容。Streaming Lakehouse 具备以下几个特点：
- 第一，Streaming Lakehouse 具备对立的数据湖存储能力；
- 第二，Streaming Lakehouse 具备对立的数据湖格局；
- 第三，Streaming Lakehouse 具备对立的数据湖治理。
明天 Streaming Lakehouse 领有十分丰盛的生态，它能够通过 Flink CDC，包含数据落到湖中，能够通过 Flink SQL ETL 以 Streaming 的形式，把数据流动起来，也能做到实时数据勘误。
在此基础上，Paimon 曾经领有了一个十分好的生态，欢送大家应用。
最初介绍下阿里云在 Paimon 上的实际。
咱们将 Paimon 和阿里云的 MaxCompute 产品做了深度集成，如上图右侧可见，这是一个简略的 Flink 的 Create Catalog，用户能够通过 Metastore 完满集成到 MaxCompute 数仓中。
这样指定后，再在 Flink 上创立表，它的元数据就会被同步到 MaxCompute 的元数据中，而后在 MaxCompute 那边就能够间接对这些表进行查问了。这样就能够达到一个 Flink 入湖 MaxCompute 剖析这样一个流程。
通过阿里云的实际，咱们能够看到 Paimon 的设计是非常灵活且凋谢的，它能够通过 Metastore 完满集成到阿里云或是其余企业原有的数仓中，集成之后能达到十分好的残缺链路的写入和剖析的成果。
Q&A
Q：请问 Paimon 是否有 Hudi 的实时旅行一样的性能么？
A：Paimon 自身就反对实时旅行，然而因为 Snapshot 每三分钟就会有一个，一天产生的量很大，也就是说数据的冗余会很大，对于存储老本不敌对。所以 Paimon 就提供了 Create Tag 的形式以解决这个问题，Snapshot 能够很快被删掉，你能够创立 Tag 保障 Time Travel 的有效性。
Q：Paimon 肯定水平上提供了 Kafka 的能力，提供了很多数据的接入形式，那么如果是文件，有没有特地好的接入形式呢？
A：你的意思是文件不留在 Queue 中，间接流到 Paimon 中。如果是这样的话，目前能够通过 Flink 或是 Spark 的这种批计算调度形式，来把文件同步到 Paimon 中。
Q：Paimon 能够被像 StarRocks 这样的产品查问，那像咱们应用阿里云的 ADB，是不是它也能够跟 ADB 有这样的连贯，在 ADB 里进行查问？
A：十分好的问题，我认为这是能够的，按时目前还没有和 ADB 集成，前面是能够推动的。
请关注 Paimon
流式数据湖的倒退须要你的反对：
- 关注微信公众号：Apache Paimon，理解行业实际与最新动静
- 进入 Paimon 交换钉钉群：搜寻 10880001919，探讨技术并失去实时的反对
- Github https://github.com/apache/incubator-paimon 点赞反对
点击查看原文视频 & 演讲 PPT
更多内容
流动举荐
阿里云基于 Apache Flink 构建的企业级产品 - 实时计算 Flink 版现开启流动：
0 元试用 实时计算 Flink 版（5000CU* 小时，3 个月内）
理解流动详情：https://click.aliyun.com/m/1000372333/
