神州优车数据交换平台的架构、建设与痛点难点详解

卢彪 2018-11-27 10:00:14
 本文根据dbaplus社群第170期线上分享整理而成

百度百科:

 

数据交换平台,是指将分散建设的若干应用信息系统进行整合,通过计算机网络构建的信息交换平台,它使若干个应用子系统进行信息/数据的传输及共享,提高信息资源的利用率,成为进行信息化建设的基本目标,保证分布异构系统之间互联互通,建立中心数据库,完成数据的抽取、集中、加载、展现,构造统一的数据处理和交换。

 

笔者认为,数据交换平台是构建分布式系统的三驾马车之一。这三驾马车分别是基于RPC的服务调用、基于MQ的事件驱动以及基于Data Sync的数据共享。

 

而驱动数据交换平台出现和发展的根本动力是:用空间换时间。

 

一、交换平台漫谈

 

1、服务场景
 

 

概括来讲,数据交换平台可以服务的场景可以分为三大类,分别是:基础架构、容灾备份和异构重构。

 

基础架构

 

场景举例一:EDA

 

通过数据交换平台,把数据库Log事件(如MySQL的Binlog)发送到MQ,然后由不同的消费者进行消费,驱动不同的业务流程(如:刷新缓存、构造搜索引擎、下单之后发短信、支付之后通知发货等),基于这样的架构,免去了业务方自己定义领域事件和发送事件的工作,大大节省了工作量。

 

更重要的是,基于数据库自己的Log机制,数据一致性更有保证,其它诸如容错处理、HA等机制也只靠数据交换平台去保证即可。

 

当然,如果事件定义比较复杂,普通的业务表对应的LogEvent无法表达的话,还需要自行设计领域事件,此时我们可以定义一张通用的事件表用于保存自定义事件;而发送事件的操作对应事件表的插入操作并且随业务操作放到一个事务中,待事务提交后,交换平台拉取事件表的日志,然后提取事件内容发送到MQ即可。

 

 

通过消费数据库的Log,可做的文章非常多,我们团队内部正在研发一个事件平台,也是基于消费MySQL-Binlog来实现的,大体架构如下所示:

 

 

事件平台提供了事件订阅,事件配置(如:是实时触发下一操作还是倒计时定时触发下一操作,下一操作是接口回调还是产生一个新的事件等),事件编排和实时监控等基础支撑,使用方只需提供配置规则和开发回调接口即可,免去了各研发团队各自为政、重复建设的各种问题。

 

另外,该平台最大的一个特色就是引入了事件驱动的定时器机制,没有这样一个机制之前,涉及到时间要素相关的判断时(如:下单后多长时间未结算订单自动转为无效,租车时长超过一定时间后,结算类型自动由短租产品转为长租产品等),业务研发团队需要写大量的定时任务扫描数据库来计算时间区间,不仅开发成本巨大并且往往也存在较大的性能问题。

 

有了定时器机制,业务方只需配置时间规则即可,并且事件平台是分布式的,可以提供更高的性能支撑。

 

场景举例二:CQRS(Command Query Responsibility Segregation)

 

这里套用DDD领域中的一个概念CQRS,具体介绍可参考链接:

https://www.martinfowler.com/bliki/CQRS.html

 

CQRS的思想本质上就是为同一份数据建立两套模型(或叫视图):

 

  • 一套是模型清晰的Domain-Model,代表业务实体,满足复杂业务逻辑的需要;

  • 另一套是查询视图,主要面向查询场景,不关心数据库范式,只关心查询最优最快。

 

CQRS架构模式的一个开源实现是Axon-Framework,基于Axon可以构建自己的领域模型、领域事件、事件仓库、查询视图等,其提供了聚合根定义、事件重放、事件消费、数据镜像等基础支撑,套用一下它的架构图如下:

 

 

理想是丰满的现实却是骨感的,DDD提出已经很多年了,却因难于实践,绝大部分公司还是停留在靠数据库表进行建模的阶段,但CQRS的思想是很好的。

 

