数据仓库

«站在「指标口径变更 → 历史数据必须回填」这条最容易被跳过的链路上，复盘一次真实的回填事故：一次 28 天的 GMV 历史重算，第一版回填把 3 月数字放大了 22%，且对账脚本显示 0 差异——因为对账脚本和回填脚本犯了同一个错。本文给

背景 10 年大数据平台，最让我头疼的不是慢查询，而是"业务方一句口径改一下，我们得回刷 N 个月、通知 20 个下游"。最近半年在几个团队里反复看到同一个场景：DWD 层一张订单明细表，"channel" 从「渠道 ID」改成「渠道名称

背景 我做了 5 年技术文档，这两年在帮团队搭指标体系。核心指标 40+ 个，DWD 明细层已经建好，查询能跑通，但运营看板一拖拽维度就慢（一张几千万行的订单明细，按「日期 × 渠道 × 城市 × 品类」下钻，P99 经常 8s+）。现在卡

缓慢变化维（SCD）三种类型：不是"选一个"，而是逐列定策略 «站在指标体系与数据仓库落地视角，把 SCD Type 1 / Type 2 / Type 3 的适用边界、拉链闭合的边界坑、以及同一张维度表内混合 SCD 类型的做法一次讲清。

背景 做了 10 年大数据平台，最近半年在多个团队里反复看到同一个争论：业务埋点（用户行为日志、操作流水、事件流）到底该怎么建模？我至少碰过三种流派，且每一种背后都站着一位"踩过坑的人"： 1) 扁平宽表派：一张 "events" 大表，几