第4章 埋点数据校验与清洗SOP：字段完整性校验、格式标准化、脏数据隔离

4.1 适用场景

本章SOP适用于以下数据处理阶段：

• 埋点数据接入层：客户端/服务端原始埋点日志进入数据管道后的第一个处理环节。
• 实时/离线ETL前置：在进入核心ETL任务之前，对原始数据进行统一质检与清洗。
• 数据仓库ODS层加载前：将校验清洗后的标准数据写入ODS，脏数据路由至隔离区。
• 数据质量事故复盘：当下游报表或模型出现异常时，回溯校验与清洗环节的日志和隔离记录。

4.2 前置条件

1. 埋点元数据字典：已完成当前业务线所有埋点事件的字段定义、数据类型、必填标识、枚举值范围的归档。
2. 校验规则配置表：在元数据中心或配置中心维护好 field_validation_rules 表，包含字段名、校验类型（not_null / type_match / enum_check）、阈值等。
3. 数据管道可用：原始埋点数据以 JSON/Parquet 形式持续写入暂存区（Kafka Topic / HDFS 临时目录），且分区键与时间戳对齐。
4. 隔离区存储就绪：已创建脏数据隔离区（如 HDFS 路径 /dirty_data/${date} 或 Kafka 死信队列），并配置生命周期策略（默认保留30天）。
5. 监控告警通道：已对接邮件/钉钉/企业微信机器人，用于脏数据率超过阈值时的实时告警。

4.3 操作步骤

下图展示了从原始埋点到清洗后数据的完整流程，包含三个核心处理阶段：

4.3.1 字段完整性校验

对每条原始埋点记录执行以下校验规则：

1. 必填字段非空检查：检查事件ID、用户ID、时间戳、事件名称等核心字段是否缺失或为空字符串。
2. 字段类型匹配：确认字段值的数据类型与元数据定义一致（如 user_id 应为字符串，timestamp 应为长整型）。
3. 枚举值范围校验：对于枚举字段（如 platform、event_type），校验值是否在允许列表中。
4. 嵌套结构完整性：对于JSON嵌套字段（如 properties），检查子字段是否存在且类型正确。

校验规则配置示例：

{
  "event_id":       { "required": true,  "type": "string", "nullable": false },
  "user_id":        { "required": true,  "type": "string", "nullable": false },
  "timestamp":      { "required": true,  "type": "int64",  "nullable": false, "range": [1600000000000, 1999999999999] },
  "event_name":     { "required": true,  "type": "string", "enum": ["page_view", "click", "purchase", "login"] },
  "platform":       { "required": false, "type": "string", "enum": ["web", "ios", "android", "miniapp"] },
  "properties":     { "required": false, "type": "json",   "nested": { "product_id": {"type": "string"} } }
}

4.3.2 格式标准化

对通过完整性校验的数据执行格式统一操作：

字段类别	标准化规则	示例
时间戳	统一为Unix毫秒时间戳（UTC+0），精度丢失时补零	1617235200000
字符串编码	强制转换为UTF-8，去除BOM头及不可见控制字符	"\u4e2d\u6587" → "中文"
数值精度	浮点数统一保留2位小数，金额字段使用分作为单位（整数）	19.9900 → 1999（分）
枚举值映射	将同义异写值映射为标准枚举（如 "ios" / "iOS" / "IOS" → "ios"）	"IOS" → "ios"
用户ID归一	去除前后空格，统一为小写，匿名ID与登录ID建立关联标记	" USER_123 " → "user_123"

4.3.3 脏数据检测与隔离

经过格式标准化后，对每条记录执行脏数据判定：

• 判定规则：若字段值存在逻辑异常（如时间戳为未来时间、金额为负数、用户ID格式不合法），或标准化过程中发现不可修复的格式错误，标记为脏数据。
• 隔离操作：将脏数据写入隔离区存储，同时记录原始载荷、校验失败原因、检测时间戳、数据源标识。
• 正常数据：通过所有检测的记录进入下游ETL管道，写入ODS层。

