2020实战复盘:如何从0到1搭建数据传输平台产品DTS?

数据库 其他数据库
数据传输服务DTS(Data Transmission System)的目标是支持RDBMS、NoSQL、OLAP等数据源间的数据交互,集数据迁移/订阅/同步于一体,帮助构建安全、可扩展、高可用的数据架构。

 2020年下半年的主要任务,就是从0到1搭建了数据传输服务平台产品。平稳上线后,基本达到预期,实现了最初的产品规划目标。

这里做个复盘,记录下从0到1的过程,包括:

  • 产品设计
  • 整体技术架构
  • 核心模块的技术选型、原理与改造适配
  • 总结与展望

1.什么是数据传输服务

数据传输服务DTS(Data Transmission System)的目标是支持RDBMS、NoSQL、OLAP等数据源间的数据交互,集数据迁移/订阅/同步于一体,帮助构建安全、可扩展、高可用的数据架构。

当然,目前我们的核心存储还是以MySQL为主,因此,自研的数据传输服务的首要数据源是MySQL。

为什么不直接采用公有云产品呢,比如阿里云DTS?

主要原因是为了能更好地对接内部其他系统,支持许多内部系统数据迁移/同步的自动化流程需求。同时,业内相关开源技术非常丰富且成熟,有很多现成的轮子可以使用,可以大大降低云服务使用成本。

2.产品设计

对于DTS的最强烈需求来源,是正在推进的多云架构,需要能够构建多云数据库镜像。同时,我们又深入调研了其他业务需求,得到了众多用户场景。

包括但不限于:

  • 数据库多云同步
  • 分库分表数据同步
  • ES 索引构建
  • 压测数据、线下导入/同步
  • 缓存刷新,Local cache/Redis cache等刷新
  • 业务数据变更订阅
  • CQRS模式实现

 

这些场景经过归纳整理,得到了DTS的三大产品功能模块。

  • 数据订阅模块:支持ES索引构建 、缓存刷新、业务数据变更订阅、CQRS模式实现
  • 数据迁移模块:支持数据库多云同步、分库分表数据同步、压测数据、线下导入
  • 数据同步模块:支持数据库多云同步、分库分表数据同步、压测数据、线下导入/同步

3.整体技术架构

整个DTS系统分为三个 逻辑层次,交互层、控制层、引擎层。

 

3.1 交互层

交互层就是用户可见的前台DTS产品,是用户视角的DTS系统。

1)产品模块

系统中包含了数据订阅产品模块、数据迁移产品模块、数据同步产品模块。


用户通过与各个产品模块交互,直接获取对应产品模块任务信息,实现对模块任务的管理,包括创建、启动、停止、释放、任务监控信息等。

2)通用服务

交互层除了产品模块之外,用户能够感知到的交互能力还包括了用户管理、权限管理、变更管理、基本任务信息管理等 通用服务能力。

这些通用服务能力可以来自于其他内部系统,也可以是独立设计的。


最重要的是,这些通用服务可以复用于DTS未来的产品扩展,包括Redis的数据同步、HBase数据同步。

3)核心设计

正如一开始提到,虽然目前我们以MySQL为主,但是未来肯定会扩展到其他数据源的数据迁移与同步。

因此交互层的核心实现采用 模板模式 ,实现了基础任务的创建、启动、停止、释放、审核、鉴权等流程。

将基础任务流程中的特定动作,如启动引擎任务、停止引擎任务等具体实现放在各个模块的实现类中进行实现。

实现了DTS模块化设计和极高的可扩展性,为未来接入其他 迁移/同步引擎(Redis/Hbase) 打下基础。


3.2 控制层

控制层是面向管理员的操作平台。

这一层主要面向运维视角,实现对引擎层的监控、启停、扩容等能力。

对比交互层产品模块,这一层次的控制台会有更复杂的任务控制选项,同时,也会具备很多运维层面的操作,比如引擎层的服务器管理能力等。

Canal、otter等开源产品都已经自带了相关控制台,可以直接使用。



3.3 引擎层

引擎层是整个系统的核心部分,目前的架构设计下,引擎层的引擎都是支持扩展、支持替换的。

