大数据平台数据入湖规范（完整版含配套落地工具、调研清单、场景示例、代码模板）

第一章 总则

1.1 目的

为规范大数据平台数据入湖全流程，实现数据统一标准、统一管控、安全合规、高效可用，规避数据混乱、质量低下、存储冗余、安全泄露等问题，保障数据湖资产的完整性、一致性和可追溯性，支撑下游数据分析、业务决策及数据应用落地，特制定本规范。本规范适用于所有接入大数据平台数据湖的数据源、数据处理、数据存储、数据管控及相关技术人员、业务人员。

1.2 适用范围

本规范覆盖大数据平台数据入湖的全生命周期，包括：数据源接入、数据采集（增量/全量/拉链）、数据清洗转换、数据分层存储、表结构设计、命名规范、元数据管理、数据质量校验、数据安全、数据生命周期管理及异常处理等环节；适用于所有业务线（如账户、订单、用户、商品等）的结构化、半结构化、非结构化数据入湖操作，涵盖实时入湖与批量入湖两种模式。

1.3 核心原则

• 标准统一：统一数据命名、格式、分层、编码，避免“同数不同名、同名不同数”，确保数据一致性；
• 质量优先：入湖数据必须经过质量校验，不符合标准的数据不得入湖，确保数据准确、完整、可用；
• 安全合规：遵循数据安全法、个人信息保护法，落实敏感数据脱敏、权限管控，防范数据泄露；
• 高效可扩展：兼顾数据入湖效率与平台扩展性，支持多源异构数据接入，适配业务增长需求；
• 可追溯可管控：全流程记录数据血缘、操作日志，实现数据从源头到入湖的可追溯、可审计；
• 按需存储：根据数据价值、访问频率，合理划分存储层级，优化存储成本，避免冗余。

第二章 数据源接入规范

2.1 数据源分类

入湖数据源按类型分为以下3类，各类数据源需符合对应接入要求：

• 结构化数据：业务数据库（MySQL、Oracle等）的表数据（如账户表、订单表）、Excel/CSV等结构化文件，需明确主键、字段类型、编码格式；
• 半结构化数据：JSON、XML、日志文件（如用户行为日志），需明确数据格式、字段含义，确保字段可解析；
• 非结构化数据：图片、音频、视频、文档等，需统一存储格式，标注元数据信息（如文件名称、大小、创建时间、来源）。

2.2 数据源接入前置调研清单（新增落地模块）

2.2.1 基础业务调研项

【数据源基础信息调研表】
1. 数据源归属业务线：账户/订单/支付/商品/用户行为日志
2. 数据源存储类型：MySQL/Oracle/PostgreSQL/本地日志/CSV/图片/视频
3. 数据库实例地址、端口、库名、表名、负责人联系方式
4. 数据所有权归属部门、数据使用授权范围
5. 业务表核心业务含义、业务上下游依赖系统
6. 表更新特征：实时变更/每日批量更新/极少变更静态基础表
7. 单表日增量条数、全量表总数据量、峰值TPS
8. 业务数据保留周期、合规审计留存要求

【字段敏感等级调研表】
1. 字段名称、字段业务含义、字段数据类型
2. 是否属于一级高度敏感（身份证/银行卡/手机号/密码）
3. 是否属于二级中度敏感（姓名/住址/余额/交易流水）
4. 是否三级普通字段（商品名称/订单状态编码）
5. 是否需要脱敏、脱敏规则需求

【采集模式调研表】
1. 业务是否需要历史全量快照追溯
2. 是否需要记录维度历史状态（账户销户、商品下架）
3. 延迟容忍度：分钟级实时/T+1批量
4. 唯一标识字段：主键ID、自增ID、更新时间字段
5. 分区需求：按日/按小时/无需分区

2.2.2 技术调研项

• 数据库是否支持CDC同步（Debezium/Flink CDC）、binlog开启状态
• 数据源服务器带宽、磁盘IO上限，是否支持定时全量抽取
• 原始数据编码格式、原始日期存储格式、空值代表逻辑含义
• 数据源是否存在逻辑删除标记字段（is_delete）
• 下游应用场景：报表看板/算法建模/风控对账/自助查询

2.3 数据源接入要求

• 接入前提：数据源需经业务部门确认，明确数据所有权、使用范围，签订数据接入协议，确保数据来源合法合规；
• 接入方式：结构化数据优先采用CDC工具（如Debezium、Flink CDC）实现实时同步，批量数据采用定时抽取（如Sqoop、DataX），非结构化数据采用对象存储（如HDFS、MinIO）接入；
• 编码要求：所有入湖数据编码统一为UTF-8，避免中文乱码；日期格式统一为“yyyy-MM-dd HH:mm:ss”，时间戳统一为毫秒级；
• 异常处理：数据源中断、数据格式变更时，需及时触发告警，通知数据源负责人及数据入湖运维人员，暂停入湖操作，排查问题后再恢复。

第三章 数据采集与转换规范

3.1 事实表与维度表区分标准（补充落地判定规则）

3.1.1 事实表定义与特征

• 存储业务发生的交易、流水、变动事件，描述行为过程，数据持续新增；
• 以增量采集(_incr)为主，单表每日产生大量新增记录；
• 核心字段：业务唯一流水ID、操作时间、关联维度外键（user_id、order_id、goods_id）、金额、数量等度量指标；
• 典型示例：订单流水、支付明细、账户变动日志、用户点击行为日志。

3.1.2 维度表定义与特征

• 存储业务实体静态属性，描述实体对象，更新频率低；
• 支持全量(_full)、拉链(_zip)两种采集模式，用于记录实体历史状态；
• 核心字段：实体主键、属性描述、状态标记、生效失效时间；
• 典型示例：用户基础信息、商品档案、机构门店、账户档案。

