考察点
这道题考的是你有没有「经营」过数仓，而不只是「建」过表。面试官想确认你知道模型的好坏是可以量化的：复用度、穿透率这两个指标要能给出定义、计算口径和改善手段。追问一般往 OneData 指标体系、以及「穿透率高了怎么治理」的方向走。
参考答案
先说为什么要度量
数仓跑两三年后的典型病灶是：烟囱式开发，业务方各自提需求，数据团队各自建表，结果同一个「支付金额」在十几张 ADS 里有十几种口径；下游嫌 DWS 不好用，直接 join DWD 明细自己算，公共层形同虚设。模型优化要见效，得先把「好不好」变成数字，复用度和穿透率就是最常用的两个。
复用度：公共层有没有人用
复用度衡量 DWS（公共汇总层）表的下游消费情况，最直接的定义是：
某 DWS 表复用度 = 直接消费它的下游任务/表数量
也可以按层聚合：DWS 层整体复用度 = 被消费的 DWS 表占比。数据从哪来？解析任务 SQL 得到表级血缘，数入度即可。健康的数仓，核心 DWS 表（如交易域的用户-日粒度汇总）下游引用应该达到几十上百个任务；如果一张 DWS 表只有一两个人用，要么它设计的粒度/维度不对，要么它本来就不该建在公共层。
提高复用度的手段：把各业务方重复写的汇总逻辑下沉成公共 DWS（一次开发，多处复用）；维度退化做得足一点，让下游不用自己再 join 维表补属性；配合数据地图和表负责人机制，让新需求能搜到已有表而不是重建。
穿透率：下游有没有绕过公共层
穿透率（也叫明细穿透率）定义是：
穿透率 = 直接读取 DWD/ODS 的下游任务数 ÷ 下游任务总数
理想模型里，ADS 和报表应该消费 DWS，只有少数复杂分析才需要碰明细。穿透率高（比如超过 30%）说明公共层没接住需求——下游宁可自己从明细重算，这会带来两个直接后果：口径分叉，同一指标多个结果；计算浪费，同一份明细被反复全量扫。
治理动作很实在：先按血缘拉出穿透最严重的几张 DWD 表，逐个分析下游任务在算什么，把高频的汇总口径沉淀成新的 DWS 表，然后推动下游迁移、老任务下线。阿里 OneData 体系的思路也在这：指标统一定义为「原子指标 + 统计周期 + 业务限定 + 修饰词」的派生指标，全部收敛到公共层产出，从源头掐断口径分叉。
其他配套优化手段
- 规范覆盖率：表命名、分层归属、字段注释、分区设计是否符合规范，做成元数据自动巡检，纳入模型健康分。
- 合并相似表：按字段相似度和血缘聚类，找出职责重叠的表，合并下线，减少维护面。
- 预聚合与物化：对高频查询粒度建物化视图或 rollup，把重复计算变成一次计算。
- 模型评审前置：新表立项时对照总线矩阵评审，确认不重复建设，比事后治理便宜得多。
工程上建议把这些指标做成周报看板：复用度上升、穿透率下降，才说明优化真落了地，而不是只靠架构图自嗨。
可能的追问
- 穿透率是不是越低越好？ 不是。即席分析、算法特征取数天然要碰明细，追求零穿透会逼你把 DWS 建成万能宽表。合理目标是核心报表类任务穿透率接近零，分析类保留合理比例。
- 复用度怎么避免「一张超级宽表撑高数字」？ 复用度要结合表的内聚性看，一张几百个字段、什么主题都塞的表复用度再高也是坏模型。评估时同时看字段数、主题单一性和变更频率。
- 你们血缘怎么解析的，字段级还是表级？ 表级靠调度依赖加 SQL 解析就能拿全；字段级要解析 AST 处理函数和 case when 的传递关系，成本高，一般只对核心资产做。