数据集成规范实践总结

type

status

date

slug

summary

1 范围

略

2 规范性引用文件

《XXXX集团数据湖仓分层规范》

《XXXX集团数据建模规范》

《XXXX集团数据标准规范》

3 术语和定义

3.1 数据

以文本、数字、图形、图像、声音和视频等格式对事实进行表现。（随着时代发展，“数据”定义也在扩展，目前主要指“以电子化格式对业务事实的表现”。）

3.2 数据集成

数据集成是一种高效、易用的数据集成服务，提供了简单易用的迁移能力和多种数据源到数据湖仓的集成能力。

3.3 数据标准

数据标准是指在数据生产、加工及应用中，用于规范数据定义、格式、规则及管理要求的规范性文件，内容涵盖业务标准、管理标准、技术标准三个维度。

3.4 数据处理

数据处理是指对数据进行一系列操作和转换的系统执行过程，包括数据清洗、转换、聚合、计算等，以支持数据分析、报表生成或业务应用的需求。

3.5 数据加工处理作业管理流程

是对数据进行处理和转换的作业进行规划、调度和监控，以实现数据集成的过程。

3.6 工作空间

工作空间是数据治理中心（DataArts Studio）从平台层面提供的用户（成员）权限管理与各模块资源配置能力，用于对数据集成、数据开发、数据质量、数据架构、数据服务、数据目录等数据治理功能进行按需隔离与精细化管理。

4 管理职责与分工

略

5 基本原则

5.1 数据入湖全周期管理原则

数据集成工作应遵循数据集成全周期管理原则。数据集成入湖前应明确数据负责人、确定数据标准、定义数据分级、明确数据源及进行入湖前的数据质量评估，数据入湖后应进行元数据注册及入湖数据质量评估，并生成数据质量评估报告，形成数据集成入湖全周期的管理。

5.2 应接尽接原则

数据集成应遵从应接尽接原则，各级各部门业务系统数据应接尽接，尤其要确保各部门业务系统的核心数据、有效数据应接尽接，如主数据、基础数据等。

5.3 按需接入原则

根据创新应用的数据需求或者其他部门的数据需求，当发现需求数据未入湖时，应遵循按需接入原则，按照业务应用场景数据需求将数据入湖。

5.4 分类施策原则

数据集成入湖应以业务需求为核心，根据数据的重要性、时效性和使用频率，制定差异化的集成策略，确保数据能有效支撑业务目标。

（一）对于准实时决策数据，需确保快速可用，满足高效响应需求；

（二）对于周期性分析数据，应优先保证完整性和一致性，支撑业务分析和历史对比；

（三）对于跨业务领域的数据，应基于业务逻辑筛选关键字段，确保数据的准确性和可理解性，满足不同业务场景下的使用需求；

（四）对安全等级“三级”及以上数据，需设计数据集成安全策略（如源系统脱敏后采集）并报数据治理与架构管控小组审批通过后方可实施。

6 数据集成入湖步骤

6.1 检查数据源准备度

（一）提供源系统数据字典

数据有源是数据入湖的基本前提。对于集团内部数据要求其已结构化，并纳入正式IT系统管理；对于外部数据须具备稳定的数据交换接口，确保数据来源的可靠性和持续性。

源系统应提供完整、准确、最新的数据字典，涵盖表结构、字段定义、数据类型、主外键关系、约束规则等内容，以支持数据治理和标准化建设。

（二）提供源系统数据模型

源系统数据模型（物理模型）是数据湖建设的重要参考依据。源系统IT产品团队应提供数据模型，并确保其与实际数据结构一致，具备可用性和完整性。如数据模型缺失，源系统IT产品团队应提供符合数据治理要求的物理模型，以支持数据中台的架构设计、数据资产管理及数据血缘分析。

（三）确认源系统物理表规范度

源系统物理表的唯一键和时间戳，是数据湖物理层建设实施增量更新等的技术前提。

唯一键：所有源系统物理表必须具备唯一键，以确保数据行的唯一性和可追溯性。对于缺失唯一键的表，需进行数据模型改造，并完成历史数据补充，确保数据完整性。

时间戳：增量数据同步依赖标准化的时间戳字段，源系统应确保关键业务表包含准确的时间戳字段（如created_at、updated_at），并与数据更新逻辑保持一致，以支持增量数据抽取策略。

（四）评估数据质量

合格的数据质量是数据消费的基本要求。数据进湖前，应该做好源系统数据质量评估，对不满足数据质量要求的数据，源系统应该根据数据入湖计划同步完成数据质量整改。

