数据集成

       数据集成是集成两个或多个数据库数据的过程(process)。涉及的主要概念有：源库、目标库、交换任务(批量/增量)、数据类型转换、数据结构转换、过程处理函数等术语概念。数据集成的拓扑结构可以是1对1、多对1汇聚、1对多分发等，传统的批处理ETL工具如Kettle、新一代技术的实时ETL/Streaming产品如数贝TurboDX等都属于数据集成的应用场景范畴。

       数据从源库到目标库的交换过程可以采用直接库对库(内存处理)，也可以引入一个中间传输通道服务，比如采用消息中间件如MQ/Kafka等，实现源库和目标库的解耦(包括数据管理权限的解耦)，同时提供更加灵活的１对多分发路由的管理。

     数据集成领域还包括一些特殊的应用场景，如异构数据库间的复制同步(即按事务边界实时复制Replicate)、 CDC(日志DML、DDL获取及同步)、 数据文件(txt、csv、excel等)加载数据库、以及非结化文件交换传输(文件目录、FTP、HDFS)等应用场景。

     区别数据集成和应用集成的一个重要特征就是：数据集成是对应用系统已产生并“落地”后的数据进行感知、抽取、传输、处理、加载到目标库的整个过程，即数据集成的任务开始时，源端应用系统的数据产生过程已完成了。而不同之处在于，应用集成是指应用系统在业务逻辑处理过程中需要实时访问其它业务系统获取相关数据，或者产生的事件需要实时更新其它业务系统并返回状态。换句话说，应用集成是应用系统程序处理过程中的集成，往往需要改造已有的业务系统逻辑程序以满足应用集成的需求；而数据集成只需要和数据库发生关系。

数据集成场景有如下的特征：

• 参与数据集成的各个应用系统与集成任务是互相独立的，应用系统无需知道运行中的数据集成任务;
• 数据集成任务可以是实时的、准实时的、或批处理定时的;
• 当交换的数据完成时，目标系统无需立即给源端系统反馈信息，因而往往是异步处理过程;
• ETL、ELT、CDC技术往往用于数据集成场景中。

  应用集成

       应用集成是指集成两个或多个应用之间的协同处理过程(process)。

应用集成场景有如下的特征：

• 参与应用集成的数据库无需知道运行中的应用集成过程（process）;
• 消费数据的应用系统在应用层保持之间的依赖性(耦合度相对高);
• 应用集成是实时的且需要双向的握手（handshake）；
• 消费数据后，目标业务过程可以返回执行结果给源端应用，因而往往是同步的处理过程；
• 被集成交换的数据可无需“落地”数据库，仅由用户界面使用数据进行展示；
• 面向服务的架构(SOA)设计理念及ESB技术产品往往应用于应用集成领域。

      哪一个更好呢？

       如果您问应用集成vs数据集成哪一个模式更好，这是个不十分准确的提问。问题的核心并不在于哪一种集成方式更好，因为每一种集成方式有它适合的目标场景以及使用的约束条件。您可以简单地理解为：应用集成是在应用层级操作数据，而数据集成是在数据库层级开展的集成工作。

       一般来说，无论企业的大小，往往都会有数据集成和应用集成的两类集成需求，但有时某种需求也可以通过不同的解决方案来实现; 比如，通过单向或双向的准实时异步数据同步的方式(数据集成)，来解决应用系统间的应用流程集成问题(应用集成)，从而降低集成的耦合程度和增加业务的灵活性，尤其是在难于改造已有应用系统的约束条件下。

     其它相关集成模式及市场产品的功能作用

• 界面集成

      还有一种可以称为界面集成或门户集成的集成需求，即将各种应用的用户界面集成于一个统一门户，或者嵌入到某个应用系统界面中，被集成的各个应用仍保持自己的独立性。用户界面集成往往采用统一单点登录和用户体系的后台集成服务来实现。 

• 混合集成方式，应用系统间数据共享交换如何实现？

      在现实的企业环境中，有许多应用系统间需要数据共享交换的需求场景(如解决数据重复录入、业务流程集成等)，但由于受制于许多约束原因：如已有需要集成的源端和目标端应用系统难于改造接口、或者源端系统提供的数据并不完整、或者需要增加中间复杂的数据处理环节及管理环节，理想化的应用集成方案并不现实，这种应用场景的解决往往需要混合式的集成方案，即从源端应用系统数据库中获取实时业务增量数据，中间进行转换加工处理或人工管理干预，通过数据准实时的同步交换，再利用写端的定制开发方案来解决; 比如, 可依据不同情况，采用中间表、或调用已有目标系统提供的写入接口(如果有)、或者在无法提供目标应用系统接口的情况下，可通过数据梳理及智能分析工具(如采用数贝的AiCATA数据梳理和数据目录产品)，分析目标应用系统数据库中的事务(transaction)和数据关系，由定制开发程序将数据直接写入到目标库中，并保证应用系统数据的完整性和业务事务的正确性。

