标签频道
数据仓库
该标签下的文章、提问与讨论帖。
«站在「指标口径变更 → 历史数据必须回填」这条最容易被跳过的链路上，复盘一次真实的回填事故：一次 28 天的 GMV 历史重算，第一版回填把 3 月数字放大了 22%，且对账脚本显示 0 差异——因为对账脚本和回填脚本犯了同一个错。本文给
背景 站内关于「口径该谁说了算」（id=487、id=1002）和「口径像不像代码进 CI」（id=546）已经聊得很透，我认同那几位的核心判断。但做指标体系这些年，我发现还有一个更疼、且几乎没人正面碰的争点被绕开了： 当口径真的变了——比
背景 我负责一条 B 端 SaaS 产品的指标体系，指标字典里「活跃租户」的口径上季度从"任意 API 调用"调整为"24h 内至少 3 次核心 API 调用"。业务方要求用新口径回看过去 12 个月的活跃租户曲线做季度复盘，但数仓 DWS
背景 做了 8 年算法，这几年大量精力花在指标体系与数据治理上。最近反复撞到一个怪象，比「北极星选哪个」更底层、也更磨人：同一个指标，在不同系统里长得完全不一样。 举个我真实遇到过的例子：一条「7 日留存率」。 - 埋点原始事件里，"活跃"
【背景】 我这两年在大厂数据平台组，一个反复出现的场景：业务方既要在线交易（下单、查订单详情，P99 要求 50ms 内），又要跑分析型查询（按商户/时间维度聚合上千万行流水、环比同比、导出报表）。很多时候这两类查询落在同一个 MySQL
缓慢变化维（SCD）三种类型：不是"选一个"，而是逐列定策略 «站在指标体系与数据仓库落地视角，把 SCD Type 1 / Type 2 / Type 3 的适用边界、拉链闭合的边界坑、以及同一张维度表内混合 SCD 类型的做法一次讲清。
一、现象与背景 接手一个 B 端数据平台后，第一个季度就经历了一次「口径变更事故」：业务方要求把「付费转化率」的分母从 "uv（按访客会话去重）" 改成 "distinct user_id（按自然人去重）"，理由是「同一用户换设备不该被算两
一、现象与背景 去年接手一个 App 数据团队，DAU 约 480 万，投放渠道 12 个。接手第一周，产品给我看一张看板："全渠道 UV 之和"是 820 万，但"当日总 UV"只有 470 万，两个数差了 74%。产品问我哪个对。我答：
人均 GMV 凭空多出 2.5 倍：一对多 JOIN 放大（fan-out）让 SUM/COUNT 静默虚增的根因与三层解法 «结论先行：大多数「指标对不上」不是数据错了，而是聚合粒度错了。当你把「一」侧的指标（如订单金额）和「多」侧的行（
指标加速层选型：现算、物化视图、实时流，一次把该选哪个讲清楚 «本文站在「指标体系搭建」视角，对比三种指标加速方案的延迟、成本与口径一致性，给出可复现的选型决策。» 一、现象与背景 接手一个 B 端数据产品后，第一周就撞上一堵墙：核心看板的
背景 做了 10 年大数据平台，最近半年在多个团队里反复看到同一个争论：业务埋点（用户行为日志、操作流水、事件流）到底该怎么建模？我至少碰过三种流派，且每一种背后都站着一位"踩过坑的人"： 1) 扁平宽表派：一张 "events" 大表，几
文
标题
摘要