做商城网站公司,如何在平台上推广产品,四川省建设工程质量监督总站网站,赶集网网站建设分析前言
本文主要概述了Flink-CDC.
1. CDC 概述
1.1 什么是CDC#xff1f;
CDC是#xff08;Change Data Capture 变更数据获取#xff09;的简称 #xff0c;在广义的概念上#xff0c;只要是能捕获数据变更的技术#xff0c;都可以称之为 CDC。 核心思想是#xff0c…前言
本文主要概述了Flink-CDC.
1. CDC 概述
1.1 什么是CDC
CDC是Change Data Capture 变更数据获取的简称 在广义的概念上只要是能捕获数据变更的技术都可以称之为 CDC。 核心思想是监测并捕获数据库的变动包括数据 或 数据表的插入INSERT、更新UPDATE、删除DELETE等将这些变更按发生的顺序完整记录下来写入到消息中间件中以供其他服务进行订阅及消费。 CDC 技术的应用场景非常广泛
数据同步用于数据备份容灾数据分发一个数据源分发给多个下游系统数据采集面向数据仓库 / 数据湖的 ETL 数据集成是非常重要的数据源。
1.2 CDC的实现机制
CDC 的技术方案非常多目前业界主流的实现机制可以分为两种
1) 基于主动查询的 CDC
用户通常会在数据源表的某个字段中保存上次更新的时间戳或版本号等信息然后下游通过不断的查询和与上次的记录做对比来确定数据是否有变动是否需要同步。 特点 离线调度查询作业批处理。把一张表同步到其他系统每次通过查询去获取表中最新的数据; 无法保障数据一致性查的过程中有可能数据已经发生了多次变更 持续的频繁查询对数据库的压力较大。 不保障实时性基于离线调度存在天然的延迟。
2) 基于事件接收CDC
可以通过触发器Trigger或者日志例如 Transaction log、Binary log、Write-ahead log 等来实现。当数据源表发生变动时会通过附加在表上的触发器或者 binlog 等途径将操作记录下来。下游可以通过数据库底层的协议订阅并消费这些事件然后对数据库变动记录做重放从而实现同步。 实时消费日志流处理例如 MySQL 的 binlog 日志完整记录了数据库中的变更可以把 binlog 文件当作流的数据源 保障数据一致性因为 binlog 文件包含了所有历史变更明细 保障实时性因为类似 binlog 的日志文件是可以流式消费的提供的是实时数据。 基于查询的CDC 基于Binlog的CDC
经过以上对比可以发现基于日志CDC 有以下这几种优势 能够捕获所有数据的变化捕获完整的变更记录。在异地容灾数据备份等场景中得到广泛应用如果是基于查询的 CDC 有可能导致两次查询的中间一部分数据丢失 每次 DML 操作均有记录无需像查询 CDC 这样发起全表扫描进行过滤拥有更高的效率和性能具有低延迟不增加数据库负载的优势 无需入侵业务业务解耦无需更改业务模型 1.3 常见的开源 CDC 方案 对比全量同步能力: 基于查询或者日志的 CDC 方案基本都支持除了 Canal(仅支持增量)。 对比全量 增量同步的能力只有 Flink CDC、Debezium、Oracle Goldengate 支持较好。 对比增量同步能力: 基于日志的方式可以很好的做到增量同步 而基于查询的方式是很难做到增量同步的。 从架构角度去看 该表将架构分为单机和分布式这里的分布式架构不单纯体现在数据读取能力的水平扩展上更重要的是在大数据场景下分布式系统接入能力。例如 Flink CDC 的数据入湖或者入仓的时候下游通常是分布式的系统如 Hive、HDFS、Iceberg、Hudi 等那么从对接入分布式系统能力上看Flink CDC 的架构能够很好地接入此类系统。 在数据转换 / 数据清洗能力上 当数据进入到 CDC 工具的时候是否能较方便的对数据做一些过滤或者清洗甚至聚合。 在 Flink CDC 上操作相当简单可以通过 Flink SQL 去操作这些数据 DataX、Debezium 等则需要通过脚本或者模板去做所以用户的使用门槛会比较高。 在生态扩展方面: 这里指的是下游的一些数据库或者数据源的支持。Flink CDC 下游有丰富的 Connector例如写入到 TiDB、MySQL、Pg、HBase、Kafka、ClickHouse 等常见的一些系统也支持各种自定义 connector。