• 消息中间件产品

      在早先的应用系统集成领域，有一款称为消息中间件/MQ的软件产品常出现。消息中间件的主要作用，是通过消息队列(Queue)和主题(Topic)的实时发布/订阅模式，以便实现消息生产者(源端应用系统)和消息消费者(目标应用系统)间的解耦、数据通道和分发路由等功能。传统的消息中间件如IBM MQ、RabbitMQ等，不提供数据内容的解析处理能力，只起到消息通道(管道)的作用，两端应用系统与MQ的集成方式主要是通过程序语言级的API接口定制开发。因此，参与集成的应用系统均需要在逻辑代码层进行相应的改造和开发，是一种业务数据紧耦合的应用集成方式。近年来，在大数据领域，出现了一些新的开源消息中间件产品如Kafka等，在数据传输的吞吐量、性能、可靠性、可扩展性、以及数据内容处理的能力方面，有了显著的提升。

      高端的数据集成产品如数贝TurboDX，支持使用第三方高性能的消息中间件如Kafka作为数据集成任务之间的数据传输通道，可应用于跨网络节点传输、数据分发、以及应用程序独立消费CDC数据等场景。

• 企业服务总线ESB产品

      十几年前市场上出现的、基于面向服务架构(SOA)的企业服务总线ESB技术产品，在企业应用集成(EAI)领域曾流行过一段时间，但由于采用ESB产品的项目实施落地起来过于复杂，产品很重，仍需要大量的二次开发，使得ESB产品适应变化和长期运维的成本高昂，可谓“理想丰满、现实骨感” 。有的ESB产品并不能提供服务本身的创建，仅提供WS、REST服务的注册、代理和服务编排，仍需要各个应用系统定制开发各自的端服务，且作为服务代理中心的ESB平台一定程度上成为服务的并发和效率瓶颈，对于小量数据的请求访问或消息传输也许还可以应付，但对于大数据的实时访问和数据传输则力不从心，造成ESB产品性价比低、市场上已逐步被边缘化。虽然传统意义上的ESB产品正走向衰落，但并不代表SOA的设计理念不好。最近几年，轻量级P2P微服务(Microservice)的架构正在深入人心，但要实现真正意义上的企业级微服务架构，您可能更需要一个好的软件架构师。但无论如何，ESB或微服务架构产品都属于应用集成EAI的范畴，代替和解决不了企业数据集成的需求。而且正相反，在数据驱动型企业应用中，数据同步、数据交换、数据整合/数仓的应用需求场景大量存在; 因此，拥有一个灵活易用的、功能强大的企业级数据集成服务平台(或称为数据总线产品)是现代企业实现数字化、智能化所必不可缺少的基础设施平台。

• 数贝TurboDX企业级数据集成服务平台产品

     企业级数据集成服务平台产品要能实现各种异构数据库、数仓/大数据平台间数据的灵活流动、汇聚和分发，属于数据中台核心功能之一。要实现数据层、共享交换层、数据管理与应用的分离（数据中台的目标），则要求数据同步、交换整合产品应提供灵活的、可自我服务的、可自主管理的强大综合能力，同时作为独立的第三方基础服务，应支持广泛的数据源连接，包括各厂商的关系型数据厍/数仓、MQ、NoSQL及大数据平台等，并能够支持任务压力负载和高可用性集群，以及支持多项目多租户的SaaS服务平台使用模式。

    TurboDX企业级数据集成服务平台产品，提供各种异构数据源连接、元数据目录及智能分析、异构数据库实时复制同步、交换整合、文件同步交换、及跨网络远程通道传输服务等集成一体化的功能，可用于数据复制、数据同步、读写分离、数据迁移、ETL/ELT、数据汇聚整合、数据分发、数据发布/订阅、大数据集成(mpp数仓、hadoop、kafka)等数据集成应用场景。作为企业级的数据集成服务平台，TurboDX提供任务负载/高可用性集群和企业级多租户服务SaaS平台的使用方式。这些需求功能的解决，过去往往由市场上某个单一的产品提供各别点上的功能，像传统的复制工具产品如Oracle GoldenGate (OGG)、ODI、IBM CDC、以及Informatica等ETL工具产品方案。这些产品往往价格十分昂贵，配置和使用十分复杂，且难于与其它厂商的产品实现集成一体化使用，造成企业级整体解决方案往往需要购买多个工具产品及大量的集成定制开发，无法提供统一的元数据目录、任务调度和运维监控管理，难于满足集约化的基础设施服务平台的使用模式要求。

     市场上出现的一些误导

• 有些服务商将企业级/城市政府的数据共享交换平台项目等同于(或转变为) 一个数仓/或主数据/或BI应用开发项目，有意无意地会将一款ETL/或消息中间件/或ESB工具产品充当为企业级的数据共享交换平台，阉割和弱化了数据共享交换平台作为基础设施平台所要求的：多功能一体化、灵活独立性、多项目多租户SaaS服务模式、统一元数据目录管理、统一任务调度和运维监控管理等作为基础设施服务平台的核心功能要求。事实上，数仓/主数据/或BI应用只是基于统一的数据共享交换服务平台支撑的某个应用而已。

• 用户数据集成产品选型应考虑第三方专业公司提供的独立产品。数据库厂商/或某些服务商提供的工具，往往服务于自我的商业利益，对支持其它厂商的数据库能力不足（或者不支持），易造成事实上的绑架及失去了数据中台的灵活性和业务灵活性，这与数据中台的目标背道而驰。选用第三方独立厂商功能強大的、灵活的、可自我服务和可自主管理的中间层数据集成平台，才能让用户按实际需求灵活地选用不同的数据库/数仓/大数据平台等相关产品，以及实现数据业务的灵活性。

         作者: 李中博士，毕业于北京大学，现任北京数贝软件科技有限公司高级咨询师