共计 4311 个字符，预计需要花费 11 分钟才能阅读完成。
背景介绍
随着 IT 技术与大数据的一直倒退，越来越多的企业开始意识到数据的价值，通过大数据分析，能够帮忙企业更深刻地理解用户需要、更好地洞察市场趋势。目前大数据分析在每个业务经营中都施展着重要作用，成为企业晋升市场竞争力的要害动作之一。通常企业会构建数据湖仓，将多个数据源通过数据集成技术，会集一起进行数据分析。由此，数据集成成为了构建数据湖仓的必经之路，然而企业在数据集成过程中却面临很多辣手问题。
- 全量 + 增量数据集成割裂。
传统的数据集成大多仅反对全量数据，对于全量 + 增量的一并集成，则须要别离部署链路，获取到数据后再手动合并。
- 多个数据源头，操作与保护简单。
表构造频繁变更，无奈主动同步表构造变更到数据湖仓，手动保护老本高。另外无奈”一键”整库同步，追加同步对象操作简单等。
- 数据获取时效性差。
传统的数据集成技术建模门路较长，依照 T + 1 的形式同步到数据仓库中，时效性差。须要做到实时数据集成和剖析，能力帮忙用户依据最新的数据做出更快、更精确的决策。
基于数据集成的外围痛点和用户诉求，近期腾讯云数据传输服务 DTS 联结 CKafka 重磅公布全新数据集成计划，该计划采取全增量数据一起的同步形式，将数据源先同步到 CKafka，再从 CKafka 生产数据投递到数据湖仓，能够无效帮忙用户解决数据湖仓建设后期数据集成的问题。
基于 DTS 的数据集成计划
DTS 在做数据集成计划的初期，产研团队做了十分充沛的调研，并剖析出了用户的外围诉求，次要聚焦以下四个方面：
- 反对全量 + 增量数据同步 ：不便疾速将全量 + 增量数据全副同步至上游数据分析工具中。
- 按序生产 ：数据生产时须要依照数据生产的程序进行。
- 数据不失落 ：数据在上游生产时至多要呈现一次，不能失落业务数据。
- 保护便捷 ：库表构造变更，或者库表对象追加须要不便操作。
DTS 的「数据订阅」模块能够利用于数据集成并散发到上游的场景中，但订阅模块次要解决增量数据，无奈实现全量 + 增量一起同步。通过屡次的技术探讨和验证后，咱们最终决定基于「数据同步」模块来做数据集成，技术计划：数据源先通过 DTS 同步数据到 CKafka，再从 CKafka 生产数据投递到数据湖仓。
不过理论落地中，咱们还是遇到了一些挑战。
全量局部数据块很大，如何晋升导出导入效率？
应用 DTS 数据同步模块来做数据集成，能够满足全量 + 增量一起同步的诉求，但在大数据场景下，又不得不面临两个问题：对于大表（如 10 亿行以上），如何晋升同步作业效率？对于超大的存量数据，在全量阶段遇到工作中断时，如何确保数据重入？
基于以上问题，DTS 设计了分块导出计划，针对大表场景（如 10 亿行以上），从源库导出数据时将一张大表分为多个分块，一个分块连贯一个线程，这样一张大表就可实现多分块同时导出，晋升大表的同步效率。
在导入到指标 CKafka 时，也是依照分块导入的，同时这些分块都会进行标记，如果 CKafka 产生重启，能够依据标记来辨认中断的分块地位，从中断的分块开始持续向指标 CKafka 写入。应用这个形式，在遇到 CKafka 异样时，就不须要从头从新写，大大晋升用户体验。
多分区，如何保障按序生产？
为了晋升用户生产的速率，音讯投递到 CKafka 时个别采纳投递到 CKafka 的多个分区的模式，多个分区能够并行生产以晋升生产速率，但在多分区处理过程中，会波及投递程序的问题，须要保障投递到每个分区的音讯与业务生产的音讯程序保持一致。
在实现中，DTS 向 CKafka 投递音讯时，依照源库日志解析后的程序来写入，因而能够实现写入 CKafka 程序与业务生成程序的统一。
- 全局程序性
DTS 在拉取源库的 Binlog 日志时，采纳单线程机制，先保障日志解析后果与业务生产程序保持一致，等写入到 CKafka 的多个分区时，再依照多线程并发，最终实现了每个分区的音讯都是按序排列。
这里须要阐明下，投递到多 Topic+ 多分区这种模式中，每个分区内的音讯都是按程序投递的，然而多个分区同时生产时，无奈保障分区间按序生产，如果用户对生产到的音讯程序有严格要求，倡议抉择投递到单 Topic+ 单分区的模式。
- 表级别程序性
在抉择按表名分区的场景中，源库同一个表的数据变更都会投递到指标 Topic 下的同一个分区中，因为日志的解析是按序排列，所以投递到 Topic 分区中的音讯也是按序排列。
总之，不管抉择哪种分区策略，DTS 都能够保障投递到各分区中音讯的程序性。
如何保证数据不丢？
要保障同步到 CKafka 的数据一条都不丢，那么所有的数据就须要有迹可循，哪些曾经同步过了、哪些还没有同步过，都必须分明可查。于是 DTS 通过对数据做标记，标识数据同步地位，以此来实现数据精确同步。
全量阶段，数据依照分块机制进行导出导入，DTS 导入到指标端 CKafka 的每个分块都会进行标记，CKafka 异样时，能够辨认中断的分块地位持续导入。
增量阶段，DTS 外部解决源库的日志解析时会插入标记，来辨认数据写入到 CKafka 的地位，如果工作中断再复原，通过 DTS 外部标记，能够找到中断的地位，持续增量同步。
库表变更，是否灵便同步？
业务数据库常常会有库表构造的变更，而数据集成须要能辨认并主动同步这些变更字段，否则，库表构造每变更一次，就须要手动改一次集成程序，这个保护工作量十分大。在 DTS 以前的链路传输中，库表构造变更的主动同步能力就曾经具备了，间接集成即可。然而咱们本次须要解决的是，当同步工作曾经启动，用户想要追加 / 删除一个新的库表对象，如何做到一键化操作，让用户便捷保护。
这里，咱们以追加一个表对象为例，同步工作曾经在进行中，然而运行过程中发现须要新增一个表对象（例如表 A），对用户来说，只须要在 DTS 工作列表页，进行一步可视化点击操作即可实现。
动静批改同步对象的过程中，其实 DTS 底层做了很多工作，对用户操作层面进行了简化，如上述操作案例：新增一个表对象（例如表 A），DTS 须要同步表 A 的历史存量数据，同时，已有的同步工作 1 还不能受影响。所以在实现中，咱们在 DTS 后盾结构了一个长期工作 2，来负责同步表 A 的存量数据，当工作 2 实现后，再将工作 1 和工作 2 合并，以此来实现动静追加同步对象的成果。
绝对于个别的集成工具，DTS 在库表构造的变更，库表对象减少 / 删除等方面都是十分敌对的，用户只须要在 Web 界面进行操作，一次配置，即可享受长期便当，大大减少用户的保护老本。
接下来，给大家重点介绍 DTS 的数据集成计划是如何配置的。
DTS+CKafka+ 数据湖仓 生产实践
实际场景
数据源头为 MySQL，通过 DTS 获取 MySQL 的全量 + 增量数据到音讯队列 CKafka，而后适配生产 Demo，将音讯投递到数据湖仓。
后期筹备
- 筹备腾讯云 CKafka 实例，并创立好生产组和生产 Topic。
- 筹备源数据库 MySQL。
- 筹备执行 DTS 工作的账号，并受权源库和指标库的对应权限。
- 筹备数据湖仓。
数据同步
DTS 的操作比较简单，在腾讯云 Web 界面进行 4 个步骤即可，无需环境部署。
步骤 1：创立 DTS 工作。
购买一个 DTS 工作，源库抉择 MySQL，指标库抉择 CKafka。
步骤 2：设置同步源和指标数据库。
配置 DTS 连贯源库和指标库，源库配置中填入 MySQL 的主机地址 / 端口 / 用户名 / 明码，指标库抉择 CKafka 实例 ID。
这个步骤次要是验证 DTS 到源和指标库的网络是否买通，对应的用户权限是否满足要求，如果源库有平安组设置须要容许 DTS IP 拜访，否则网络不通。
步骤 3：配置数据同步选项。
这个步骤次要是抉择同步的数据格式（Avro、JSON）、数据投递到 CKafka 的哪个 Topic 下、分区策略等。
- 对于库表构造的变更，一键勾选 DDL，即可在后续主动同步库表构造的变更数据。
- 选定同步的库表对象后，如果有须要追加，在工作启动后通过批改工作即可增加。
步骤 4：校验工作。
上述配置实现后，DTS 会对源和指标库的各项参数进行预校验，如 Binlog 必须开启，并且 binlog\_format 须要设置为 row 模式等等，以保证数据同步后果的正确性。
预校验通过后同步工作就能够启动了。
数据生产和投递
步骤 1：下载生产 Demo 样例。
DTS 同步工作失常运行后，下载 DTS 生产 Demo 样例，将 Demo 包解压后运行，进行数据生产。
这里以 Go 语言为例，解压 Demo 包后运行 go build -o subscribe ./main/main.go，生成可执行文件 subscribe。
而后运行 ./subscribe –brokers=xxx –topic=xxx –group=xxx –trans2sql=true。这里的 Brokers、Topic、Group 别离填入 CKafka 的地址、生产 Topic 名称、生产组名称。
运行结果显示如下，示意 CKafka 失常连贯，生产链路已买通。
步骤 2：测试数据后果。
在源数据库上插入一条数据。
INSERT INTO student\_school (id, name, school\_name) VALUES (9, 'Li Ming', 'Hengshui');
在生产端即可查看到对应数据。
步骤 3：批改 Demo，减少适配到后端数仓的代码逻辑。
DTS 提供的生产 Demo 仅对数据做了打印解决，用户须要在 Demo 根底上自行编写数据处理到后端数据湖仓的适配逻辑。
实际成果
应用 DTS 同步到 CKafka 的链路模式代替之前应用 Canal 组件的链路，最终实现高性能传输、高稳定性保障的同时无效升高了运维老本。
- 传输性能高 ：DTS 的传输性能与用户理论网络延时、带宽、数据自身的规格配置都有关系，在用户源端和指标端规格都比拟高，网络无瓶颈的状况下，我的项目实测 DTS 全量阶段的 RPS 最高可达 30 万 /s，增量阶段最高可达 1.5 万 /s。
- 稳定性强 ：DTS 可提供高 SLA 保障，工作稳定性极强。
- 运维成本低 ：用户之前应用 Canal 组件时，均匀每月大略须要半个人力投入到研发和运维中，改用 DTS 后，工作配置实现后根本无需运维人员投入，大大减少运维老本。
DTS 提供的同步到 CKafka 数据集成计划具备通用性，目前已胜利利用在出行、批发、游戏、互联网、金融等多个行业，并播种了用户的良好口碑。
总结和瞻望
DTS 目前已上线了 MySQL 系列数据库同步到 Kafka 的链路，为用户在大数据集成中提供了便捷的技术通道，后续为了满足用户更多的需要和更高的应用体验，DTS 和 CKafka 将聚焦「数据库生态」和「产品体验」上继续发力。
- 数据库生态方面 ：继续拓宽数据库生态，反对其余类型的数据库同步到 CKafka，如 MongoDB，Oracle，PostgreSQL 等同步到 CKafka。
- 产品体验方面 ：反对更多高阶个性，如全量阶段反对数据可重入，投递到多 Topic 的策略优化等等。