那么我们抛开DDD,基于表模型来理解CQRS:数据表模型也是领域模型,只不过不是面向对象的领域模型,数据库的Log也是事件,只不过表达能力不像DDD中的领域事件那么丰富。

 

基于此,靠数据库管理模型和事件,加上一个数据交换平台进行事件转发和消费,便可以构建一个广义上的CQRS架构,如下所示:

 

 

场景举例三:数据采集和回流

 

很多公司正在建设或者已经建设了自己的大数据平台,其中数据采集和回流是必不可少的一个环节,一般小一些的公司在数据采集这一层做的比较零散,各种开源产品堆积在一起完成采集相关的工作,而大一些的公司会考虑平台化,把数据采集放到整个数据交换平台的规划中,以便于提升效率和降低成本。

 

下图是我们团队的数据交换平台和大数据平台的关系示意图:

 

 

容灾备份

 

场景举例一:多机房

 

多中心、多备份、异地双活、异地多活等是很多大公司正在实践或者已经实践过的技术难题,这中间的核心便是一整套完整的数据同步方案。

 

场景举例二:数据镜像

 

通过数据交换平台,可以创建各种类型的DB镜像,满足不同场景下的使用需要。

 

场景举例三:数据归档

 

通过增量交换,在同步过程中忽略删除事件,可以实现实时归档。

 

异构重构

 

场景举例一:DB升级换代,迁库、拆库、合库

 

对DB进行升级换代,日常的迁库、拆库和合库等运维操作,就要涉及到数据迁移,如果有平台,迁移工作就会变得很简单。

 

场景举例二:资产复用

 

越大的公司,包袱也越重,很多公司拥有各种类型的数据库和存储产品,为了复用这些资产,就涉及到各种场景下的数据同步,统一的数据交换平台会让这些场景各异的同步变得容易很多。

 

2、建设思路
 

 

一千个读者就有一千个哈姆雷特,一千个架构师就有一千种架构思想,数据交换平台的建设也没有什么银弹可言。不同团队面对的场景各异,进化出来的架构也就不尽相同。此处结合自己的经验和心得,谈一谈数据交换平台建设过程的一些方法论和注意事项。

 

架构选型

 

数据同步流程是生产者-消费者模式的典型体现,生产者负责从不同的数据源拉取数据,消费者负责把数据写到不同的数据源,生产者和消费者之间可以是1对1的关系,也可以是1对多的关系。

 

那么,数据交换平台就是把生产者和消费者串联起来的中枢,并且可以在串联的过程中控制流程,概括来讲就是进行数据集成。

 

数据集成是数据交换平台最基本的工作,架构的选型和设计应该仅仅围绕这个基本点展开,只有便于快速集成的架构才能支撑不断变化的数据同步需求。

 

在进行架构设计时,需要考虑的点,大致总结如下:

 

  • 捋清自己的场景和需求。平台可大可小,目标一定要明确,这样才知道怎样取舍。

  • 统一建模。一些通用功能要进行归纳和抽象,抽离出一套统一的模型,常见的功能如下:库别名、表别名、列别名、列黑名单、列白名单、多表聚合、特定数据过滤、自定义同步规则、同步优先级等。

  • 统一管理数据源。

  • 统一数据契约。统一的数据格式定义是生产者和消费者能够自由组合的前提。

  • 统一位点管理。对于增量同步来说,消费位点的定义和模式最好统一,以方便统一监控和管理。

  • 统一协调全量和增量。需要处理好全量同步和增量同步的对立统一关系。

  • 统一基础设施。抽象公用API、HA、监控、报警等。

  • 所有架构设计时都需要考虑的点:可运维、易用性、可扩展、参数化。

 

很多公司都在基于消息中间件构建自己的数据交换平台(有的称之为数据总线),生产者把数据发送到MQ,消费者从MQ上消费数据,并且数据可以自描述,此模式的一个典型开源实现就是Kafka-Connect,其架构图如下所示:

 

 

