目录

一、数据汇聚

1.1 概述

1.2 汇聚数据类型

1.2.1 结构化数据

1.2.2 半结构化数据

1.2.3 非结构化数据

1.3 汇聚数据模式

1.3.1 概述

1.3.2 离线

1.3.3 实时

1.4 汇聚数据方法

1.4.1 概述

1.4.2 ETL

1.4.3 ELT

1.5 汇聚数据工具

1.5.1 概述

1.5.2 Flink CDC

1.5.3 Canal

1.5.4 Sqoop

1.5.5 DataX

1.6 数据汇聚产品

1.6.2 产品建设内容分析

1.6.2.1 数据源

1.6.2.2 抽取与加载程序

1.6.2.3 同步模式

1.6.2.4 同步范围

1.6.2.5 其他产品特性

1.6.2.5.1 前置稽核

1.6.2.5.2 数据转换

1.6.2.5.3 传输加密

1.6.2.5.4 流量控制

1.6.3 总结

二、数据交换

---

一、数据汇聚

1.1 概述

数据汇聚不同于数据采集，数据采集有一定的数据生产的性质，其能力是将终端的对象业务过程信息用特定的方法记录后，通过中间系统的流转写入目标存储系统中。而数据汇聚则是通过一定的手段将已存在的数据从一个数据源搬运到另一个数据源的数据同步过程，也常被称为“数据集成”。企业可以根据汇聚数据类型、汇聚数据模式等维度筛选适合自身的数据汇聚工具。

1.2 汇聚数据类型

1.2.1 结构化数据

规则、完整、能够通过二维逻辑表现的数据，严格遵循数据格式与长度规范，常见的有数据库表、Excel工作表等二维表。

1.2.2 半结构化数据

数据规则、完整，同样严格遵循数据格式与长度规范，但无法通过二维逻辑来表现，常见的有用JSON、XML等形式表达的复杂结构。

1.2.3 非结构化数据

数据结构不规则或不完整，不方便用二维逻辑来表现，需要经过复杂的逻辑处理才能提取其中的信息内容，如办公文档、图片、图像和音视频等。

1.3 汇聚数据模式

1.3.1 概述

应用哪种模式进行数据汇聚，主要依据业务应用的需要。汇聚数据模式主要分为以下两种。

1.3.2 离线

主要用于大批量数据的周期性迁移。这种模式对时效性的要求不高，一般采用分布式批量数据同步的方式通过连接读取数据。读取数据有全量、增量两种方式，将数据经过统一处理后写入目标存储系统。

1.3.3 实时

主要面向低时延的数据应用场景，一般通过增量日志或通知消息的方式实现，如通过读取数据库的操作日志(redo log、binlog)来实现相应的实时数据处理。业界常见的Flink CDC、Canal、MaxWell、StreamSets、NiFi等框架和组件都有较多的实际应用。

1.4 汇聚数据方法

1.4.1 概述

基于不同数据汇聚需求、硬件成本及网络带宽要求，可以选择不同的汇聚数据方法。这里的汇集方法主要有ETL、ELT两种。

1.4.2 ETL

Extract-Transform-Load的缩写，指抽取—转换—存储这一过程，即在数据抽取过程中进行数据的加工转换，然后加载至存储系统中。ETL模式在清洗过程中只抽取有价值的信息进行存储，而是否有价值是基于当前对数据的认知来判断的。由于数据价值会随着我们对数据的认知以及数据智能相关技术的发展而不断被挖掘，因此ETL模式很容易出现一些有价值的数据被清洗掉，导致当某一天需要用这些数据时又需要重新处理，甚至数据丢失无法找回。相比存储的成本，重新处理数据或者数据丢失的代价可能会更大。

1.4.3 ELT

与ETL的缩写内容一致，只是顺序变为抽取—存储—转换。这种方法更适合大规模数据场景，它将数据抽取后直接加载到存储系统中，再通过大数据和人工智能相关技术对数据进行清洗与处理。在数据存储成本越来越低廉、数据量越来越庞大的今天，ELT是更好的选择。

1.5 汇聚数据工具

1.5.1 概述

在数据能力建设过程中，很多企业结合自身的场景和最佳实践开源了一些优秀的汇聚工具，如Flink CDC、Canal、Sqoop、DataX等，这些工具的适用场景不同，也各有优缺点。

1.5.2 Flink CDC

Flink CDC于2020年发布，使用CDC（变化数据捕捉）技术，通过源数据库日志更新的订阅及消费捕获源数据库数据的变化，并将数据同步到目的数据库，而且在同步过程中可以对数据进行一定的处理。

