数仓分层的原因也即是分层的好处体现在下面几个方面:我们知道数仓一般都是用来保存大量的历史数据的，这些数据可能是业务数据也可能是日志数据，由于数据量级很大，如果直接查询数仓中的原始数据需要访问的表的数量和底层文件的数量都较多，体现在我们日常工作中就是SQL异常复杂，甚至join和union加一起都不够用，造成的直接后果就是SQL运行很慢，甚至跑不出来结果或者报错。而分层要做的就是对原始数据重新做归纳整理，在不同层级对数据或者指标做不同粒度的抽象。经过分层后，同一个指标可能在不同层的数据中都有体现，似乎是“重复”了，但这种重复是一种“不完全”的重复，因为每个层级中指标的粒度是不完全一致的。这种不是完全重复的重复给我们带来的直接好处就是SQL写起来大大简化了，SQL计算耗时大大降低了。有人可能会质疑这样会造成存储成本的提高，但是相比带来的直接收益，这一点成本是可接受的，毕竟谁也不想被老板一遍又一遍的dis：我要的数怎么还没有跑出来？分层把大部分常用的、通用的数据模型和指标进行抽象和汇总，经过这样的处理后生成可满足大部分业务场景使用的数据表和指标。这些表和指标就类似于程序开发中的公共模块和接口，下游的使用方在使用的时候就不需要再从头开发了，直接拿来用即可。这样不仅减少了重复开发而且做到了数据和指标的统一。举个栗子，大多数分析师刚到一个新公司的时候常常会被迫接手一个甚至是几个长达上千行的祖传SQL代码，里面join、uoion数不过来，一层又一层嵌套的子查询更是剪不断、理还乱。遇到这样的情况不知道的小白会认为这个前辈很牛逼，能写出这么长的SQL，甚至窃认为自己很幸运学习到了一个这么牛逼的SQL。但实际情况往往是数仓分层不合理或者刚开始的时候没有数仓，所有的逻辑都要从最底层的表中来计算，这个时候不复杂都难。而数仓分层要做的一部分工作就是把这个又臭又长的SQL进行拆解和预处理，一方面就是上面提到的把通用的数据和指标进行归类和预计算，另外一方面就是把JOIN和UNION这些复杂的操作拆解放在数仓的ETL中来处理。这就是所谓的把复杂的问题简单化。数据经过分层以后，每层的表的宽度和指标的粒度都不同，这样就可以针对不同的使用的对象开放不同层级的数据。不需要关心明细数据的对方直接开放聚合度高的数据即可，这样就避免了底层明细、敏感数据的泄漏。另外在分层处理的时候也可以对一些敏感的字段做删除、脱敏加密的处理，避免因安全控制精细化不够带来的数据使用权限大于申请的权限。分层的其他好处还包括，数据更加规范有条理，数据血缘更加清晰，数据表和指标的统一等等。我们以阿里的数仓架构图为例来说明数仓常用的分层模型。阿里整体数据分了5层，分别是ODS,DWD, DIM,DWS,ADS，下面我们分别介绍一下。ODS(Operation Data Store)层，中文通常有两种叫法，分别是贴源数据层和操作数据层。前者是站在与数据源的关系层面来说的，也就是说这一层的数据是跟数据源的数据是一致的，所以称其为贴源数据层。后者是站在数据产生的层面来说的，也就是说这一层的数据是公司发生的一系列业务动作产生形成的，所以叫操作数据层。我们可以看到不论是哪一种叫法都体现了与源数据的一致性。所以这一层的数据一般来说是与业务库中中的数据保持一致的，也即是说这一层的数据来源于业务mysql、oracle等库中或者日志中，在同步的过程中不对数据做任何处理，保证与源数据的一致。这一层是最基础也是最重要的一层，就像大厦的地基一样，地基不牢，越是高层越是不稳定。DWD（Data Warehouse Detail），中文称之为明细数据层。这一层在与原表保持同一粒度的基础上根据业务过程对ODS的数据进行去除脏数据，按照业务过程对表进行归类和关联，经过ETL得到与业务过程相对应的事实表。通常是实际业务中按照维度建模的方式把一些常用的维度也会冗余的到这一层的表中以降低数据查询的成本。需要特别提醒的是这一层的数据在粒度上仍然是明细数据，是没有进行聚合的，只是表变得更宽了些。DIM(Dimension)，中文称之为维度数据层。这一层其实是与DWD平行的一个层级，是对业务中常用维度的建模和抽象，例如常见的地域维度，日期维度，商品品类SKU等维度。所谓的维度也即是我们看数据和分析数据的一种习惯和视角。这一层通常存储的是完整的维度key和维度的名称，而事实表中通常存储的是维度key的字段。DWS（Data Warehouse Service），直译为数据服务层，我们通常称其为汇总数据层。这一层的数据来源基本上都是DWD和DIM，通常是把DWD中的事实表的key和DIM中的维度key关联，然后对事实按照更高的维度进行上卷的聚合操作，得到在某一维度或者多个维度上的汇总数据或指标。需要提醒的是数据在这一层发生了粒度变化，不再是明细的数据，而是聚合后的数据，这也是这一层别称之为汇总数据层的原因。ADS（Application Data Service），直译应用数据服务层，也就是我们通常说的应用层或者指标层。这一层的数据来源可以是DWD层，也可以是DWS层，或者是二者的混合计算。这一层的数据也是聚合后的数据。那么它与DWS层的区别是什么呢？DWS通常是对明细数据按照常用的维度所做的较低维度的聚合汇总，而ADS层通常是面向具体应用（报表、接口等）的较高维度的数据指标的聚合汇总。举一个不是特别恰当但是很能说明问题的栗子，DWD的10条数据可能在DWS中聚合成了5条，但是在ADS中可能被聚合成了1条，所以二者的聚合度是不一致的。不过也可能存在二者的聚合度一致，但此时ADS层的表中的字段更多或者更少，这也是体现了其面向具体应用的含义。以上是阿里数仓的主要分层，抛开具体的层次名称，一般意义上数仓可分为三个大的层次，分别是原始数据层，也就是数仓中数据的来源；清洗处理层，也就是对原始数据经过各种操作后形成的数据；面向应用层，也就是说是针对单个特定的数据需求清洗而形成的数据。明白了这层含义，我也就不用再解释其他一些诸如DWM,FACT,DW,DM等的写法和叫法了，这些都只是表象，核心还是上面说的三层的本质。好多同学可能看了上面的分层介绍后觉得分层不就是那么回事吗？可是一到实际的场景中就犯了难，ODS中还好说，可是后面要分几层，每一层的原则和依赖怎么定义？针对一个具体表是放在ADS层合适呢还是放在DWS层合适呢？下面就来跟大家说说如何对你的数仓分层。首先我们要记住一个原则：不要为了分层而去分层，盲目的分层不但会造成数仓中表的混乱而且造成很大的资源浪费更是给后面的数据治理留下的无穷的隐患。分层的目的是让数据更规范、清晰更易用而不是为了让层次更多。两点要牢记的是越是往上层数据的粒度就越粗，所表达的内容就越有限，所以不是层级越多越好；本层的表一般只允许依赖他紧邻的上一层，应严格避免同层依赖，否则极易产生循环依赖。
知道了上面的原则和要点，我的建议是如果业务场景比较简单且数据表也不是很多，三层就足够了；如果业务场景和过程比较复杂，指标口径需要很多表关联才能计算的话建议四层或者更多的层。不要为了分层而分层也不要被这个层所层层困住。一千个读者可能有一千种分层的想法，一千个公司可能也有一千种分层的方法，适合自己的就是最好的。
发表评论 取消回复