数仓一般都是用来保存大量的历史数据的，这些数据可能是业务数据也可能是日志数据

数仓分层的原因也即是分层的好处体现在下面几个方面:

1. 分层是一种空间换时间的操作

我们知道数仓一般都是用来保存大量的历史数据的，这些数据可能是业务数据也可能是日志数据。

由于数据量级很大，如果直接查询数仓中的原始数据需要访问的表的数量和底层文件的数量都较多，体现在我们日常工作中就是SQL异常复杂，甚至join和union加一起都不够用，造成的直接后果就是SQL运行很慢，甚至跑不出来结果或者报错。

而分层要做的就是对原始数据重新做归纳整理，在不同层级对数据或者指标做不同粒度的抽象。

经过分层后，同一个指标可能在不同层的数据中都有体现，似乎是“重复”了，但这种重复是一种“不完全”的重复，因为每个层级中指标的粒度是不完全一致的。

这种不是完全重复的重复给我们带来的直接好处就是SQL写起来大大简化了，SQL计算耗时大大降低了。

有人可能会质疑这样会造成存储成本的提高，但是相比带来的直接收益，这一点成本是可接受的，毕竟谁也不想被老板一遍又一遍的dis：我要的数怎么还没有跑出来？

2. 分层有利于减少重复开发

分层把大部分常用的、通用的数据模型和指标进行抽象和汇总，经过这样的处理后生成可满足大部分业务场景使用的数据表和指标。

这些表和指标就类似于程序开发中的公共模块和接口，下游的使用方在使用的时候就不需要再从头开发了，直接拿来用即可。

这样不仅减少了重复开发而且做到了数据和指标的统一。

3. 分层可以把复杂的问题简单化

举个例子，大多数分析师刚到一个新公司的时候常常会被迫接手一个甚至是几个长达上千行的祖传SQL代码，里面join、uoion数不过来，一层又一层嵌套的子查询更是剪不断、理还乱。

遇到这样的情况不知道的小白会认为这个前辈很牛逼，能写出这么长的SQL，甚至窃认为自己很幸运学习到了一个这么牛逼的SQL。

但实际情况往往是数仓分层不合理或者刚开始的时候没有数仓，所有的逻辑都要从最底层的表中来计算，这个时候不复杂都难。

而数仓分层要做的一部分工作就是把这个又臭又长的SQL进行拆解和预处理，一方面就是上面提到的把通用的数据和指标进行归类和预计算，另外一方面就是把JOIN和UNION这些复杂的操作拆解放在数仓的ETL中来处理。

这就是所谓的把复杂的问题简单化。

4. 分层带来更高的数据安全

数据经过分层以后，每层的表的宽度和指标的粒度都不同，这样就可以针对不同的使用的对象开放不同层级的数据。

不需要关心明细数据的对方直接开放聚合度高的数据即可，这样就避免了底层明细、敏感数据的泄漏。

另外在分层处理的时候也可以对一些敏感的字段做删除、脱敏加密的处理，避免因安全控制精细化不够带来的数据使用权限大于申请的权限。

分层的其他好处还包括，数据更加规范有条理，数据血缘更加清晰，数据表和指标的统一等等。

二、常用的数仓分层模型

我们以阿里的数仓架构图为例来说明数仓常用的分层模型。