关于大数据:详解MRS-CDL整体架构设计

摘要：MRS CDL是FusionInsight MRS推出的一种数据实时同步服务，旨在将传统OLTP数据库中的事件信息捕获并实时推送到大数据产品中去，本文档会具体为大家介绍CDL的整体架构以及关键技术。

本文分享自华为云社区《MRS CDL架构设计与实现》，作者：rujia01。

1 前言

MRS CDL是FusionInsight MRS推出的一种数据实时同步服务，旨在将传统OLTP数据库中的事件信息捕获并实时推送到大数据产品中去，本文档会具体为大家介绍CDL的整体架构以及关键技术。

2 CDL的概念

MRS CDL（Change Data Loader）是一款基于Kafka Connect的CDC数据同步服务，能够从多种OLTP数据源捕捉数据，如Oracle、MySQL、PostgreSQL等，而后传输给指标存储，该指标存储能够大数据存储如HDFS，OBS，也能够是实时数据湖Hudi等。

2.1 什么是CDC？

CDC(Change Data Capture)是一种通过监测数据变更（新增、批改、删除等）而对变更的数据进行进一步解决的一种设计模式，通常利用在数据仓库以及和数据库密切相关的一些利用上，比方数据同步、备份、审计、ETL等。

CDC技术的诞生曾经有些年头了，二十多年前，CDC技术就曾经用来捕捉利用数据的变更。CDC技术可能及时无效的将音讯同步到对应的数仓中，并且简直对以后的生产利用不产生影响。现在，大数据利用越来越广泛，CDC这项古老的技术从新焕发了活力，对接大数据场景曾经是CDC技术的新使命。

以后业界曾经有许多成熟的CDC to大数据的产品，如：Oracle GoldenGate(for Kafka)、 Ali/Canal、Linkedin/Databus、Debezium/Debezium等等。

2.2 CDL反对的场景

MRS CDL排汇了以上成熟产品的成功经验，采纳Oracle LogMinner和开源的Debezium来进行CDC事件的捕获，借助Kafka和Kafka Connect的高并发，高吞吐量，高牢靠框架进行工作的部署。

现有的CDC产品在对接大数据场景时，根本都会抉择将数据同步到音讯队列Kafka中。MRS CDL在此基础上进一步提供了数据间接入湖的能力，能够间接对接MRS HDFS和Huawei OBS以及MRS Hudi、ClickHouse等，解决数据的最初一公里问题。

表1 MRS CDL反对的场景

3 CDL的架构

作为一个CDC零碎，可能从源指标抽取数据并且传输到指标存储中去是根本能力，在此基础上，灵便、高性能、高牢靠、可扩大、可重入、平安是MRS CDL着重思考的方向，因而，CDL的外围设计准则如下：

• 系统结构必须满足可扩展性准则，反对在不侵害现有零碎性能的前提下增加新的源和指标数据存储。
• 架构设计该当满足不同角色间的业务侧重点拆散
• 在正当的状况下缩小复杂性和依赖性，最大限度的升高架构、安全性、韧性方面的危险。
• 须要满足插件式的客户需要，提供通用的插件能力，使得零碎灵便、易用、可配置。
• 业务平安，防止横向越权和信息泄露。

3.1 架构图/角色介绍

图1 CDL架构

MRS CDL蕴含CDL Service和CDL Connector两个角色，他们各自的职能如下：

• CDL Service：负责工作的治理和调度，提供对立的API接口，同时监测整个CDL服务的衰弱状态。
• CDL Connector：实质上是Kafka Connect的Worker过程，负责实在Task的运行，在Kafka Connect高牢靠、高可用、可扩大的个性根底上减少了心跳机制来帮助CDL Service实现集群的衰弱监测。

3.2 为什么抉择Kafka？

咱们将Apache Kafka与Flume和Nifi等各种其余选项进行了比拟，如下表所示：

表1 框架比拟

对于CDC零碎，Kafka有足够的劣势来撑持咱们做出抉择。同时，Kafka Connect的架构完满符合CDC零碎：