3.1.3 快速判定示例

表名：order_pay_detail → 支付流水（事实表，增量采集）
表名：user_account_info → 用户账户（维度表，拉链采集）
表名：goods_base_info → 商品档案（维度表，每日全量快照）
表名：user_click_log → 用户行为日志（事实表，实时增量）

3.2 采集模式规范（增量/全量/拉链选型对比）

3.2.1 三种采集模式优缺点&适用场景对比

采集模式	后缀标识	优势	劣势	最优适用场景
增量_incr	_incr	数据量小、同步速度快、存储成本低	无法直接查看完整实体快照，需关联历史数据	所有事实流水表、高频变更明细表
全量_full	_full	可直接获取当日完整快照，查询简单	每日存储全量数据，存储成本高	小体量静态维度表（万级以内）
拉链_zip	_zip	完整保存实体全生命周期状态，支持任意历史时间切片	更新逻辑复杂，写入性能略差	金融/风控维度表、需追溯历史状态实体

3.2.2 增量采集（_incr）

• 适用场景：事实表（如订单表、流水表）、高频更新的维度表（如账户表），仅采集当日新增/变更的数据；
• 采集规则：基于更新时间（update_time）、自增ID等字段，每日定时采集或实时采集，确保不重复、不遗漏；实时入湖场景需控制时延，单表TPS可支持万级，端到端时延控制在分钟级；
• 存储要求：增量表需按dt（数据日期）分区，仅存储当日变动数据，数据量控制在合理范围，便于后续更新全量、拉链表。

3.2.3 全量采集（_full）

• 适用场景：维度表（如商品表、机构表）、数据量较小的业务表，需每日保留全量最新数据快照；
• 采集规则：每日定时全量抽取数据源所有数据，覆盖前一日全量数据，采用Truncate+Insert或Insert Overwrite方式更新；
• 存储要求：全量表需按dt（同步日期）分区，每日保留一份完整快照，便于下游直接查询最新数据。

3.2.4 拉链采集（_zip）

• 适用场景：需追溯历史状态的维度表（如账户表、用户表），尤其是金融、风控、对账场景，需记录数据从生效到失效的全生命周期；
• 采集规则：基于增量数据，每日更新拉链表，新增数据生效时间（start_date）设为当日，失效时间（end_date）设为“9999-12-31”；变更数据需关闭历史记录（将end_date设为前一日），新增最新记录；
• 存储要求：拉链表不做日分区，为一张全量历史表，需包含start_date、end_date两个必选字段，确保历史状态可追溯。

3.3 分区选型规范（新增落地规则）

3.3.1 三种分区方式适用范围

1. 日分区dt=yyyy-MM-dd（使用范围最广）
   • 适用：批量增量表、全量表、T+1离线明细、汇总表、拉链衍生快照；
   • 优势：分区粒度适中，分区数量可控，查询过滤简单，存储生命周期清理便捷；
   • 适用场景：90%业务离线数据入湖。
2. 小时分区dt=yyyy-MM-dd/HH（次选）
   • 适用：高吞吐实时行为日志、实时交易明细、秒级时延监控指标；
   • 劣势：分区数量爆炸，长期存储分区过多，元数据压力大；
   • 限制：仅实时DWD明细层使用，DWS/ADS层统一合并为日分区汇总。
3. 不分区
   • 适用：小体量基础维度字典表（千级数据以内）、拉链历史主表；
   • 禁止：千万级以上大表不允许无分区存储。

3.3.2 分区路径示例

# 日分区增量订单明细
/user/hdfs/data/dwd/dwd_order_detail_incr/dt=2026-06-24
# 小时分区实时行为日志
/user/hdfs/data/dwd/dwd_user_click_incr/dt=2026-06-24/hour=14
# 无分区拉链账户表
/user/hdfs/data/dwd/dwd_account_info_zip

3.4 数据转换规范

数据入湖前需经过清洗、标准化转换，确保数据干净、规范，转换操作主要在DWD层完成，具体要求如下：

• 数据清洗：剔除测试数据、垃圾数据、逻辑删除数据，过滤重复数据、空值异常；补全缺失字段（如默认值填充），修正格式错误（如日期格式、编码格式）；
• 字段标准化：统一字段名称（如用户ID统一为user_id，不使用uid、u_id）、字段类型（如手机号统一为字符串类型）、状态编码（如账户状态1=正常、2=冻结、3=销户）；
• 敏感数据脱敏：手机号、身份证号、银行卡号等敏感数据，入湖前必须脱敏处理（如手机号保留前3位+后4位，身份证号保留前6位+后4位），脱敏规则统一制定并留存；
• 数据关联：关联字典表、基础表，补全编码对应的名称（如pay_type=1补全为“微信支付”），确保数据可理解；
• 格式转换：半结构化数据（如JSON）需解析为结构化字段，非结构化数据需提取关键元数据，统一存储格式。

3.4.1 脱敏代码模板（Flink SQL）

-- DWD层手机号、身份证统一脱敏逻辑
CREATE TEMPORARY FUNCTION mask_phone AS 'com.datahub.udf.MaskPhoneUDF';
CREATE TEMPORARY FUNCTION mask_idcard AS 'com.datahub.udf.MaskIdCardUDF';

INSERT OVERWRITE dwd_user_info_incr
SELECT
    user_id,
    mask_phone(phone) AS phone, -- 138****1234
    mask_idcard(id_card) AS id_card, -- 440106********1234
    user_name,
    create_time,
    update_time,
    data_source,
    data_owner,
    dt
FROM ods_user_info_incr
WHERE is_delete = 0;

第四章 数据分层与存储规范