受惠于丰富的生态以及良好的场景兼容性，Flink CDC已经成为主流数据同步工具。由于对有界数据流和无界数据流都有完善的兼容性，因此它可以同时应用在离线、实时以及混合的数据同步场景中，令从业人员的学习成本、部署维护成本大幅降低。

Flink CDC的机制决定了它无法支持非结构化数据的同步，因此使用数据湖技术的企业还需选择非结构化数据同步工具。

1.5.3 Canal

Canal Server模拟MySQL Slave的交互协议，将自己伪装为MySQLSlave向Master发送dump协议，Master收到请求后开始推送binlog，Canal解析字节流产出解析后的增量数据。

Canal的主要优点是流程架构非常清晰，部署和配置等相对简单，同时可以额外做一些配置管理、开发改造的工作。它的主要缺点是Server中的Instance和Client之间是一对一消费的，不太适用于多消费和数据分发的场景。

1.5.4 Sqoop

Sqoop是目前市面上相对通用的一种解决方案，是在结构化数据和HDFS之间进行批量数据迁移的工具。其整体框架以Hadoop为核心，底层使用MapReduce程序实现，MapReduce天生的特性保证了并行化和高容错率，任务运行在Hadoop集群上，减少了服务器资源的使用情况。

其主要优势是，在特定场景下，数据交换过程会有很大的性能提升。主要缺点是，处理过程定制程度较高，目前主要通过在命令行中配置参数来调整数据同步操作行为，在用户的一些自定义逻辑和数据同步链路监控方面比较薄弱。除此之外，任务运行完全依赖于MapReduce，功能扩展性方面受到比较明显的约束和限制。

1.5.5 DataX

DataX是阿里巴巴开源的一套插件式离线数据同步工具，以实现各种异构数据源之间的高效数据同步为目标而设计，提供数据同步作业全链路的流量监控，将作业本身的状态、数据流量、数据速度、执行进度等信息进行展示，提供脏数据探测功能，支持在传输过程中对传输报错（如类型转换错误）进行策略化处理。由于它是基于进程内读写直连的方式，因此在高并发数据同步场景下它对机器内存要求比较高。

与Flink CDC相同，DataX也不支持非结构化数据本身的同步，但它目前支持非结构化数据源。使用非结构化数据源时，在同步路径中需要存储一张逻辑意义上的二维表（如CSV格式的文本信息）供DataX读取，其本质还是将表格内的结构化数据同步到目的端。

1.6 数据汇聚产品

1.6.1 背景

从上文的介绍中可以了解到，各式各样的工具都无法独立满足企业复杂的数据汇聚场景。从数据类型来看，有结构化数据和非结构化数据；从作业实效性来看，有离线数据同步和实时数据同步。另外，数据汇聚是后续数据处理、加工作业的起点，因此，相应的同步、汇聚任务调度及状态要能够有效地与上下游形成依赖，借助统一调度的能力构建数据作业流。

数据汇聚产品首先要考虑的是屏蔽底层工具的复杂性，以可视化配置的方式提供给企业用户；其次需要考虑，为了解决数据孤岛问题，应满足异构存储、异构数据类型的同步需求；最后，还要考虑不同时效要求下的数据互通。因此，数据汇聚产品需要屏蔽系统底层协议、传输安全、特性组件等信息，让开发人员在数据接入过程中无须关注数据格式转换、数据路由、数据丢失等，而只需要关注与业务本身相关的数据同步、汇聚部分。

在构建数据同步、汇聚链路的实践过程中，基于异构数据源、异构厂商集群、数据应用时效性和相关技术栈等因素考虑，需要采取不同的同步策略：离线数据同步和实时数据同步。但是在产品形态上，两种同步服务可以采用相同的可视化同步配置策略，以降低用户操作成本。

1.6.2 产品建设内容分析

1.6.2.1 数据源

数据汇聚是将数据从一个存储点搬运到另一个存储点的动作，在搬运之前，需要让系统知晓数据原来在哪，搬运目的地在哪，以及如何连接，这样才能顺利进行数据同步与汇聚。这就需要对数据库连接方式进行配置、记录，即数据源管理。

数据源可以是已有系统存储业务数据的地方，作为数据中台的数据来源，也可以是数据应用场景，为应用场景提供结果数据存储的地方。

根据业务系统及数据应用场景的不同，数据源也有不同的选择。例如，广告场景对时效性要求很高，相应地，对数据源读性能的要求就会很高，有些场景对于大批量数据的多维分析有需求，因此数据源需要具备对大批量数据进行多维分析的能力。针对这些场景，涉及的数据源会有很多种，大致可以分成以下几类。

