优采集平台( 而成，文末还有好书送哦~~（讲师介绍）)

　　优采集平台(

而成，文末还有好书送哦~~（讲师介绍）)

　　

　　本文基于dbaplus社区第170期在线分享，文末有好书~

　　导师

　　

　　陆标

　　技术专家

　　百度百科：

　　数据交换平台是指通过计算机网络，将多个单独搭建的应用信息系统集成起来，构建的信息交换平台，使多个应用子系统能够传输和共享信息/数据，提高信息资源的利用率，成为信息化建设的基本目标是保证分布式异构系统之间的互联互通，建立中央数据库，完成数据的抽取、集中、加载和展示，构建统一的数据处理和交换。

　　笔者认为，数据交换平台是构建分布式系统的三驾马车之一。这些三驾马车是基于RPC的服务调用、基于MQ的事件驱动和基于数据同步的数据共享。

　　推动数据交换平台出现和发展的根本动力是：交换空间换时间。

　　一、说说交流平台

　　1、服务场景

　　综上所述，数据交换平台可以服务的场景可以分为三类：基础设施、容灾备份、异构重构。

　　基础设施

　　场景一：EDA

　　通过数据交换平台，将数据库Log事件（如MySQL Binlog）发送到MQ，然后被不同的消费者消费，驱动不同的业务流程（如：刷新缓存，构建搜索引擎，放置后发送短信下单，付款后通知发货等），基于这种架构，业务端省去了定义领域事件和发送事件的工作，大大节省了工作量。

　　更重要的是，基于数据库自身的Log机制，数据一致性更有保障，其他的容错处理、HA等机制只能靠数据交换平台来保证。

　　当然，如果事件定义比较复杂，无法表达普通业务表对应的LogEvent，那么还是需要自己设计领域事件。这时候我们可以定义一个通用的事件表来保存自定义事件；而发送事件的操作对应于将事件表的插入操作与业务操作一起放在一个事务中。交易提交后，交易平台拉取事件表的日志，然后提取事件内容并发送给MQ。

　　

　　有很多事情可以通过使用数据库日志来完成。我们的团队正在开发一个基于 MySQL-Binlog 消费的事件平台。一般架构如下：

　　

　　事件平台提供事件订阅、事件配置等基础支持（如：是否实时触发下一个操作或倒计时触发下一个操作，下一个操作是接口回调还是新事件等） 、事件调度、实时监控等，用户只需要提供配置规则和开发回调接口，免去了各个研发团队各自为政、重复建设的各种问题。

　　此外，该平台最大的特点之一是引入了事件驱动的定时器机制。在这种机制之前，当涉及到与时间要素相关的判断时（如：未结算的订单下单后多久自动失效，租车一定时间后，结算类型自动从短租转产品到长租产品等），业务研发团队需要编写大量定时任务扫描数据库来计算时间间隔，不仅开发成本巨大，而且往往存在较大的性能问题。.

　　有了定时器机制，业务侧只需要配置时间规则，事件平台分布式，可以提供更高的性能支持。

　　场景二：CQRS（Command Query Responsibility Segregation）

　　这里是DDD领域的一个概念CQRS，具体介绍可以参考链接：

　　CQRS的思想本质上是为同一条数据创建两组模型（或视图）：

　　CQRS 架构模型的开源实现是 Axon-Framework。基于Axon，可以构建自己的领域模型、领域事件、事件仓库、查询视图等，提供聚合根定义、事件回放、事件消费、数据镜像等基础支持，应用其架构图如下：

　　

　　理想是丰满的，现实是骨感的。DDD已经提出很多年了，但是由于实践的难度，大部分公司还停留在通过数据库表建模的阶段，但是CQRS的想法非常好。

　　所以抛开DDD，基于表模型来理解CQRS：数据表模型也是领域模型，但不是面向对象的领域模型。数据库日志也是事件，但表达能力不如DDD中的领域事件丰富。

　　在此基础上，依靠数据库管理模型和事件，加上一个事件转发和消费的数据交换平台，可以构建一个广泛的CQRS架构，如下图：

　　

　　场景三：数据采集并返回