4.1 数据分层标准（完整流转链路说明）

数据湖按业务职责、数据加工程度，分为5层，分层需前置判断，严格遵循ODS→DWD→DWB→DWS→ADS的流转顺序，不得跨层入湖，所有业务数据必须完整流经分层，禁止直接ODS写入ADS层。

4.1.1 ODS层（原始数据层）

• 作用：原汁原味存储原始数据，不做任何业务加工，仅做格式转换（如编码统一），保留数据原始面貌；
• 存储内容：从数据源直接同步的原始数据，包括结构化、半结构化、非结构化数据；
• 存储要求：采用HDFS或对象存储，按数据源、业务主题分区，保留原始字段名称和数据格式，支持数据回溯。

4.1.2 DWD层（明细数据层）

• 作用：对ODS层数据进行清洗、标准化、脱敏、关联，生成干净、规范的业务明细数据，粒度与原始数据一致（一行一条业务明细）；
• 存储内容：清洗后的明细数据，如dwd_account_info_incr（账户增量明细）、dwd_order_detail_incr（订单增量明细）；
• 存储要求：采用Hudi、Iceberg等湖格式，支持增量更新、Upsert操作；事实表明细表优先采用增量存储，维度表明细表采用增量+全量+拉链存储。

4.1.3 DWB层（宽表数据层，补充宽表落地判定规则）

4.1.3.1 是否需要构建宽表判定标准

• 需要宽表场景：下游报表频繁多表关联、单查询关联≥3张DWD明细表、日查询量万次以上；
• 无需宽表场景：临时一次性分析、单表独立查询、算法原始明细样本取数；
• 宽表构建规则：同一业务主题下DWD明细+关联维度字典一次性拼接，减少下游重复JOIN；禁止跨大主题拼接（订单+用户+商品允许，订单+物流+人事禁止）。
• 作用：将同一业务主题的多张DWD明细表层关联，拼成一张宽表，减少下游关联操作，提升查询效率；
• 存储内容：按业务主题聚合的宽表，如dwb_account_info_wide（账户全量宽表）、dwb_order_full_wide（订单全量宽表）；
• 存储要求：以全量宽表为主，采用Hudi MOR表格式，支持高效查询；字段涵盖业务主题相关的所有关键信息，避免冗余。

4.1.4 DWS层（汇总数据层）

• 作用：对DWB宽表层数据按业务维度（如按天、按用户、按商品）进行轻度汇总，为下游应用提供聚合数据；
• 存储内容：汇总统计数据，如dws_account_day_incr（每日账户变动统计）、dws_order_day_incr（每日订单统计）；
• 存储要求：按汇总维度分区，采用增量汇总方式，每日更新当日汇总数据，支持快速查询。

4.1.5 ADS层（应用数据层）

• 作用：为前端报表、业务系统、数据分析提供直接可用的数据，是数据湖的出口层；
• 存储内容：报表数据、统计指标数据，如ads_order_stat_full（订单统计报表）、ads_user_portal_full（用户门户数据）；
• 存储要求：以全量存储为主，按业务需求分区，数据需经过最终质量校验，确保直接可用。

4.2 存储格式规范

• 结构化数据：优先采用Hudi格式，实时入湖场景（如增量采集）使用MOR表，批量入湖场景（如全量采集）使用COW表；特大表采用MOR表+Bucket索引+分区，提升读写性能；
• 半结构化数据：JSON格式统一为标准JSON，解析后存储为结构化字段，保留原始JSON备份；
• 非结构化数据：统一存储为通用格式（如图片为JPG/PNG，文档为PDF/DOCX），存储路径按“业务主题/数据源/日期”划分；
• 索引规范：多引擎操作同一Hudi表时，使用统一索引；数据量较大时采用Bucket索引，分桶数根据业务峰值预估（分区表按分区未压缩数据量/2G计算，非分区表按分区分桶数×2计算）；2亿数据量以下可使用状态索引，COW表优先使用Simple索引，大表可采用Bloom索引。

4.3 分区规范

• 分区字段：增量表、全量表统一按dt（日期）分区，格式为“yyyy-MM-dd”；实时表采用日期分区，维度表采用非分区或粗粒度日期分区；
• 分区命名：分区目录格式为“dt=yyyy-MM-dd”，如“dt=2026-05-20”；增量表dt为数据产生日期，全量表dt为同步日期；
• 分区管理：支持隐式分区，直接使用业务字段进行分区，无需额外加工日期字段；可根据业务场景调整分区规则，实现分区演进，优化查询性能；定期清理过期分区，避免存储冗余。

第五章 表结构与命名规范

5.1 表结构设计规范

5.1.1 主键、唯一键、更新依据字段定义（补充落地标准）

1. 主键primary key：表唯一标识，不可重复、非空；
   • 事实表：流水ID order_id、pay_id；
   • 维度表：实体ID user_id、goods_id；
2. 唯一键unique key：业务逻辑唯一组合，拉链表强制配置 (user_id, start_date)；
3. 更新依据字段：增量同步判断变更字段，统一使用update_time（毫秒时间戳），无更新时间字段使用自增id。

• 前置判断：建表前需明确表类型（事实表/维度表）、更新方式（增量/全量/拉链）、分层、主键/唯一键，避免后期修改；
• 字段设计：字段名称简洁明了，采用小写字母+下划线命名，避免使用关键字；字段类型合理（如手机号用string，金额用decimal(18,2)），避免字段冗余；
• 必选字段：
  • 增量表/全量表：需包含create_time（创建时间）、update_time（更新时间）、dt（分区字段）；
  • 拉链表：需包含start_date（生效时间）、end_date（失效时间）、create_time、update_time；
  • 所有表：需包含数据来源字段（data_source）、数据所有者字段（data_owner）。