目前全部采用开源项目,包括:

  • 数据迁移引擎采用Datax:https://github.com/alibaba/DataX
  • 数据订阅引擎采用canal: https://github.com/alibaba/canal
  • 数据同步引擎采用otter: https://github.com/alibaba/otter

对于引擎层,最核心的在于技术选型。需要结合业务需求、开源项目稳定性、开源项目功能特点综合分析,下文我们会仔细展开说明。

另外,对于生产环境使用的项目,必须做好配套的监控告警措施,保证线上的稳定性

otter/canal都有现成的监控指标,我们需要将 同步延迟 等关键指标进行采集,并设置合理的告警阈值。

同时,对于一些没有现成的监控指标,比如 任务存活状态 等,我们可以通过 巡检 进行定时检查,避免由于同步任务挂起而影响上层业务。

4.数据订阅模块

4.1 技术选型

数据订阅实际上就是一种CDC(Change Data Capture)工具,目前开源产品中比较成熟的有Canal、DataX、DataBus、Debezium等。

整体而言,Canal、DataX、Debezium的使用人数多,社区活跃,框架也比较成熟。在满足应用场景的前提下,优先选择,代价适中。

DataX支持丰富,使用简单,但延迟较大(依赖获取频率),只需要手写规则文件,对复杂同步自定义性不强。

Debezium虽然比Canal支持更多类型的数据源,但是我们实际上只需要mysql,并不需要PostgreSQL这些的支持。

而Canal有几点特性我们非常需要,让我们决定使用Canal作为数据订阅引擎:

  • 对阿里云RDS有特殊定制优化,可以自动下载备份到oss的binlog文件然后指定位点开始同步
  • 有非常友好的控制台
  • 支持投递到Rocketmq
  • 新版本的Canal-Adapter可以支持多种客户端消费,包括mysql、es等

4.2 基本原理

数据订阅的原理基本一样,都是基于MySQL的主从复制原理实现。

MySQL的主从复制分成三步:

  • master将改变记录到二进制日志(binary log)中(这些记录叫做二进制日志事件,binary log events,可以通过show binlog events进行查看);
  • slave将master的binary log events拷贝到它的中继日志(relay log);
  • slave重做中继日志中的事件,将改变反映它自己的数据。

Canal 就是模拟了这个过程。

Canal模拟 MySQL slave 的交互协议,伪装自己为 MySQL slave ,向 MySQL master 发送 dump 协议;

MySQL master 收到 dump 请求,开始推送 binary log 给 slave (即 canal );

Canal 解析 binary log 对象(原始为 byte 流);


4.3 部署架构


核心组件:

  • zookeeper:使用已有的zookeeper集群,实现订阅任务的HA
  • canal-admin:数据订阅的控制层的控制台,管理canal-server上的订阅任务状态与配置
  • canal-server:用于运行数据订阅任务,抓取数据库binlog,投递到MQ或者下游client。

4.4 使用方式

Canal支持TCP直接消费、MQ消费两种模式。

为了支持多个下游消费,减少上游数据库订阅压力,我们使用了MQ消费模式。

将数据库订阅binlog投递到Rocketmq,下游用户可以利用Rocketmq的Consumer Group,多次、重复消费对应数据,实现业务解耦、缓存一致性等场景。

4.5 改造适配

1)控制台api封装

由于canal-admin的技术栈还是比较新的,有比较成熟的分层结构和独立的rpc接口,因此,在DTS服务中,包装相关canal-admin的接口,即可实现产品化的前台接口逻辑。

2)云原生改造

计划中,改造为k8s部署,支持快速扩缩容

5.数据迁移模块

5.1 技术选型

跟数据订阅不同,Mysql的数据迁移五花八门,实现原理也都各不相同。


综合来看,我们选择了DataX作为数据迁移引擎。

5.2 基本原理

DataX 是阿里巴巴集团内被广泛使用的离线数据同步工具/平台,实现包括 MySQL、Oracle、SqlServer、Postgre、HDFS、Hive、ADS、HBase、TableStore(OTS)、MaxCompute(ODPS)、DRDS 等各种异构数据源之间高效的数据同步功能。

我们主要使用了MySQL的数据同步,它的实现原理比较简单,就是通过

  1. select * from table

获取全量数据,然后写入到目标库中。

