【第二部分规划篇】第6章数据集成

1.1. 概述与关键概念

1.1.1. 数据集成的定义
根据DAMA国际在《DAMA数据管理知识体系指南（原书第2版修订版）》中的定义，数据集成是指数据存储、应用程序和组织内部及之间的数据流动和整合。数据集成是把不同来源、格式、特点、性质的数据以物理或虚拟的方式整合到数据中心，从而为组织提供全面的数据应用。

1.1.2. 数据集成管理的目标
数据集成的主要目的是对数据移动进行有效管理，企业级的数据集成设计远比分散的或点对点的解决方案效率更高、成本更低。对于需要跨组织共享的数据，也可以极大地简化管理这些数据的复杂性。如果采用多种技术来共享和应用数据，会导致支撑成本增加。基于标准工具进行集中化的数据集成，能够避免重复投入与资源浪费，减少冗余处理，提升数据流转效率，加速业务响应，降低维护与变更成本。同时，通过统一的数据转换和清洗流程，确保数据基本符合规范，为分析与决策奠定坚实基础。随着组织数据量增长与来源多样化，数据集成已成为数据管理的核心环节。
具体而言，数据集成管理的目标主要包括以下几个方面：
(1) 确保能够及时以数据消费者（如业务分析师或应用系统）所需的格式和结构提供数据，降低数据使用门槛，提升数据易用性。
(2) 将分散在不同源系统中的数据合并到统一的数据中心或数据仓库中，打破数据孤岛，形成一致、全面的数据视图。
(3) 通过高质量的数据集成支撑关键业务活动，包括深度数据分析、主数据管理、BI应用以及企业运营效率的全面提升，从而赋能业务创新与数字化转型。

1.1.3. 关键概念
1.1.3.1. 企业应用集成
企业应用集成（EAI）指将企业内部各自独立、异构的应用程序、数据和业务流程连接和整合起来，使它们能够协同工作，形成一个协调统一的企业级系统的过程、方法和技术。在EAI模型中，软件模块之间仅通过定义良好的API调用进行交互。即数据存储只能通过自己的软件模块更新，其他软件不能直接访问应用程序中的数据，只能通过定义好的API访问。因此，其核心价值在于对未来业务的集成、维护和修改，实现时间和成本的节约。
企业应用集成主要分为4个层面，包括用户交互集成、应用集成、流程集成以及数据集成：
(1) 用户交互集成，将企业零散的系统界面集中到一个统一的界面中，通常通过统一用户管理、统一身份认证、单点登录、界面集成等技术实现。
(2) 应用集成，多应用系统间的交互，实现系统功能的复用和组合，通常通过API网关、消息中间件等技术实现。
(3) 流程集成，实现跨系统业务流程的整合，实现业务流闭环，通常通过业务流程管理（BPM）等技术实现。
(4) 数据集成，将互相关联的异构数据源集成到一起，保证多个系统中的数据保持一致，通常通过数据复制、数据聚合、接口集成等方式实现。

1.1.3.2. 数据集成交互模型
交互模型指系统间数据传输与协作的规则和方式，主要包括点到点、中心辐射型、发布与订阅几种类型。
(1) 点到点模型
点到点模型是最直接、简单的集成方式。它通过在需要通信的两个应用系统之间建立独立的、专用的通道来实现数据传递，如下图所示。

图 1 点到点模型示意图

点到点模型适用于系统数量极少（如只有2～3个）、集成需求非常简单且变化不频繁的环境，也常用于临时性的、无需复用集成逻辑的特定需求。但该模型的根本弱点在于其难以扩展和维护，一旦系统数量增长，错综复杂的连接会形成“蜘蛛网”架构，导致任何单个系统的变更都可能产生难以预估的连锁反应，使得整体集成架构变得脆弱，开发维护成本也会急剧上升。
(2) 中心辐射型模型
中心辐射型模型通过引入一个中心节点来解耦所有系统之间的直接联系。即它将共享数据（物理或虚拟）整合到应用程序可以使用的一个中央数据中心（如数据仓库）。所有想交换数据的系统都是通过一个中央公共数据控制系统进行交换的，而不是直接与其他系统（点对点）进行交换。

