指标口径管理
总结
| 记忆点 | 内容 |
|---|---|
| 口径问题根因 | 定义不统一、SQL各写各的、数据源不同 |
| 指标三层 | 原子指标 → 派生指标 → 复合指标 |
| 治理三步 | 建指标字典 → 收口汇总层 → 技术卡控 |
| 核心原则 | 一个指标，一个SQL定义，一个取数出口 |
先把这段讲顺；面试官追问时，再展开下面的原理和细节。
详细讲解
进阶 | 大数据面试 · 数仓建模系列
| 面试真题 你们公司有没有遇到过指标口径不一致的问题？是怎么解决的？ |
|---|
最真实的数仓痛点
技术问题好解决，口径问题要命。我相信做过数据开发的都经历过这种场景：运营说「昨天GMV是500万」，财务说「不对，是480万」，老板看大屏又是510万。三个人看的三张报表，同一个指标三个数字。
这不是Bug，这是口径不一致——大家对「GMV」的定义不一样。运营算的是所有已下单金额（含未支付），财务算的是已支付且未退款的金额，大屏算的是已支付金额（含退款中的）。名字一样，SQL不一样，数字当然不一样。
| Wood的实战经验 我在做广告归因的时候，ROI这个指标就出过问题。投放团队算的ROI用的是「7日归因收入/当日花费」，管理层看的是「当日收入/当日花费」。归因窗口不同，ROI差了3倍，开会差点吵起来。 后来统一定义为「7日归因ROI」和「当日ROI」两个独立指标，各自有明确的SQL口径。核心教训：口径不同就是不同的指标，绝对不要复用名字。 |
|---|
指标的分类体系
原子指标（最底层）：一个不可再拆分的度量+聚合方式。比如SUM(order_amount)、COUNT(DISTINCT user_id)。原子指标必须有唯一的SQL定义，这是口径一致的基石。
派生指标（原子+限定条件）：在原子指标上加时间范围、业务过滤条件。比如「近7日GMV = SUM(pay_amount) WHERE dt >= 近7天 AND status = 'paid'」。
复合指标（多个指标计算）：两个及以上指标的运算。比如「客单价 = GMV / 下单用户数」、「ROI = 收入 / 广告花费」。
口径不一致的三大根因与解法
| 根因 | 表现 | 解法 |
|---|---|---|
| 定义不统一 | 同一个名字不同含义 | 建立指标字典，统一定义 |
| 取数逻辑不同 | 不同报表各自写SQL | 收口到同一张汇总表，统一取数 |
| 数据源不同 | A报表用DWD，B报表用ODS | 所有报表统一从DWS/ADS取数 |
治理三步法
第一步：建指标字典。每个指标必须包含：指标名称、英文名、业务定义、计算逻辑（具体SQL）、所属主题、负责人、数据来源。
第二步：收口汇总层。所有下游报表不允许直接查DWD/ODS，必须从DWS/ADS统一取数。一个指标只有一个SQL出口，口径想不一致都难。
第三步：技术卡控。指标SQL模板化，变更走审批流程；新增报表必须关联已有指标，不能自己造；定期巡检对比不同报表的同名指标数值。
| 面试加分提示 这道题是区分「做过数仓」和「只学过数仓」的分水岭。面试官想听的不是理论，而是你处理过的真实混乱： 「我们之前遇到过口径问题。运营和财务看的GMV差了20万，排查后发现运营的报表直接查的DWD层，包含了未支付订单；财务查的ADS层，过滤了未支付。解决方案是把GMV拆成两个指标：下单GMV和支付GMV，各自在DWS层有明确定义，所有报表统一从DWS取数。上线后再没出现过口径扯皮的问题。」 这种回答有场景、有原因、有方案、有结果，满分。 |
|---|