浅谈数仓分层
本期内容
分层背景
分层的优势
分层的具体实践
总结
1. 分层背景
1.1 数据计算效率低下
在未分层的情况下，各个业务系统数据库中的表都一股脑被放入数仓中，BI在取数做看板的时候，不免会读取全量的表，这其中有许多无用的数据IO会导致资源使用效率低，计算时间过长，导致我司的看板产出时间基本都维持在10点以后，有时候数据产生问题，甚至会延迟到下午2-3点。在没有数据支持的情况下，运营同学进行业务决策就如黑夜中走路一般，没有了方向，会造成一连串的不可估影响。
1.2 字段名标准不规范
数仓作为离线数据的接收方与输出方，需要把握整体数据的字段命名规范，将不同业务方对于同一含义的字段进行命名统一，例如在我司的shop表中userid代表的含义实际就是seller_id，在order表中selleruserid代表的含义也是seller_id，但是不同的写法会增加下游BI同学在使用时的理解难度。
1.3 业务更迭导致脚本调整困难
当源业务系统的业务规则发生变化时，可能影响整个数据的清洗过程。遇到过最痛苦的事就是莫过于itemtype增加了字段，从数仓到BI都要去自己的各个脚本翻找哪里有使用这个字段，极大增加了工作量。但如果数仓有进行动态的调整可用itemtype类型，只需要在字典表内维护便可一键通用到所有脚本内，快速支持业务的更迭。
2. 分层的优势
2.1 将复杂工作拆分成多个简单步骤
数据仓库通过分层，将工作分为了多个步骤，相当于把一个复杂的工作拆分成了多个简单的工作，这样每一层的分工都很简单明确，当数据发生错误的时候，只需要逐层溯源，找到产生错误的步骤并调整这个步骤即可。就像工厂里的流水线一样，每个工人都做着自己的活，当发现错误的时候可以精确定位到错误的人，快速调整。
2.2 将数据与业务变化隔离
公司的业务与需求经常会发生变化，如果不分层，每次业务与需求的变化都会导致数据仓库需要全部重新清洗、计算数据，而使用分层设计，数据仓库只需要调整与变化最接近的一层即可，起到将数据与业务分离的作用。
2.3 用空间换时间
数据仓库的分层实际上是提前将可能需要用到的数据计算出来并存储，这样当我们需要数据的时候就不必现计算了，直接就可以使用了，提升了业务方的用户体验与效率。
3. 分层的具体实践
以【以人为本】项目为例，具体讲解一下怎么一层层拆分数据指标，并在数仓中落实到各个数据层内。
3.1指标的拆解
从产品同学处我们可以获知本次需求中需要输出的数据为用户的活跃粉丝数，那么这个派生指标实际可以拆解为：活跃的+粉丝数。活跃的是对于粉丝数这个源自指标的修饰。
粉丝的定义是A关注了B，且关注关系存续，则认为A是B的粉丝，那么原子指标粉丝数的定义就是计算被关注者，在上文的例子的中就是B，和他有关注存续关系的用户数量。修辞词中，活跃定义是指90天内有过访问的。
3.2 确定数据域与业务过程
活跃是根据用户访问记录来判断的，那么必然是属于日志域内，且属于访问的业务过程，取用户的pageshow事件即可；粉丝在主站中多次都有使用到，是用户之间的一种关系，可以认为属于互动域，这个数据域通常包括多个主体之间的行为和关系，例如评价、出价也可属于这个数据域。
3.3 数据的分层与输出
首先先思考原子指标的产生过程，当A首次关注B时，会产生一条数据，同时落下创建时间，当关注关系发生变更时，会通过逻辑删除字段进行数据的更新，也就是说这是一份频繁变动的数据，那么更适合全量清洗。其次。由于关注表存在多种关注关系，需要确定我们所需的关注是要单独拆分洗表还是合并在一起洗，由于数据量大的原因，这里单独按照用户、直播间、商家的关注进行了三张表的拆分，并统一了字段名。
然后是修饰词部分，修饰词是一种用户的状态，更适合冗余在维表中，但是用户基本的信息维表属于用户域，用户的访问记录又属于日志域，跨数据域进行数据联合需要产生一张新的杂项维度表，在这里就是日志域与用户域的杂项维度。计算这个状态有两种方式，第一种是取近90天的pageshow表，只要有数据就认为他是活跃的，第二种是有一张用户首次登录与最近一次登录的事实表，通过判断用户最近一次登录时间来判断90天内是否活跃。相较于前者，后者读入的数据量更少，计算速度更快。
最后以关注表作为主表，被关注者作为维度进行dws层的汇总，并关联杂项维度表，取出活跃的用户进行COUNT DISTINCT计算，就可以得到最后数据了。
3.4 可拓展性
当数据口径产生变化时，比如口径变成了近90天新增的活跃粉丝数，那么在dws层汇总时我们只需加上时间的限制，下游表所引用的字段及脚本都无需做更改。
4. 总结
数仓分层必须有统一的数据标准、清晰的数据分层结构，既要保证数据层的稳定又要屏蔽对下游的影响，并且避免循环依赖和链路过长，减少重复的开发工作，让计算资源更高效地跑起来，让数据更高质更快速的产出。
- END -