优点:

 

  • 生产者和消费者完全解耦;

  • 一份数据可以供多个消费者进行消费;

  • 性能和吞吐率很高;

  • 扩展性也很不错。

 

缺点:

 

  • 运维成本偏高(需要管理大量Broker和Topic,很多时候源到目标的直连式同步其实更简单有效);

  • 同步关系不易于管理;

  • 对同步的顺序性和数据一致性要求比较高的场景的支持还有缺陷;

  • 不太适用于多机房同步等场景。

 

不论如何,该架构模式是很优秀的,能满足百分之六七十的应用场景。但我们团队并没有直接套用该架构,而是针对其缺点,并受Kafka-Connect思路的启发,实现了一套基于消息中间件和直连同步的混合架构,如下所示(即DataLink的架构):

 

 

在Kafka-Connect的架构中,因为要以Kafka做数据中转站,所以运行的Task要么是SourceTask、要么是SinkTask,而DataLink中的Task可以对Reader和Writer进行任意组合(理论上)。

 

基于这样的特性,要构建基于消息中间件的同步,组合Mq-Writer和Mq-Reader即可;要构建直连式的同步,绕过Mq直接组合源端Reader和目标Writer即可。根据不同场景选择不同模式,更加灵活。

 

消息中间件的方案也好,混合方案也好,针对的大部分场景都是实时增量同步(虽然也支持部分场景下的全量同步,但毕竟不是其主业),针对离线全量同步场景,目前大家用的最多的方案是阿里开源的DataX,有兴趣的可以研究一下。

 

简单总结,没有最好的架构只有最合适的架构,基于消息中间件构建数据交换平台是目前比较流行的架构模式,但它也有自身的缺点,组合各种技术,扬长避短,针对自己的问题和痛点找到适合自己的方案才是最合理的方案。

 

方式方法

 

如果说架构选型是制定战略,那方式方法就是具体战术。从同步行为上来换分,可以分为实时增量同步和离线全量同步。

 

前者的可行战术主要有触发器、日志解析和基于时间戳的数据抽取(当然,不同DB还会有自己的一些特殊方案,如Oracle的物化视图机制,SQL Server的CDC等),后者的可行战术主要有文件Dump和API抽取。

 

实时增量同步

 

先说实时增量同步。基于触发器的方式获取数据比较传统,并且因为运维繁琐和性能较差等原因,用的也越来越少。

 

但在某些特定场景下还是有适用空间的,有一个开源的产品代号为SymmetricDS,可以自动化管理触发器并提供统一的数据抓取和消费机制,如果想基于触发器做数据同步的话可以参考该产品。

 

基于日志解析的方式去做同步目前最受青睐,像MySQL、HBase等都提供了日志重放机制,并且协议开源.

 

该方式的主要优点有:对业务表零侵入、异步解析日志没有性能问题、实时性比较高等。

 

日志解析很美好,但并不是所有DB都提供了这样的机制(如SQL Server),当触发器和日志解析都搞不定时,通过时间戳字段(如:modify_time)定时扫表,拿到变更数据并进行同步,也是常用的一种手段.

 

该方式有几个明显的缺点:实时性比较低、需要业务方保证时间戳字段不能出现漏更新,定时扫表查询也可能会带来一些性能问题等。

 

离线全量同步

 

再说离线全量同步。文件Dump的方式一般用在同构数据源之间的同步场景,并且需要靠DB自己的导入导出机制进行支持,可以服务的场景比较单一。API抽取的方式更通用和灵活一些,同构异构都可以编码进行实现,做的好的话,还可通过灵活的参数控制提供各种高级功能特性,如开源产品DataX。

 

 

难点问题

 

把数据从一个地方搬到另一个地方,怎样保证在同步过程中数据不出问题(不丢、不重、不乱)或者出现问题后能快速恢复,要考虑的点非常多也非常杂,这里结合自己的经验谈谈主要的难点以及常用的解决方案。

 

其一:种类繁多的API

 