6.2 明确数据责任人

为确保数据湖的数据管理责任清晰，在数据入湖前，应该明确相应的数据责任人；如果缺失，应该按照“谁产生数据，谁负责”的原则确定数据责任人并刷新数据资产目录。

6.3 确定数据集成方式

数据集成方式是确保数据高效、有序入湖的关键环节，应以确保业务系统稳定运行为核心，结合业务需求、技术架构及数据治理要求，合理规划数据采集方式和执行时机，最大程度降低对业务系统的影响。

（一）核心业务系统：应优先从从库或灾备数据库集成，确保主库高可用性；如无从库/备库，则应在业务低峰期执行集成，避免影响在线交易或关键业务流程。

（二）一般业务系统：建议优先在低峰期集成，如具备从库/备库，应优先使用，以减少业务干扰。

（三）已下线的老系统：可采用全量一次性集成，减少系统维护和资源消耗，降低历史数据迁移的复杂度。

6.4 刷新数据架构/数据标准

（一）刷新数据资产目录

数据资产目录是元数据资产的重要组成和数据导航的重要基础，也是明确数据责任人的重要依据。

数据湖数据应该记录在集团数据资产目录中。如果缺失，应依据《XXXX集团数据资产目录管理规范》刷新数据资产目录并进行编码。

（二）确认数据标准

数据标准定义了数据属性的业务含义、业务规则等，是正确理解和使用数据的重要依据，也是业务元数据的重要组成部分。

数据集成入湖前须确认其符合集团数据标准。如果数据标准缺失，应该依据《XXXX集团数据标准管理规范》进行开发。

（三）刷新数据模型

数据模型是元数据资产的核心组成，是数据湖数据集成的重要依据。为确保数据的完整性、一致性和业务语义的准确性，数字信息中心数据架构师须在数据入湖前审核并更新数据逻辑模型，确保其符合数据治理标准，并纳入数据治理流程，以保障数据湖的高质量建设与稳定运行。

6.5 数据入湖实施与验证

IT团队在承接业务需求后，应制定数据集成与质量监测方案，确保数据入湖的准确性、完整性和可用性。实施过程中，需遵循数据治理规范，与数据责任人协同推进，合理规划数据采集与调度策略，确保数据同步稳定高效。

各领域数据责任人应组织UAT(用户验收测试，User Acceptance Test)测试，确保数据正确、流程完整、系统稳定，最终完成数据入湖。

7 数据集成作业开发规范

7.1 集成工具

集团数据中台采用CDM（Cloud Data Migration）作为批量数据集成工具，CDM是华为云数据中台提供的一种高效、易用的数据集成服务，提供简单易用的迁移能力和多种数据源到数据湖的集成能力，有效的提高数据迁移和集成的效率。

7.2 集成集群管理

集成集群管理旨在统一规范数据集成系统的部署与运行环境，保障资源合理使用、安全隔离和任务稳定执行。

7.2.1 整体原则

为保障数据集成系统的高效性、安全性和稳定性，集群管理指导原则如下：

（一）环境隔离原则。

采取敏感数据隔离机制。涉及个人隐私、商业机密等敏感数据的工作空间，必须部署独立数据集成集群，确保物理环境隔离及访问权限最小化。

（二）资源扩容机制。

采取持续监控集群资源阈值，建立集群资源预警响应机制：

资源占用率≥80%：限制在该集群上新增作业调度，并立即启动新集群的购买评估流程；

资源占用率≥90%：停止在该集群上创建新作业，优先保障存量作业稳定执行。

7.2.2 命名要求

数据集成集群名称须确保唯一性，并由字母、数字及下划线组成，全部采用小写命名，以保障规范性与可读性。数据集成集群名称构成：cdm区域交易集团英文简称数据治理类别英文简称集群规格及配置(核心数与内存)自增序号如（cdm_xxxzy_dg_4xl64u128g_001），所有新增集群必须基于实际资源规格及序号进行命名，不得随意变更命名规范。

代理集群（DataArts-xxxxzy_AGENT_UlwyOBgP）用于作业请求的转发及结果传输，不推荐用于创建数据集成任务，严禁配置集成作业调度任务。代理集群的使用应严格遵循系统架构设计要求，确保数据流转的稳定性和安全性。

7.3 数据连接规范

在创建数据迁移任务前，需先配置数据源连接，确保 CDM集群具备访问和操作数据源的权限。每个迁移任务必须配置两个连接：源连接（用于读取数据）和目标连接（用于写入数据）。若已存在可用的数据连接，可直接复用，无需重复创建。创建数据连接命名规范：