• 主键与唯一键：明确表主键（如账户表account_id），增量表用“主键+update_time”判断新增/修改；拉链表用“主键+start_date”确保唯一，避免重复记录。

5.1.2 Hive建表代码模板（Hudi增量事实表）

CREATE TABLE dwd.dwd_order_detail_incr (
    order_id STRING COMMENT '订单唯一主键',
    user_id STRING COMMENT '用户ID',
    goods_id STRING COMMENT '商品ID',
    order_amount DECIMAL(18,2) COMMENT '订单金额',
    pay_type TINYINT COMMENT '支付类型 1微信 2支付宝',
    create_time STRING COMMENT '订单创建时间 yyyy-MM-dd HH:mm:ss',
    update_time BIGINT COMMENT '更新毫秒时间戳',
    data_source STRING COMMENT '数据源 mysql_order',
    data_owner STRING COMMENT '数据负责人账号'
)
PARTITIONED BY (dt STRING COMMENT '数据日期')
STORED AS HUDI
TBLPROPERTIES (
    'hoodie.table.name' = 'dwd_order_detail_incr',
    'hoodie.datasource.write.recordkey.field' = 'order_id',
    'hoodie.datasource.write.precombine.field' = 'update_time',
    'hoodie.datasource.write.table.type' = 'MERGE_ON_READ',
    'hoodie.parquet.max.file.size' = '134217728'
);

5.2 表命名规范

命名格式统一为：分层_主题_业务_类型，全小写，下划线分隔，简洁明了，无歧义，具体规则如下：

5.2.1 分层前缀

• ODS层：ods_
• DWD层：dwd_
• DWB层：dwb_
• DWS层：dws_
• ADS层：ads_

5.2.2 主题与业务

• 主题：账户（account）、用户（user）、订单（order）、商品（goods）、支付（pay）、日志（log）等；
• 业务：明细（detail）、信息（info）、全量（full）、宽表（wide）、汇总（summary）、统计（stat）等。

5.2.3 类型后缀（增量/全量/拉链）

• 增量表：_incr（如ods_account_info_incr、dwd_account_info_incr）；
• 全量表：_full（如ods_account_info_full、dwd_account_info_full）；
• 拉链表：_zip（如ods_account_info_zip、dwd_account_info_zip）；
• 临时表：_tmp（如dwd_account_tmp，仅用于跑数过渡，不长期留存）；
• 历史归档表：_his（如ods_account_info_his，用于归档过期原始数据）。

5.2.4 示例（账户表完整命名）

• ODS层增量：ods_account_info_incr
• ODS层全量：ods_account_info_full
• ODS层拉链：ods_account_info_zip
• DWD层增量：dwd_account_info_incr
• DWD层全量：dwd_account_info_full
• DWD层拉链：dwd_account_info_zip
• DWB层宽表：dwb_account_info_wide
• DWS层汇总：dws_account_day_incr
• ADS层报表：ads_account_stat_full

第六章 元数据管理规范

6.1 元数据采集

• 采集范围：涵盖数据源元数据（数据源类型、地址、字段信息）、表元数据（表结构、字段含义、分层、分区、更新方式）、数据血缘（数据从数据源到入湖各层的流转关系）、操作日志（入湖任务执行时间、执行结果、操作人员）；
• 采集方式：采用自动化采集工具（如Atlas、FineDataLink），实时采集元数据变更，避免人工录入，确保元数据与实际数据一致；
• 采集频率：实时入湖任务元数据实时采集，批量入湖任务元数据每日采集一次。

6.2 元数据存储与管理

• 存储要求：元数据统一存储在元数据数据库（如MySQL、GraphDB），支持元数据版本管理、变更追溯，确保元数据一致性、安全性；
• 元数据维护：指定专人负责元数据维护，及时更新元数据（如表结构变更、字段含义修改），定期校验元数据准确性，避免元数据与实际数据脱节；
• 数据血缘管理：构建完整的数据血缘关系，记录数据从源头到入湖各层、再到下游应用的流转路径，支持血缘追溯、影响分析，便于问题排查。

6.3 元数据服务

搭建元数据查询门户，提供元数据搜索、浏览、订阅功能，方便技术人员、业务人员快速查询表结构、字段含义、数据血缘等信息；建立元数据变更告警机制，元数据发生变更时，及时通知相关负责人。

第七章 数据质量校验规范

7.1 校验原则

数据入湖全流程需进行质量校验，不达标数据不入湖、不修复数据不流转，校验分为前置校验（采集前）、过程校验（转换中）、后置校验（入湖后）三个环节。

7.2 校验内容与标准

• 完整性：主键非空率100%，关键业务字段（如account_id、order_id）非空率≥99.9%，无缺失字段；
• 准确性：字段值符合业务规则（如金额非负、状态编码在指定范围内），无错误数据、重复数据；
• 一致性：字段格式、编码、命名统一，同一字段在不同表中的含义、类型一致；
• 及时性：实时入湖数据时延≤5分钟，批量入湖数据每日按时完成，无延迟；
• 合规性：敏感数据已脱敏，数据来源合法，符合数据安全法、个人信息保护法要求。

7.3 校验流程与处理