　　很多企业正在或已经搭建了自己的大数据平台，其中数据采集和回流是不可或缺的一环。一般小公司在采集层面做数据相对碎片化，各种开源产品堆积起来完成采集相关工作，大公司会考虑平台化，放数据采集@ > 在整个数据交换平台的规划中，以提高效率和降低成本。

　　下图是我们团队的数据交换平台与大数据平台的关系*敏*感*词*：

　　

　　灾难恢复备份

　　场景示例1：多个机房

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

　　场景二：数据镜像

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

　　场景三：数据归档

　　通过增量交换，同步时忽略删除事件，实现实时归档。

　　异构重构

　　场景示例一：数据库升级、搬迁、拆迁、整合

　　数据库的升级，数据库的搬迁、拆除、整合等日常运维操作都会涉及到数据迁移。如果有平台，迁移工作就会变得非常简单。

　　场景二：资产复用

　　公司越大，负担越重。许多公司拥有各种类型的数据库和存储产品。为了复用这些资产，涉及到各种场景下的数据同步。统一的数据交换平台将使这些场景变得不同。同步变得容易多了。

　　2、施工思路

　　一千个读者将拥有一千个哈姆雷特，一千个建筑师将拥有一千个建筑理念。数据交换平台的建设没有灵丹妙药。不同的团队面对的场景不同，演进的架构也不同。在这里，结合自己的经验和体会，谈谈数据交换平台建设中的一些方法论和注意事项。

　　架构选择

　　数据同步过程是生产者-消费者模型的典型表现。生产者负责从不同的数据源拉取数据，消费者负责将数据写入不同的数据源。生产者和消费者之间可以存在*敏*感*词*的关系。该关系也可以是一对多关系。

　　那么，数据交换平台是串联连接生产者和消费者的枢纽，可以控制串联过程中的过程。简而言之，就是数据集成。

　　数据整合是数据交换平台最基本的工作。架构的选择和设计应该只关注这个基本点。只有便于快速集成的架构才能支持不断变化的数据同步需求。

　　在设计架构时，需要考虑的要点总结如下：

　　许多公司正在构建自己的基于消息中间件的数据交换平台（有些称为数据总线）。生产者向MQ发送数据，消费者从MQ消费数据，数据可以自描述。这是一个典型的开源实现是Kafka-Connect的模型，其架构图如下：

　　

　　优势：

　　缺点：

　　无论如何，架构模型都非常优秀，可以满足60%到70%的应用场景。但是我们团队并没有直接应用这个架构，而是针对它的缺点，受到了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等），后者是可行的，主要策略是文件转储和API提取。

　　实时增量同步

　　先说实时增量同步。基于触发器获取数据比较传统，而且由于运维繁琐，性能差，使用越来越少。

　　但是，在某些特定场景中仍有应用空间。有一个代号为SymmetricDS的开源产品，可以自动管理触发器，提供统一的数据采集和消费机制。如果你想基于触发器同步数据，可以参考这个产品。

　　基于日志分析的同步目前最为流行，如MySQL、HBase等，提供日志重放机制，协议开源。

　　这种方法的主要优点是：零侵入业务表，异步日志解析没有性能问题，实时性比较高。

　　日志解析很漂亮，但并不是所有的DB都提供这样的机制（比如SQL Server）。当触发器和日志解析不固定时，通过时间戳字段（如modify_time）定时扫描表，获取变化的数据，同步也是常用的方法。

　　这种方法有几个明显的缺点：实时性比较低，需要业务端保证时间戳字段不能漏更新，常规的表扫描查询也可能带来一些性能问题。

　　离线完全同步

　　再说说离线全同步。文件转储方式一般用于同构数据源之间的同步场景，需要DB自身的导入导出机制支持，可以服务的场景比较单一。API提取方法更通用、更灵活。同构和异质都可以通过编码实现。如果做得好，它还可以通过灵活的参数控制提供各种高级功能，例如开源产品DataX。

　　

　　难题

　　将数据从一处移动到另一处，如何保证数据在同步过程中没有任何问题（不丢失、不重、不乱）或者出现问题后快速恢复，需要考虑的点很多，非常复杂，这里结合自己的经验说说主要的难点和常见的解决办法。

　　一：种类繁多的API

　　好像没什么难的，不就是调用API进行数据操作吗？事实上，市面上的存储产品有上百种，常用的存储产品有几十种。产品特性差异极大。