图 2 中央辐射型模型示意图

中心辐射型模型适用于业务系统数量较多（如超过3个），需要集成多种异构系统的中型或大型企业，极大地提升了集成的可管理性和可复用性。当然，这种集中化也存在一定的弊端，中心节点可能成为整个架构的性能瓶颈或存在时延问题，其本身的复杂性也要求较高的技术投入和专业运维能力。
(3) 发布与订阅模型
发布和订阅模型涉及推送（发布）数据的系统和其他接受（订阅）数据的系统。在数据服务的目录中列出推送数据的系统，希望使用数据的系统订阅这些服务。在发布数据时，数据会自动发送给订阅用户。

图 3 发布与订阅模型示意图

发布与订阅模型实现了较高的解耦性和可扩展性，允许发布者和订阅者独立演变，能轻松地将事件数据广播给大量消费者，非常适合异步、实时的数据分发场景，如实时数据看板、事件通知，以及将同一数据事件分发给多个下游系统等。然而，由于是异步通信，其代价是只能提供最终一致性，难以保证数据的强一致和即时同步，故障排查和消息追溯的复杂性也显著增加。

1.1.3.3. 抽取、转换和加载（ETL）
数据集成的核心是数据的抽取（Extract）、转换（Transform）和加载（Load）。根据数据集成的需求，ETL可以作为定期调度事件执行（批处理），也可以在新数据或旧数据更新后执行（实时或事件驱动）。

图 4 发布与订阅模型示意图

(1) 抽取过程：选择所需的数据并从其数据源中提取。
(2) 转换过程：使选定的数据与目标数据库的结构兼容。一般情况下，是在专门的ETL引擎中进行格式转换、结构变化、语义转换、去重等操作。
(3) 加载过程：在目标系统的物理存储中进行持久化或直接呈现转换结果。

1.1.4. 数据集成与其他模块的关系

1.1.4.1. 数据集成与数据模型
数据模型管理为数据集成工作制定目标结构。数据模型定义了数据在数据仓库/数据湖中的理想状态——表结构、字段、数据类型、主外键关系及业务含义。数据集成工作则必须遵循并实现这种目标结构，它通过转换和清洗，将来源各异、格式不一的原始数据“重塑”为符合模型规范的数据资源。
1.1.4.2. 数据集成与元数据
元数据是数据集成的导航图。元数据为数据集成提供了至关重要的上下文信息，包括数据源的物理位置、结构、语义、血缘关系、转换规则等。同时，集成过程中捕获的血缘元数据能够清晰展现数据的来源和变换过程，对于数据治理、合规审计和影响分析具有不可替代的价值。
1.1.4.3. 数据集成与数据安全
数据安全是数据集成过程的护栏。数据集成过程是数据安全风险的高发区，因为数据在移动和变换时极易发生未授权访问、泄露或篡改。因此，数据安全管理应该嵌入到数据集成环节，通过适当的安全手段（如加密传输、访问控制、数据脱敏等）对数据进行适当保护。
1.1.4.4. 数据集成与主数据
主数据是黄金记录，数据集成则是它的提纯和分发工具。主数据（如客户、产品、供应商等核心业务实体数据）在企业范围内应该保持高度一致性、准确性和唯一性。数据集成技术是实现和维持这一目标的核心手段，实现跨系统、跨平台的主数据整合与同步。

1.2. 实施指南

1.2.1. 落地思路
数据集成实施的整体思路是“以终为始、循序渐进”，从数据源到数据仓库/数据湖逐步进行归集、清洗和融合，最终服务于业务应用。

图 5 数据集成落地思路图

