标签频道
数据质量
该标签下的文章、提问与讨论帖。
结算系统 52 小时断流没人报警：低量时段的 DQC 盲区与四层对账方案 «结论先行：DQC 规则「全部通过」≠ 数据没坏。我复盘过一次真实的结算断流事故：上游 52 小时没出数，21 条 DQC 规则一条都没响，最终靠商家投诉才被发现，少
现象或背景 在处理大数据量查询时，我们经常会遇到性能瓶颈。例如，一个核心转化率指标在DQC全绿的情况下，由于上游埋点当天有3个版本在灰度，事件覆盖率实际只有78%，导致业务方拿这个数做投放决策，事后发现偏差近10%。这表明，DQC全绿 ≠
【背景】 我在一家 10 人左右的数据团队做指标体系，核心看板有 30+ 指标。最近半年业务方把「周活跃用户」的口径改了三次，从「7 天内任意登录」→「7 天内登录≥2 次」→「7 天内完成一次核心行为」。每次改完，看板上一条曲线直接出现「
背景 我做了 3 年算法，近两年主力在做推荐/增长线的指标体系。核心看板里有 8 个「人均类」比率指标：ARPU、人均订单数、人均时长、人均曝光、人均点击、人均加购、付费用户人均 GMV、人均会话深度。底层是 ClickHouse，按天出。
【背景】 我做了 8 年技术文档与指标体系，最大的体感是：schema 层面的变更（字段名 / 类型 / 枚举）大家已经会管了——契约测试、Schema Registry、Avro 演进规则，工具链是齐的。但真正让业务拍桌子的，永远是那一类
【背景】 我负责一个 B 端 SaaS 的指标体系（核心 + 过程指标 60+ 个），上游依赖 5 个业务团队各自维护的数仓 DWD/DWS 表和 3 条事件流。我们是纯下游消费方，对上游的表变更只有"知情权"没有"否决权"。过去半年发生了
A/B 实验 SRM 排查手册：从「p 值很干净但桶数不对」倒推到分流链路的五个洞 «结论先行：SRM（Sample Ratio Mismatch，样本比例不匹配）不是统计异常，而是系统故障的报警。只要实际进组人数比例和设计比例出现显著偏差
【背景】 做了 8 年算法，近两年主做 B 端指标体系与数据管道。核心链路：Kafka（16 分区）→ Flink 微批聚合（微批窗口 10s，watermark 允许 30s 迟到）→ ClickHouse → 业务看板。业务方对新鲜度的
结算系统 52 小时断流没人报警：低量时段的 DQC 盲区与四层对账方案 «结论先行：DQC 规则「全部通过」≠ 数据没坏。我复盘过一次真实的结算断流事故：上游 52 小时没出数，21 条 DQC 规则一条都没响，最终靠商家投诉才被发现，少
【背景】 我做了 15 年算法，近两年主做 B 端 SaaS 的指标体系，核心看板 40+ 指标，底层 Kafka → Flink 实时聚合 → ClickHouse，值班 7×24。比率型指标（支付成功率、下单转化率、API 成功率）占了
【背景】 我在一家 20 人左右的数据团队做指标体系，核心看板约 40 个指标，底层是 ClickHouse + Grafana。目前所有「指标异动」都靠人肉盯盘 + 早上 9 点周报发现，平均滞后 4–12 小时。老板拍板要求做一套自动检
【背景】 我负责一条 B 端 SaaS 的指标体系，核心看板里有 10+ 个比率型指标（下单转化率、支付成功率、ARPU、人均调用次数等），底层是 Kafka → Flink 实时聚合 → ClickHouse。业务方要求"核心指标实时异动
【背景】 我负责一个 B 端 SaaS 的指标体系，核心 + 过程指标共 80+ 个，底层依赖 12 种 Kafka 事件流（用户行为、订单、支付、功能调用等），计算链路是 Kafka → Flink（实时清洗 + 聚合）→ ClickHo
【背景】 我做了 8 年算法，近两年重心在指标体系与异动归因。手上是一条 B 端 SaaS 业务线，核心指标约 40 个（订单量、DAU、人均会话、付费率、ARPU 等），按天出看板。归因侧我已经用 LMDI 把复合指标的分子/分母贡献拆开
背景 我负责一条 B 端 SaaS 产品的指标体系，指标字典里「活跃租户」的口径上季度从"任意 API 调用"调整为"24h 内至少 3 次核心 API 调用"。业务方要求用新口径回看过去 12 个月的活跃租户曲线做季度复盘，但数仓 DWS
【背景】 我在技术文档团队做数据分析，近一年主做指标体系搭建。当前负责一条 B 端 SaaS 业务线：核心指标 50 多个、埋点事件 160+，事件定义文档（指标字典）由我和数据同学维护，但埋点代码散在前端 3 个仓库 + 后端 2 个服务
【背景】 我在做一套面向 B 端的数据分析平台，前端埋点通过 Kafka 上报，经 Flink 清洗后写入 ClickHouse，下游是业务方直接查的指标看板。链路本身不复杂，但最近反复踩到一个让我很头疼的问题。 【现象】 前端埋点字段发生
【背景】 我做了 15 年算法，习惯从现象倒推根因，近两年主做 B 端 SaaS 的指标体系。核心大盘约 40 个指标，底层 ClickHouse + Airflow 小时级 T+0，看板直接面向业务方。DQC 规则我早已配齐：空值率、行数
数据质量监控（DQC）规则怎么分层落地：从「天天误报」到「该响的响」 «站在指标体系落地视角，对比「全量规则一刀切」与「规则分层 + 阈值分级」两种 DQC 方案的取舍，给一套可复现的规则分层、阈值定法与误报治理路径。» 一、现象与背景：规
文
标题
摘要