• 并行 - 对于一个数据复制工作，能够通过拆解成多个子工作并且并行运行来进步吞吐率。
• 保序 - Kafka的partition机制能够保障在一个partition内数据严格有序，这样有助于咱们实现数据完整性。
• 可扩大 - Kafka Connect在集群中分布式的运行Connector。
• 易用 - 对Kafka的接口进行了形象，晋升了易用性。
• 平衡 - Kafka Connect自动检测故障，并在残余过程上依据各自负载从新进行平衡调度。
• 生命周期治理 – 提供欠缺的Connector的生命周期治理能力。

4 MRS CDL关键技术

图2 CDL关键技术

4.1 CDL Job

MRS CDL对业务进行了下层的形象，通过引入CDL Job的概念来定义一个残缺的业务流程。在一个Job中，用户能够抉择数据源和指标存储类型，并且能够筛选要复制的数据表。

在Job构造的根底上，MRS CDL提供执行CDL Job的机制，在运行时，应用Kafka Connect Source Connector联合日志复制技术将CDC事件从源数据存储捕捉到Kafka，而后应用Kafka Connect Sink Connector从Kafka提取数据，在利用各种转换规则后将最终后果推送到指标存储。

提供定义表级和列级映射转换的机制，在定义CDL Job的过程中能够指定转换规则。

4.2 Data Comparison

MRS CDL提供一种非凡的Job，用于进行数据一致性比照。用户能够抉择源和指标数据存储架构，从源和指标架构中抉择各种比拟对进行数据比拟，以确保数据在源和指标数据存储中统一。

图3 Data Comparison形象视图

MRS CDL提供了专用的Rest API来运行Data Compare Job，并且提供如下能力：

• 提供多样的数据比拟算法，如行哈希算法，非主键列比拟等。
• 提供专门的查问接口，能够查问同步报表，展现以后Compare工作的执行明细。
• 提供实时的基于源和指标存储的修复脚本，一键修复不同步数据。

如下是Data Compare Job执行流程：

图4 Data Compare Job执行和查看流程

4.3 Source Connectors

MRS CDL通过Kafka Connect SDK创立各种源连接器，这些连接器从各种数据源捕捉CDC事件并推送到Kafka。CDL提供专门的Rest API来治理这些数据源连接器的生命周期。

4.3.1 Oracle Source Connector

Oracle Source Connector应用Oracle RDBMS提供的Log Miner接口从Oracle数据库捕捉DDL和DML事件。

图5 Log Miner抓取数据示意图

在解决DML事件时，如果表中存在BOLB/CLOB列，CDL同样能够提供反对。对于BOLB列的解决，关键点解决如下：

• 当insert/update操作产生时，会触发一系列的LOB_WRITE操作。
• LOB_WRITE用于将文件加载到BLOB字段中。
• 每个LOB_WRITE只能写入1KB数据。
• 对于一个1GB的图片文件，咱们会整顿全副的100万个LOB_WRITE操作中的二进制数据，而后合并成一个对象。咱们会把这个对象存储到Huawei OBS中，最终在写入Kafka的message中给出该对象在OBS中的地位。

对于DDL事件的捕捉，咱们创立独自的会话来继续跟踪。以后反对的DDL语句如下：

表2 反对的DDL语句

4.3.2 MYSQL Source Connector

MYSQL的Binary Log（Bin Log）文件程序记录了所有提交到数据库的操作，包含了对表构造的变更和对表数据的变更。MYSQL Source Connector通过读取Bin Log文件，生产CDC事件并提交到Kafka的Topic中。

MYSQL Source Connector次要反对的性能场景有：

• 捕捉DML事件，并且反对并行处理所捕捉的DML事件，晋升整体性能
• 反对表过滤
• 反对配置表和Topic的映射关系
• 为了保障CDC事件的相对程序，咱们个别要求一张表只对应一个Partition，然而，MYSQL Source Connector依然提供了写入多Partition的能力，来满足某些须要就义音讯保序性来晋升性能的场景
• 提供基于指定Bin Log文件、指定地位或GTID来重启工作的能力，保障异样场景下数据不失落
• 反对多种简单数据类型
• 反对捕捉DDL事件