(1) 明确范围
在业务调研基础上，明确数据集成需要支撑的数据管理和业务目标，确定集成的主题域（如客户、订单信息等），即解决“集成什么”的问题。
(2) 数据归集
数据归集是集成的“原材料采集”阶段。该阶段需要确定时效性模式（批量或实时）和归集方式（库表、API接口或文件），将原始数据无损地同步到数据仓库（贴源层），形成数据的原始备份。它不仅为后续所有数据加工提供原材料，也为数据追溯提供保障。
(3) 数据清洗
数据清洗是集成的“规范化处理”阶段。该阶段依据业务需求、数仓规范和数据标准，将数据仓库（贴源层）中的数据清洗、转换为干净、规范的数据，并加载到数据仓库（治理层），为后续融合与应用打下坚实、可靠的基础，降低“垃圾进，垃圾出”的风险。
(4) 数据融合
数据融合是集成的“组装与创造”阶段。该阶段基于业务主题或应用需求，将分散在不同表中的规范数据，按照设计好的数据模型，进行关联、整合和汇总，形成面向业务场景、可使用的数据，支撑起数据分析、决策支持、用户画像等具体应用，驱动业务创新与增长。
(5) 集成监控
集成监控如同集成实施的“质量守门员”，它贯穿于归集、清洗和融合全过程，通过可观测、可预警、可追溯的监控机制，实时跟踪集成服务状态，及时发现并告警异常，确保数据集成过程的稳定性与可靠性。

1.2.2. 实施策略
根据数据时效性需求选择集成模式
摒弃“一刀切”的集成方式，而是根据业务场景对数据延迟的容忍度，科学地选择集成技术。对于大多数场景，如业务系统数据汇聚到数据中心、T+1的报表分析等，采用批处理集成是性价比最高的方式。而对业务协同、实时监控、风险预警等场景，就必须采用基于API、CDC或流处理的实时集成方式。混合模式则能够在满足业务需求的同时，最优地平衡技术复杂度和实施成本。
推动主数据和关键维度数据优先集成
在开始数据集成时，最好优先识别并集成企业核心的主数据和关键维度数据。率先在这些数据域实现统一的数据模型、数据标准和分发服务，为其他所有集成流程提供准确、一致的黄金数据源。这能从源头减少后续集成过程中大量的数据清洗、匹配和冲突解决工作，起到“事半功倍”的效果，为企业的数据一致性打下坚实基础。

1.2.3. 常见挑战与解决方法
如何实现多源异构数据源的适配问题？
对于大多数数据仓库的建设来说，数据源类型多样，包括关系型数据库（如MySQL、Oracle等）、非关系型数据库（如MongoDB、Redis等）、文件系统、API接口等，其中也涵盖在信创背景下必须适配的国产数据库（如达梦、人大金仓、海量、华为高斯、TiDB等），其数据结构、存储方式和访问协议各不相同。多源异构数据的适配是一项关键挑战。因此，就要求数据采集工具具备强大的适配能力和灵活的扩展性，能够兼容各种数据源的接入需求。同时，构建标准化的数据接入规范，统一管理数据采集流程，结合元数据管理机制，便于在出现问题时快速定位原因并解决。
如何保障大规模数据集成下的性能与效率？
当集成数据量巨大或需要在有限时间内完成集成任务时，性能瓶颈会导致任务超时、延迟，甚至宕机，无法满足业务时效性要求。为解决这一问题，可采用分布式计算框架，将数据分发到多个计算节点进行处理，提高系统的处理能力和扩展性。同时，也可以根据数据的特性进行分区，将大数据集拆分为多个较小的数据集，分别进行处理和集成。当然，还需要做好异常处置的准备工作，无论是实时集成、全量集成或增量集成，在数据处理过程中出现异常时，都需要能够快速恢复数据集成流程。

1.3. 实施流程

1.3.1. 实施概述

1.3.2. 确认数据集成范围
1.3.2.1. 实施概述
表 1 步骤1 确认数据集成范围实施概述

1.3.2.2. 活动
1.3.2.2.1. 分析数据源
分析数据源主要是评估数据集成的技术可行性与影响，包括数据源的技术可获取性、数据量级是否符合集成要求，以及数据源系统的稳定性与安全性等因素。主要包括以下方面：
(1) 技术可连接性分析。评估是否能够从技术层面建立连接（如：开放数据库访问权限、提供API接口、建立网络通道），工具是否支持该数据源类型，是否存在其它技术障碍或限制。
(2) 数据可访问性分析。确认各业务系统、数据集成工具以及数据仓库所处的环境是否互相连通，是否存在网络隔离或权限限制等问题。
(3) 数据访问限制分析。确认该数据源是否存在访问时间段的限制，如业务办理时间段内不允许海量数据抽取，或存在调用频率限制等管控策略。同时评估数据源在高峰期的负载能力，避免因集成操作引发源系统性能下降。
(4) 检查当前账户权限是否足够读取所需数据，是否需要申请新的、更高级别的权限。
1.3.2.2.2. 确认数据集成范围
根据调研阶段所获得的数据资源、业务系统现状和业务需求，明确集成的数据范围。结合数据源分析情况，绘制数据归集网络拓扑图，以下为某热力公司的网络拓扑图示例。

