数据质量阈值怎么定？固定波动百分比为什么总误报？
面试怎么回答
我会把硬性数据约束和统计波动监控分开。主键重复、必需分片缺失等可以直接按规则判断；行数和金额波动则选择同星期或活动阶段基线，结合数据成熟度、历史异常和低基数处理。异常后再用链路证据区分业务变化与数据故障，按影响分级并明确责任人。阈值需要回测误报漏报，不能所有表套同一个环比百分比。
先把这段讲顺；面试官追问时，再展开下面的原理和细节。
详细讲解
每到周末订单量都会下降，监控也准时报警。值班同学逐渐学会忽略它，等真正漏了一半数据时，告警又淹没在同一批消息里。问题不是监控太少，而是阈值没有理解业务的正常节奏。
质量阈值应结合业务约束、可比周期和数据成熟度；统计异常是调查线索，不是数据错误的自动判决。
有些规则不需要预测，有些规则必须理解周期
同一主键不应重复、必需分片不能缺失、合法枚举不能出现未知编码，这些属于确定性约束，通常不需要先拟合历史曲线。
订单量、消耗和活跃人数则会随星期、节假日、活动和业务规模变化。昨天与今天未必可比，固定环比阈值很容易在正常周期里频繁触发。
不要把两类规则塞进同一种异常分数。确定性错误可以直接给出违反了哪条约定；统计偏离更适合作为需要调查的线索。
比较基线应与业务节奏匹配
周末波动明显的表，可以比较历史同星期；活动驱动的表，可以比较相同活动阶段；新业务与成熟业务也不宜共用同一量级基线。
历史基线要排除已知故障和明显不可比期间，否则过去的坏数据会变成未来的正常标准。规则版本和排除原因应留下记录，避免人为调整后无法解释。
低基数尤其要单独处理。昨天两单、今天一单，下降50%并不一定值得最高级别告警；大业务下降很小比例，也可能已经影响大量金额。
可以结合绝对差和相对差，但阈值应由影响与容忍范围确定，而不是把两个随意数字相乘后宣称科学。
数据还没到齐，先别急着判断业务下滑
上午九点的数据与昨天全天数据直接比较，异常几乎必然出现。即使都是上午九点，上游延迟不同，也可能造成暂时不可比。
应同时记录输入完成标记、已到分片和处理延迟。对于未成熟数据，可以标记等待、延迟风险或暂估，不要直接判定业务减少。
这也意味着行数看起来正常不代表数据健康。如果部分渠道缺失、另一部分渠道重复，总量可能刚好抵消，所以监控应覆盖关键维度和业务键，而不只有总行数。
一个典型场景：放宽阈值后，真正漏数更难发现
比如周末经常下降，团队把所有日期的阈值不断放宽，误报确实减少。随后一个工作日上游漏掉某渠道，下降幅度落在新阈值以内，没有触发。
最初认为故障波动不够大，实际根因是用统一宽阈值解决季节性误报，牺牲了工作日的检测能力。旧验收只数告警量是否下降，没有回测历史故障能否被发现。
修复应按可比周期建立基线，并为渠道覆盖设置独立完整性规则。再回放已知正常日和故障日，分别观察误报与漏报，而不是只追求安静。
异常之后，必须有人知道该做什么
告警应附带当前值、基线、比较范围、成熟度、异常维度和样本入口。只有“数据异常”四个字，会把解释工作全部转给值班人员。
优先级可以参考影响范围、金额、时效和是否阻断下游；责任人应知道先看源端业务变化还是采集链路。促销结束导致真实下降，不应该被反复要求重跑ETL。
阈值调整也要留审计记录。短期豁免应有到期时间，不能因为一次活动临时关闭规则，半年后仍然没人记得恢复。
没有历史样本的新表，可以先使用业务硬约束和观察模式，逐步积累基线；不要伪造一个看起来精确的统计阈值。
好的质量监控不是每天都红，也不是永远不红，而是在重要异常出现时，给出足够证据让人迅速做对判断。