（一）连接名称格式：如果数据源为数据库类型，数据连接名称格式为“数据源类型平台（或者子系统）名称数据库名称”；如果数据源类型为其他数据源类型，数据连接名称格式为“数据源类型_平台（或者子系统）”。

（二）数据连接名称应唯一，由小写英文字母和下划线组成。

（三）连接名称长度不宜过长，应限制在20个字符以内。当字段名超过20个字符时，可以用缩写来减少长度。

（四）湖内数据连接命名构成：数据库类型_link（dws_link）。

（五）湖外数据连接命名构成：数据库类型conn业务单元_系统（oracle_conn_erp）。

7.4 集成作业管理

7.4.1 作业组创建规范

为规范管理作业，在创建数据集成任务前，需要先创建作业组，方便对数据集成作业进行分组。作业组规范如下：

（一）作业组名称格式：源端板块简称业务系统简称DI，源端计数作业使用源端板块简称业务系统简称CNT,共享交换作业使用SHARING_EXCHANGE。

（二）作业组名称由大写英文字母和下划线组成。

（三）作业组名称长度不宜过长，应限制在20个字符以内。当字段名超过20个字符时，可以用缩写来减少长度。

7.4.2 作业创建规范

在创建数据集成作业时候，应遵循统一的命名规范，方便对作业进行统一管理。作业规范如下：

（一）作业名称格式：cdm全量all/增量add/计数cnt源端数据源类型2目标端数据源类型源端系统简写目标表名称，如cdm_all_mysql2dws_erp_mem_info。

（二）作业名称由小写英文字母和下划线组成。

（三）作业名称长度不宜过长，应限制40个字符以内。当字段名超过40个字符时，可以用缩写来减少长度。

7.4.3 作业调度规范

建议通过DataArts Studio的数据开发模块调度数据集成作业，不推荐使用CDM的原生调度功能，以确保调度体系统一、便于管理。

7.4.4 作业变量规范

数据集成作业使用DataArts Studio中的EL表达式或简易变量集进行日期变量传参，不推荐使用CDM的自有时间宏能力。

7.4.5 作业备份规范

数据集成作业配置完成后，应配置周期性备份任务，按日定期备份作业，以确保在作业异常删除或发生故障时能够及时恢复。备份策略：全量备份所有作业。

备份周期：按日。

OBS桶：obs-xxxzy。

备份数据目录：/backup/cdm_bak/cdm集群名称/，如

cdm_bak/cdm-xxxxzy-dg-4xl64u128g-001/。

7.4.6 作业删除规范

原则上不允许随意删除数据集成作业。如确需删除，需先手动导出所有作业至指定OBS备份目录，并完成报备流程后操作，以防止误删造成作业调度失败。

备份策略：全量备份所有作业。

备份周期：按需手动执行。

OBS桶：obs-xxxxzy。

备份数据目录：cdm_bak/cdm_mannual_export/cdm集群名称/，如cdm_bak/cdm_mannual_export/cdm-xxxxzy-dg-4xl64u128g-001。

备份命名：原有导出命名+导出人IAM子账号名称+备份日期。

7.5 全量集成规范

7.5.1 全量集成标准流程

全量数据集成需遵循以下步骤：

贴源表创建：在目标数据仓库（DWS）中建立与源表结构一致的贴源表，仅增加记录来源、记录创建时间、记录更新时间、逻辑删除标记（参见《XXXX集团数据建模规范》）。

全量覆盖集成：将源表数据以全量覆盖方式同步至目标表，确保数据一致性。

7.5.2 集成模式选择与实施

（一）历史数据全量集成。适用于历史数据迁移一次性初始化入湖。实施中可通过逐表开发定制化集成作业，支持字段映射、清洗规则等灵活配置，并通过脚本自动化生成CDM作业JSON模板，批量导入实现高效迁移。

（二）T+1周期性全量集成。适用于源表数据量较小（如行数低于 1000 万，SQL Server 源系统低于 100 万）且对作业运行时长有要求的场景；同时适用于源表缺乏可用的创建、更新时间字段，或时间字段数据缺失、异常，无法准确识别增量变化的情况；此外，当源系统存在人工不规范操作（如直接修改数据但未更新时间戳、物理删除数据、手工插入未填写创建时间等）时，需要全表保持与源端最新数据相同时，也建议采用T+1全量进行定期比对，以保证数据的完整与准确。