• 前置校验：采集前校验数据源格式、字段完整性，不符合要求的拒绝采集，触发告警，通知数据源负责人整改，整改完成后重新发起采集；
• 过程校验：转换过程中校验数据清洗、脱敏、标准化效果，对清洗后仍不达标的数据（如无法修正的格式错误、缺失的关键字段）进行标记，单独存入异常数据临时表，不进入后续分层流转，同步触发告警；
• 后置校验：数据入湖后，校验数据量、字段完整性、一致性等指标，对比数据源与入湖数据的条数差异（允许±0.1%的误差，超出误差范围视为异常），校验通过后，数据方可对外提供使用；校验失败的，暂停下游数据流转，排查问题（如采集遗漏、转换错误），修复后重新入湖并再次校验；
• 异常处理：建立异常数据台账，记录异常数据的来源、异常类型、发现时间、处理人、处理结果及处理时间，定期复盘异常原因，优化校验规则和数据采集转换流程，减少异常数据产生；异常数据留存期限不少于3个月，便于追溯排查。

7.3.1 数据质量规则配置示例（JSON模板）

{
  "table_name": "dwd_order_detail_incr",
  "quality_rules": [
    {
      "rule_type": "not_null",
      "column": "order_id",
      "threshold": "100",
      "alarm_level": "紧急"
    },
    {
      "rule_type": "value_range",
      "column": "order_amount",
      "min_value": "0",
      "alarm_level": "重要"
    },
    {
      "rule_type": "row_count_diff",
      "source_table": "ods_order_detail_incr",
      "diff_rate": "0.001",
      "alarm_level": "紧急"
    }
  ]
}

第八章 数据安全规范

8.1 数据分级分类

入湖数据按敏感程度分为三级，分级标准及管控要求如下，分级需在数据入湖前完成判定：

• 一级（高度敏感）：身份证号、银行卡号、手机号、密码、生物识别信息等，需严格脱敏、加密存储，仅授权人员可访问；
• 二级（中度敏感）：用户姓名、地址、邮箱、账户余额、交易流水等，需脱敏处理，访问需授权并记录操作日志；
• 三级（一般敏感）：非个人信息类数据（如商品分类、订单状态编码、机构名称等），可正常存储，访问需符合平台权限要求。

8.2 数据脱敏与加密

• 脱敏要求：所有高度、中度敏感数据，在ODS层采集后、DWD层转换前完成脱敏，脱敏规则统一制定，不得随意修改；脱敏后的数据需保留业务可用性，不得影响下游分析使用；
• 加密存储：敏感数据存储时采用AES-256加密算法，加密密钥统一管理，定期更换；非结构化敏感数据（如含个人信息的文档），需加密后再存储；
• 传输加密：数据从数据源到数据湖、数据湖内部流转、数据湖到下游应用的传输过程，采用SSL/TLS加密，防止数据传输过程中泄露。

8.3 权限管控

• 权限分级：按“最小权限原则”，将权限分为管理员、运维人员、开发人员、业务分析人员四级，不同级别人员拥有对应操作权限，不得越级访问；
• 权限申请与审批：访问数据湖数据需提交权限申请，明确访问范围、访问目的、访问期限，经数据所有者及管理员审批通过后，方可授予权限；权限到期后自动回收，需延续访问的需重新申请；
• 操作审计：所有访问、修改、删除数据湖数据的操作，均需记录详细日志（包括操作人员、操作时间、操作内容、操作结果），日志留存期限不少于1年，便于安全审计和问题追溯。

8.4 合规要求

• 遵循《中华人民共和国数据安全法》《中华人民共和国个人信息保护法》等法律法规，不得采集、存储、使用非法来源数据；
• 个人信息类数据入湖前，需确认已获得用户授权，明确数据使用范围，不得超出授权范围使用；
• 定期开展数据安全合规检查，排查安全隐患，及时整改问题，确保数据入湖、存储、使用全流程合规。

第九章 数据生命周期管理规范（补充完整保留周期明细）

9.1 生命周期划分

根据数据价值、访问频率，将入湖数据生命周期分为活跃期、归档期、销毁期三个阶段，不同分层、不同类型数据的生命周期标准统一制定。

9.1.1 分层数据完整保留周期明细

分层	表类型	活跃期高性能存储	归档期低成本存储	超归档后销毁
ODS	增量_incr	30天	1年	满1年自动销毁
ODS	全量_full	30天	1年	满1年自动销毁
DWD	增量_incr	30天	2年	满2年自动销毁
DWD	拉链_zip	90天	3年	满3年自动销毁
DWB	宽表_wide	90天	2年	满2年自动销毁
DWS	汇总_incr	180天	1年	满1年自动销毁
ADS	报表_full	180天	1年	满1年自动销毁
非结构化	图片/文档	90天	1年	按业务合规要求销毁

9.1.2 活跃期

• 定义：数据处于高频访问、频繁使用的阶段，需保证查询性能和数据可用性；
• 期限：ODS层增量表、DWD层增量表活跃期30天；DWD层全量、拉链表、DWB层宽表活跃期90天；DWS层、ADS层数据活跃期180天；
• 存储要求：活跃期数据存储在高性能存储介质（如SSD），确保快速访问。

9.1.3 归档期

• 定义：数据访问频率降低，但仍有留存价值（如用于历史追溯、合规审计），需低成本存储；
• 期限：ODS层、DWD层数据归档期1-3年；DWS层、ADS层数据归档期1年；非结构化数据归档期根据业务需求确定（不少于1年）；
• 存储要求：归档期数据迁移至低成本存储介质（如HDFS归档节点、对象存储归档层），压缩存储，保留查询能力。

9.1.4 销毁期

• 定义：数据无留存价值，且符合销毁条件，需安全销毁，避免数据泄露；
• 销毁条件：超过归档期、无业务需求、无合规留存要求的数据；
• 销毁要求：采用物理删除+逻辑删除结合的方式，确保数据无法恢复；销毁过程记录日志，留存销毁凭证，销毁日志保存不少于6个月。

9.2 生命周期管理操作

