大数据平台数据入湖规范

大数据平台数据入湖规范

第一章 总则

1.1 目的

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

1.2 适用范围

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

1.3 核心原则

• 标准统一：统一数据命名、格式、分层、编码，避免"同数不同名、同名不同数"，确保数据一致性；

• 质量优先：入湖数据必须经过质量校验，不符合标准的数据不得入湖，确保数据准确、完整、可用；

• 安全合规：遵循数据安全法、个人信息保护法，落实敏感数据脱敏、权限管控，防范数据泄露；

• 高效可扩展：兼顾数据入湖效率与平台扩展性，支持多源异构数据接入，适配业务增长需求；

• 可追溯可管控：全流程记录数据血缘、操作日志，实现数据从源头到入湖的可追溯、可审计；

• 按需存储：根据数据价值、访问频率，合理划分存储层级，优化存储成本，避免冗余。

  第二章 数据源接入规范

  2.1 数据源分类

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

• 结构化数据：业务数据库（MySQL、Oracle等）的表数据（如账户表、订单表）、Excel/CSV等结构化文件，需明确主键、字段类型、编码格式；

• 半结构化数据：JSON、XML、日志文件（如用户行为日志），需明确数据格式、字段含义，确保字段可解析；

• 非结构化数据：图片、音频、视频、文档等，需统一存储格式，标注元数据信息（如文件名称、大小、创建时间、来源）。

  2.2 数据源接入要求

• 接入前提：数据源需经业务部门确认，明确数据所有权、使用范围，签订数据接入协议，确保数据来源合法合规；

• 接入方式：结构化数据优先采用CDC工具（如Debezium、Flink CDC）实现实时同步，批量数据采用定时抽取（如Sqoop、DataX），非结构化数据采用对象存储（如HDFS、MinIO）接入；

• 编码要求：所有入湖数据编码统一为UTF-8，避免中文乱码；日期格式统一为"yyyy-MM-dd HH:mm:ss"，时间戳统一为毫秒级；

• 异常处理：数据源中断、数据格式变更时，需及时触发告警，通知数据源负责人及数据入湖运维人员，暂停入湖操作，排查问题后再恢复。

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

  3.1 采集模式规范

  根据数据更新频率、业务需求，明确采集模式（增量/全量/拉链），采集模式需在表设计阶段前置确定，具体要求如下：

  3.1.1 增量采集（_incr）

• 适用场景：事实表（如订单表、流水表）、高频更新的维度表（如账户表），仅采集当日新增/变更的数据；

• 采集规则：基于更新时间（update_time）、自增ID等字段，每日定时采集或实时采集，确保不重复、不遗漏；实时入湖场景需控制时延，单表TPS可支持万级，端到端时延控制在分钟级；

• 存储要求：增量表需按dt（数据日期）分区，仅存储当日变动数据，数据量控制在合理范围，便于后续更新全量、拉链表。

  3.1.2 全量采集（_full）

• 适用场景：维度表（如商品表、机构表）、数据量较小的业务表，需每日保留全量最新数据快照；

• 采集规则：每日定时全量抽取数据源所有数据，覆盖前一日全量数据，采用Truncate+Insert或Insert Overwrite方式更新；

• 存储要求：全量表需按dt（同步日期）分区，每日保留一份完整快照，便于下游直接查询最新数据。

  3.1.3 拉链采集（_zip）

• 适用场景：需追溯历史状态的维度表（如账户表、用户表），尤其是金融、风控、对账场景，需记录数据从生效到失效的全生命周期；

• 采集规则：基于增量数据，每日更新拉链表，新增数据生效时间（start_date）设为当日，失效时间（end_date）设为"9999-12-31"；变更数据需关闭历史记录（将end_date设为前一日），新增最新记录；

• 存储要求：拉链表不做日分区，为一张全量历史表，需包含start_date、end_date两个必选字段，确保历史状态可追溯。

  3.2 数据转换规范

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

• 数据清洗：剔除测试数据、垃圾数据、逻辑删除数据，过滤重复数据、空值异常；补全缺失字段（如默认值填充），修正格式错误（如日期格式、编码格式）；

• 字段标准化：统一字段名称（如用户ID统一为user_id，不使用uid、u_id）、字段类型（如手机号统一为字符串类型）、状态编码（如账户状态1=正常、2=冻结、3=销户）；

• 敏感数据脱敏：手机号、身份证号、银行卡号等敏感数据，入湖前必须脱敏处理（如手机号保留前3位+后4位，身份证号保留前6位+后4位），脱敏规则统一制定并留存；

• 数据关联：关联字典表、基础表，补全编码对应的名称（如pay_type=1补全为"微信支付"），确保数据可理解；

• 格式转换：半结构化数据（如JSON）需解析为结构化字段，非结构化数据需提取关键元数据，统一存储格式。

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

  4.1 数据分层标准

  数据湖按业务职责、数据加工程度，分为5层，分层需前置判断，严格遵循"ODS→DWD→DWB→DWS→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层（宽表数据层）

