Flink 如何实时分析 Iceberg 数据湖的 CDC 数据

阿里云云栖号

于 2021-02-26 09:29:36 发布

阅读量1.1k

点赞数

分类专栏：云栖号技术分享

本文链接：https://blog.csdn.net/yunqiinsight/article/details/114113671

版权

简介：数据湖的架构中，CDC 数据实时读写的方案和原理

本文由李劲松、胡争分享，社区志愿者杨伟海、李培殿整理。主要介绍在数据湖的架构中，CDC 数据实时读写的方案和原理。文章主要分为 4 个部分内容：

常见的 CDC 分析方案
为何选择 Flink + Iceberg
如何实时写入读取
未来规划

一、常见的 CDC 分析方案

我们先看一下今天的 topic 需要设计的是什么？输入是一个 CDC 或者 upsert 的数据，输出是 Database 或者是用于大数据 OLAP 分析的存储。

我们常见的输入主要有两种数据，第一种数据是数据库的 CDC 数据，不断的产生 changeLog；另一种场景是流计算产生的 upsert 数据，在最新的 Flink 1.12 版本已经支持了 upsert 数据。

1.1 离线 HBase 集群分析 CDC 数据

我们通常想到的第一个方案，就是把 CDC upsert 的数据通过 Flink 进行一些处理之后，实时的写到 HBase 当中。HBase 是一个在线的、能提供在线点查能力的一种数据库，具有非常高的实时性，对写入操作是非常友好的，也可以支持一些小范围的查询，而且集群可扩展。

这种方案其实跟普通的点查实时链路是同一套，那么用 HBase 来做大数据的 OLAP 的查询分析有什么问题呢？

首先，HBase 是一个面向点查设计的一种数据库，是一种在线服务，它的行存的索引不适合分析任务。典型的数仓设计肯定是要列存的，这样压缩效率和查询效率才会高。第二，HBase 的集群维护成本比较高。最后，HBase 的数据是 HFile，不方便与大数据里数仓当中典型的 Parquet、Avro、Orc 等结合。

1.2 Apache Kudu 维护 CDC 数据集

针对 HBase 分析能力比较弱的情况，社区前几年出现了一个新的项目，这就是 Apache Kudu 项目。Kudu 项目拥有 HBase 的点查能力的同时，采用列存，这样列存加速非常适合 OLAP 分析。

这种方案会有什么问题呢？

首先 Kudu 是比较小众的、独立的集群，维护成本也比较高，跟 HDFS、S3、OSS 比较割裂。其次由于 Kudu 在设计上保留了点查能力，所以它的批量扫描性能不如 parquet，另外 Kudu 对于 delete 的支持也比较弱，最后它也不支持增量拉取。

1.3 直接导入 CDC 到 Hive 分析

第三种方案，也是大家在数仓中比较常用的方案，就是把 MySQL 的数据写到 Hive，流程是：维护一个全量的分区，然后每天做一个增量的分区，最后把增量分区写好之后进行一次 Merge ，写入一个新的分区，流程上这样是走得通的。Hive 之前的全量分区是不受增量的影响的，只有当增量 Merge 成功之后，分区才可查，才是一个全新的数据。这种纯列存的 append 的数据对于分析是非常友好的。

这种方案会有什么问题呢？

增量数据和全量数据的 Merge 是有延时的，数据不是实时写入的，典型的是一天进行一次 Merge，这就是 T+1 的数据了。所以，时效性很差，不支持实时 upsert。每次 Merge 都需要把所有数据全部重读重写一遍，效率比较差、比较浪费资源。

1.4 Spark + Delta 分析 CDC 数据

针对这个问题，Spark + Delta 在分析 CDC 数据的时候提供了 MERGE INTO 的语法。这并不仅仅是对 Hive 数仓的语法简化，Spark + Delta 作为新型数据湖的架构（例如 Iceberg、Hudi），它对数据的管理不是分区，而是文件，因此 Delta 优化 MERGE INTO 语法，仅扫描和重写发生变化的文件即可，因此高效很多。