• 自动化管理：采用生命周期管理工具，按预设规则自动识别数据所处阶段，完成数据迁移（活跃期→归档期）、销毁操作，减少人工干预；
• 人工干预：特殊业务数据（如金融对账数据、合规审计数据），可申请延长生命周期，经管理员审批通过后，调整生命周期期限；
• 定期检查：每月检查数据生命周期执行情况，排查未按规则迁移、销毁的数据，及时处理异常，确保生命周期管理落地。

第十章 异常处理规范

10.1 异常分类

数据入湖过程中，异常分为以下4类，各类异常需明确处理责任人、处理流程和处理时限：

• 采集异常：数据源中断、采集任务失败、采集数据量异常（过多/过少）、采集时延超标；
• 转换异常：数据清洗、脱敏、标准化失败，字段关联错误，数据格式转换异常；
• 存储异常：存储介质故障、分区创建失败、数据写入失败、存储容量不足；
• 质量异常：数据校验不达标，如主键缺失、重复数据、敏感数据未脱敏、字段格式错误。

10.2 异常处理流程

1. 异常发现：通过监控工具自动告警、人工巡检发现异常，记录异常类型、发生时间、影响范围、异常描述；
2. 异常上报：发现异常后，10分钟内上报至相关负责人（运维人员、数据负责人），重大异常（如数据泄露、大规模数据丢失）立即上报平台负责人；
3. 异常排查：责任人在30分钟内启动排查，定位异常原因（如数据源问题、任务配置错误、存储故障），记录排查过程；
4. 异常处理：根据异常原因，采取对应处理措施（如重启采集任务、修复转换规则、扩容存储、修复数据），处理完成后，验证数据入湖正常；
5. 复盘归档：异常处理完成后，24小时内完成复盘，分析异常原因，优化流程，避免同类异常再次发生；异常处理记录、复盘报告归档留存，留存期限不少于6个月。

10.3 告警机制

• 告警分级：按异常严重程度分为紧急、重要、一般三级，紧急异常（如数据泄露、大规模数据丢失）立即推送至责任人手机、企业微信；重要异常（如采集任务失败）30分钟内推送；一般异常（如个别数据质量不达标）1小时内推送；
• 告警方式：采用手机短信、企业微信、邮件、平台告警中心多渠道推送，确保责任人及时接收；
• 告警升级：异常未在规定时限内处理，自动升级告警，推送至更高层级负责人，直至异常处理完成。

第十一章 附则

11.1 规范更新

本规范根据业务发展、技术升级、法律法规变更，定期进行修订，修订后另行发布，修订版生效后，旧版规范自动废止。

11.2 责任划分

• 数据源负责人：负责确保数据源合法合规、格式规范，配合处理数据源相关异常；
• 运维人员：负责数据入湖任务部署、监控、异常处理，确保入湖流程正常运行；
• 开发人员：负责数据采集、转换、存储相关代码开发，遵循本规范设计表结构、命名、分层；
• 数据负责人：负责本规范的落地执行、修订、监督，确保数据入湖全流程符合规范要求。

附录A 落地问题统一答案（对应前置思考问题）

A.1 调研清单如何设计

分为三大模块：业务基础调研、字段敏感等级调研、采集技术调研，完整模板见2.2章节数据源接入前置调研清单，覆盖业务含义、数据量级、更新特征、敏感字段、同步延迟、分区需求全维度。

A.2 事实表维度表如何区分

• 事实表：存储业务流水、交易、变动行为记录，持续新增，优先增量采集；代表业务过程；
• 维度表：存储业务实体静态属性，更新频率低，支持全量/拉链采集；代表业务对象；详细判定标准见3.1章节。

A.3 更新方式：增量/全量/拉链哪种更好

无绝对最优，按需选择：

1. 流水事实表：优先增量_incr，存储成本最低；
2. 万级以内小静态维度：全量_full，查询最简单；
3. 金融风控需追溯实体历史状态维度：拉链_zip，完整记录生命周期。

A.4 分区方式：日分区/小时分区/不分区应用哪种范围最广

日分区dt=yyyy-MM-dd使用范围最广，覆盖90%离线批量业务；小时分区仅用于高吞吐实时日志；不分区仅限千级小字典、拉链主表。

A.5 业务数据需要流经哪些层级

所有业务数据强制完整流经链路：ODS→DWD→DWB→DWS→ADS，禁止跨层直接落地；明细停DWD，宽表DWB，汇总DWS，报表ADS。

A.6 主键、唯一键、更新依据字段是什么

1. 主键：表实体唯一标识，不可重复；
2. 唯一键：业务逻辑组合唯一（拉链表固定user_id+start_date）；
3. 更新依据字段：统一update_time毫秒时间戳，用于CDC增量变更判断。

A.7 是否需要脱敏、清洗规则

必须配置：

1. 清洗规则：DWD层统一过滤垃圾数据、补全空值、修正格式、剔除逻辑删除；
2. 脱敏规则：一级、二级敏感字段强制脱敏，提供统一UDF函数，脱敏规则归档留存。

A.8 是否需要宽表

下游多表频繁关联查询、日访问量大场景必须构建DWB宽表；一次性临时分析、单表独立取数无需宽表，判定标准见4.1.3章节。

A.9 数据保留周期多久

分层差异化生命周期，完整明细见9.1.1分层数据完整保留周期明细表，ODS最短30天活跃，拉链维度最长3年归档，超期自动销毁，合规数据可申请延期。

附录B 流程架构示例文本图

【数据入湖全流程架构图 文本版】
业务源端 → CDC/批量采集工具 → ODS原始层（仅编码转换）
        ↓
DWD明细层（清洗+脱敏+标准化）
        ↓
DWB宽表层（多明细主题关联拼接）
        ↓
DWS汇总层（日维度轻度聚合）
        ↓