脏数据隔离记录格式示例：

{
  "dirty_record_id":   "dirty_20250121_10001",
  "original_payload":  {"event_id":"...", "user_id":"...", "timestamp":-1, ...},
  "failed_rules":      ["timestamp_out_of_range", "user_id_format_error"],
  "detected_at":       1705824000000,
  "source_topic":      "user_behavior_raw",
  "partition":         3,
  "offset":            20456,
  "status":            "pending_review"
}

4.4 输入输出物

类型	名称	说明	来源/去向
输入	原始埋点数据	来自客户端/服务端的JSON或Parquet格式日志	Kafka Topic / HDFS暂存区
输入	校验规则配置表	字段级校验规则，支持热加载	元数据中心 / 配置中心
输入	格式映射字典	枚举值映射、时间格式模板、编码转换规则	数据标准库
输出	清洗后标准数据	通过完整性校验、格式标准化、脏数据检测的干净数据	写入ODS层 / 下游ETL
输出	脏数据隔离记录	包含原始载荷、失败原因、检测元数据的隔离日志	HDFS脏数据区 / 死信队列
输出	校验与清洗运行报告	包含通过率、失败分布、处理耗时、隔离数据量	调度系统 / 监控看板

4.5 责任边界

角色	职责	输出物
数据工程师	编写/维护校验规则脚本、格式标准化UDF、脏数据隔离管道；处理告警与异常	清洗代码、调度配置、告警处理记录
数据质量专员	审核脏数据采样、推动来源修复、定期输出质量报告	脏数据复盘报告、修复工单
数据产品经理	定义业务级校验标准（如核心事件必填字段、枚举值范围）、审批规则变更	校验规则变更申请、元数据字典更新
数据架构师	设计校验与清洗架构、制定隔离策略、评审技术方案	架构设计文档、技术评审纪要

4.6 记录材料

每次校验与清洗任务执行后，需自动生成并归档以下记录：

1. 字段完整性校验报告：包含总记录数、缺失字段分布TOP10、必填字段通过率。
2. 格式标准化处理日志：记录每条记录的格式转换操作（如时间戳重写、枚举映射、编码转换），便于问题回溯。
3. 脏数据隔离台账：按数据源、失败类型、时间段聚合的脏数据明细表，支持按状态（待审核/已修复/已废弃）筛选。
4. 任务运行监控记录：包含启动时间、结束时间、处理速率、内存/CPU峰值、是否触发告警。

所有记录材料应至少保留 90天，用于审计和质量回溯。

4.7 异常处理

异常场景	影响	应急措施	修复方案
校验规则配置错误导致大量正常数据被拦截	下游数据延迟、报表缺失	立即回滚至上一版本规则配置，恢复数据管道	修复规则并灰度验证后重新发布
格式标准化UDF抛出运行时异常	清洗任务中断，数据堆积	跳过异常字段并写入脏数据区，任务继续运行	修复UDF后重跑脏数据
脏数据隔离区存储写满	新脏数据无法写入，管道阻塞	临时扩容隔离区或触发自动清理策略（删除超过30天数据）	评估隔离区容量并调整生命周期策略
元数据字典与真实埋点字段不一致	校验误报或漏报	暂停该事件的校验流程，人工比对后更新字典	建立元数据版本管理与变更通知流程

4.8 验收标准

本章SOP执行效果通过以下指标验收：

• 字段完整性校验通过率 ≥ 99.5%（基于近7天滚动统计）。
• 格式标准化覆盖率 100%（所有进入清洗管道的数据必须经过格式标准化，不允许跳过）。
• 脏数据检测召回率 ≥ 98%（人工抽检脏数据区，确认被正确隔离的比例）。
• 脏数据隔离及时性 从数据到达清洗层到完成隔离写入，P99 耗时 ≤ 5 分钟。
• 异常告警响应率 100%（所有触发告警的异常均在15分钟内得到人工确认或自动处理）。
• 记录材料完整性 每次任务执行均生成三项核心记录（校验报告、处理日志、隔离台账），归档率 100%。