完整题目
面对大规模业务场景下的原始数据（如用户行为日志、交易记录等），如何设计自动化流程进行高质量的数据清洗？请说明关键步骤（去重、异常值处理、格式标准化、缺失值填充等）及技术实现方案。
大规模清洗要以数据契约、精确主键和可回放状态为核心
入口建立数据契约和不可变原始层，记录 source、schema_version、event_time、ingest_time、event_id 与血缘。精确去重应优先使用上游生成的不可变 event_id，或由稳定业务键与规范化载荷构成幂等键；“用户 ID 加时间戳”在重试、并发和时间精度冲突下不能通用保证唯一。权威存储保存已处理 ID 或最终实体版本。
Bloom Filter 是近似成员查询结构，可能把从未见过的事件判断为“可能存在”。因此它只能作为预筛：判断不存在时可快速放行，判断可能存在时还要查精确状态；若直接丢弃命中项，会因假阳性误删新事件。Flink keyed state 可按去重键记忆已见事件，但窗口与 TTL 代表有限保留范围，过期后同一 key 会再次被视为新事件，所以必须明确业务去重范围、迟到数据和补数策略。
格式标准化统一编码、时区、单位、枚举和字段类型；异常值按物理约束、业务规则和分位统计识别，并区分真实极端值与错误；缺失值应标记缺失原因，按下游用途选择保留、填充或剔除，避免把填充值冒充事实。流程还要有 quarantine、质量指标、幂等写入、checkpoint、重放和数据版本。上线监控重复率、解析失败、规则拒绝、迟到量、状态规模和下游对账差异，并按来源切片抽检。
继续追问 · 3 个问题
- 如何平衡清洗的严格程度和数据保留率，避免过度清洗导致样本偏差？
- 实时流处理和离线批处理的清洗策略有何不同，如何统一？
- 如何评估清洗后的数据质量，建立反馈闭环？
换一种问法，检查是否真正理解
场景切入
假设你在做电商订单的实时风控，每天几亿条用户行为日志进来，里面经常有重复点击、时间戳乱填、字段缺失的情况。你怎么自动化地把它洗干净，保证下游模型拿到的数据靠谱？
层层追问
你平时处理大规模数据时，怎么保证数据质量？……数据量一上来，去重和异常检测怎么搞？……比如用户行为日志，去重键怎么选？异常值你是直接扔掉还是标记？
直球架构
设计一个面向百亿级日志的数据清洗流水线，需要覆盖去重、异常值处理、格式标准化和缺失值填充，关键步骤和技术实现方案是什么？
练习口述回答 · 30秒速答 + 90秒主答 + 完整展开
- 从数据契约和不可变原始层开始
- 用 event_id 与权威状态做精确去重
- 限定 Bloom Filter、窗口和 TTL 边界
- 处理异常、缺失和标准化
- 通过隔离、重放和对账保障质量
【30秒速答】 大规模清洗先建立数据契约和不可变原始层，再做标准化、去重、异常与缺失处理。精确去重优先依赖上游不可变 event_id 或稳定幂等键，用户 ID 加时间戳不能保证唯一。Bloom Filter 有假阳性，只能预筛，命中后仍查权威存储。Flink keyed state 要明确 key、窗口、TTL、水位线和迟到策略，TTL 过期后并非永久记住历史。所有拒绝数据进入隔离区，处理作业可重放，最终用下游对账和质量指标验收。
【90秒主答】 接入层为每条记录保留 source、schema_version、event_time、ingest_time、event_id 和原始载荷，原始层只追加，解析失败不静默删除。格式层统一编码、时区、单位、枚举和字段类型，并对 schema 变更做兼容检查。去重先定义语义：是同一次采集重试、同一业务事件，还是同一实体的多次更新。最理想是生产者生成不可变 event_id；没有时才用订单号、事件类型、业务版本和规范化载荷构造稳定幂等键。用户 ID 与时间戳会受到并发、时间精度、设备时钟和重放影响，不能作为通用精确键。Bloom Filter 返回“不存在”时适合快速放行，返回“可能存在”必须去精确 KV 或数据库确认，否则假阳性会把新事件当重复删掉。
【完整展开】 流式方案可按 event_id keyBy，在 Flink keyed state 中保存已处理状态并借助 checkpoint 恢复。状态保留不是免费资源，设置窗口或 TTL 后要明确语义：只保证某个时间范围内去重，过期事件再次到达可能被接受。水位线、allowed lateness、旁路输出和补数流程决定迟到事件如何处理。若业务要求永久全局去重，应把精确 ID 落到可长期查询的权威存储，流状态只做近期加速。写入下游使用幂等 upsert 或事务键，避免处理器重启造成二次效果。
异常处理把数据错误与真实极端值分开。金额、年龄、时间顺序可用业务约束，连续特征可用稳健统计提供候选，但自动截断必须验证对任务影响。缺失值保留 missing reason，区分未采集、不适用、解析失败和延迟到达；填充策略按训练、报表或交易用途分别设计，并保留指示变量。每一步输出输入量、通过量、隔离量、原因码和样本，监控重复率、解析失败、规则违例、迟到量、状态大小、checkpoint 健康和源端到下游对账。版本化代码、schema 和参考数据，使任一批次都能从原始层重跑。这样精确性由权威状态保证，概率结构与流状态只承担明确范围内的性能优化。