• ❑关系型数据库：如Oracle、MySQL、SQL Server、PostgreSQL、DB2、King-Base、达梦、ClickHouse、TiDB等。
• ❑NoSQL：如Redis、MongoDB、Elasticsearch、OTS、Neo4J等。
• ❑MPP型数据库：如Greenplum、AnalyticDB for PostgreSQL、GaussDB、GBase等。
• ❑网络及MQ：如Kafka、Pulsar等。
• ❑文件系统：如HDFS、FTP、OSS等。
• ❑大数据相关：如Hive、Impala、Presto、Kudu、MaxCompute、LibrA、ELK等。

1.6.2.2 抽取与加载程序

数据汇聚、同步需要从源头数据源读取数据，并写入目标数据源。在实现上，抽象为从源头数据源读取数据的读取插件，以及向目标端写入数据的写入插件，理论上可以支持任意类型数据源的数据同步工作。

结构化数据和非结构化数据都可以通过扩展插件的方式进行同步。对于结构化数据，主要场景是将原始数据库中的数据复制到目标表，在源头数据端通常采用数据查询或者捕捉日志变化的方式获取数据，根据不同的需求设计开发适配插件。

非结构化数据则有更多汇聚同步方法，常规的场景主要是以文件或数据块的方式进行同步，因此只需要适配源或目标存储系统的相应插件及数据处理的机制。例如文件传输，将数据块保存为特定格式的文件，即可满足相应的需求。一些非结构化数据由于规模比较大，并且全部搬运的意义不大（比如某个区域的监控录像），那么通常在传输过程中直接对视频流内容进行识别，并提取关键信息，最后写入目标端结构化存储系统中以降低存储成本。这类场景对读取和写入插件的适配要求没有变化，但在同步过程中增加了计算环节，需要数据处理模块发挥作用。主要有一下数据处理模块：

• ❑读取插件：数据采集模块，负责采集数据源的数据，将数据发送给数据同步核心模块。
• ❑写入插件：数据写入模块，不断从数据同步核心模块取数据，并将数据写入目标端。
• ❑数据同步核心模块：用于连接读取插件和写入插件，作为两者的数据传输通道，并处理缓冲、流控、并发、数据转换等核心技术问题。

1.6.2.3 同步模式

离线数据同步与实时数据同步是数据汇聚、同步的两种同步模式。

针对数据时效要求低、吞吐量大的场景，主要采用离线模式。在过去网络带宽紧张、业务数据库性能瓶颈很低时，主要使用该模式。当时，大部分企业将数据同步任务放在夜间执行，以降低对业务的影响，并在完成同步后处理数据、加工业务指标、生成报表，以供业务人员次日查阅。这种方式需要在任务执行前进行开发、测试、验证和发布，并由系统代理在次日启动程序进行同步。

而对于时效要求高、需要频繁实时获取最新数据的业务场景，就需要采用实时模式。实时同步支持将关系型数据库、消息队列中间件等多种数据源作为数据源端，通过读取数据库日志或者订阅消费的方式持续读取数据，将新增数据或者变更数据写入目标存储系统。实时同步可以在任务发布后立即开始同步，并且能够在网络抖动等造成同步中断后断点续传。

随着硬件性能的提升以及软件方案的成熟，流（实时）与批（离线）的界限越来越模糊，流批逐渐一体化。在过去，相同的数据同步内容需要单独开发任务，流批一体化后只需要开发一次同步任务，在执行时再根据资源、业务需求、数据存储要求自动或手动切换同步模式就能响应业务要求，从而大幅降低研发和维护成本。

1.6.2.4 同步范围

数据是具备生命周期属性的要素，大部分数据的价值会伴随时间的推移而减弱，但不会完全消失。企业在数据汇聚时，要充分考虑目标数据对当下业务的重要程度、存储与计算成本、过去业务变化的价值影响等因素，选择汇聚全部数据（全量同步）还是只汇聚最近产生的数据（增量同步）。

• ❑全量同步：全量数据同步分为表全量同步和库全量同步（整库同步）两种方式。表全量同步每次读取表中全量数据并写入；库全量同步是把库中所有表进行数据同步，要求源端和目标端的表名称、结构相同，允许目标表不存在，不存在时自动创建目标表。
• ❑增量同步：增量同步分为新增、覆盖和更新三种策略。新增策略主要通过在目标端创建新分区或者直接追加写数据实现。覆盖和更新策略在同步配置时选择唯一键，根据唯一键对比同步中的数据和目标端数据，结合增量策略来判断数据是应覆盖还是更新。