（三）整库全量集成。适用于首次全量同步且时效性要求严格的场景。整库迁移从数据库级别进行对应库下所有表的集成作业创建。该方式以标准化批量迁移方式执行，确保数据完整快速同步，不支持针对表级、字段级的个性化剪裁和转化配置。

7.6 增量集成规范

增量集成作业必须确保每经过T+1个时间周期（分钟/小时/天），DWS贴源表与源表数据保持完全一致，以满足数据一致性要求。

7.6.1 T+1增量集成

T+1增量集成的方式适用的场景如下：

（一）源表数据行数大于1000万行（若源系统为SQLServer，则需大于100万行），且对数据集成作业有作业运行时长要求。

（二）源表有用于记录更新时间的时间戳字段，或存在判断增量数据的方式。

7.6.2 T+1滚动增量集成

当数据集成/同步过程中，需要每次增量更新多个时间周期的数据（如最近7天或30天），应采用T+1滚动增量集成，确保数据在滚动窗口内的完整性与一致性。适用场景：

（一）数据存在回溯/更新需求：部分数据可能在多个时间周期内被修改（如账务调整、业务补录、异常回溯等），需要同步近几天的数据以保证完整性。

（二）长周期数据分析：部分业务场景需要连续天数的数据，而非单日数据同步（如风控模型、时间序列分析、用户行为日志分析等）。

（三）源表无精确更新时间戳，或更新策略不稳定：如部分数据变更逻辑较复杂，导致单独的T+1增量不足以保证数据准确性。

7.6.3 T+N周期性增量集成

当数据同步需求不需要每日更新，而是基于周、月、季度等特定业务周期进行同步时，应采用T+N周期性增量集成，其中N代表数据同步的时间间隔（如7天、30天、90天等）。此方式能够降低数据同步频率，减少计算资源消耗，同时确保数据的完整性和一致性，适用场景：

（一）低频数据更新：源数据不需要每日更新，例如财务结算数据、月度报表、季度汇总数据、合并分析数据等。

（二）业务分析按周期运行：如企业绩效考核、客户行为分析、季度报告，仅需每周（T+7）、每月（T+30）进行一次数据同步。

（三）减少数据同步开销：对于数据量大但更新不频繁的业务，降低数据同步频率可以减少ETL作业压力，提高数据处理效率。

（四）外部数据源更新周期较长：部分外部系统或第三方API数据每月、每季度提供一次更新，不适用于T+1方式。

（五）数据治理要求周期性数据归档：某些业务场景下，数据需按月、季、年归档，例如政策报送、合规数据存档、法规要求的审计数据，可通过T+N周期性增量集成确保定期同步。

7.6.4 T+1历史变更追踪集成

T+1历史变更追踪集成适用于需要记录数据每次变更，保留历史版本，以支持数据回溯、审计和业务趋势分析的场景。与普通T+1增量集成不同，该方式不仅同步最新数据，还存储数据的所有历史变更，以便进行数据对账、合规审计和状态追踪。使用场景如下：

（一）数据变更历史管理：适用于客户信息、合同审批、订单状态等需要追踪变更的业务场景，例如客户手机号、地址变更记录，或订单从“待支付”到“已支付”再到“已退款”的全过程。

（二）数据仓库历史快照管理：适用于数据仓库SCD（慢变化维度），如员工职位变更、薪资调整等，需要存储每次调整的时间点，以便进行历史趋势分析。

（三）合规与审计需求：在政务、医疗等行业，数据必须符合审计和合规要求，确保所有改动可溯源，例如监管机构要求保留所有账户变更记录，以支持合规检查。

7.7 增量集成目标表处理规范

增量集成目标表应根据是否为分区表采用相应的数据处理策略，以确保数据一致性、并优化存储与查询性能。

7.7.1 当目标表为分区表，要求如下：

（一）TRUNCATE目标写入分区。

（二）INSERT OVERWRITE或INSERT对应分区数据至目标表，避免重复数据堆积。

（三）禁止使用DELETE语法，以防止脏页问题，需定期执行VACUUM以优化表性能。

7.7.2 当目标表为非分区表，要求如下：

（一）DELETE+定期VACUUM：适用于目标日期数据清理，防止脏页积累，维持表性能。

（二）UPSERT语法：适用于每日查询数据集100万行以下场景，脏页影响低于DELETE，需搭配VACUUM操作维护表性能。

（三）MERGE INTO语法：适用于每日查询数据集100万行以上的场景，脏页影响低于DELETE，较大数据量下性能优于UPSERT，需结合VACUUM操作进行表性能优化。