图 6 某公司数据集成网络拓扑图示例

方式二，优先选择核心业务系统中的关键数据表。基于数据资源梳理过程获得的核心数据资源表，综合考虑业务需求、未来应用场景、系统间的关联性、数据量情况等因素，选择具有高业务价值和应用潜力的数据表进行优先集成。如下表，为某热力公司收费系统的核心数据资源表集成范围清单示例。
表 3 数据集成范围清模板及示例（方式二）

1.3.3. 数据归集
1.3.3.1. 实施概述
表 4 步骤2 数据归集的实施概述

1.3.3.2. 活动
1.3.3.2.1. 剖析数据
设计数据集成方案之前，应该先进行数据剖析，尽可能地理解数据的内容和结构。这不仅为了确定数据源中哪些数据需要被集成，也为后续设计合适的数据集成模式等活动做准备。对源数据进行剖析，需要了解其在多大程度上能满足业务需求。在分析过程中，还应尽可能分析和收集相关业务规则，并初步判断数据满足这些业务规则的程度。剖析内容主要包括：数据范围、数据格式、数据质量、更新逻辑等方面。
(1) 数据范围：分析数据的业务范围和时间范围，确保数据覆盖关键业务场景和历史周期。
(2) 数据格式：初步探查源系统数据结构（表结构、文件格式、API结构）。同时与目标结构进行比对，识别潜在的重大差异。
(3) 数据质量：通过简单的样本数据，初步评估null值、空的数量，或是否有明显异常值，以及在集成过程中可能需要进行的数据转换或清洗工作。
(4) 增量数据获取能力：这是至关重要的一步，需要确认源系统是否支持可靠地获取增量变更数据。对于数据库，是否有时间戳、自增ID，或是否支持CDC？对于文件，能否按规则生成增量文件？对于API，是否有提供增量数据查询的参数？
数据剖析是归集工作的基础，将影响后续集成模式与清洗策略的设计。传统方式依赖人工抽样与经验判断，耗时长且易遗漏深层模式。引入AI工具可大幅提升剖析效率与深度：
智能结构推断：利用自然语言处理（NLP）技术，自动解析表名、字段名、注释及样本数据，推断其业务含义与数据结构，辅助生成初步的数据字典和实体关系图。
自动质量探查：基于统计学习与异常检测算法，自动扫描数据分布、空值率、值域范围、格式一致性等，识别潜在的数据质量问题（如异常值、重复记录、违反业务规则的数据），并生成质量评估报告。
增量变更智能识别：通过模式识别与日志分析，自动判断数据源是否支持增量同步，并推荐合适的增量捕获策略（如时间戳、CDC、差异对比等）。
1.3.3.2.2. 设计数据归集模式
数据归集模式需要考虑业务需求、数据集成范围、数据剖析结果，选择合适的交互模型、时效性模式和交换方式，确定数据源与数据仓库/数据湖之间的数据流动模式、频率与延迟容忍度等。
(1) 交互模型
首先，确定满足需求的交互模型或组合——点到点、中心辐射型或发布订阅。如果组织已经有了数据中台，那么中央辐射型或发布订阅模型可能是更合适的选择。
(2) 时效性模式
时效性模式主要包括批处理和实时两种形式，需要根据业务对数据时效性的要求来选择。批处理适用于数据更新频率较低的场景，如每日汇总报表；而实时集成则适用于对数据更新要求高的场景，如在线交易业务。
需要注意的是，实时模式对于源系统的功能要求、性能要求、资源消耗要求都远高于批处理模式，因此必须评估源系统是否具备足够的能力来支撑实时数据抽取与传输。此外，还需考虑组织的网络带宽、安全机制以及运维能力是否能够匹配实时模式的长期稳定运行。
(3) 归集方式
归集方式包含库表、API接口或文件等。在选择具体的归集方式时，应结合具体需求，综合考虑性能、灵活性与维护成本。
对于结构稳定且访问高效的场景，库表直连是可靠的选择；若数据来源是外部系统或需要通过网络服务获取，则API接口更灵活易用；而对于大量数据的一次性传输或异步处理，文件交换则更便于管理和调度。
(4) 增量机制
结合数据剖析结果，设计增量数据的同步机制，如每次全量同步、增量同步等。
全量同步是每一次同步任务执行时，都从头开始读取源表的全部数据，并全部归集到目标表中。通常会先清空目标表再重新插入。这种机制适用于数据量非常小且静态、无法准确识别变更数据、业务上需要定期完整覆盖数据、初始化历史数据等场景。
增量同步是基于时间戳（或自增ID）、事务日志等捕获到变化的数据，仅将变化数据进行同步。这种机制适用于仅追加类型的数据、大数据量等场景。
“第一次全量同步 + 后续持续增量同步” 的组合是目前较为主流的机制。
同时，还应考虑数据加密、传输、权限控制等安全机制，确保数据在传输过程中的保密性与完整性。
以数据集成范围清单示例的源表为例，时效性模式和交换方式如下表所示。由于其他业务系统有实时获取收费系统中费用记录信息表（缴费状态）的需求，因此这张表应采用实时集成模式，而其他表通过批处理模式即可满足需求。
表 5 数据归集模式示例