看上去貌似也没有什么难的,不就是调用API进行数据操作吗?其实不然,市面上的存储产品有上百种,常用的也有几十种,其产品特性是千差万别的。

 

为了构建一个高效可靠的平台,对这些产品的API及其内部机制进行透彻的研究是必须要做的 (如:是否支持事务?事务粒度是表级别还是记录级别?是支持随机读写还是只能支持Append?操作API时有没有客户端缓存?HA是怎么实现的?性能瓶颈点在什么地方?调优参数都有哪些?自带的Replication机制是怎么实现的?等等),否则平台也就仅仅停留在能用的阶段。

 

拿我们自己的经历举个例子:在建设大数据平台时,需要数据交换平台把MySQL和HBase的数据实时同步到HDFS中,基于DataLink我们开发了HDFS Writer插件,在实践过程中没少趟坑。

 

  • 首先是租约的问题,HDFS中一个文件同时只能有一个Writer,但我们的系统是分布式的,同一文件的Writer会经常在不同的机器上“漂移”,这就需要管理好租约占用的问题,没有现成的解决方案,只能去研读Hadoop的工程源码,花费了很长时间才解决好这个问题。

    相关总结参见链接:

    https://www.cnblogs.com/ucarinc/p/8064447.html

  • 其次是数据丢失问题,HDFS的流有flush、hflush、sync、hsync等方法,需要了解透彻才能区分清楚应该调用哪一个。先说flush,和普通的文件流不一样,HDFS文件流的flush只是在客户端进行了缓存操作,如果按常规调用该方法进行刷新的话,当客户端进程重启时如果本地有缓存数据会导致数据丢失;然后hflush和hsync,前者只是刷入了操作系统的缓存,后者是每次force磁盘,需要根据实际情况决定使用前者还是后者。

  • 最后再次说一下hsync。其有两个重载方法,一个不带参数,另一个可以传入SyncFlag类型的参数,后者可以force磁盘的同时更新block-length,这样才能保证当按block去读取数据时能读到最新写入的数据,但这个方法比较隐藏,我们直接拿到的FSDataOutputStream并没有暴露这个方法。(不知道这个方法之前,读取不到数据的问题困挠了我们很长时间,具体现象是:数据可以写入文件,通过命令行和文件流都能读取到最新写入的数据,但是通过Spark和Hive读取最新数据总是取不到)。

    相关参考链接:

    https://issues.cloudera.org/browse/DISTRO-696

     

解决这个难点问题,没有捷径,只能靠增加自身硬实力来进行突破。

 

其二:同步关系治理

 

对于服务框架来说,随着服务数量不断增加,我们需要服务治理;对于数据交换平台来说,随着同步关系的不断增加,同样需要对同步关系进行治理。

 

需要治理的点主要有:

 

  • 怎样避免回环同步

  • 怎样保证源端和目标端Schema的一致

  • 怎样降低配置同步关系的运维成本等。

 

避免回环同步一般加入DAG检测机制即可。

 

保证Schema的一致性一般有两个思路:一个是在同步过程中获取到源端的ddl语句自动同步到目标端,另一个是平台提供同步关系检测机制供外部系统使用,前者在异构数据源比较多的时候实现起来困难比较大(脚本转换、性能问题、幂等判断等),并且不是所有的方案都能拿到ddl语句,而后者更具有通用性和可行性。

 

目前我们内部的方案是,SQL脚本上线时,由数据交换平台进行SQL解析,然后返回同步关系树给DBA团队的DBMS系统,然后由DBMS系统按照同步关系的提示逐库执行脚本即可。

 

同步关系树的一个示意图如下所示:

 

 

其三:数据质量

 

保证数据质量是数据交换平台的核心使命,同步过程中做到不丢、不重、不乱,通过数据巡检能迅速发现问题;发现问题后能快速修复。

 

如果能把事前、事中、事后这三个阶段都控制好,那平台已经达到优秀的级别了。

 

