一 . 业务背景
随着云计算的普及和大数据时代的到来，如何让各种数据源中的种类丰富的数据高效上云，以及经过云上大数据计算后，如何把计算结果回流到种类丰富数据源 ？或者云上各个产品之间的数据怎么进行同步 ？ 各个云厂商或者大数据解决方案提供商都推出了各自的数据集成产品，本文将就常见的解决方案进行探讨。
典型的大数据业务集成场景
二. 数据集成需要解决的问题
数据集成的本质是实现不同数据源之间的数据交换，并且在交换过程中具备数据清洗转换的能力；当然，在实际应用场景中，还需要解决各种复杂网络问题，例如用户本地机房如何进行数据上云，云上不同VPC 内的数据源如何进行相互同步等。
一个商业数据集成产品通常需要具备以下功能:
1）支持种类丰富的数据源，并具备数据源的元数据管理
2）具备数据源的全量抽取和增量抽取能力，并且稳定高效
3）具备可视化的转换清洗能力
4）具备数据质量监控能力，能收集脏数据并对同步的数据做质量校验
5）完善的运维体系
6）开放性，方便第三方扩张数据源
7）系统水平扩展能力
8）具备复杂网络下的数据集成方案
三. 业内常见解决方案及痛点
目前业内公司的集成产品有很多，但技术选型上基本分为两类：
1） 单机同步引擎+资源管理分布式扩展，典型的如开源的Datax，Kettle + k8s 进行整合 ，当然还有部分拿web服务器来嵌入同步引擎的，这种方案并不如拿专门的资源管理系统来做扩展好
2） 利用已有大数据计算引擎，将插件运行在计算引擎上，在上面包装成数据集成产品，如早期的Sqoop，以及现在不少公司搞的基于Spark，Flink 的流批一体数据集成产品
下面将从技术角度分析一下上面两种方案
方案一：
采用方案一典型架构如下 ：
其中Node 节点上面安装需要运行的同步引擎，如datax 或者kettle
方案一的好处就是简单可控，当需要接入不同网络环境的数据源时候，可以借助资源调度层来做扩展，当然像K8S 这类的资源管控还不支持这种复杂网络情况，如果有这种业务场景，需要自建资源调度层。借助与资源调度层，多个同步任务运行时候可以水平扩展，但由于同步引擎只能单机运行，所以当同步的源头和目标都为集群时候，单机版本可能会出现性能瓶颈。
方案二 ：
方案二直接利用现有的大数据计算引擎，如hadoop,spark,flink ；按照具体的计算引擎规范开发相应的同步插件，然后通过数据集成产品的特性进行业务化包装。技术细节可以参考具体的计算引擎，不再细述
方案二的优缺点也很明显 :
优点 : 大数据计算引擎本身功能比较强大，在上面包装数据集成产品可以快速获取集群同步能力，转换清洗能力
缺点 : 无法适应复杂的网络情况，另外对应大数据计算引擎，一般需要专门的团队去维护，几乎没人为一个数据集成会去单独搭建并且运维一个大的计算引擎，成本高。另外整个数据集成跟某个具体的计 算引擎绑死，如果将来要换计算引擎，成本更高
方案二对于大厂自建数据集成能力比较适用，因为通常大数据计算引擎有专门团队维护，不仅用于数据集成，而且用于其他的计算场景，成本会比较低，而且因为自己公司用，很少有复杂的网络场景。
经过对上面方案一和方案二的分析，我们发现性能、成本、以及适应复杂网络环境似乎存在着矛盾，那么是否有一直解决方案可以完美解决上述痛点呢？
四. 我们的解决方案-Dlink
Dlink 是阿里巴巴自研的数据集成引擎，采用插件和引擎分离式设计，插件通过引擎适配层运行在具体引擎上，整个插件逻辑跟具体引擎无关，不仅实现了插件可扩展，还可以实现运行引擎扩展，具体架构如下 :
- 插件与运行引擎分离
我们针对数据集成场景，把读取/写入的插件需要的方法做了最原子的抽象，通过引擎适配层运行在具体的引擎上，从而实现插件与引擎解耦；整个同步过程不仅可以运行在自带的原生引擎上面，也可以运行在flink,spark,hadoop 上面，单机能力与集群能力、清洗转换能力全部具备，并且运行引擎可以通过增加新的引擎
适配层进行扩展，不需要改动插件代码。 - 成本优势
由于Dlink 运行态没有与任何引擎绑死，也就意味着只要客户有任何一套Dlink 已经支持的运行引擎，那么可以直接把插件运行在客户原有的计算引擎上面。举个例子，有个客户自己有个spark 或者 flink 计算集群 ，那么可以不需要单独购买同步资源，可以直接利用客户的计算资源做同步，从而降低成本 - 复杂网络支持能力
1） Dlink 支持单机运行，可以通过资源调度层的能力将客户环境的机器注册上来，解决网络问题
2）如果客户本身有Dlink 支持的计算集群，如flink , 由于直接运行在客户的计算集群上面，那么就天然的跟 用户的网络做了打通
目前Dlink一期功能已经在阿里云上线 ，感兴趣的可以通过Dataphin产品中的集成模块进行试用