ADS应用层（报表指标输出）
下游：自助BI、风控系统、算法平台、业务看板

监控链路：数据质量校验 + 元数据自动采集 + 全链路告警
管控链路：数据分级脱敏 + 权限审批 + 生命周期自动归档销毁

附录C 常用采集工具代码示例

C.1 DataX MySQL批量全量同步配置JSON

{
  "job": {
    "content": [
      {
        "reader": {
          "name": "mysqlreader",
          "parameter": {
            "username": "data_sync",
            "password": "xxxx",
            "connection": [
              {
                "table": [
                  "user_account_info"
                ],
                "jdbcUrl": "jdbc:mysql://127.0.0.1:3306/biz_account"
              }
            ],
            "column": ["*"]
          }
        },
        "writer": {
          "name": "hdfswriter",
          "parameter": {
            "defaultFS": "hdfs://hdfs-cluster",
            "fileType": "parquet",
            "path": "/user/hdfs/data/ods/ods_account_info_full/dt=${dt}",
            "column": [
              {"name":"user_id","type":"string"},
              {"name":"phone","type":"string"},
              {"name":"create_time","type":"string"},
              {"name":"update_time","type":"bigint"}
            ],
            "writeMode": "overwrite"
          }
        }
      }
    ],
    "setting": {
      "speed": {
        "channel": 8
      }
    }
  }
}

C.2 Flink CDC实时同步Flink SQL模板

CREATE TABLE mysql_account_source (
    user_id STRING PRIMARY KEY,
    phone STRING,
    id_card STRING,
    account_status TINYINT,
    create_time STRING,
    update_time BIGINT
) WITH (
  'connector' = 'mysql-cdc',
  'hostname' = '127.0.0.1',
  'port' = '3306',
  'username' = 'sync',
  'password' = 'xxxx',
  'database-name' = 'biz_account',
  'table-name' = 'user_account_info',
  'scan.startup.mode' = 'latest-offset'
);

CREATE TABLE dwd_account_info_incr (
    user_id STRING,
    phone STRING,
    id_card STRING,
    account_status TINYINT,
    create_time STRING,
    update_time BIGINT,
    data_source STRING,
    data_owner STRING,
    dt STRING,
    PRIMARY KEY (user_id, dt) NOT ENFORCED
) WITH (
  'connector' = 'hudi',
  'table.type' = 'MERGE_ON_READ',
  'path' = 'hdfs:///user/hdfs/data/dwd/dwd_account_info_incr',
  'precombine.field' = 'update_time',
  'partition.fields' = 'dt'
);

INSERT INTO dwd_account_info_incr
SELECT
    user_id,
    mask_phone(phone),
    mask_idcard(id_card),
    account_status,
    create_time,
    update_time,
    'mysql_biz_account' AS data_source,
    'data_owner_01' AS data_owner,
    DATE_FORMAT(TO_TIMESTAMP_LTZ(update_time, 3), 'yyyy-MM-dd') AS dt
FROM mysql_account_source;

大数据平台数据入湖落地场景示例

一、MySQL业务库批量T+1入湖场景（全量/增量）

场景1：商品基础档案维度表全量入湖（ods_goods_base_full、dwd_goods_base_full）

业务背景

商品基础表数据量5w条，每日新增/修改不足千条，下游需要每日完整商品快照用于报表、商品匹配，无需追溯历史下架记录。

采集方案

• 采集模式：全量_full，每日凌晨2点DataX全量抽取MySQL商品表
• 分区规则：日分区dt=同步日期
• 分层流转链路：MySQL源表 → ODS全量表 → DWD清洗全量表 → DWB商品宽表 → ADS商品基础报表

各层表示例

1. ODS层原始全量表：ods_goods_base_full
   • 仅统一编码UTF-8，不做任何清洗，保留原始字段、原始编码状态
   • 分区dt=2026-06-24，存储当日完整原始快照
2. DWD层清洗全量表：dwd_goods_base_full
   • 清洗逻辑：过滤is_delete=1逻辑删除商品；商品名称去首尾空格；统一商品分类编码；无敏感字段无需脱敏
   • 必带字段：create_time、update_time、data_source、data_owner、dt
3. DWB层宽表：dwb_goods_store_wide
   • 关联DWD商品表+门店维度表，拼接门店名称、仓库地址，避免下游重复关联
4. ADS层报表：ads_goods_daily_stat_full
   • 统计每日上架商品数、各分类商品数量，供运营看板直接查询

DataX同步配置核心逻辑

覆盖写入ODS当日分区，Insert Overwrite实现每日全新快照，适用于小体量静态维度表。

场景2：订单流水事实表增量实时入湖（dwd_order_detail_incr）

业务背景

线上交易订单，每秒数百笔订单写入MySQL，需要分钟级延迟实时统计销售额、订单量，留存每一笔交易明细用于对账。

采集方案

• 采集模式：增量_incr，Flink CDC监听MySQL binlog实时同步新增、更新订单
• 分区规则：日分区dt=订单创建日期，高并发时段追加小时分区辅助查询
• 分层流转链路：MySQL binlog → Kafka消息队列 → ODS增量原始层 → DWD明细增量层 → DWS每日订单汇总 → ADS交易实时看板

关键处理逻辑

1. ODS层ods_order_detail_incr：原样存储binlog原始JSON，不解析字段，用于故障回溯
2. DWD层实时明细：
   • JSON解析结构化字段；过滤测试环境订单；金额字段校验≥0；pay_type编码映射中文支付名称
   • 敏感字段：收件手机号、收件人姓名脱敏
   • Hudi MOR表，主键order_id，预合并字段update_time，支持实时upsert更新订单状态（待支付→已付款→已取消）
