聊聊流式数据湖Paimon(二)

本文主要是介绍聊聊流式数据湖Paimon(二)，对大家解决编程问题具有一定的参考价值，需要的程序猿们随着小编来一起学习吧！

当前的问题

Apache Paimon 最典型的场景是解决了 CDC (Change Data Capture) 数据的入湖；CDC 数据来自数据库。一般来说，分析需求是不会直接查询数据库的。

1. 容易对业务造成影响，一般分析需求会查询全表，这可能导致数据库负载过高，影响业务
2. 分析性能不太好，业务数据库一般不是列存，查询部分列 Projection 性能太差
3. 没有 Immutable 的视图，离线数仓里面需要根据 Immutable 的一个分区来计算

所以需要通过 CDC 的方式同步数据库的数据到数据仓库或数据湖里。

CDC可以理解为是Changelog数据流。

目前典型的同步方式依然是 Hive 的全量与增量的离线合并同步方式。

在 Hive 数仓里维护两张表：增量分区表和全量分区表，通过：

1. (按需) 初始化时使用 DataX 或 Sqoop 等工具同步整张数据库表到 Hive 全量表的分区中。
2. 每天定时 (比如凌晨0点30分) 同步增量数据 (通过 Kafka) 到 Hive 增量分区表，形成一个增量分区 T。
3. 将 增量分区 T 与 全量分区 T-1 进行合并，产出今天的 全量表 分区 T。

这个流程在今天也是主流的同步方式，离线数据提供一个 Immutable 的视图，让数据的可靠性大大增加。
但是它的问题不少：

1. 架构链路复杂度高：由于链路复杂，每天产出全量分区容易有问题导致不能按时产出，新增业务也比较复杂，全量和增量割裂。
2. 时延高：至少 T + 1 延时，而且需要等全量和增量合并完成。
3. 存储成本高：每天全量表一个分区存储所有数据，意味着 100 天就需要 100 倍的存储成本。
4. 计算成本高：每天需要读取全量数据，与增量数据进行全量合并，在增量数据不多时浪费严重。

引入Paimon

和其它数据湖不同的是，Paimon 是从流世界里面诞生的数据湖，所以它在对接流写流读、对接 Flink 方面都要比其它数据湖做得更好。
Flink 结合 Paimon 打造的入湖架构如下：

步骤如下：

1. 通过 Flink CDC 一键全增量一体入湖到 Paimon，此任务可以配置 Tag 的自动创建，然后通过 Paimon 的能力，将 Tag 映射为 Hive 的分区，完全兼容原有 Hive SQL 的用法。

只需一步。

Paimon 的每一次写都会生成一个 Immutable 的快照，快照可以被 Time Travel 的读取，但是快照会有过期被删除的问题，因此要解决此问题，可以基于快照创建 Tag；Tag 就是快照集合，通过Tag提供离线历史数据的访问。

流式入湖方式可以有如下多种方式：

1. Flink SQL 入湖，SQL 处理，可以有函数等 Streaming SQL 的处理
2. Paimon 一键 Schema Evolution 入湖，好处是 Schema 也会同步到下游 Paimon 表里：详见 https://paimon.apache.org/docs/master/cdc-ingestion/overview/

它的好处是：

1. 架构链路复杂度低，不再因为各种组件的问题导致链路延时，你只用运维这一个流作业，而且可以完全兼容原有 Hive SQL 用法。
2. 时延低：延时取决于流作业的 Checkpoint Interval，数据最低1分钟实时可见 (建议1-5分钟)。不但如此，Paimon 也提供了流读的能力，让你完成分钟级的 Streaming 计算，也可以写到下游别的存储。
3. 存储成本低：得益于湖格式的 Snapshot 管理，加上 LSM 的文件复用，比如同样是存储 100天的快照，原有 Hive 数仓 100 天需要 100 份的存储，Paimon 在某些增量数据不多的场景只需要 2 份的存储，大幅节省存储资源。
4. 计算成本低：得益于 LSM 的增量合并能力，此条链路只有增量数据的处理，没有全量的合并。可能有用户会担心，常驻的流作业会消耗更多的资源，对 Paimon 来说，你可以打开纯异步 Compaction 的机制，以 Paimon 优异的性能表现，只用少量的资源即可完成同步，Paimon 另有整库同步等能力帮助你节省资源。

参考

Flink + Paimon 数据 CDC 入湖最佳实践

这篇关于聊聊流式数据湖Paimon(二)的文章就介绍到这儿，希望我们推荐的文章对大家有所帮助，也希望大家多多支持为之网！