数仓随笔一：封装具有业务含义的字段并暴露

发表于 分类于 阅读次数： Valine：

说明

本系列记录日常数仓中碰到的一些现象，用于个人总结。

现状

最近碰到了一个问题，属于典型的模型设计不合理，未考虑扩展性，有必有记录。

现状是这样的。

在公司业务上，当一套房子的付款达到20%，那么认为这套房子符合业绩考核。而是否符合业绩考核在公司的业务上是一个通用的逻辑。

于是在总部的数仓模型中，到处遍布着这样一个字段is_received_20_pct是否付款达到20%。当为1的时候表示达到，为0的时候表示没达到。

问题

大部分场景下，这样是没有问题的，比如求业绩考核签约金额

1
select sum(amt) from trd_sign where is_received_20_pct = 1

但是，个别项目的，回款10%就算业绩考核，于是，增加了is_received_10_pct，sql就变成了

1
2
3
4
select sum(amt) 
from trd_sign 
where (is_received_20_pct = 1 and proj not in (xxx))
and (is_received_10_pct = 1 and proj  in (xxx))

我们不妨想想，如果个别项目再增加逻辑呢，8%？16%？不断的暴露指标？
这样肯定是不合理的。

而且，如果后续某个项目判断逻辑发生变更（虽然这不太会），所有的业务逻辑都要修改，会涉及几十上百个模型表，这将会是个灾难。

更好的解决方案

有没有更好的解决方案？必然是有的。
更优雅的设计应该是暴露业务相关含义的逻辑，本例中业务方要的是是否符合考核，因此我们只需暴露is_kpi_received即可，至于是否符合考核的逻辑，则由源头模型加工表实现，这样，后续逻辑变更，只需改加工表即可。即该的少，又保障了逻辑的一致性。

总结

  1. 在模型设计时，应考虑扩展性，尽可能暴露业务相关含义的逻辑。
  2. 在血缘链路开发中，传递数据而非逻辑。