事前阶段靠完善的设计和测试,事中阶段靠立体化的监控报警,事后阶段靠功能丰富的修复工具,但每个阶段实践起来都不容易,原因在于场景的灵活性和复杂性,如:

 

  • 数据如果是从RDBMS同步到HDFS,数据巡检时数据采样就很麻烦;

  • 验证数据不丢和不重相对容易一些,但验证数据内容的一致性就相对较难,尤其是异构数据源之间同步时;

  • 不丢、不重、不乱只是基本的验证,很多场景还需要各种定制化的验证手段,如大数据平台自己的数据质量管理体系;

  • 海量数据场景下,数据巡检的性能也要重点考虑;

  • 定位出问题数据后,怎样在不影响正常同步的前提下并行进行数据修复,也很重要,像Otter的自由门机制就可以把修数据的操作混合到正常的同步流程中,还有像LinkedIn的Databus提供了无限回溯的能力,在历史消费和实时消费之间可以灵活切换等。

 

目前我们团队也还在不断探索的路上,没有绝对完美的方案,针对自己的场景和对数据一致性要求的程度,找到最合适的方案才是正解。下面借用一张图来展示数据质量的设计要点:

 

 

其四:扩展性

 

技术的发展是快速的,业务的演进也是千变万化的,为了应对这些变化,平台肯定也要跟着变,但怎样用最小的变化带来最大的收益,是判断一个平台、一个产品成熟与否的关键指标。

 

笔者信奉一句名言:架构是进化出来的,而不是设计出来的;但同时也信奉另一句名言:好的设计是成功的一半。二者并不矛盾,主要在于怎么去折中。

 

做平台和做工具的一个重要区别在于,前者要重点考虑抽象、建模和参数化,以提供灵活的扩展性。

 

那么扩展性应该考虑到什么程度呢?一句话来概括:我们在平台的建设过程中应该不断归纳、不断纠错、不断抽象、不断迭代、不断推演,把已知的事情做到模型化,把未知的事情做到可预见,不做过度设计,但也要充分设计。

 

开源数据同步中间件中,扩展性做的比较好的:阿里的DataX不错,KafKa-Connect不错,基于触发器的SymmetricDS也不错,下文要介绍的我们最近开源的DataLink也在这方面做了很多考虑。

 

3、开源产品
 

 

在这里罗列一下数据同步相关的开源产品,供参考学习:

 

 

二、实战项目介绍

 

1、DataLink项目介绍
 

 

