同一个指标，三个部门三个数——你怎么处理？

数仓开发手册第 15 题约 10 分钟读完

先说结论

口径不一致的三大根源：口径定义不清、数据来源不同、计算逻辑分散。解决要对症下药，一个手段解决不了所有。

解法四步：统一定义（建指标字典）→ 统一来源（建 DWS 层公共聚合）→ 统一计算（封装 UDF 或公共视图）→ 统一出口（OneService）。

最难的不是技术，是组织对齐。技术手段能做到 80%，剩下 20% 得靠指标 owner 制度和跨团队评审。

先把这段讲顺；面试官追问时，再展开下面的原理和细节。

详细讲解

面试进行到 45 分钟后，话题开始从『执行层』转到『架构层』。第一道架构题几乎是必问：『GMV / DAU / 留存率——同一个指标，三个部门三个数，你怎么处理？』这题表面考技术，实际考架构设计能力和跨团队协作——一个 senior 和一个 junior 在这题上的答案会有明显差别。

业务场景：某出海硬件品牌的 DAU 三个数事件

我在某出海硬件品牌做数据平台时亲历过这个场景。某周一早上，CEO 收到三份周报：运营组的 DAU 是 120 万、产品组的 DAU 是 135 万、财务组的 DAU 是 98 万，差异 35%。CEO 在群里炸了：『我到底信哪个？』我们数据组被卷入这场跨部门战争，花了一个月才统一口径。

Plain

三个口径的差异（复盘后发现）：
 
运营组 DAU = 120 万
  定义：登录过 App 的去重用户
  来源：user_login_log
  计算：count(distinct uid) where dt
 
产品组 DAU = 135 万
  定义：有过任何事件的去重用户（含 push 点击）
  来源：event_tracking_log
  计算：count(distinct uid) where dt
  比运营组多了 push 打开但没登录的用户
 
财务组 DAU = 98 万
  定义：活跃并消费过的用户
  来源：order_log + login_log
  计算：count(distinct uid) where has_order = 1
  这根本不是 DAU，是 DPU（Daily Paying Users）
 
→ 三个团队叫同一个名字『DAU』，含义完全不同

段落一：第一步——指标字典

解决口径不一致的第一步是建指标字典（Metric Dictionary）。每个核心指标必须有：官方定义、业务口径、计算逻辑、数据来源、owner。

# 指标字典条目示例
metric: DAU
official_name: daily_active_users
definition: |
  当日活跃用户数，定义为 '当日打开过 App 并产生有效事件的去重用户数'
  - 打开定义：登录成功 或 主动启动（含静默拉起）
  - 有效事件：排除 push 被动曝光
 
calculation: |
  SELECT COUNT(DISTINCT uid)
  FROM dws_user_activity_daily
  WHERE dt = :bizdate AND is_active = 1
 
source: dws_user_activity_daily
owner: data_team_wood
 
variants:
  - name: DAU_login_only
    definition: 仅登录用户（运营组原口径）
  - name: DPU
    definition: 付费活跃用户（财务组原口径）
 
approved_by: [product_director, coo, cfo]
updated: 2024-03-20

关键：指标字典不是数据团队自己写的，是和业务方共同 review 通过的。指标 owner 最好不是数据同学——是业务 owner（比如 DAU 的 owner 是产品经理），数据团队只是维护者。

段落二：第二步——公共 DWS 层

光有字典不够，还要让所有人的计算来自同一份数据。这就是 DWS 公共汇总层的意义——把核心指标在 DWS 层先算好，下游所有看板 / ADS 表都从 DWS 读，不允许各自从 DWD 自己算。

-- DWS 公共层：核心活跃指标
CREATE TABLE dws_user_activity_daily (
  dt STRING,
  uid BIGINT,
  is_active INT,       -- DAU 口径标识
  is_login INT,        -- 登录过
  is_paying INT,       -- 有支付行为
  event_cnt INT,
  -- 一份数据支撑 DAU / DLU / DPU 多种口径
) PARTITIONED BY (dt);
 
-- 下游只能从 DWS 取，禁止各自从 DWD 算
-- 运营组看板
SELECT COUNT(DISTINCT uid) AS dau FROM dws_user_activity_daily
WHERE dt = '${bizdate}' AND is_active = 1;
 
-- 财务组看板
SELECT COUNT(DISTINCT uid) AS dpu FROM dws_user_activity_daily
WHERE dt = '${bizdate}' AND is_paying = 1;
 
-- 结果一致——因为来源一致、只是筛选条件不同

段落三：第三步——封装视图 / UDF

对于复杂指标（比如留存率、LTV），除了 DWS 数据一致，计算逻辑也要一致。用公共视图或 UDF 封装。

-- 公共视图：7 日留存率
CREATE VIEW v_retention_7d AS
SELECT
  u1.dt AS new_user_date,
  COUNT(DISTINCT u1.uid) AS new_users,
  COUNT(DISTINCT u2.uid) AS retained_7d,
  ROUND(COUNT(DISTINCT u2.uid) * 1.0 
    / COUNT(DISTINCT u1.uid), 4) AS retention_7d
FROM dws_new_user_daily u1
LEFT JOIN dws_user_activity_daily u2
  ON u1.uid = u2.uid AND u2.dt = DATE_ADD(u1.dt, 7)
GROUP BY u1.dt;
 
-- 任何地方需要 7 日留存都从 v_retention_7d 读
-- 不允许自己写

段落四：第四步——OneService 统一出口

最高层的统一是 OneService——所有数据查询不直接访问表，而是通过一个统一的 API 层。API 层里固化了口径、权限、缓存。

层级	统一程度	适合公司规模
指标字典	定义层统一	小公司即可开始
DWS 公共层	数据层统一	中等规模、有数仓建设
公共视图 / UDF	计算层统一	数仓成熟、逻辑复杂
OneService API	出口层统一	大厂 / 数据中台