　　为了构建一个高效可靠的平台，需要对这些产品的API及其内部机制进行深入研究（例如：是否支持事务？事务粒度是表级还是记录级？是否支持随机读写还是只能支持Append？操作API的时候有没有客户端缓存？HA是怎么实现的？性能瓶颈在哪里？调优参数是什么？内置的Replication机制是怎么实现的?等），否则平台只会停留在可用阶段。

　　以我们自己的经验为例：在搭建大数据平台时，我们需要一个数据交换平台，将MySQL和HBase的数据实时同步到HDFS。基于DataLink，我们开发了HDFS Writer插件，在实践过程中走了不少弯路。

　　要解决这个难题，没有捷径可走。只有提升自己的硬实力才能取得突破。

　　二：同步关系治理

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

　　需要治理的要点是：

　　为了避免环回同步，一般添加DAG检测机制就足够了。

　　保证schema一致性的方法一般有两种：一是在同步过程中，从源端获取的DDL语句自动同步到目标端；二是平台提供了同步关系检测机制供外部系统使用。前者在异构数据源中比较。在很多情况下，实现起来比较困难（脚本转换、性能问题、幂等判断等），也不是所有的解决方案都能得到ddl语句，后者更加通用和可行。

　　目前我们内部的计划是，当SQL脚本上线时，数据交换平台会进行SQL分析，然后将同步关系树返回给DBA团队的DBMS系统，然后DBMS系统会根据到同步关系提示。

　　同步关系树*敏*感*词*如下：

　　

　　第三：数据质量

　　保证数据质量是数据交换平台的核心使命。在同步过程中，不丢失、不重、不乱。通过数据检查可以快速发现问题；发现问题后可以快速修复。

　　如果事前、事中、事后三个阶段都能控制好，那么平台就达到了极好的水平。

　　事前阶段依靠完善的设计和测试，事中阶段依靠三维监控和报警，事后阶段依靠功能丰富的修复工具。但是，由于场景的灵活性和复杂性，每个阶段都不容易实践，例如：

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

　　

　　第四：可扩展性

　　科技发展日新月异，业务演进也日新月异。为了应对这些变化，平台也必须变化，但如何用最小的变化带来最大的收益，是判断一个平台或一个产品是否成熟的关键。指数。

　　作者信奉一句名言：建筑是进化的，不是设计的；但同时，我也相信另一句名言：好的设计是成功的一半。两者并不矛盾，主要是如何妥协。

　　构建平台和构建工具之间的一个重要区别在于，前者应侧重于抽象、建模和参数化，以提供灵活的可扩展性。

　　那么可扩展性应该考虑到什么程度呢？一句话概括：在搭建平台的过程中，我们要不断的总结、修正、抽象、迭代、推演，对已知的事物进行建模，使未知的事物可以预见而不是去做。过度设计，也是充分设计。

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

　　3、开源产品

　　以下是数据同步相关的开源产品列表，供参考学习：

　　

　　二、实战项目介绍

　　1、DataLink 项目介绍

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

　　翻译含义：数据链，数据（自动）传送器

　　语言：纯Java开发（JDK1.8+）

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

　　开源地址：

　　这个开源是去掉内部依赖后的版本（开源是增量同步子系统）。DataLink和阿里集团内的DataX也进行了深度融合，增量（DataLink）+全量（DataX）共同构成了一个统一的数据交换平台（打个比方，DataLink也算是DataX的增量版） ，平台架构如下：

　　

　　2、项目背景

　　随着神州优车集团业务的快速发展，各种数据同步场景层出不穷，原有的系统架构难以支撑复杂多变的业务需求。于是，从2016年底开始，团队开始酝酿DataLink产品。

　　着眼于未来，我们的目标是打造一个满足各种异构数据源之间实时增量同步，支持公司业务快速发展的新平台。在深入研究的基础上，我们发现没有任何开源产品可以轻松实现我们的目标。每个产品都有明显的缺点和局限性，所以最后的选择是“自己设计”。

　　然而，自我设计并不是凭空设计的。现有的数据交换平台、现有的经验、大大小小的开源产品是我们设计的基础。与其说是自我设计，不如说是站在巨人的肩膀上。进行了一次飞跃。于是，像DataLink这样的产品诞生了，其产品特点主要有以下几点：

　　3、申请状态