名称: DataLink['deitə liŋk]

译意: 数据链路,数据(自动)传输器

语言: 纯Java开发(JDK1.8+)

定位: 满足各种异构数据源之间的实时增量同步,一个分布式、可扩展的数据同步系统

开源地址:https://github.com/ucarGroup/DataLink

 

此次开源为去除内部依赖后的版本(开源的是增量同步子系统),在集团内部DataLink和阿里的DataX还进行了深度集成,增量(DataLink)+全量(DataX)共同组成统一的数据交换平台(如果去做类比的话,DataLink可以看做增量版的DataX),平台架构如下所示:

 

 

2、项目背景
 

 

随着神州优车集团业务的高速发展,各种各样的数据同步场景应运而生,原有的系统架构难以支撑复杂多变的业务需求。所以,从2016年底开始,团队内部开始酝酿DataLink这个产品。

 

着眼于未来,我们的目标是打造一个新平台,满足各种异构数据源之间的实时增量同步,支撑公司业务的快速发展。在充分调研的基础之上,我们发现,没有任何一款开源产品能轻易的满足我们的目标,每个产品都有其明显的短板和局限性,所以最终的选项只有“自行设计”。

 

但自行设计并不是凭空设计,现有的数据交换平台、已有的经验、大大小小的开源产品都是我们的设计根基,与其说是自行设计,倒不如说是站在巨人的肩膀上做了一次飞跃。由此诞生了DataLink这样一个产品,其产品特性主要如下:

 

  • 满足各种异构数据源之间的实时增量同步,提供抽象模型,支持高可扩展;

  • 平台提供统一的基础设施(高可用、动态负载、同步任务管理、插件管理、监控报警、公用业务组件等),让设计人员专注于同步插件开发,一次投入,长久受益;

  • 吸收、整合业内经验,在架构模型、设计方法论、功能特性、可运维、易用性上进行全面的升级,在前瞻性和扩展性上下足功夫,满足公司未来5-10年内的各种同步需求。

 

3、应用现状
 

 

DataLink从2016年12月开始立项,第一版于2017年5月份上线,在神州优车集团内部服役到现在,基本上满足了公司所有业务线的同步需求,目前内部的同步规模大体如下:

 

  • 日均数据同步量800G+;

  • 涉及272个数据库实例之间的3208个同步映射;

  • 60台Worker+2台Manager机器的集群规模。

 

4、架构模型
 

 

基础架构

 

 

DataLink是典型的Master-Slave架构,Manager(管理节点)+Worker(工作节点),下面对基础架构的重点模块做概要介绍:

 

Manager

 

Manager是整个DataLink集群的大脑,有三个核心功能:

 

  • 担任整个集群的负载均衡协调器:当集群出现状态变更时,第一时间进行Re-Balance;

  • 负责整个集群的配置管理:提供管理后台,配置发生变更时进行事件通知、缓存刷新等操作,保证系统能够获取到最新的变更;

  • 监控整个集群的健康状况主要有:同步是否出现延迟、同步是否出现异常、数据同步TPS、数据同步吞吐量、机器健康状况检查等等。

 

Group

 

  • 分组是DataLink的一个核心概念,Worker和Task在运行之前必须先知道自己属于哪个分组;

  • 分组的目的是:实现组内自治、组间隔离,不同分组会有不同的参数配置、运行策略、高可用级别等。

 

Worker

 

  • Worker必须归属于某个分组;

  • Worker的核心功能是管理Task的生命周期,并配合Manager进行Re-Balance;

  • Worker运行哪些Task受Manager的分配。

 

Task

 

  • Task的核心功能是进行数据同步;

  • 一个Task由一个TaskReader和多个TaskWriter组成,Reader和Writer使用独立的Classloader;

  • Task必须归属于某个分组。

 

(Re-)Balance

 

(Re-)Balance的定义:通过一定的负载均衡策略,使Task在Worker节点上均衡的分布。(Re-)Balance的单位是Group,一个分组发生(Re-)Balance不会影响其它分组的正常运行。

 

发生(Re-)Balance的时机有:

 

  • Manager发生主备切换;

  • 新的Worker加入分组;

  • 某个Worker离开分组;

  • 新增Task;

  • 删除Task。

 

Plugin

 

插件模型最大的意义在于解耦和复用,只需要提供一套基础框架,开发一系列同步插件,通过配置组合便可以支持“无限多”的同步场景。

 

插件划分为两种:Reader插件和Writer插件,插件之间通过Task串联起来。Task运行时,每个插件都有自己独立的Classloader,保证插件之间的JAR包隔离。

 

MySQL

 

DataLink的运行需要依赖各种配置信息,这些配置信息统一保存到MySQL中。DataLink在运行过程中会动态产生监控和统计数据,这些数据也统一保存到MySQL中。

 

存储的配置信息主要有:同步任务信息、工作节点信息、分组信息、数据源配置信息、映射规则信息、监控信息、角色权限信息等。

 

ZooKeeper

 

Manager的高可用需要依赖于ZooKeeper,通过抢占和监听“/datalink/managers/active节点,实现秒级Switch。

注:Worker的高可用并不依赖ZooKeeper,只要Manager能够保证高可用,Worker就是高可用的。

 

Task会将运行时信息注册到ZooKeeper,注册信息主要有两类:

 

  • Task的状态信息(运行、暂停还是出错),通过状态信息可以监控Task的健康状况;

  • Task的Position信息,通过Postion信息可以查看当前的同步进度,也可以实现故障恢复。

 

具体介绍可参见wiki:

https://github.com/ucarGroup/DataLink/wiki/1.0_DataLink总体架构  

 

概念模型

 

 

一句话概括概念模型:高度可扩展的、可对接任意存储之间数据同步的松散模型。架构选型章节对该模型已有介绍,此处不再赘述。

 

领域模型

 

 

Contract

 

契约即规范,是对不同领域内数据类型的高层抽象,其在Datalink中的主要表现形式为Record,如针对关系型数据库有RdbEventRecord、针对Hbase有HRecord。

 

在整个产品规划中,契约处于最顶层,无论采用何种基础设施、何种业务模型、何种开发语言,契约都是一套独立的规范。契约是连接Reader和Writer的纽带,Reader和Writer互不感知,它们通过识别共同的契约实现数据交换。

 

Business Model

 

Business Model是对数据交换业务场景的高层抽象,将不同场景的共性需求进行了归纳和总结,抽象出了一套统一的模型定义。

 

当然,它不是万能的,不能包含所有的需求点,并且是随着场景的增多不断演化的。但它是必须的,统一的模型抽象可以支撑80%场景下的功能复用。

 

主要模型定义如下:

 

  • Media:对存储单元的抽象。如:RDBMS中的表,HBase中的表,ElasticSearch中的索引,HDFS中的一个文件路径等,都称之为Media。

  • MediaSource:对存储产品的抽象。如:MySQL、SQL Server、HBase、Kafka、HDFS等,都称之为MediaSource。

  • MediaMapping(MediaMappingColumn):对存储单元间数据同步规则的抽象。具体见领域功能介绍部分。

  • MetaMapping:对存储产品间数据类型映射规则的抽象。如:MySQL的varchar映射到ElasticSearch的数据类型是String。

 

具体介绍可参见wiki:

https://github.com/ucarGroup/DataLink/wiki/1.6_深入领域 

 

插件模型

 

 

插件体系:一般由两部分组成,Framework+Plugin。DataLink中的Framework主要指【TaskRuntime】,Plugin对应的是各种类型的【TaskReader&TaskWriter】。

 

TaskRuntime:提供了Task的高层抽象、Task的运行时环境和Task的插件规范。

 

TaskReader&TaskWriter:一个个具体的数据同步插件,遵从Task插件规范,功能自治,和TaskRuntime完全解耦,理论上插件数量可无限扩充。

 

Task:DataLink中数据同步的基本单位是Task,一个Worker进程中可以运行一批Task,一个运行中的Task由一个TaskReader和至少一个TaskWriter组成,即有:

 

  • 程序运行期,同一类型的插件在一个进程中可以有多个实例,实例个数取决于有多少个Task用到了该插件;

  • 程序运行期,插件的生命周期归属于Task,在不同的生命周期阶段,依照Task的配置信息或相关指令,进行创建、初始化、运行或销毁等操作;

  • 理论上,TaskReader和TaskWriter可动态任意组合(能否组合,主要取决于待组合的TaskWriter能否适配TaskReader的Record类型);

  • 理论上,每新增一种插件,可支持的同步场景可以成倍数的增加(具体几倍,和插件类型和当前已有的插件数量有关系)。

 

具体介绍可参见wiki:

https://github.com/ucarGroup/DataLink/wiki/1.5_深入插件 

 

5、项目未来
 

 

DataLink项目借鉴了很多开源产品的思想,这里要重点感谢的产品有:Canal、Otter、DataX、Yugong、Databus、Kafka-Connect、Ersatz。

 

站在巨人的肩膀上,我们进行了开源,一方面回馈社区,一方面抛砖引玉。展望未来,我们希望这个项目能够活跃起来,为社区做出更大的贡献,内部的各种新特性也会尽快同步到开源版本,同时也希望有更多的人参与进来。

 

目前内部正在规划中的功能有:双机房(中心)同步、通用审计功能、各种同步工具和插件、实时数据仓库、整个更多已有开源产品的功能特性和各种大数据架构进行深度融合等。

 

直播回放
 

 

https://m.qlchat.com/topic/details?topicId=2000002588170519

活动预告