数据汇聚产品中，既可以单独进行全量数据同步和增量数据同步，也可以将二者结合使用，先进行全量同步，然后自动进行增量同步，从而大幅降低技术人员的操作成本，无须重复设置。

1.6.2.5 其他产品特性

数据汇聚与同步除了对数据传输有要求，对传输数据内容的规范性和安全性及传输过程的稳定性都有一定要求。

1.6.2.5.1 前置稽核

在开始源端数据同步前，可以进行数据质量规则校验，根据配置规则的阻塞、告警等策略控制数据同步是否运行。

1.6.2.5.2 数据转换

数据转换是指将各类非标准数据转换成标准数据格式，并且将转换后的数据推送到大数据平台指定的位置或库表。在数据同步、传输过程中，存在用户对于数据传输进行定制化的场景，包括字段截取、替换、编码转换等操作，可以借助ETL的T（Transform，转换）过程实现。在配置数据同步作业的字段映射关系时，可以对每个字段定义转换函数，例如字符串截取函数dx_substr、字符串替换函数dx_replace、字符串过滤函数dx_filter，还支持用户用Groovy自定义转换逻辑。

1.6.2.5.3 传输加密

数据中台通常建设在本地环境，与外网隔离，在数据传输过程中相对安全，不容易发生数据泄露，但也存在混合云、公有云部署的模式，为了防止数据泄露，在传输过程中会采取SASL认证等机制保证数据安全。也可以采用先在源端加密再传输到目标端的方式进行解密，但对计算资源的开销较高，除非是涉密数据、隐私数据，其他类型数据使用这种方式传输的性价比并不高。

1.6.2.5.4 流量控制

数据存储、数据计算、网络资源都影响着数据传输的快慢，数据汇聚、同步任务也因业务的优先级、源系统的并发限制等需要调整资源占用比例。在产品中，可以调整内存的分配、运行的优先级别、传输速率等多项指标，以满足不同场景下的数据汇聚需求，同时充分利用硬件资源。

1.6.3 总结

数据与数据之间天然存在着显性的和隐性的关系，大数据的极致魅力就在于通过对这些关系的识别和挖掘，创造前所未有的应用场景，带来意想不到的巨大价值。而要实现这一切，首先需要将数据进行物理层面的汇聚，让有价值的数据自动、快速地整合到统一的存储空间，为后面的数据开发、机器学习、数据分析打好坚实的基础。

数据汇聚是数据中台建设的第一个环节，其主要目的是打破企业数据的物理孤岛，形成统一的数据中心，为后续数据资产的价值挖掘提供原始材料。企业的每一个业务端都是一个数据触点，会产生大量的数据，这些数据的生产和采集过程需要符合数据安全、隐私保护的相关要求。同时，异构的数据源所采用的汇聚方法也有一定的差异，这里介绍了常见的数据汇聚的方法和工具，以及企业在使用这些方法和工具的过程中，如何将它们包装成一个简单易用的工具，以便于快速满足数据汇聚的需求。

二、数据交换

在数字化转型过程中，企业会因为自身数据不足无法快速开展业务，而希望从企业外部获取数据或数据能力以增强企业数据的完整性和丰富度，此时就出现了数据在组织之间的供需关系。通常使用数据交换来满足数据供需两端的各类场景诉求。

对于数据需求方，数据交换可以算作一种数据共享与获取的方法，需求方只需要与供给方约定好数据格式、传输协议、计算方式、结算逻辑、交换时间等就可以获取到数据，对于数据源存储的位置、形态、结构都不需要关注，这也是它在数据传输时与数据汇聚最大的区别。

根据业务需求与数据安全要求的不同，数据交换的场景五花八门。例如集团与子公司之间数据的定时报送，通常采用未加密数据的交换传输，更多在传输协议层面进行加密，因为在内网环境交换，数据泄露风险较低；再如企业的业务需求是让预测模型更准确，那么不需要直接获取真实数据，只要通过联邦学习的方式与数据供应方联合计算获取模型即可，虽然没有获取数据，但达到了获取数据的目的。

数据交换是数据中台的能力补充，通过数据交换，数据中台的数据以及数据能力能够逐步提升，也能够基于数据交换构建新的业态（数据交易）。当企业与企业之间的数据中台通过数据交换连接时，就实现了更广泛意义上的数据中台。

好了，本次内容就分享到这，欢迎大家关注《数据中台》专栏，后续会继续输出相关内容文章。如果有帮助到大家，欢迎大家点赞+关注+收藏，有疑问也欢迎大家评论留言！