　　DataLink于2016年12月开始立项，2017年5月推出第一个版本，在神州优车集团内服务至今，基本满足了公司各业务线的同步需求。目前内部同步规模大致如下：

　　4、架构模型

　　基础设施

　　

　　DataLink是典型的Master-Slave架构，Manager（管理节点）+Worker（worker节点），以下是基础架构的关键模块概览：

　　经理

　　Manager是整个DataLink集群的大脑，具有三个核心功能：

　　团体

　　工人

　　任务

　　（重新）平衡

　　(Re-)Balance的定义：通过一定的负载均衡策略，将任务平均分布在Worker节点上。(Re-)Balance的单位是Group，一个组中(Re-)Balance的发生不会影响其他组的正常运行。

　　当（重新）平衡发生时：

　　插入

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

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

　　MySQL

　　DataLink 的操作依赖于各种配置信息，这些信息存储在 MySQL 中。DataLink在运行过程中动态生成监控和统计数据，这些数据也统一存储在MySQL中。

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

　　动物园管理员

　　Manager的高可用需要依赖ZooKeeper，通过抢占和监控“/datalink/managers/active”节点，实现二级Switch。

　　注意：Worker 的高可用不依赖于 ZooKeeper。只要Manager能保证高可用，Worker就是高可用。

　　任务会将运行时信息注册到 ZooKeeper。注册信息主要有两种类型：

　　详情请参考维基：

　　整体架构

　　概念模型

　　

　　一句话概括概念模型：高度可扩展、松散的模型，可以对接任何存储之间的数据同步。这个模型在架构选择章节已经介绍过，这里不再赘述。

　　领域模型

　　

　　合同

　　契约是规范，是对不同领域的数据类型的高级抽象。它在Datalink中的主要表现形式是Record，比如关系型数据库的RdbEventRecord，Hbase的HRecord。

　　在整个产品规划中，契约处于最顶层，无论什么样的基础设施，什么样的商业模式，什么样的开发语言，契约都是一套独立的规范。合约是连接Reader和Writer的纽带，Reader和Writer互不感知，它们通过识别一个共同的合约来实现数据交换。

　　商业模式

　　业务模型是数据交换业务场景的高级抽象。它总结归纳了不同场景的共同需求，抽象出一套统一的模型定义。

　　当然，它也不是万能的，它不可能收录所有的需求点，它会随着场景的增加而不断进化。但这是必要的。统一的模型抽象可以支持80%场景的功能复用。

　　主要模型定义如下：

　　详情请参考维基：

　　深入领域

　　插件型号

　　

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

　　TaskRuntime：提供Task的高层抽象，Task的运行环境，Task的插件规范。

　　TaskReader&TaskWriter：具体的数据同步插件，符合Task插件规范，功能自主，与TaskRuntime完全解耦。理论上可以无限扩展插件的数量。

　　Task：DataLink中数据同步的基本单位是Task。一批任务可以在一个 Worker 进程中运行。一个正在运行的Task由一个TaskReader和至少一个TaskWriter组成，即有：

　　详情请参考维基：

　　深入的插件

　　5、项目未来

　　DataLink 项目借鉴了许多开源产品的想法。我们要感谢的产品有：Canal、Otter、DataX、Yugong、Databus、Kafka-Connect、Ersatz。

　　站在巨人的肩膀上，我们进行开源，一方面是回馈社会，另一方面是我们在发家致富。展望未来，我们希望这个项目能够活跃起来，为社区做出更大的贡献。各种新的内部功能也将尽快同步到开源版本。我们也希望有更多的人参与。

　　目前内部正在规划的功能包括：双机房（中心）同步、通用审计功能、各种同步工具和插件、实时数据仓库、更多现有开源产品的全功能特性，以及深入各种大数据架构的集成等等。

　　实时回放

　　复活节彩蛋来了

　　在本文微信订阅号（dbaplus）的评论区留下引起共鸣的见解。小编将在本文发表后的次日中午12点，根据留言的精彩程度，选出1位幸运读者，赠送以下好书一本~

　　注：同月，已领取赠书者将无法获得两次赠书。

　　

　　特别感谢华章科技为本次活动提供图书赞助。

　　- 近期活动 -

　　2018 Gdevops全球敏捷运维峰会广州站