4.3.3 PostgreSQL Source Connector

PostgreSQL的逻辑解码个性容许咱们解析提交到事务日志的变更事件，这须要通过输入插件来解决这些变更。PostgreSQL Source Connector应用pgoutput插件来实现这项工作。pgoutput插件是PostgreSQL 10+提供的规范逻辑解码插件，无需装置额定的依赖包。

PostgreSQL Source Connector和MYSQL Source Connector除了局部数据类型的区别外其余性能基本一致。

4.4 Sink Connectors

MRS提供多种Sink Connector，能够从Kafka中拉取数据并推送到不同的指标存储中。当初反对的Sink Connector有：

• HDFS Sink Connector
• OBS Sink Connector
• Hudi Sink Connector
• ClickHouse Sink Connector
• Hive Sink Connector

其中Hudi Sink Connector和ClickHouse Sink Connector也反对通过Flink/Spark利用来调度运行。

4.5 表过滤

当咱们想在一个CDL Job中同时捕捉多张表的变更时，咱们能够应用通配符（正则表达式）来代替表名，即容许同时捕捉名称满足规定的表的CDC事件。当通配符（正则表达式）不能严格匹配指标时，就会呈现多余的表被捕捉。为此，CDL提供表过滤性能，来辅助通配符含糊匹配的场景。以后CDL同时反对白名单和黑名单两种过滤形式。

4.6 对立数据格式

MRS CDL对于不同的数据源类型如Oracle、MYSQL、PostgreSQL采纳了对立的音讯格局存储在Kafka中，后端消费者只需解析一种数据格式来进行后续的数据处理和传输，防止了数据格式多样导致后端开发成本减少的问题。

4.7 工作级的日志浏览

通常境况下，一个CDL Connector会运行多个Task线程来进行CDC事件的抓取，当其中一个Task失败时，很难从海量的日志中抽取出强相干的日志信息，来进行进一步的剖析。

为了解决如上问题，CDL标准了CDL Connector的日志打印，并且提供了专用的REST API，用户能够通过该API一键获取指定Connector或者Task的日志文件。甚至能够指定起止工夫来进一步放大日志查问的范畴。

4.8 监控

MRS CDL提供REST API来查问CDL服务所有核心部件的Metric信息，包含服务级、角色级、实例级以及工作级。

4.9 应用程序错误处理

在业务运行过程中，经常会呈现某些音讯无奈发送到指标数据源的状况，咱们把这种音讯叫做谬误记录。在CDL中，呈现谬误记录的场景有很多种，比方：

• Topic中的音讯体与特定的序列化形式不匹配，导致无奈失常读取
• 指标存储中并不存在音讯中所存储的表名称，导致音讯无奈发送到指标端

为了解决这种问题，CDL定义了一种“dead letter queue”，专门用于存储运行过程中呈现的谬误记录。实质上“dead letter queue”是由Sink Connector创立的特定的Topic，当呈现谬误记录时，由Sink Connector将其发往“dead letter queue”进行存储。

同时，CDL提供了REST API来供用户随时查问这些谬误记录进行进一步剖析，并且提供Rest API能够容许用户对这些谬误记录进行编辑和重发。

图6 CDL Application Error Handling

5 性能

CDL应用了多种性能优化计划来进步吞吐量：

• Task并发

咱们利用Kafka Connect提供的工作并行化性能，其中Connect能够将作业拆分为多个工作来并行复制数据，如下所示：

图7 Task并发

• 应用Executor线程并行化执行工作

因为Log Miner，Bin Log等数据复制技术的限度，咱们的Source Connector只能程序的捕捉CDC事件，因而，为了进步性能，咱们将这些CDC事件先缓存到内存队列中，而后应用Executor线程并行的解决它们。这些线程会先从外部队列中读取数据，而后解决并且推送到Kafka中。

图8 Executor线程并发

6 总结

MRS CDL是数据实时入湖场景下重要的一块拼图，咱们依然须要在数据一致性、易用性、多组件对接以及性能晋升等场景须要进一步扩大和欠缺，在将来可能更好的为客户发明价值。

点击关注，第一工夫理解华为云陈腐技术~