一张宽表撑起几十张报表——报表底层的宽表怎么设计？

-- 粒度决策的方法：枚举报表需求，取最细分析粒度的并集
-- 报表1：国家日报        → 天 × 国家
-- 报表2：渠道周报        → 周 × 渠道（可由天聚合）
-- 报表3：素材效果排行    → 天 × 渠道 × 素材
-- 报表4：ROI总览         → 天
-- 结论：宽表粒度 = 天 × 国家 × 渠道 × 素材
 
CREATE TABLE dws_ad_perf_1d (
  stat_date     STRING COMMENT '统计日期',
  country       STRING COMMENT '国家',
  channel       STRING COMMENT '渠道',
  creative_id   STRING COMMENT '素材ID',
  channel_type  STRING COMMENT '渠道类型（冗余维度属性）',
  cost          DOUBLE COMMENT '消耗USD｜可加',
  install_cnt   BIGINT COMMENT '安装数｜可加',
  pay_amount    DOUBLE COMMENT '付费金额USD｜可加',
  pay_user_cnt  BIGINT COMMENT '付费人数｜按天去重，跨天不可直接SUM'
) PARTITIONED BY (ds STRING);

指标处理：可加性指标需特别注意

宽表里最容易埋雷的是指标的可加性分类：

类型	例子	宽表处理方式
可加指标	消耗、金额、次数	直接存，任意维度SUM都对
半可加指标	余额、库存（快照值）	只能沿部分维度加，跨时间要取期末/平均
不可加指标	去重用户数UV、留存率	存明细/Bitmap，或者只在最终粒度算

-- 经典错误：把按天去重的UV跨天SUM
-- ✘ 错：周UV ≠ 7个日UV之和（同一用户会被重复计数）
SELECT SUM(pay_user_cnt) FROM dws_ad_perf_1d
WHERE ds BETWEEN '20250301' AND '20250307';
 
-- ✔ 对（方法1）：回明细层重新去重
SELECT COUNT(DISTINCT user_id) FROM dwd_trade_pay_di
WHERE dt BETWEEN '20250301' AND '20250307';
 
-- ✔ 对（方法2）：Hologres/Doris用Bitmap类型存用户集合
-- 跨天聚合时对Bitmap求并集再取基数，又快又准
SELECT RB_CARDINALITY(RB_OR_AGG(user_bitmap))
FROM dws_ad_user_bitmap_1d
WHERE ds BETWEEN '20250301' AND '20250307';

我的规范是在字段注释里强制标注可加性（上面DDL里的“跨天不可直接SUM”），并且给BI建模时把不可加指标配置成不可SUM聚合。防呆要做在机制里，不能指望每个用表的人都懂。

宽表的边界：什么时候拆

宽表的失败模式是“万能宽表”：什么需求都往里加列，最后几百列、十几个上游依赖，一个上游延迟全表难产，谁也不敢动。我的拆分原则有三条：主题域不同就拆（投放域和交易域分开）；粒度不同就拆（天粒度和小时粒度分开，不要用NULL占位硬挤一张表）；上游依赖的产出时间差异大就拆（避免最慢的上游拖累所有报表）。宽表之间共享的逻辑下沉到DWD/DWM层复用，而不是靠一张表包打天下。

面试高频追问

追问一：宽表和指标统一出数层是什么关系？

互补关系，分工不同。宽表是分析底座，粒度较细、维度丰富，供报表聚合和自助分析用；出数层是口径权威，存的是已经算好的核心指标终值，供“要一个准确数字”的场景用。实践中出数层的指标往往就是从宽表聚合出来的——宽表保证灵活性，出数层保证唯一性，两层都从同一套DWD加工，口径同源。小团队可以合并成一层，但心里要清楚这两个职责的区别。

追问二：报表要加一个新维度，宽表没有，怎么办？

先判断这个维度和现有粒度的关系。如果是现有粒度上的维度属性（比如给素材加一个“素材类型”），直接加列冗余，重刷需要回溯的历史分区即可，成本可控。如果它会改变粒度（比如要按“剧目”看数，而一个素材对应多个剧目），就不能硬塞——粒度变了整张表的行数和所有指标含义都变，这种情况要么新建一张该粒度的宽表，要么评估是不是低频需求直接从明细层临时算。最忌讳的是硬加进去导致原有指标出现重复计数，几十张存量报表全部被污染。

追问三：宽表每天全量重算还是增量更新？

看数据特性。事件类数据（曝光、安装、支付）天然按天分区增量写入，每天算当天分区即可；但如果有迟到数据或者归因回补（广告归因窗口常见7天回看），就要每天重刷最近N天的分区——我们的投放宽表就是每天重刷近7天，覆盖归因回补。状态类数据（订单状态会变化）要么每天全量快照，要么用Delta Lake/Hudi这类支持MERGE INTO的格式做增量合并。我在出海硬件品牌把维表更新从UNION全量重写改成MERGE INTO之后，代码量减了70%，这个思路同样适用于状态类宽表。

实战踩坑：BI里一个SUM，周报虚高30%

付费人数那个“不可加”的雷，我是真的踩过。在短剧公司早期，投放宽表里存了按天去重的付费人数，BI里有人拖了一张周报，聚合方式默认SUM——周付费人数直接变成7天日值相加，比真实值虚高了约30%（周活跃付费用户平均每周付费两三天）。这张周报被用了快一个月才被发现，发现的契机是业务方拿它和财务的收入数据算ARPPU，发现人均付费低得离谱。修复动作有三个：宽表新增Bitmap字段支持跨天精确去重；BI数据集里把所有去重类指标的默认聚合改成“禁止SUM”；给团队做了一次可加性的分享。最后在报表上线checklist里加了一条：每个指标的聚合方式必须显式确认过。

-- 修复：宽表增加Bitmap列，跨天去重交给引擎
ALTER TABLE dws_ad_perf_1d ADD COLUMN
  pay_user_bitmap RB COMMENT '付费用户Bitmap｜跨天聚合用RB_OR_AGG';
 
-- 周报的正确写法：Bitmap并集后取基数
SELECT country,
       RB_CARDINALITY(RB_OR_AGG(pay_user_bitmap)) AS week_pay_uv
FROM dws_ad_perf_1d
WHERE ds BETWEEN '20250301' AND '20250307'
GROUP BY country;

教训：宽表设计者要为“最不懂数据的使用者”兜底。指标能不能加、怎么加，必须固化在表注释和BI配置里，而不是留在设计者的脑子里。

总结

报表宽表设计三决策：粒度取所有报表需求的最细分析粒度（由消费端决定）；高频维度属性冗余进表（快照固化口径，免JOIN）；指标严格分类可加性（去重类用明细或Bitmap，禁止预聚合后二次SUM）。再加一条边界原则：按主题域、粒度、产出时间拆表，拒绝万能宽表。面试时把“可加性”和“维度快照”这两个点讲透，就能证明你的建模功力是在报表场景里真实磨出来的。

下一篇聊报表人最狼狈的时刻：早上9点报表还没出数，老板在群里@你——产出延迟怎么排查和兜底？

你们的宽表最宽的有多少列？有没有见过失控的“万能宽表”？评论区聊聊～

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

数据报表 面试通关手册

第6-10篇：技术实现（上）

Wood聊大数据

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