我的建议：小公司做到前两层即可（字典 + DWS），性价比最高。OneService 是大公司数据中台的玩法，小公司搞不起这个层次的治理，强行上反而拖慢业务。

段落五：组织层面——指标 Owner 制度

技术手段能解决 80% 的口径问题，剩下 20% 必须靠组织。最关键的是建立指标 Owner 制度。

Plain

指标 Owner 制度（我在某出海硬件品牌推行的）：
 
1. 每个核心指标必须有一个业务 owner（不是数据同学）
   - DAU owner: 产品总监
   - GMV owner: COO
   - 留存率 owner: 增长负责人
   - 广告 ROI owner: 投放总监
 
2. 口径变更流程：
   - 任何人申请变更 → owner 评审 → 数据团队实施
   - 老口径保留至少 1 季度，打过渡标签
 
3. 指标质量月会：
   - 每月对核心指标做一次 sanity check
   - 对比不同看板的数值是否一致
   - 发现偏差立刻追查
 
效果：半年后跨部门数据口径分歧减少 80%

面试高频追问

追问一：老口径已经深入业务方心智了，怎么切换到新统一口径？

最务实的做法：双口径并行一段时间。新看板上同时显示新口径（官方）和老口径（历史），并标注『老口径将于 X 月 X 日下线』。2-3 个月过渡期让业务方适应。硬切是大忌——业务方看到数字突然变了第一反应不是接受新口径，是怀疑数据出错了，信任一丢很难挽回。

追问二：有没有遇到过业务方各自坚持自己的口径，不愿意统一？

遇到过。解法只有一个——让数据治理 owner 足够高层（至少 VP / COO 级别）来拍板。我在某出海硬件品牌那次 DAU 事件最后是 COO 拍板统一口径，如果只靠数据总监去推，三个部门谁也不让。『口径对齐』本质是组织议题，不是技术议题。

追问三：小公司没有数据中台也没有中台团队，怎么治理口径？

三件最小可行的事：（1）把指标字典做成一个共享文档（飞书 / Notion），不一定有系统支持；（2）核心 5-10 个指标用 DWS 表统一好，不需要全量建 DWS；（3）每月开一次『数据对齐会』，每个业务方派一个代表，看当月各个看板的数字是否对得上。这三件事基本不花钱但能解决 70% 的问题。

实战踩坑：指标字典建好之后又散了

我还见过一个反例：某公司很认真地建了指标字典，100+ 指标都写了定义，但一年后再看——字典没更新、业务已经变了、每个团队又各自算了。为什么？因为字典是『事后登记』，变更时没有强制走字典更新流程。结果字典成了陈列品。

教训：指标字典必须和数据变更流程绑定。任何 DWS 表变更都必须同步更新字典，否则 CR 不通过。把字典从『文档』变成『流程中的卡点』，才能长期有效。

Plain

指标字典存活检查（半年审计）：
 
□ 字典最后更新时间 < 1 个月？
□ 核心指标 owner 仍在职？
□ 最近 3 个月的变更是否全走了字典更新？
□ 抽查 5 个指标 SQL 是否和字典一致？
□ 业务方是否知道字典存在？
 
任何一条失败 → 字典失效，需要重新梳理

总结

同指标不一致题的高分答案包含四个层面：（1）技术层面的四步解法（字典 / DWS / 视图 / OneService）；（2）组织层面的 Owner 制度；（3）切换新口径的务实做法（并行过渡）；（4）一个真实的大事件故事（CEO 质问那种）。能把技术 + 组织讲全，这题就到了架构师水平。

下一篇：『元数据管理怎么做？血缘有什么用？』——架构题第二道。元数据是『数仓的数仓』，做好了降维打击、做不好全靠脑记。

你们公司有指标字典吗？有的话是『活的』还是『陈列品』？

关注「Wood聊大数据」| 9年大数据老兵，聊技术、聊职场、聊成长

数仓开发面试通关手册

第16-20篇：架构视野 + 收尾反问（系列收官）

Wood聊大数据

9年大数据老兵，聊技术、聊职场、聊成长

按面试官真实提问顺序设计的 20 道题

第四部分导读（系列收官）

这是数仓开发面试通关手册 20 题的最后一册——第 16-20 篇。

前 15 篇把面试官会问到的『暖场 → SQL 实操 → 建模深挖 → 生产问题 → 架构起点』都走过了。本册是面试最后 15 分钟的四道架构题 + 最后 5 分钟的反问环节。

第 16-18 篇是三道重架构题：元数据管理、引擎迁移、实时数仓。这三题考察的是你有没有『架构师思维』——能不能站在系统和组织层面看问题。第 19 篇是经典的 STAR 讲项目题，决定你给面试官留下的最终印象。

第 20 篇是整个系列最特别的一篇——『你有什么想问我的吗』的反问环节。这不是一道技术题，但 90% 的候选人在这里翻车。能把反问做成『信息战 + 展示特质』而不是走过场，是 senior 的标志。

整套手册到这一册完结。感谢一路看到这里的每一位读者。希望这本手册能在你的某个面试前夜，替你省掉两个小时的焦虑，多拿一个 offer。

— Wood，2026 年春

刷题进度保存在当前浏览器

同一个指标，三个部门三个数——你怎么处理？

先说结论

业务场景：某出海硬件品牌的 DAU 三个数事件

段落一：第一步——指标字典

段落二：第二步——公共 DWS 层

段落三：第三步——封装视图 / UDF

段落四：第四步——OneService 统一出口

段落五：组织层面——指标 Owner 制度

面试高频追问

实战踩坑：指标字典建好之后又散了

总结

第四部分导读（系列收官）

相关题目