此外，随着业务需求的变化，数据源和数据量都可能会不断增加或调整，为了确保整体数据集成的高效运行，不仅应合理规划数据缓存与计算资源的分配，还需要充分考虑数据编排的灵活性与扩展性。
1.3.3.2.3. 数据归集开发
数据归集开发的前提是数据仓库或数据湖的基础环境已建设完毕，已预先创建好数据仓库/数据湖（贴源层）的对应数据库。通常，贴源层的数据库表与数据源库表保持表结构一致。同时，配置好相应的访问权限，保证数据归集任务能够正常读取源系统数据并写入目标端。
根据技术选型，选用已确定的工具和归集模式具体实现数据归集开发。建议归集工具具备以下能力：
- 支持信创要求；
- 支持所有数据源的数据库类型，也支持API、文件等类型的数据源；
- 支持集群（根据数据量情况决定）；
- 支持可视化方式和代码脚本方式（根据使用人员的技术基础决定）；
- 支持CDC、Kafka、流批一体等技术（根据归集模式决定）。
数据归集开发完成后，通过对数据归集流程进行全面的端到端验证，确保将数据从源系统准确无误地输送至数据仓库/数据湖。可以从以下几方面来进行数据归集测试：
功能测试：执行同步任务，验证数据是否能从源端正确传输到目标端。
数据准确性测试：对同步到贴源层的数据进行抽样比对，确保数据内容无失真、无遗漏。核对记录总数、金额总和等统计值是否与源端一致。
- 增量逻辑测试：针对增量任务，专门模拟数据的新增、更新和删除（若支持），验证增量机制是否能准确捕获变更。
- 性能与稳定性测试：针对大数据量的表，测试任务运行时长是否在预期窗口内，是否会压垮源库或网络，是否会因内存溢出等原因失败
1.3.4. 数据清洗
1.3.4.1. 实施概述
表 6 步骤3 数据清洗的实施概述

1.3.4.2. 活动
1.3.4.2.1. 设计数据清洗规则
数据集成中最复杂的活动之一就是将数据由一种格式清洗为另一种格式，因为数据清洗过程需要很详细的业务需求，而抽取和装载过程几乎全都是面向技术的。建议每个组织统一维护自己的清洗规则库，适用于所有主题数据和主数据。
(1) 规则设计依据
参考数据剖析的结果，基于业务需求、数仓技术规范、主数据需求以及数据标准要求等设计数据清洗和转换规则，确保清洗后的数据符合应用场景和数据管理要求。
表 7 清洗规则设计依据

(2) 清洗类型
数据清洗和转换类型包括但不限于空值处理、格式标准化、映射、非法值与异常值处理、数据拆分与合并、数据补齐等。
表 8 清洗类型示例

