摘要：本文整理自阿里巴巴开发工程师、ApacheFlinkCommitter任庆生9月24日ApacheFlinkMeetup的分享。主要内容包括：FlinkCDC技术对比分析Flink+Kafka实时数据集成方案Demo：Flink+Kafka实现CDC数据实时集成与实时分析点击查看直播回放及演讲PPT1.FlinkCDC技术比较与分析1.1．ChangedataCapture（CDC）技术在广义的概念中，可以捕获数据变化的技术统称为CDC（ChangeDataCapture）。通常我们说CDC主要是面向数据库变化的，是一种捕捉数据库中数据变化的技术。CDC的主要应用有三个方面：数据同步，通过CDC将数据同步到其他存储位置，用于异地容灾或备份。数据分发，通过CDC从一个数据源中提取数据，然后分发给各个下游业务方进行数据处理和转换。数据获取，使用CDC读取源数据库中的数据后，通过ETL写入数据仓库或数据湖。根据实现机制，CDC可以分为两种：基于查询的CDC和基于日志的CDC。Query-basedCDC是通过定时调度离线任务来实现的，一般采用批处理方式，不能保证数据的实时性，数据的一致性也会受到影响。基于日志的CDC是通过实时消费数据库中的日志变化来实现的，比如通过connector直接读取MySQL的binlog来捕获变化。这种流处理方式可以实现低延迟，因此更好的保证了数据的实时性和一致性。1.2.FlinkCDC的技术优势在上图中，我们对比了几种常见的CDC方案。相比其他方案，FlinkCDC在功能上集成了很多优势：在实现机制上，FlinkCDC通过直接读取数据库日志来捕捉数据变化，保证了数据的实时性和一致性。在同步能力上，FlinkCDC支持全量和增量两种读模式，可以无缝切换。在数据连续性方面，FlinkCDC充分利用了ApacheFlink的checkpoint机制，提供断点续传功能。当作业失败并重新启动时，它可以直接从中断的位置开始恢复。在架构上，FlinkCDC的分布式设计使得用户可以开启多并发消费源库中的数据。在数据转换方面，FlinkCDC从数据库中读取后，可以通过DataStream、SQL等进行各种复杂的计算和数据处理。在生态方面，FlinkCDC依托强大的Flink生态和众多的连接器类型，可以将实时数据连接到各种外部系统。1.3.FlinkCDC全增量一体化框架FlinkCDC从2.0版本开始引入了增量快照框架，实现了数据库中全量和增量数据的一体化读取，并且可以在全量和增量读取之间进行无缝切换。FlinkCDCSource在读取全量数据时，会先将数据表中已有的数据按照主键分布（如上图中绿色方块所示）划分为多个Chunk，并将Chunk分布到多个供读者同时阅读Pick。对于数据变化频繁、现存数据量大的数据库，在全量同步过程中，同步的数据可能会发生变化。一些数据集成工具的解决方案是在读取前获取表锁，防止数据发生变化，然后读取全量数据。但是，这种解决方案将对在线业务产生更大的影响。为了解决这个问题，FlinkCDC的增量快照框架引入了watermark的概念：在开始全量同步之前，先获取数据库最新的binlog位置，记录为lowwatermark，如上图蓝色方块所示在，然后开始全文阅读。全量数据读取完毕后，CDC源会再次获取最新的binlog位置，并将其标记为高水位线，如上图第二个蓝色方块所示。抓取表相关的高低水位线之间的binlog事件（上图中黄色方块）是全量数据在读取阶段的数据变化，CDC源会合并这部分增量数据合并到现有快照中合并完成后，可以获得与源数据库完全一致的实时快照，过程中无需锁库，不影响正常运行在线业务。业界常用的另一个CDC工具是Debezium。与FlinkCDC相比，Debezium方案在全量读取前需要对数据库进行加锁，只能使用单并发读取。如果某个任务在同步过程中失败，则需要重新从全量数据中读取以保证一致性。FlinkCDC的增量快照框架方案在全读前不需要加锁，可以使用多个并发读。依靠Flink的checkpoint机制，如果同步过程中出现异常，可以快速从最新成功的checkpoint恢复读取。1.4.FlinkCDC社区发展自2020年7月成立以来，FlinkCDC社区受到了开发者的广泛关注，整个社区蓬勃发展。截至2023年1月，项目star数超过3000，超过70位贡献者提交了超过500个commit，项目分叉数量超过1200。特别感谢每一位参与FlinkCDC的开发者，为社区的蓬勃发展做出的突出贡献！2022年11月，FlinkCDC社区发布了最新的2.3版本，对MySQLCDC进行了多项稳定性和稳定性改进，新增了Db2CDCconnector，MongoDBCDCconnector接入了增量快照框架。详情请阅读FlinkCDC2.3发布公告：https://mp.weixin.qq.com/s/eo...2.Flink+Kafka实时数据集成方案上图为一个典型的数据同步场景.源数据库中的变更数据使用FlinkCDC同步到下游。如果下游业务方较多，需要同步的数据库表较多，或者数据处理逻辑复杂，每张数据表都需要启动一个Flink作业进行同步，这会对源数据库造成很大的压力。此外，一些热点表或数据库会被多个FlinkCDC同步任务频繁访问，也会增加数据库访问的压力。为了解决上述业务痛点，一个可行的设计是引入分布式能力数据管道中的消息队列中间件，缓解数据库压力。比如源库中发生变化的数据，先同步到Kafka，再由各业务方消费。但是引入消息队列之后，还有很多问题需要人工干预，比如配置CDCsources，配置Kafkasinks，手动创建Kafkatopic和partition。另外，基于目前FlinkCDC的设计，每张表都需要启动一个同步作业。如果数据库中的表很多，也会给源数据库带来很大的压力。针对以上问题，阿里云实时计算平台推出了Flink+Kafka实时数据整合方案。用户可以通过一条SQL语句快速将数据库同步到Kafka。该方案使用CREATETABLEAS(CTAS)语法和CREATEDATABASEAS(CDAS)语法，指定源表名或源库名，以及目标表名或目标库名，可以快速同步源库中的数据到target在Kafka中，不需要手动配置配置任务和创建Kafka主题/分区。此外，该解决方案支持将结构更改自动同步到源表。如果在源表中新增、删除或重命名了可为空的列，Kafkasink将动态调整用于写入的JSON格式，并根据更改后的表结构将数据写入Kafka消息中。按照目前FlinkCDC的设计，当整个数据库同步时，数据库中的每一张数据表都需要启动一个Flink作业进行消费。如果表的数量非常多，Flink作业的数量和消耗的资源也会非常多。整个数据库同步方案针对这个问题进行了优化。在Flink作业中，同一个数据库复用一个CDCSource实例，连接多个Sink，将不同表中的数据分发到不同的KafkaTopic中。因此，只需要启动一个Flink作业就可以同步数据库中的所有表。如果数据量很大，只需要调整同步作业的并发度，不需要启动多个作业来消费同一个数据库，大大降低了Flink对数据库连接数的压力。Flink+Kafka实时数据整合方案具有以下优势：只需要一条SQL（CTAS、CDAS）即可完成单表或全库的同步，无需重复配置作业参数即可启动多项工作。自动创建目标端Kafka主题和分区，用户无需在Kafka集群中手动配置。原生支持新增可空列、删除可空列、重命名列等表结构变更同步策略，可支持更多数据同步场景。3、Demo：Flink+Kafka实现CDC数据的实时集成和实时分析。数据库中有三张表，分别是产品表、订单表和运输表。通过CDAS全库的同步能力，一次性将数据同步到Kafka，下游有多条业务线消费Kafka中的数据。Flink作业将前三个表连接成一个宽表。如果没有中间Kafka或同步能力，需要启动多个Flink作业来消费源库中两个或多个数据表的变化数据，比如订单表本身，变化非常快，造成非常大的对数据库的影响。压力。我们将通过demo演示如何解决这个问题。Demo演示-看演讲视频23:00-36:00时间段点击查看直播回放和演讲PPT了解更多内容活动推荐阿里云基于ApacheFlink构建的企业级产品-实时计算Flink版现已开放活动：99元实时体验如果算上Flink版本（包年，10CU），就有机会获得Flink专属定制卫衣；3个月及以上的套餐还有15%的折扣！了解更多活动详情：https://www.aliyun.com/produc...
