共计 5643 个字符，预计需要花费 15 分钟才能阅读完成。
简介：徐榜江在 5.21 Flink CDC Meetup 的分享。摘要：本文整顿自 Apache Flink Committer，Flink CDC Maintainer，阿里巴巴高级开发工程师徐榜江（雪尽）在 5 月 21 日 Flink CDC Meetup 的演讲。次要内容包含：Flink CDC 技术传统数据集成计划的痛点基于 Flink CDC 的海量数据的实时同步和转换 Flink CDC 社区倒退 点击查看直播回放 & 演讲 PDF 一、Flink CDC 技术
CDC 是 Change Data Capture 的缩写，是一种捕捉变更数据的技术，CDC 技术很早就存在，倒退至今，业界的 CDC 技术计划泛滥，从原理上能够分为两大类：一类是基于查问的 CDC 技术，比方 DataX。随着当下场景对实时性要求越来越高，此类技术的缺点也逐步凸显。离线调度和批处理的模式导致提早较高；基于离线调度做切片，因此无奈保障数据的一致性；另外，也无奈保障实时性。一类是基于日志的 CDC 技术，比方 Debezium、Canal、Flink CDC。这种 CDC 技术可能实时生产数据库的日志，流式解决的模式能够保障数据的一致性，提供实时的数据，能够满足当下越来越实时的业务需要。
上图为常见开源 CDC 的计划比照。能够看到 Flink CDC 的机制以及在增量同步、断点续传、全量同步的体现都很好，也反对全增量一体化同步，而很多其余开源计划无奈反对全增量一体化同步。Flink CDC 是分布式架构，能够满足海量数据同步的业务场景。依附 Flink 的生态劣势，它提供了 DataStream API 以及 SQL API，这些 API 提供了十分弱小的 transformation 能力。此外，Flink CDC 社区和 Flink 社区的开源生态十分欠缺，吸引了很多社区用户和公司在社区开发共建。
Flink CDC 反对全增量一体化同步，为用户提供实时一致性快照。比方一张表里有历史的全量数据，也有新增的实时变更数据，增量数据一直地往 Binlog 日志文件里写，Flink CDC 会先同步全量历史数据，再无缝切换到同步增量数据，增量同步时，如果是新增的插入数据（上图中蓝色小块），会追加到实时一致性快照中；如果是更新的数据（上图中黄色小块），则会在已有历史数据里做更新。Flink CDC 相当于提供了实时物化视图，为用户提供数据库中表的实时一致性快照，用于能够对这些数据做进一步加工，比方荡涤、聚合、过滤等，而后再写入上游。二、传统数据集成计划的痛点
上图为传统数据入仓架构 1.0，次要应用 DataX 或 Sqoop 全量同步到 HDFS，再围绕 Hive 做数仓。此计划存在诸多缺点：容易影响业务稳定性，因为每天都须要从业务表里查问数据；天级别的产出导致时效性差，提早高；如果将调度距离调成几分钟一次，则会对源库造成十分大的压力；扩展性差，业务规模扩充后极易呈现性能瓶颈。
上图为传统数据入仓 2.0 架构。分为实时和离线两条链路，实时链路做增量同步，比方通过 Canal 同步到 Kafka 后再做实时回流；全量同步个别只做一次，与每天的增量在 HDFS 上做定时合并，最初导入到 Hive 数仓里。此形式只做一次全量同步，因而根本不影响业务稳定性，然而增量同步有定时回流，个别只能放弃在小时和天级别，因而它的时效性也比拟低。同时，全量与增量两条链路是割裂的，意味着链路多，须要保护的组件也多，零碎的可维护性会比拟差。
上图为传统 CDC ETL 剖析架构。通过 Debezium、Canal 等工具采集 CDC 数据后，写入音讯队列，再应用计算引擎做计算荡涤，最终传输到上游存储，实现实时数仓、数据湖的构建。
传统 CDC ETL 剖析里引入了很多组件比方 Debezium、Canal，都须要部署和保护，Kafka 音讯队列集群也须要保护。Debezium 的缺点在于它尽管反对全量加增量，但它的单并发模型无奈很好地应答海量数据场景。而 Canal 只能读增量，须要 DataX 与 Sqoop 配合能力读取全量，相当于须要两条链路，须要保护的组件也减少。因而，传统 CDC ETL 剖析的痛点是单并发性能差，全量增量割裂，依赖的组件较多。三、基于 Flink CDC 的海量数据的实时同步和转换 Flink CDC 的计划可能给海量数据的实时同步和转换带来什么改善？
Flink CDC 2.0 在 MySQL CDC 上实现了增量快照读取算法，在最新的 2.2 版本里 Flink CDC 社区 将增量快照算法形象成框架，使得其余数据源也能复用增量快照算法。增量快照算法解决了全增量一体化同步里的一些痛点。比方 Debezium 晚期版本在实现全增量一体化同步时会应用锁，并且且是单并发模型，失败重做机制，无奈在全量阶段实现断点续传。增量快照算法应用了无锁算法，对业务库十分敌对；反对了并发读取，解决了海量数据的解决问题；反对了断点续传，防止失败重做，可能极大地提高数据同步的效率与用户体验。
上图为全增量一体化的框架。整个框架简略来讲就是将数据库里的表按 PK 或 UK 切分成 一个个 chunk，而后分给多个 task 做并行读取，即在全量阶段实现了并行读取。全量和增量可能主动切换，切换时通过无锁算法来做无锁一致性的切换。切换到增量阶段后，只须要独自的 task 去负责增量局部的数据解析，以此实现了全增量一体化读取。进入增量阶段后，作业不再须要的资源，用户能够批改作业并发将其开释。
咱们将全增量一体化框架与 Debezium 1.6 版本做 简略的 TPC-DS 读取测试比照，customer 单表数据量 6500 万，在 Flink CDC 用 8 个并发的状况下，吞吐晋升了 6.8 倍，耗时仅 13 分钟，得益于并发读取的反对，如果用户须要更快的读取速度，用户能够减少并发实现。
Flink CDC 在设计时，也思考了面向存储敌对的写入设计。在 Flink CDC 1.x 版本中，如果想实现 exactly-once 同步，须要配合 Flink 提供的 checkpoint 机制, 全量阶段没有做切片，则只能在一个 checkpoint 里实现，这会导致一个问题：每个 checkpoint 两头要将这张表的全量数据吐给上游的 writer，writer 会将这张表的全量数据混存在内存中，会对其内存造成十分大的压力，作业稳定性也特地差。Flink CDC 2.0 提出了增量快照算法后，通过切片可能将 checkpoint 粒度降至 chunk，并且 chunk 大小是用户可配置的，默认是 8096 条，用户能够将其调至更小，加重 writer 的压力，缩小内存资源的应用，晋升上游写入存储时的稳定性。
全增量一体化之后，Flink CDC 的入湖架构变得非常简单，且不会影响业务的稳定性；可能做到分钟级的产出，也就意味着能够实现近实时或实时剖析；并发读取实现了更高的吞吐，在海量数据场景下有着不俗的体现；链路短，组件少，运维敌对。
有了 Flink CDC 之后，传统 CDC ETL 剖析的痛点也失去了极大改善，不再须要 Canal、Kafka 音讯队列等组件，只须要依赖 Flink，实现了全增量一体化同步和实时 ETL 加工的能力，且反对并发读取，整个架构链路短，组件少，易于保护。
依靠于 Flink DataStream API 以及易用的 SQL API，Flink CDC 还提供了十分弱小欠缺的 transformation 能力，且在 transformation 过程中可能保障 changelog 语义。在传统计划里，在 changelog 上做 transformation 并保障 changelog 语义是十分难以实现的。
海量数据的实时同步和转换示例 1：Flink CDC 实现异构数据源的集成 这个业务场景是业务表比方产品表和订单表在 MySQL 数据库里，物流表存在 PG 数据库里，要实现异构数据源的集成，并且在集成过程做打宽。须要将产品表、订单表与物流表做 Streaming Join 之后再将后果表写入库里。借助 Flink CDC，整个过程只须要用 5 行 Flink SQL 就可能实现。这里应用的上游存储是 Hudi，整个链路能够失去分钟级甚至更低的产出，使围绕 Hudi 做近实时的剖析成为了可能。
海量数据的实时同步和转换示例 2：Flink CDC 实现分库分表集成 Flink CDC 对分库分表做了十分欠缺的反对，在申明 CDC 表时反对应用正则表达式匹配库名和表名，正则表达式意味着能够匹配多个库以及这多个库下的多张表。同时提供了 metadata column 的反对，能够晓得数据来自于哪个 数据库、来自于哪张表，写入上游 Hudi 时，能够带上 metadata 申明的两个列，将 database_name、table_name 以及原始表中的 主键（例子中为 id 列）作为新的主键，只需三行 Flink SQL 即可实现分库分表数据的实时集成，非常简单。
依靠于 Flink 丰盛的生态，可能实现很多上下游的扩大，Flink 本身就有丰盛的 connector 生态。Flink CDC 退出之后，上游有了更丰盛的源能够摄取，上游也有丰盛的目标端能够写入。
海量数据的实时同步和转换示例 3：三行 SQL 实现单品累计销量实时排行榜 这个 Demo 演示在无需任何依赖的前提下，通过 3 行 SQL 实现商品的实时排行榜。首先在 Docker 里增加 MySQL 和 ElasticSearch 镜像，ElasticSearch 是目标端。将 Docker 拉起后，下载 Flink 包以及 MySQL CDC 和 ElasticSearch 的两个 SQL Connector jar。拉起 Flink 集群和 SQL Client。在 MySQL 内建库建表，灌入数据，更新后再用 Flink SQL 做一些实时加工和剖析，写入 ES。在 MySQL 的数据库里结构一张订单表并插入数据。
上图第一行 SQL 是创立订单表，第二行是创立后果表，第三行是做 group by 的查问实现实时排行榜性能，再写入到第二行 SQL 创立的 ElasticSearch 表中。
咱们在 ElasticSearch 里做了可视化出现，能够查看到随着 MySQL 中订单源源不断地更新，ElasticSearch 的排行榜会实时刷新。四、Flink CDC 社区倒退
在过来的一年多工夫，社区发了 4 个大版本，contributor 和 commits 数量在一直增长，社区也越来越沉闷。咱们始终保持将外围的 feature 全副提供给社区版，比方 MySQL 的百亿级超大表、增量快照框架、MySQL 动静加表等高级性能。
最新的 2.2 版本中同样新增了很多性能。首先，数据源方面，反对了 OceanBase、PolarDB-X、SqlServer、TiDB。此外，不断丰富了 Flink CDC 的生态，兼容了 Flink 1.13 和 1.14 集群，提供了增量快照读取框架。另外，反对了 MySQL CDC 动静加表以及对 MongoDB 做了欠缺，比方反对指定的汇合，通过正则表达式使其更加灵便敌对。
除此之外，文档也是社区特地重要的一部分。咱们提供了独立的版本化社区网站，在网站里不同版本对应不同版本的文档，提供了丰盛的 demo 以及中英文的 FAQ，帮忙老手疾速入门。
在社区的多个要害指标，比方创立的 issue 数，合并的 PR 数，Github Star 数上，Flink CDC 社区的体现都十分不错。
Flink CDC 社区的将来布局次要蕴含以下三个方面：框架欠缺：增量快照框架目前只反对 MySQL CDC，Oracle、PG 和 MongoDB 正在对接中，心愿将来所有数据库都可能对接到更好的框架上；针对 Schema Evolution 和整库同步做了一些探索性的工作，成熟后将向社区提供。生态集成：提供更多 DB 和更多版本；数据湖集成方面心愿链路更通顺；提供一些端到端的计划，用户毋庸关怀 Hudi 和 Flink CDC 的参数。易用性：提供更多开箱即用的体验以及欠缺文档教程。问答 Q：CDC 什么时候可能反对整库同步以及 DDL 的同步？A：正在设计中，因为它须要思考到 Flink 引擎侧的反对与配合，不是独自在 Flink CDC 社区内开发就能够实现的，须要与 Flink 社区联动。Q：什么时候反对 Flink 1.15A：目前生产上的 Flink 集群还是以 1.13、1.14 为主。社区打算在 2.3 版本中反对 Flink 1.15，能够关注 issue：https://github.com/ververica/…，也欢送奉献。Q：有 CDC 后果表写入 Oracle 的实际吗？A：1.14 版本的 Flink 暂不反对，这个是因为 Sink 端的 JDBC Connector 不反对 Oracle dialect，Flink 1.15 版本的 JDBC Connector 曾经反对了 Oracle dialect，1.15 版本的 Flink 集群能够反对。Q：下个版本是否反对读取 ES？A：还须要考查 transactional log 机制以及它是否适宜作为 CDC 的数据源。Q：能做到单 job 监控多表 sink 多表吗？A：能够实现单作业监控多表 sink 到多个上游表；但如果是 sink 到多表，须要 DataStream 进行分流，不同的流写到不同的表。Q：Binlog 日志只有最近两个月的数据，是否反对先全量后增量读取？A：默认反对的就是先全量后增量，个别 binlog 保留七天或两三天都能够。Q：2.2 版本 MySQL 没有主键，全量如何同步？A：能够回退到不必增量快照框架；在增量快照框架上，社区已有组件的 issue，预计将在社区 2.3 版本提供反对。点击查看直播回放 & 演讲 PDF 更多 Flink 相干技术问题，可扫码退出社区钉钉交换群第一工夫获取最新技术文章和社区动静，请关注公众号～
流动举荐阿里云基于 Apache Flink 构建的企业级产品 - 实时计算 Flink 版现开启流动：99 元试用 实时计算 Flink 版（包年包月、10CU）即有机会取得 Flink 独家定制卫衣；另包 3 个月及以上还有 85 折优惠！理解流动详情：https://www.aliyun.com/produc… 原文链接：http://click.aliyun.com/m/100… 本文为阿里云原创内容，未经容许不得转载。
