转载本文需注明出处：微信公众号EAWorld，违者必究。
前言：
本文主要介绍数据交换过程中常用的数据交换方法和方式以及数据交换在新技术下所面对的“挑战”，方便大家深入理解数据交换过程。普元实施数据交换项目已有多年成功经验，本文也将分享大数据时代数据交换所遇到的问题和应对策略。
目录：
1、为什么要进行数据交换
2、数据交换存在的问题
3、数据交换面临的挑战
4、数据交换破解“数据孤岛”
5、总结
1.为什么要进行数据交换
企业大量的IT投资建立了众多的信息系统，但是随着信息系统的增加，各自孤立工作的信息系统将会造成大量的冗余数据和业务人员的重复劳动。企业急需通过建立底层数据集成平台来联系横贯整个企业的异构系统、应用、数据源等，完成在企业内部的ERP、CRM、SCM、数据库、数据仓库，以及其它重要的内部系统之间无缝的共享和交换数据。
数据是在流通、应用中创造价值的，这就涉及“数据共享”和“数据交换”。在实施数据交换的过程中，不同的数据内容、数据格式和数据质量千差万别，有时甚至会遇到数据格式不能转换或数据转换格式后丢失信息等棘手问题，严重阻碍了数据在各部门和各应用系统中的流动与共享。因此，对企业内各系统异构底层数据进行有效的整合已成为增强企业商业竞争力的必然选择。
2.数据交换存在的问题
企业对数据服务的需求日趋迫切，如何有效的管理数据、高效的提供数据服务是目前企业对所面临的关键挑战。目前集团层面客户信息分散，各子公司之间的客户信息无共享。内部系统获取客户数据来源系统分散，方式多样难以管理，且获取客户数据时效性较低，供数标准不统一，缺乏统一的客户数据服务平台。
1. 数据平台中数据内容繁多，难以全面掌控。
通过多年的信息化建设和运营，企业已经建立了完善的业务应用系统，有效的支撑了核心业务的创新和发展，但随着应用系统的增多，数据量和数据应用环境增大，在对这些数据进行使用的过程中逐渐存在不合理、不统一的问题。
2. 数据平台中数据的流转和逻辑过程复杂，难以追溯数据来源。
许多企业目前没有统一的数据资产标准，各业务系统中数据质量参差不齐，存在信息孤岛现象，不同部门同一名称数据可能有不同的含义，同一个数据可能又有不同的命名，数据有效交互和共享存在问题。存在部分系统数据更新不及时的问题，核心业务数据无法朔源，数据的准确性和及时性较低，现有报表在建模时几乎每个报表都要重复建模，人为参与工作过多且层次复杂，无法高效的对流程及指标进行精确监控及分析，数据的利用效率和模型重复使用率较低。
3. 业务部门对数据结构和质量无法管控
目前数据管控的发展方向和需求是由业务部门提出，但业务人员对公司复杂的系统无法进行全面深入掌握，特别是技术层面。为了使业务部门从数据结构到数据质量上更好的管控，梳理业务系统与数据库结构关系，成为目前急需解决的问题之一。
3.数据交换面临的挑战
随着互联网以及大数据等诸多新技术的发展，传统的数据交换面临着许多挑战。
1. 传统方式一般是以单表数据交换作为单位进行作业开发，随着企业中数据库以及表的增多这种方式的开发效率低下、容易出错。整库数据交换时工作量巨大
2. 传统方式下开发交换模型只能手工一个一个进行，任务多、易出错。需要一种能够在同一种业务下批量进行开发的模式
3. 在进行实时数据同步时需要许多额外的操作配合才能完成，过程复杂，对人员技术要求高，
4. 在进行PB级数据交换时传统交换方式效率较低，需要很长时间才能完成。
5. 传统的数据交换工具不具备业务化的开发能力，遇到相同的数据交换需求需要重头开发。
6. 在安全保障上传统的方式是手工编写加密、脱敏的脚本来实现
7. 进行跨区域数据同步时需要多种技术配合，实现方案复杂。
4.数据交换破解“数据孤岛”
4.1 数据标准
为保证各应用系统中的代码表对同一业务信息定义一致，确保数据消费系统可以根据业务代码辨别数据的确切业务含义，应提供可配置的功能，基于一定的标准对数据供应系统代码进行转换，使数据存储和数据消费系统按照统一标准来理解数据。
数据交换离不开数据标准，数据未动标准先行是构建优质数据交换的前提。但现实中许多企业没有做好数据标准，导致这些标准是在进行数据交换或数据采集的时候进行，影响了数据的质量。一旦出现数据被篡改、被泄露等安全性问题，轻的影响业务开展，严重的泄露核心机密造成企业重大损失。拷贝的数据难以控制准确性和合规性，拷贝的数据流向哪里也无法控制，是谁拷贝了信息也无法掌控。一旦出现信息泄露，无法追责。
统一指标数据标准，可以规范业务统计分析语言，帮助企业提升分析应用和监管报送的数据质量，进而提高全行数据质量和数据资产价值。
4.2 自动采集元数据
数据交换依托于元数据，数据交换的本质是基于元数据的交换。对半结构化和结构化数据自动采集。
元数据是关于数据、操纵数据的数据和数据库系统的结构和意义的描述信息，重要目标就是提供数据资源的全面指南。元数据不仅定义了数据交换中的数据模式、来源以及抽取转换规则等，而且整个数据交换系统的运行都应该是基于元数据的，是元数据把数据交换系统中各个松散的组件联系起来，组成了一个有机的整体。
通过自动化的元数据采集完成部门核心职能的业务梳理及其对应的信息资源梳理，编制部门信息资源目录，摸清信息资源有什么、在哪里，提高信息资源共享程度，建立信息资源共享机制和管理制度。结合企业内部信息系统中的数据现状和企业业务属性、技术属性的要求形成企业数据标准的业务属性和技术属性，制定有效合理的指标数据规范要求。
4.3 数据交换方式和方法
4.3.1 不同类型数据交换方式
新的数据交换平台提供数据、报文文件等多种数据交换服务，能够快速建立跨硬件平台、数据库和操作系统的可交互操作的数据交换与信息共享平台，交换平台提供了一个开放的环境，支持多样的客户机、数据库、网络和通讯协议，通过可视化配置实现与数据库、文件以及web接口的数据交互。使得数据交换与业务逻辑的个性有机结合，快速响应数据集成和外部数据交换的需求。
数据交换的方式一般是根据数据的类型来进行区分，如结构化或半结构化的数据可通过ETL的数据交换方式进行，非结构化的数据像压缩文件、电影、图片等采用文件传输的方式进行交换，而对于一些实时性较高的交换一般采用接口形式进行。例如：restfull、webservice等。
结构化数据交换方法
结构化和半结构化数据交换主要有：时间戳同步、全文比对同步、触发器同步、CDC增量同步、全量同步。
这里我们对几种做一个比较：
- 全量同步
全量抽取一般适用于统计分析或无需进行二次更新的业务需求，通过全量抽取一次或多次将业务系统数据源在不做任何操作的情况下直接抽取过来，全量数据抽取方式虽然较简单、直接、快速。通过系统中的采集组件，无需增加过滤条件，即可对数据库中的全量文件进行一次性采集。全量采集比较适合于数据业务量小的业务需求。这种方式不能增量的进行数据同步，对于大数据量下的同步并不适用。
- 时间戳同步
使用这种方式进行增量数据抽取的前提是源数据库与目标数据库都必须有时间戳字段。先读取目标数据库中的最大时间，然后以这个时间作为参数从源数据库中读取大于这个时间的所有数据。
基于时间戳的方法需要相关应用系统中的每个表中都有一个时间戳字段，以记录每个表的修改时间。这种方法不影响原有应用的运行效率，但如果表中没有时间戳的字段却需要对原有系统做较大的调整，这种方式不能捕获到那些并非通过应用系统引起的操作数据变化。
优点：处理速度快，数据处理逻辑相对简单。
缺点：源数据库没有时间戳字段的表需要更改表结构，而且需要源数据库来维护时间戳字段；无法实现数据同步，因为使用时间戳字段无法获取删除后的数据。
- CDC增量同步
通过分析数据库日志的信息来捕获复制对象的变化序列。这种方法不仅方便，也不会占用太多额外的系统资源，对任何类型的复制都适合，不但能提高效率和保证数据的完整性，还能在对等式复制时提供详细的控制信息。但由于数据库日志的格式是不公开的，因而不得不基于某一固定的数据库日志分析工具或接口，这给异构数据库复制带来了问题。
优点：可靠性强，对源系统没有影响。
缺点：各数据库系统的日志文件绝大部分都是私有的，并且日志格式都不一样，因此捕获这些日志需要有专门有针对性的组件来进行，个别数据库还需要管理员权限进行配合才能实现。对于没有提供日志分析接口的数据源，开发的难度比较大
- 触发器同步
在业务数据表中创建相应的触发器，当提取、复制对象进行变更（插入、修改、删除）时，由触发器触发提数程序，将变化写入目标数据库中。这种方案可用于同步复制、增量复制。
优点：借助数据库本身的机制，可靠性强。
缺点：对源系统有影响，需要建立触发器以及临时表或临时数据存储文件
- 全文比对同步
对前后两个时间点取业务数据表的全量进行数据比对，比对出来有差异的部分就是数据增量的部分。此法可以用于一段时间后进行数据的强制同步，但由于消耗资源较大，因此一般建议用于业务空闲期使用。
优点：对源系统没有任何影响。
缺点：面对海量数据（千万级、万万级）进行比对时有一定的性能问题。
这些同步方式除了全量同步，其他几种都需要业务表有主键。这些同步的方式各有优缺点，在实际使用中应根据企业系统自身实际情况来采取适合的交换方法。网上有许多人推荐使用CDC的方式，CDC这种架构下数据写入主存储后会由主存储再向辅存储进行同步，对应用层是最友好的，只需要与主存储打交道。主存储到辅存储的数据同步，则可以再利用异步队列复制技术来做。不过这种方案对主存储的能力有很高的要求，必须要求主存储能支持CDC技术。另外这种方式在一些数据库中需要有DBA的权限配合才能够完成，所以在进行CDC同步的时候首先就需要考虑数据库的环境是否有条件能够完成CDC的配置。
触发器、时间戳、全文比对以及方式都能够支持断点续传，所使用的方式各不相同。
触发器数据同步的过程是先将增量数据同步到临时表中，这个临时表会增加两个字段，一个是所做操作的标识(标识有：insert、update和delete),另一个是自增的列。在进行同步时是查询这张临时表来进行的，再查临时表时会使用自增的列进行排序进行查询，检查寻到的增量数据通过组件到目标库中根据操作标识进行相应的操作，操作完成后如果成功执行则会去临时表把已经同步的增量数据按照自增列的值进行删除。如果这个过程中在向目标同步数据时出现异常，则这张临时表中的数据不会被删除掉。而我们在进行作业触发时一般使用的都是按照频度、计划去定期执行，当前这次同步失败后，在下一次计划触发执行时由于上一次所执行的作业最后并没有将临时表中的作业删除，在这次作业执行时上一次没有同步的数据还在。所以这次执行时就会从断点位置开始再次进行同步。
时间戳数据同步的过程是首先到目标表去根据时间戳使用数据库中的获取最大值的函数(一般数据库使用MAX函数)来查找时间戳里的最大值，然后使用这个最大值去源表找大于这个值的数据(同时需要根据这个时间戳进行排序)，这些查找到的数据就是我们需要同步的增量数据，时间戳这种方式不能区分这些数据是插入还是更新的操作。那么接下来使用的是数据平台提供的插入更新组件，这个组件会在执行操作前先根据主键到数据库中查寻一下数据如果有则执行更新，如果没有则执行插入。这样进行数据同步，如果在执行过程中出现异常那么目标数据库就没有同步这些增量数据。同样我们在进行作业触发时使用的都是按照频度、计划去定期执行，当前这次同步失败后，在下一次计划触发执行时由于上一次所执行的作业没有进入目标表，在这次执行作业时从目标表查找的最大值就没有变化。所以这次执行时就会从断点位置开始再次进行同步。
全文比对的过程是先从源和目标中将数据按照排序字段先进行排序然后抽取出来，经过比对组件计算得到变化的状态(insert、update和delete),最后根据得到的变化状态将数据同步到目标表。如果在这一过程中发生异常，那么这次同步的数据就没有进入目标表，在下一次计划触发执行时由于上一次所执行的作业没有进入目标表，在这次执行作业时又会重新进行比对得到断点位置又会再次进行数据同步。
CDC数据同步的执行过程是根据日志记录的偏移来从日志中找出需要同步的增量数据，然后到目标表根据操作标识进行数据同步完成后修改日志记录的偏移，那么作业在执行过程中出现异常时，这个日志的偏移量没有改变。在进行性下一次数据交换时还会从这个偏移量的位置进行，从而实现断点续传。
非结构化数据交换
以前的非结构化的数据交换，常常使用网盘或者FTP传输文件时，尤其是大文件，容易出现中断，严重影响工作效率和业务。
数据交换平台中采用了数字签名、时间戳、报文加密的方式对传输的消息进行完整性验证，防止消息在传输过程中被篡改。通过数据交换平台可以验证消息确实来自于其真正的发送者而非假冒；确保消息的内容没有被修改；防止以插入、删除、调换或修改等方式篡改消息。
交换平台中的文件传输具有以下特点：
- 数据包裹传输方式 防止数据被篡改
采用全新数字包裹数据传输方式，有效防止数据被恶意篡改。
- 加密传输和存储 保障数据安全性
提供文件安全交换加密传输和存储。采用私有文件传输协议和SSL安全协议访问。提供文件效期控制，支持文件自动清除销毁。
- 支持断点续传错误重传 确保数据高效流转
采用超高速传输协议，支持超大文件和海量文件传输。支持断点续传，错误重传，文件秒传和文件校验。
下面列举了平台中文件传输中所使用到的技术：
- 文件校验
平台采用单向散列算法用于文件的完整性验证，在文件传输之前会使用单向散列算法生成文件唯一摘要信息，在文件传输后会将收到的文件再次使用单向散列算法生成摘要信息和之前的摘要信息进行比较。
- 断点续传：
断点续传是在下载或上传时，将下载或上传任务（一个文件或一个压缩包）人为的划分为几个部分，每一个部分采用一个线程进行上传或下载，如果碰到网络故障，可以从已经上传或下载的部分开始继续上传下载未完成的部分，而没有必要从头开始上传下载。用户可以节省时间，提高速度。
- 压缩传输：
在文件传输时先将文件进行压缩，然后传送压缩文件到目标，最后进行解压和清除工作，压缩传输能有效减小文件体积节省传输带宽。
- 文件切片：
切片传输是将文件进行切片，每一片形成一个传输线程进行传输。采用并行的数据流传输管道，有效地将传输速率最大化。
4.3.2 实时数据交换
打破信息壁垒和信息孤岛，实现统一高效、互联互通、安全可靠的数据资源体系，实时数据交换是推动信息跨部门跨层级共享共用数据中心的重要环节。实时数据交换适用于对于数据时效要求快速、高频度、少量数据传输的场景。实时数据交换通过将数据中心库中的数据快速的发布出来提供给外部系统共享调用，同时能够监控外部调用数据的情况提升数据的价值。
在新的Web服务共享下数据交换平能够自助的、一键式将数据中心库(包括常见的关系型数据库mysql、oracle、sqlserver等，或Hbase、Hive、MongoDB)中的数据通过标准的Web服务发布出来。用户只需要配置发布数据中表和表之间的关系以及发布的字段就能够实现单表、多表或数据实体的发布。发布出的服务带有对输入输出以及调用url的详细描述信息，消费方能够很方便的对这些信息进行查看和订阅。
服务方能够对订阅的信息进行审批，审批通过后消费方才能根据审批信息，配置服务调用参数调用服务。服务方通过对订阅信息的管理和监控能更好的掌握和发掘数据的价值。
4.3.3 数据驱动的交换
变化数据捕获简称CDC，这种方式主要应用于增量数据同步并且实时性要求较高的场景。这种架构下数据写入主存储后会由主存储再向辅存储进行同步，对应用层是最友好的，只需要与主存储打交道。主存储到辅存储的数据同步，则可以再利用异步队列复制技术来做。不过这种方案对主存储的能力有很高的要求，必须要求主存储能支持CDC技术。而目前每种数据库实现CDC的方式和方法各不相同，于是就需要根据数据库类型定制化的进行CDC的开发。
CDC的数据同步具有低影响、低延迟、高性能等特点。这里以mysql为例采用Canal来说明实现CDC数据同步。canal利用了mysql的slave协议将自己伪装为mysql的一个子服务器，向mysql master发送dump协议mysql master收到dump请求，就会将记录的日志信息给slave(也就是canal)，canal解析日志信息获取需要同步的数据,数据交换平台通过Canal组件监听Canal服务获取到变化数据交给之后的增量数据输出组件根据CDC所捕获的操作类型(类型有：insert,update,delete)对目标数据库进行相同的操作来完成数据同步。
这里Canal通过对日志数据的监听触发。
4.3.4 指定周期的交换
数据交换平台作为一个批量数据处理系统，每天都会进行大量的数据处理作业，这些作业之间可能存在复杂的时序关联，因此必须有一个具备一定自动化程度的调度层，来实现作业有序、高效的执行。
作业在运行前都需要在统一调度系统中注册，注册成功后再由调度系统自身的调度管理根据配置的任务计划决定作业的执行次序进行资源调配。
调度包含以下内容：
- 触发方式：在调度管理中定期根据日历、频度进行作业触发。
- 作业次序：触发后作业会根据之前设定好的数据性进行作业排序调整作业次序。
- 任务计划：任务计划会按照配置好的任务执行周期来进行任务调度。
- 资源调配：在执行调度的时候会根据注册的作业服务器的状况进行资源分配执行传输任务。
4.3.5 事件驱动的交换
数据交换平台在与用户的系统进行集成式往往会遇到客户系统需要直接运行交换作业的情况，为此数据交换平台提供了一套基于事件触发的作业运行机制。能够通过文件监听或者http调用来与用户的系统进行集成。
交换服务能够通过监听文件目录或端口，当目录中有符合作业触发规范的文件时或接口被调用时，对文件中描述的计划按照之前设定好的数据性进行作业排序调整作业次序触发执行，并删除监听到的文件。整个触发执行过程都会进入日志信进行留痕。
4.4 新方式迎接数据挑战
4.4.1 批量数据交换
在进行数据交换时往往遇到的情况是要将整个库中所有的表进行迁移或同步，这些迁移或同步的大体逻辑往往相同，但库中的表非常多，传统的数据交换中是一张源表对一张目标表进行作业任务开发，造成开发人员巨大的工作量，表中的字段和和类型在进行配置时容易出错，效率低下。
批量数据交换采用作业模板作为业务规格定义，结合资源目录能够通过简单地可视化操作批量数据源，对数据源进行批量的数据交换处理。批量数据交换有以下特性：
- 基于作业模板实现业务能力定义
- 可批量进行整库的数据交换
- 自动控制数据交换中的各种数据转换
- 自动进行数据分批次交换传输
- 对交换的数据可配置数据脱敏
通过批量数据交换加强了大数据量的交换能力。配置、部署、运维简单，能够有效提升开发人员的开发效率和质量。
4.4.2 跨区域数据交换
跨域的数据交换在实际应用中，每个单位或部门从安全的角度考虑，都会设置前置机和防火墙，以及根据需求双方商定通讯方式编制相应的交换策略。因此，实施难度会加大，实施进度也会拉长。
以前遇到跨区域数据同步往往是先将数据转换为文件，然后通过p2p文件传输将文件发送到目标节点，最后目标节点拿到文件再将文件通过转换导入到目标数据源中。
新的模式对下面几个因素都要考虑周全。
- 简单。交互的设计要简单，这对调用双方都有好处。
- 安全性。如何保证数据在交互过程中出现各种异常的情况下，数据不出错、不丢失。
- 性能。在选择的时候，要考虑数据量的大小，以决定一种合适的交换方式（比如：一次调用请求的数据量，请求调用的频率）。
在新的交换模式下通过对节点的管理和注册，结合了文件传输高效、安全、稳定的特性，在进行跨区域数据同步时只需要配置源和目标的数据库信息按照既定的业务逻辑就能够完成跨节点的数据交换，文件传输的过程自动交由数据交换平台完成，减轻了跨域数据同步的复杂度。
4.4.3 应对大数据的挑战
传统 ETL 主要以 SQL 为主要技术手段，把数据经抽取、清洗转换之后加载到数据仓库。但是在如今移动互联网大力发展的场景下，产生大量碎片化和不规则的数据。这中间的数据导入和 SQL ETL 的提取的过程，大量消耗 IO 性能和计算资源，在很多场景下已经是数据处理的瓶颈所在。
Spark通过在数据处理过程中成本更低的洗牌（Shuffle）方式，将MapReduce提升到一个更高的层次。利用内存数据存储和接近实时的处理能力，Spark比其他的大数据处理技术的性能要快很多倍。
新的数据交换中我们开发了 FlumeOnYarn 的架构，基于 XML 描述的可编程的函数 ETL 转换方法。这种方式充分利用了Spark对大数据的处理能力，通过XML文件描述源和目标以及中间的转换过程就能够控制Spark对数据进行ETL过程处理，在应对Hadoop、Hive以及Hbase等任务处理时能够充分体现出大数据处理的优势。
4.5 监控与管理
4.5.1 监控保证运行的稳定
交换平台的监控需要获取交换服务器的CPU、内存以及磁盘，在作业运行时首先根据负载算法将收集到的CPU、内存和磁盘信息进行负载运算，判断那台交换服务器的负载较低，将作业分发到负载较低的交换服务器上运行。
负载均衡解决了单台作业服务器在进行多作业并发时数据ETL过程压力过大的一种多节点负载方案。通过负载均衡将多个作业服务器节点组合，将作业通过负载算法分摊到这些节点上进行ETL过程。使这些作业服务器能以最好的状态对外提供服务，这样系统吞吐量最大，性能更高，对于用户而言处理数据的时间也更小。而且，负载均衡增强了系统的可靠性，最大化降低了单个节点过载、甚至宕机的概率。
4.5.2 对各个运行环节的监控
在数据交换过程中，监控管理系统负责监控作业的运行和调度情况，统计交换的过程和数据，形成图形化的报表进行统计的数据展现。能够清晰地体现数据交换过程的各种状态和数据量。
数据交换平台提供了总揽全局的总体监控和明细型的计划监控以及事件监控；可视化的多维度作业运行监控以及完善的资源监控功能，对作业以及和作业相关的节点进行数据监控和统计。可统计作业交换过程中的调度日志、作业执行日志、历史日志、交换的数据量以及统计数据交换的成功失败次数，可以保证在第一时间发现系统存在的问题，并且及时排除，保证系统的正常运行。
5.总结
随着数据交换在企业中越来越受到重视，企业不仅仅局限于只对数据进行简单的交换，更有许多企业通过数据交换打造出了自己的数据中台和数据共享平台，通过对数据的加工、分析和共享提升了数据的价值。创建了在各个业务系统之间的数据高速公路使原先的数据孤岛，变成数据仓库、数据集市有效的对数据进行管理和应用
关于作者：光芒，普元项目经理，十多年的IT从业经验，一直专注于企业数据交换和数据管理的工作。曾主持参与了Primeton DI和Primeton ESB的产品研发工作，致力于自服务的数据共享和数据交换研究，在数据治理领域不断探索和研发。