数据清洗规则的设计，可以借助AI工具，基于数据剖析结果，更加高效、全面地覆盖数据异常场景，有针对性地设计数据清洗规则：
- 规则智能推荐：基于历史数据清洗经验与业务规则库，利用机器学习模型推荐适用于当前数据特征的清洗规则（如空值填充策略、格式标准化模板、代码值映射表等）。
- 异常模式自动发现：通过无监督学习（如聚类、孤立森林）自动识别数据中的隐蔽异常模式（如隐蔽的重复记录、跨表矛盾值、时序异常等），辅助设计针对性的清洗逻辑。
- 语义一致性校验：利用知识图谱与实体链接技术，自动校验数据中实体（如客户、产品）在不同系统中的语义一致性，发现并建议统一映射规则。
1.3.4.2.2. 数据清洗开发
数据清洗开发的前提是预先创建好数据仓库/数据湖（治理层）的对应数据库，并配置好相应的访问权限。根据技术选型，组织使用确定的工具和规则来清洗、转换数据，将清洗后的数据写入治理层中。通常，清洗后的治理层数据库表依然与数据源库表保持表结构基本一致。
在清洗过程中，建议设计错误处理策略，将无法通过规则清洗的“脏数据”存至指定的错误表并记录明确原因，而非简单丢弃，以确保数据可追溯性。可参考的数据处理策略如下：
- 填充默认值；
- 填充统计值（如使用均值等统计值填充）；
- 置空保留，不做处理；
- 强制按标准转换；
- 数据截断；
- 按照代码表或指定规则映射；
- 按照固定规则或采用智能识别技术拆分或合并字段；
- 通过关联字段精确匹配或采用模糊匹配技术补齐信息。
数据流编排是从开始到结束的数据流模式，包括完成转换和/或事物所需的所有中间步骤。单个集成任务开发完成后，通过数据流编排将它们组织成一个有序的、自动化的业务流程，确保集成流程能作为一个整体，可靠、自动地运行。通常使用工作流编排调度工具来定义任务之间的依赖关系、执行计划等。
而对于跨工作流的复杂依赖，可以定义高阶主控工作流，来协调多个子工作流的执行顺序与依赖关系，也可以使用具备高阶编排功能的集成工具，实现组织级的任务调度和管理。

1.3.5. 数据融合
1.3.5.1. 实施概述
表 9 步骤4 数据融合的实施概述

1.3.5.2. 活动
1.3.5.2.1. 数据建模
数据融合中所需要的数据模型包括数据持久化的模型，以及那些只是用于移动或转换数据的临时数据模型。
在构建数据模型时，应根据数据的用途和生命周期合理划分模型类型。对于需要长期存储和高频查询的数据，可采用规范化的数据仓库模型，以保证数据一致性和访问效率。同时，数据模型的设计还应注重可扩展性，以便在业务变化时能够快速调整。
下图为数据建模样例，具体实施可查看“数据模型”章节。

图 7 数据建模样例

1.3.5.2.2. 映射数据源到目标
由于数据融合后的目标数据表与源系统结构可能存在差异，需通过字段映射、逻辑转换和数据标准化实现一致化。应分析已完成的数据模型，明确每个目标字段的数据来源、数据标准以及转换映射规则，以确保数据在传输过程中的准确性和一致性。
映射规则包含以下几个方面：
- 直接映射，即指明目标字段直接来源于某个源表的某个字段，无需转换。
- 数据转换，包括数据类型转换、格式标准化、代码值映射等。通常在清洗环节已完成基础转换工作。如目标数据模型“订单信息”中的“订单日期”字段，需要截取订单表的“下单时间”字段的年月日部分，舍弃时分秒部分。
- 数据关联取值，包括跨表关联取值或多字段合并等。如目标数据模型“订单信息”中的“产品品类名称”字段，需要通过“产品ID”字段，将订单表与产品品类表关联，取产品品类表中对应产品的“产品品类名称”字段。
- 计算逻辑，即指明由哪些源字段通过何种计算逻辑得出目标字段的值。
- 数据过滤规则，即指明在融合过程中需要过滤掉哪些数据。如只需要订单状态为“已完成”的订单数据。
建议形成数据映射表，让使用人员结合数据模型，能够无歧义地理解“数据从哪里来、要经历何种变换、最终以何种形态存在”。
以电商场景中的交易主题为例，已设计了“订单信息”数据模型，其对应的数据库表名为dwd.order。为了完成“订单”模型的数据融合，制定的数据映射示例如下。
表 10 数据映射清单模板及示例

