两个案例搞定数据指标口径的一致性

点击上方“数据管道”，选择“置顶星标”公众号

干货福利，第一时间送达

一、背景

在数据仓库中，常常使用一些中间表来做数据的过度，这些中间表的产生，都是依托于基础的埋点表/业务明细表/用户明细表等，旨在提高数据提取与输出的效率。

举个栗子：

客户端上报的埋点数据，或者某个功能的明细表，需要与用户明细表做关联可使用。这些数据一天的产生都是以亿级为单位，数据人员如果每次都将这些数据重跑一次，数据复用性低下，势必会造成资源和人员的浪费，有些使用第三方数据库（阿里云）的公司，每次数据提取都是需要钱的，数据量大的话，每次损耗也不少。

同时，明细表的数据存储，有时会依托于业务，逻辑比较复杂，对新人不友好（例如，研发同学会将信息以json格式存储）。而随着业务线的增加，跨表引用增多，如果逻辑口径发生变化，势必会成为一个灾难。

所以，中间表的作用，就是在dws层，将基础事实层的数据，通过与产品人员既定的规则编写，用”case when”或syscode系统码表来将业务口径标签化，将数据固定在对应主题域中，方便日常的汇报或者用户分析使用。

那么如何来构建有价值的中间表呢，下面看两个例子，一个是供给端，一个是消耗端：

 

二、案例一（供给端）

某App为办公协同类产品，内部附有公司动态、通知、新闻、培训课程、留言等功能，管理员或领导层可使用这些功能，下发一些公司内部的信息，分为全公司可见或者指定部门可见。

如果该App的运营部，想查看某一功能的使用情况，所需要的数据为：

 

形成了一个从供给到消耗的转化漏斗，来观测某功能带来了多少活跃，判定此项功能的使用情况。

该转化漏斗的难点在于供给人数，可能是发给全公司的，也可能是发给个人的，同时涵盖了上述举例的多种功能。业务明细表会记录该功能的发布者ID、内容ID，发送对象ID，发送类型（公司、部门、个人）等。

这时取数的麻烦点在于，发送类型如果为全公司，那么业务明细表关联用户明细表时，发送对象ID（公司ID）与公司ID关联；发送类型为部门时，发送对象ID（部门ID）与部门ID关联；发送类型为个人时，发送对象ID即是用户ID。用union all 将数据合并，得出了供给人数。

这种数据提取，单次可行，代码也可复用，但是每次提取花费较大，也比较耗时间，数据都是存储在逻辑里，并没有一张表来记录。OK，那我们就创建一张中间表，将所有功能数据存储，对于有关需求可以随取随用。

 

需要注意的几点：

1. 考虑供给用户正常情况下（工作日），数据量较大，所以设计报表时，考虑为每一个业务进行单独建表，后续只考虑总供给的话，可对分表进行处理，去掉内容ID等，进行合并去重。

2. 本表记录数据较多，所以内容ID对应的其他信息不做记录，如有需要，与对应业务表连接即可。

三、案例二（消耗端）

某App为内容资讯类产品，用户可在其查看各种文章和音视频，浏览入口分为推荐feed流，banner焦点图，关注频道，收藏，消息公众号推送等。

运营人员除了关注整体的文章阅读外，还会关注各个入口的转化情况，数据如下：

以上数据，除日活外，都属于用户的行为数据，用埋点表即可提取，关键在于埋点的数据每天是以亿级产生。以上数据当然可以做成BI报表，但是数据依然只是存在于逻辑中，每次需要，每次重新跑，没有复用性，消耗时效和人效，依然可以用中间表解决这个问题。

与产品/运营人员，开会商议，确定每个来源入口的规则，对埋点表进行处理，用case when使不同的来源入口标签化：

 

这样，一张只记录用户关于内容的消耗表就做好了，需要注意以下几点：

1.本表旨在记录用户对内容的消耗，方便数据人员快速解决运营人员的需求，也可做RFM等分析。目前只记录观看和播放，是否应记录互动（点赞、评论、分享等），需要商议。

2.除课程、文章外，是否有必要添加其他类型内容等。

3.由于每天对内容的消耗用户量较多，所以内容的相关信息本表不做存储，如有需要，与内容的事实表进行连接。

四、结束语

通过建立中间表，确实可以提高数据的输出效率，但是光建立是远远不够的，后期的维护也同样重要。

由于规则是与产品/运营商定的，必须形成规范的数据字典文档，存储在公共平台上（wiki、SVN等），有改动或者新增，需及时调整。

有新增的业务时，也要在发版之后，添加至中间表中，避免数据遗漏或者重跑。