3. DWS层dws_order_day_incr：按dt、pay_type轻度汇总订单总额、订单笔数
4. ADS层ads_order_real_time_stat_full：推送到OLAP引擎，前端大屏实时展示交易指标

二、金融维度历史追溯拉链入湖场景（账户用户表拉链dwd_user_account_zip）

场景背景

金融账户业务，用户可修改手机号、解绑银行卡、冻结销户，风控、对账需要任意时间点账户状态，不能丢失历史变更记录。

采集方案

• 采集模式：拉链_zip，每日基于当日增量更新拉链表
• 分区规则：拉链主表不分区，单表存储全量历史账户状态
• 流转链路：MySQL账户表CDC增量 → ODS增量 → DWD增量明细 → DWD拉链主表

拉链核心逻辑示例

1. 当日新增用户：start_date=当日dt，end_date=9999-12-31
2. 用户修改手机号：原有记录end_date=前一日dt，新增一条新记录start_date=当日，end_date=9999-12-31
3. 用户销户：最新有效记录end_date=销户当日，无新增有效记录

表核心字段

user_id(主键)、phone(脱敏)、account_bank_no(脱敏)、account_status、start_date、end_date、create_time、update_time、data_source、data_owner

使用场景

风控查询2026-05-01当天用户账户状态：筛选start_date <= ‘2026-05-01’ AND end_date >= ‘2026-05-01’，精准还原历史快照。

三、用户行为日志半结构化实时入湖场景（埋点日志JSON）

场景背景

APP/小程序前端埋点行为日志（点击、浏览、下单、收藏），原始数据为JSON半结构化日志，每秒万级吞吐，用于用户画像、流失分析、渠道转化统计。

采集方案

• 数据源：Nginx日志/前端埋点上报 → Kafka实时队列
• 采集模式：实时增量_incr
• 分层链路：Kafka原始日志ODS → DWD解析明细 → DWS用户行为日汇总 → ADS画像标签报表

分层处理细节

1. ODS层ods_user_click_log_incr
   • 原样存储原始JSON字符串，保留日志时间、设备号、渠道号，不做解析
   • 按dt+hour小时分区，方便实时按小时排查日志丢失问题
2. DWD层dwd_user_click_log_incr
   • 转换逻辑：解析JSON提取user_id、event_name、page_id、device_id、operate_time；过滤空user_id测试日志；设备标识脱敏
   • 统一时间格式yyyy-MM-dd HH:mm:ss，毫秒时间戳标准化
3. DWS层dws_user_behavior_day_incr
   • 按用户、日期、行为事件汇总点击次数、停留时长，生成轻度聚合数据
4. ADS层ads_user_channel_conversion_full
   • 多维度汇总各渠道曝光、点击、下单转化漏斗数据，供产品分析使用

四、非结构化文件对象存储入湖场景（图片/合同PDF）

场景背景

电商商品主图、金融电子签约PDF合同、用户上传凭证图片，无固定结构化字段，需要统一归档并绑定业务元数据。

接入方式

MinIO对象存储直写入湖，文件路径分层：业务主题/数据源/日期/文件类型
示例路径：

minio://data-lake/goods/image/2026-06-24/main_pic_10001.png
minio://data-lake/finance/contract/2026-06-24/sign_contract_8921.pdf

配套元数据表dwd_file_meta_incr

每条文件对应一条结构化元数据记录，关键字段：
file_path、file_name、file_type、file_size、business_id（商品ID/账户ID）、upload_time、data_owner、dt

管控规则

1. 含身份证、人脸的合同PDF加密存储，一级敏感文件访问强制双人审批
2. 生命周期：活跃期90天高性能对象存储，超过90天迁移低成本归档存储，留存1年后无业务申请自动销毁

五、离线日志批量文件入湖场景（服务器系统日志CSV）

场景背景

业务服务器每日输出系统运行日志CSV文件，凌晨定时上传至HDFS，用于运维监控、异常排查。

采集方案

Sqoop/脚本批量拉取文件每日一次全量同步，采集模式增量_incr，按dt日分区。

处理规范

1. ODS层保留原始CSV分隔格式，不修改原始文件内容
2. DWD层清洗：过滤空行、错误乱码日志，拆分日志字段（服务名、错误码、报错信息、发生时间）
3. 数据质量校验：每日校验日志文件行数，与服务器日志生成行数差值超过0.5%触发告警

六、多源融合宽表落地场景（DWB层业务宽表）

场景背景

交易分析报表每次查询需要关联订单、用户、商品、支付4张DWD明细表，单次查询耗时久、资源消耗大，构建主题宽表简化下游查询。

宽表名称：dwb_order_user_goods_wide

构建逻辑

每日基于DWD订单增量、用户拉链快照、商品全量、支付明细4表JOIN，生成当日全量宽表

下游使用场景

1. ADS交易报表直接读取宽表，无需多表关联，查询速度提升80%
2. 算法样本取数直接从宽表抽取用户-订单-商品完整特征，减少重复开发关联逻辑

限制规则

仅同一业务域内表关联，禁止跨业务大表拼接（如订单+人事、订单+供应链分开建宽表）

七、实时指标ADS输出至业务系统场景

场景背景

业务后台运营系统需要T+0实时订单、余额统计数据，不直接开放DWS明细给业务系统，通过ADS层标准化报表输出。

流程

Flink实时计算DWS汇总数据 → ADS层ads_biz_real_time_index_full → 同步至MySQL业务中间库

管控要求

1. ADS层输出前强制全量数据质量校验，异常数据禁止写入业务库
2. 敏感指标（账户余额、交易总额）访问单独权限审批，操作日志留存1年
3. 每日凌晨全量校验ADS数据与底层DWD明细数据一致性，修复统计偏差