聊聊流式数据湖Paimon(二)
当前的问题Apache Paimon 最典型的场景是解决了 CDC (Change Data Capture) 数据的入湖；CDC 数据来自数据库。一般来说，分析需求是不会直接查询数据库的。
[*]容易对业务造成影响，一般分析需求会查询全表，这可能导致数据库负载过高，影响业务
[*]分析性能不太好，业务数据库一般不是列存，查询部分列 Projection 性能太差
[*]没有 Immutable 的视图，离线数仓里面需要根据 Immutable 的一个分区来计算
所以需要通过 CDC 的方式同步数据库的数据到数据仓库或数据湖里。
CDC可以理解为是Changelog数据流。
目前典型的同步方式依然是 Hive 的全量与增量的离线合并同步方式。
https://cdn.nlark.com/yuque/0/2023/png/28551376/1703473431705-b43f2333-2788-483f-8de4-ce9d6643d7d8.png#averageHue=%23eeeff1&clientId=u93b89e70-394f-4&from=paste&height=166&id=u32a0f2c7&originHeight=208&originWidth=646&originalType=binary&ratio=1.25&rotation=0&showTitle=false&size=164057&status=done&style=none&taskId=u2333e647-dc8f-43ac-be81-c114788be41&title=&width=516.8
在 Hive 数仓里维护两张表：增量分区表和全量分区表，通过：
[*](按需) 初始化时使用 DataX 或 Sqoop 等工具同步整张数据库表到 Hive 全量表的分区中。
[*]每天定时 (比如凌晨0点30分) 同步增量数据 (通过 Kafka) 到 Hive 增量分区表，形成一个增量分区 T。
[*]将 增量分区 T 与 全量分区 T-1 进行合并，产出今天的 全量表 分区 T。
这个流程在今天也是主流的同步方式，离线数据提供一个 Immutable 的视图，让数据的可靠性大大增加。
但是它的问题不少：
[*]架构链路复杂度高：由于链路复杂，每天产出全量分区容易有问题导致不能按时产出，新增业务也比较复杂，全量和增量割裂。
[*]时延高：至少 T + 1 延时，而且需要等全量和增量合并完成。
[*]存储成本高：每天全量表一个分区存储所有数据，意味着 100 天就需要 100 倍的存储成本。
[*]计算成本高：每天需要读取全量数据，与增量数据进行全量合并，在增量数据不多时浪费严重。
引入Paimon
和其它数据湖不同的是，Paimon 是从流世界里面诞生的数据湖，所以它在对接流写流读、对接 Flink 方面都要比其它数据湖做得更好。
Flink 结合 Paimon 打造的入湖架构如下：
https://cdn.nlark.com/yuque/0/2023/png/28551376/1703473606036-014a6289-0208-4b76-95a9-2b59e8d08557.png#averageHue=%23ecf0f4&clientId=u93b89e70-394f-4&from=paste&height=262&id=ufcda175e&originHeight=328&originWidth=642&originalType=binary&ratio=1.25&rotation=0&showTitle=false&size=207805&status=done&style=none&taskId=u3716ef12-c83e-41e9-ae5a-6a6f7fcbdf4&title=&width=513.6
步骤如下：
[*]通过 Flink CDC 一键全增量一体入湖到 Paimon，此任务可以配置 Tag 的自动创建，然后通过 Paimon 的能力，将 Tag 映射为 Hive 的分区，完全兼容原有 Hive SQL 的用法。
只需一步。
Paimon 的每一次写都会生成一个 Immutable 的快照，快照可以被 Time Travel 的读取，但是快照会有过期被删除的问题，因此要解决此问题，可以基于快照创建 Tag；Tag 就是快照集合，通过Tag提供离线历史数据的访问。
流式入湖方式可以有如下多种方式：
[*]Flink SQL 入湖，SQL 处理，可以有函数等 Streaming SQL 的处理
[*]Paimon 一键 Schema Evolution 入湖，好处是 Schema 也会同步到下游 Paimon 表里：详见 https://paimon.apache.org/docs/master/cdc-ingestion/overview/
它的好处是：
[*]架构链路复杂度低，不再因为各种组件的问题导致链路延时，你只用运维这一个流作业，而且可以完全兼容原有 Hive SQL 用法。
[*]时延低：延时取决于流作业的 Checkpoint Interval，数据最低1分钟实时可见 (建议1-5分钟)。不但如此，Paimon 也提供了流读的能力，让你完成分钟级的 Streaming 计算，也可以写到下游别的存储。
[*]存储成本低：得益于湖格式的 Snapshot 管理，加上 LSM 的文件复用，比如同样是存储 100天的快照，原有 Hive 数仓 100 天需要 100 份的存储，Paimon 在某些增量数据不多的场景只需要 2 份的存储，大幅节省存储资源。
[*]计算成本低：得益于 LSM 的增量合并能力，此条链路只有增量数据的处理，没有全量的合并。可能有用户会担心，常驻的流作业会消耗更多的资源，对 Paimon 来说，你可以打开纯异步 Compaction 的机制，以 Paimon 优异的性能表现，只用少量的资源即可完成同步，Paimon 另有整库同步等能力帮助你节省资源。
参考
Flink + Paimon 数据 CDC 入湖最佳实践
Apache Paimon 实时数据湖 Streaming Lakehouse 的存储底座
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！
页:
[1]