• 作用：将同一业务主题的多张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 表结构设计规范

• 前置判断：建表前需明确表类型（事实表/维度表）、更新方式（增量/全量/拉链）、分层、主键/唯一键，避免后期修改；

• 字段设计：字段名称简洁明了，采用小写字母+下划线命名，避免使用关键字；字段类型合理（如手机号用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.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个月，便于追溯排查。

  第八章 数据安全规范

  8.1 数据分级分类

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

• 一级（高度敏感）：身份证号、银行卡号、手机号、密码、生物识别信息等，需严格脱敏、加密存储，仅授权人员可访问；

• 二级（中度敏感）：用户姓名、地址、邮箱、账户余额、交易流水等，需脱敏处理，访问需授权并记录操作日志；

• 三级（一般敏感）：非个人信息类数据（如商品分类、订单状态编码、机构名称等），可正常存储，访问需符合平台权限要求。

  8.2 数据脱敏与加密

• 脱敏要求：所有高度、中度敏感数据，在ODS层采集后、DWD层转换前完成脱敏，脱敏规则统一制定，不得随意修改；脱敏后的数据需保留业务可用性，不得影响下游分析使用；

• 加密存储：敏感数据存储时采用AES-256加密算法，加密密钥统一管理，定期更换；非结构化敏感数据（如含个人信息的文档），需加密后再存储；

• 传输加密：数据从数据源到数据湖、数据湖内部流转、数据湖到下游应用的传输过程，采用SSL/TLS加密，防止数据传输过程中泄露。

  8.3 权限管控

• 权限分级：按"最小权限原则"，将权限分为管理员、运维人员、开发人员、业务分析人员四级，不同级别人员拥有对应操作权限，不得越级访问；

• 权限申请与审批：访问数据湖数据需提交权限申请，明确访问范围、访问目的、访问期限，经数据所有者及管理员审批通过后，方可授予权限；权限到期后自动回收，需延续访问的需重新申请；

• 操作审计：所有访问、修改、删除数据湖数据的操作，均需记录详细日志（包括操作人员、操作时间、操作内容、操作结果），日志留存期限不少于1年，便于安全审计和问题追溯。

  8.4 合规要求

• 遵循《中华人民共和国数据安全法》《中华人民共和国个人信息保护法》等法律法规，不得采集、存储、使用非法来源数据；

• 个人信息类数据入湖前，需确认已获得用户授权，明确数据使用范围，不得超出授权范围使用；

• 定期开展数据安全合规检查，排查安全隐患，及时整改问题，确保数据入湖、存储、使用全流程合规。

  第九章 数据生命周期管理规范

  9.1 生命周期划分

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

  9.1.1 活跃期

• 定义：数据处于高频访问、频繁使用的阶段，需保证查询性能和数据可用性；

• 期限：ODS层增量表、DWD层增量表活跃期30天；DWD层全量、拉链表、DWB层宽表活跃期90天；DWS层、ADS层数据活跃期180天；

• 存储要求：活跃期数据存储在高性能存储介质（如SSD），确保快速访问。

  9.1.2 归档期

• 定义：数据访问频率降低，但仍有留存价值（如用于历史追溯、合规审计），需低成本存储；

• 期限：ODS层、DWD层数据归档期1-3年；DWS层、ADS层数据归档期1年；非结构化数据归档期根据业务需求确定（不少于1年）；

• 存储要求：归档期数据迁移至低成本存储介质（如HDFS归档节点、对象存储归档层），压缩存储，降低存储成本，保留查询能力。

  9.1.3 销毁期

• 定义：数据无留存价值，且符合销毁条件，需安全销毁，避免数据泄露；

• 销毁条件：超过归档期、无业务需求、无合规留存要求的数据；

• 销毁要求：采用物理删除+逻辑删除结合的方式，确保数据无法恢复；销毁过程记录日志，留存销毁凭证，销毁日志保存不少于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 责任划分
• 数据源负责人：负责确保数据源合法合规、格式规范，配合处理数据源相关异常；
• 运维人员：负责数据入湖任务部署、监控、异常处理，确保入湖流程正常运行；
• 开发人员：负责数据采集、转换、存储相关代码开发，遵循本规范设计表结构、命名、分层；
• 数据负责人：负责本规范的落地执行、修订、监督，确保数据入湖全流程符合规范要求。

问题思考：

• 调研清单如何设计 ？
• 事实表维度表如何区分 ？ --》 事实表：流水、交易、变动记录（增量为主）
• 更新方式：增量 / 全量 / 拉链 哪种方式更好 ？ --》 事实表：流水、交易、变动记录（增量为主）
• 分区方式：日分区 / 小时分区 / 不分区 应用哪种范围最广 ？
• 业务数据需要流经哪些层级：ODS/DWD/DWB/DWS/ADS？
• 主键、唯一键、更新依据字段是什么？
• 是否需要脱敏、清洗规则？
• 是否需要宽表？
• 数据保留周期多久？