当然,这里利用了JDBC的流式查询,避免OOM。同时,datax也支持自定义限速。

5.3 部署架构与使用方式

Datax的使用方式比较简单,通过配置任务Json,执行脚本即可。

由于数据迁移使用不多,且基本是一次性使用,所以暂时是直接部署在DTS的服务中,通过Java的Process类进行相关处理。

  • 创建Datax所需的conf文件,并返回地址
  • 使用Runtime.getRuntime().exec()执行 Datax的python脚本
  • 根据返回的Process对象,处理成功/失败、执行输出日志等

后面会考虑进一步迭代,采用独立服务器部署Datax,然后通过自定义Java服务或者使用Saltstack实现远程调用脚本。

 

6.数据同步模块

6.1 技术选型

数据同步的方案主要有三种


综合实施性、技术成熟度、双向同步需求的考虑,我们选择了otter作为数据同步引擎。

6.2 基本原理

基于Canal开源产品,获取数据库增量日志数据。Canal原理参考 数据订阅 的基本原理。

典型管理系统架构,manager(web管理)+node(工作节点)。

6.3 部署架构


核心组件:

  • zookeeper:解决分布式状态调度的,允许多node节点之间协同工作
  • manager: 运行时推送同步配置到node节点
  • node: 内嵌canal,负责binlog订阅,并把事件同步到目标数据库;同时,将同步状态反馈到manager上

6.4 改造适配

1)控制台api封装

由于otter-admin的技术栈比较旧,采用webx框架实现,没有前后端分离。

因此,需要根据已有代码,重新封装独立的rpc接口,然后才能对接到DTS服务中,包装相关otter-admin的接口,实现产品化的前台接口逻辑。

2)云原生改造

改造为k8s部署,支持快速扩缩容,具体可以参考我上一篇文章 拥抱云原生,如何将开源项目用k8s部署?

7.总结与展望

从产品设计、技术调研、架构设计到最后研发上线,历时半年左右。最终功夫不负有心人,项目顺利上线,通过前台产品的简单交互与审核,就能秒级快速创建DTS任务。

目前已经支持数十个DTS任务(包括数据订阅、数据迁移、数据同步),落地了多云数据库镜像、ES索引构建、数据实时同步、业务数据订阅等多个业务场景。

未来,还需要做进一步的技术迭代,包括:

1)扩展数据传输引擎

目前已经在尝试接入Redis-shake做Redis的迁移与同步。

后面还会继续尝试HBase-replication的接入,做HBase相关的任务迁移与同步。

这些都可以通过复用 通用服务能力 和 模版流程,实现快速接入。

2)增加调度模块

后续还需要增加任务调度模块,主要实现两方面的能力:

根据实例负载进行任务的调度,保证资源的合理使用

根据业务特性、重要程度做任务调度,保证资源隔离

3)完成云原生化改造

目前只有otter引擎实现了k8s部署,后面还需要对canal-server、Datax实现k8s部署,满足快速扩缩容,提高资源使用率。

 

责任编辑:姜华 来源: 阿丸笔记
相关推荐

2020-06-12 07:50:15

大数据

2022-10-14 16:25:50

数据可视化大屏搭建BI平台

2009-12-08 11:17:41

WCF双向通信

2022-06-13 07:02:02

Zadig平台自动化

2023-02-03 11:32:22

以太网光纤

2010-04-07 14:54:38

2022-05-09 08:35:43

面试产品互联网

2010-07-13 15:55:12

FTP数据传输模式

2015-10-14 09:44:55

TCP网络协议数据传输

2013-11-26 15:51:45

Android编程蓝牙数据传输

2023-04-12 16:20:00

同步数据异步数据传输

2023-03-06 11:35:55

经营分析体系

2023-03-01 09:55:56

2023-04-10 07:40:50

BI 体系数据中台

2021-12-14 11:01:44

TCPUDP网络协议

2021-06-09 11:28:06

加密数据Jsencrypt

2009-07-07 16:46:33

数据传输铜缆结构

2021-10-08 08:37:38

数据传输数据调用网络协议

2019-09-06 09:11:36

以太网数据二层交换

2011-03-02 11:23:48

点赞
收藏

51CTO技术栈公众号