1.3.5.2.3. 数据融合开发
数据融合开发的前提是预先创建好数据仓库/数据湖（治理层）的对应数据库，并配置好相应的访问权限。根据已设计完成的数据模型和映射规则，使用组织已确定的工具进行数据融合开发。
开发方式主要有可视化ETL工具和代码脚本两种。
(1) 使用可视化ETL工具
如下图，开发人员在ETL工具的画布上，通过拖拽数据源、转换组件、目标表等构件，并以连线的方式构建工作流。随后，对每个组件进行配置：定义SQL查询、设置字段映射规则、配置连接条件、编写计算表达式等。该方式降低了编码门槛，易于上手和维护。

图 8 可视化ETL工具示意图

(2) 编写代码脚本
开发人员主要使用 SQL 或大数据计算框架（如Spark、Flink）的API 进行编码。这种方式为开发人员提供了极大的灵活性和控制力，适用于处理非常复杂或定制化的业务逻辑。
在融合开发过程中，传统方式依赖开发人员手动编写复杂SQL或配置ETL任务，不仅耗时且对人员经验要求高。引入AI技术可显著提升融合开发的智能化与自动化水平：
- 融合逻辑自动生成与建议：针对融合场景，AI根据映射规则与业务意图，自动生成或推荐高效的可视化ETL流程配置或代码脚本，减少编码工作。
- 性能与逻辑优化：在开发过程中，AI对编写的融合逻辑进行静态分析与性能模拟，识别潜在的冗余计算或执行瓶颈，并提出优化建议，提升融合任务的运行效率与稳定性。
无论采用哪种开发方式，融合开发过程都应遵循规范的步骤，包括开发、测试和上线等，确保每个环节可追溯、可审计。

1.3.6. 监控数据集成服务
1.3.6.1. 实施概述
表 11 步骤4 监控数据集成服务的实施概述

1.3.6.2. 活动
1.3.6.2.1. 数据集成监控
数据集成服务正式启用后，需要持续性地监控服务运行状态，确保数据流转的稳定与可靠。通常用工具或平台设置关键监控指标，通过自动监控任务，简化人工操作，降低运维成本。监控内容包括作业健康度、数据流质量和系统资源等方面。
作业健康度监控：跟踪每个集成作业的运行状态（成功/失败）、开始与结束时间、执行耗时等，确保任务按时完成。
数据流质量监控：核心是监控数据流量，并记录错误记录数，及时发现数据流中断或异常，及时触发告警机制，通知相关人员进行处理。
系统资源监控：监控集成平台或底层计算资源的CPU、内存、磁盘IO和网络带宽使用情况，预防资源瓶颈。
数据对账监控：数据对账目标远超于流程是否成功，而在于验证归集数据量和内容的绝对准确性，确保从源系统到目标系统的数据“不多一条、不少一条、内容不差一分”。

图 9 集成监控示意图

（或访问：https://xcnoejbrkx3v.feishu.cn/drive/folder/HCXufFf6ilq0ejdF5Hmc3CJhnYf）

本书采用了开放式共创的编撰模式。我们坚信，内容的可靠性与实践性来自持续的交流与共创。因此，我们诚挚邀请您——每一位关注数据治理的同行者、实践者与思考者——加入本书的共创计划。

如果您在阅读过程中，提出关键修正、贡献具有借鉴价值的优质案例，或补充了不可或缺的核心内容，我们将诚挚邀请您成为本书的共同署名共创者，并参与后续的专题研讨与行业交流，共同推动数据治理领域的实践进步与生态发展。

愿这本书不仅是一本指南，更是一次连接行业、凝聚共识、共创未来的行动。

【第二部分 规划篇】第6章 数据集成

【第二部分规划篇】第6章数据集成