最周全的数仓分层剖析一文搞定企业数仓分层

从事数仓干系事情的职员都知道数仓模型设计的紧张事情之一便是进行模型分层，可见模型分层在模型设计过程中的主要性，确实精良的分层设计是一个数仓项目能否培植成功的核心要素，让数据易理解和高复用是分层的核心目标。

早期作者在考虑对公司数仓制订分层规范时，也是查了很多资料，网上资料也是较为全面，有利用阿里大数据分层方案，也有分三层、或者四五层的都有，这么多分层思路，让作者一阵脑瓜疼。
以是作者希望整理一篇文章，对数仓分层进行一个较为全面的阐发，讲下自己对分层的见地和想法，和大家互换。

本文将对数据仓库分层方法进行全方位的阐述和整理，详细包含如下内容：

通过数据分层管理可以简化数据洗濯的过程，由于把原来一步的事情分到了多个步骤去完成，每一层的处理逻辑都相对大略和随意马虎理解，从而达到解耦的目的，这样我们比较随意马虎担保每一个步骤的精确性，当数据发生缺点的时候，方便问题排查和追溯定位。

分层的核心思想便是解耦，再解耦，把繁芜的问题大略化，这直接影响了数据架构到底分几层。

这里再讲下数据分层的好处：

这里先容一种较为常见，也是适用性较广的四层分层架构，至于出处的话，我觉得该当是阿里吧，感兴趣的同学可以看下《大数据之路：阿里巴巴大数据实践》这本书中有先容，"大众年夜众号回答“大数据图书”可以获取电子版。

数据公共层CDM（Common Data Model）或者 企业级数据仓库EDW （Enterprise Data Warehouse）紧张用于存放明细事实数据、维表数据及公共指标汇总数据，个中明细事实数据、维表数据一样平常根据ODS层数据加工天生；公共指标汇总数据一样平常根据维表数据和明细事实数据加工天生。
本层采取维度模型作为建模方法的理论根本，更多的是通过采取一些维度退化手段，将维度退化至事实表中，减少维表和事实表的关联，提高数据易用性。

三、一些不同的分层思路（大厂数仓分层案例）1. 爱奇艺数仓分层架构

从上图可以看到，可以跟看到实在爱奇艺数仓分层和通用的分层架构差别不太大，也是包含原始数据层、明细层，汇总层、运用层以及统一的维度层，下面紧张先容一些不同的地方。

爱奇艺的架构中，最底层是统一数仓，实在是将原始数据层、统一明细数据层和统一聚合数据层进行了整合。
明细层卖力对接下层所有的原始数据，百分之百还原所有业务域和业务过程的数据，同时屏蔽底层原始数据变动对上层造成的影响，是全体爱奇艺数仓的底层根本。

最底层是统一数仓，紧张分为统一明细数据层和统一聚合数据层。
明细层卖力对接下层所有的原始数据，百分之百还原所有业务域和业务过程的数据，同时屏蔽底层原始数据变动对上层造成的影响，是全体数仓 2.0 的底层根本。

通过明细层完成业务关系到数据关系逻辑转换，并补充干系的维度，保存最细粒度数据，进行繁芜业务逻辑分离、数据洗濯、统一规范化数据格式等 ETL 过程。

聚合层卖力对通用的指标进行沉淀，向上供应统一口径的打算指标，同时避免重复打算。
除此之外，还会供应基于 OneID 体系的统一累计设备库和新增设备库供上层利用。

业务集市紧张以业务诉求为主，培植知足业务剖析的各种数据凑集。
在业务集市培植过程中，按照尽可能细的粒度去划分业务集市，且每个业务集市之间不会涌现数据依赖和横向引用，在运用层可以跨集市进行汇总打算对外供应数据做事。
这样做的好处是，如果涌现一些组织架构调度或者事情职责的变更等情形，每个业务集市无需调度，只需在运用层做相应的修正即可，同时也避免由于打算任务代码混在一起、数据权限拆分等问题带来的数据变更本钱。

主题数仓以公司范围内公共的主题域/主题角度，以同等性维度为根本，跨各业务做数据的整合剖析和干系培植，包括流量数仓、内容数仓、用户数仓等。

运用层包括业务报表、内容剖析、用户运营等数据运用产品，按照详细的场景和需求，从业务集市和主题数仓获取数据。

2. SaaS收银运营数仓分层架构

这里作者的案例是美团站点分享的SaaS收银运营数仓培植一文中的架构，这个分层架构大概是五层，虽然从名称上看着和通用分层架构差异比较大，实际详细功能上，只是增加了一个DWT主题宽表层，APP层和通用的ADS层浸染基本同等，DWA汇总层实在和通用的DWS层是类似的。

DWT层主题宽表层，实在是对DWD各层的信息进行join整合，基于主题，将业务过程干系的数据冗余处理，从而方便上层DWS汇总数据利用。

3. 美团数仓分层架构

从上图中，看起来美团数仓分层架构和通用分层架构也是差异较大，但是实在和通用的分层架构也是异曲同工，只不过是将数据分的更新，做更多的解耦。

ODS数据源层不用多说，名字都和通用的原始数据层同等，下面紧张说下上面四层：

IDL数据集成层，整合多数据源的同等性建模，完成数据维度，事实组合。
这一层要看重分外的两个观点，一是宽表，二是聚合表。
宽表与 kimball 的 fact table 不一样，我们常日所说的fact table，实际上仅仅是明细表的统称，而宽表，则是把干系的事实表，都整合到一起，这样的好处，一是加快速率，二是一次查询更加全面。
这块你看和《SaaS收银运营数仓培植》案例中的DWT又是何其相识。

CDL数据组件层，用来完成聚合汇总，进一步按照粒度划分，完成年月日级的聚合。
至此，一个中心数据仓库就完成了。

MDL数据集市层，按照业务单元，做数据集市。
比如营运，发卖。
这样供应给数据运用层，就有了完全的、可复用的数据源。

1M0t81

终极的ADL运用层，会大略很多，紧张是选型，也便是针对业务数据运用，会选择哪些数据库技能，剖析引擎技能，还有报表打算，归纳起来，离不开存储，打算，可视化。

4. 网易严选数仓分层架构

这里轻微大略说下吧，实在网易严选数仓分层架构和通用数仓分层架构差别不大，也算是直不雅观的利用表示吧。

严选数仓分层模型将数据分为三层，ods，dw和dm层。
个中ods是操作数据层，保留最原始的数据；dw包含dwd和dws层，这两层共同组成中间层；dm是运用层，基于dw层做汇总加工，知足各产品、剖析师和业务方的需求。

5. 网易云音乐数仓分层架构

不多说，这里不同之处在于增加了stg缓冲层，用于存储每天的增量数据和变更数据，合营ODS对数据进行沉淀，减少了抽取的繁芜性，比如进行增量数据的合并操作等。

五、个人对如何设计数仓分层架构的想法（数仓到底分几层）

数据仓库分层没有绝对的规范，适宜的便是最好的，至于分几层，建议按照目前的业务和培植现状，进行合理解构和分层设计，一样平常刚开始做，建议3、4层。
方案1-1.5年的架构，然后不断的培植、优化、再优化。
不断逼近知足所有需求。

下面针对一些场景说下分层的想法：

场景一：韶光紧任务重，急于当作果

这种场景，直接连各个业务数据库，抽取数据到大数据平台，根据需求组合join或者汇总count、sum就行，就不要不分层了，作者现在公司做事的数仓项目前身便是这样，将各个业务系统数据抽取到oracle，你看都没有大数据平台就做了。

场景二：公司业务大略，且相比拟较固定，数据来源不多，构造也很清晰，需求也不多

那么还弄啥来，直策应用通用的数仓架构就行，ODS起到解耦业务数据库+异构数据源的问题，DWD办理数据脏乱差的问题，DWS服用的指标打算，ADS直接面向前台业务需求。

场景三：公司业务繁芜，业务变革较快

那就多一层DWT层做汇总，多一层解耦，业务变革的时候，我们只改DWS层就好了，最多穿透到DWT层。
业务变革的时候调度一下，事情量也不会太大，最主要的是能担保底层构造的稳定和数据剖析的可持续性。

场景四：公司业务较为繁芜，集团性公司，下辖多个部门bu奇迹线，bu间业务内容交叉不大

可以在数仓通用分层架构上，增加一层DM层，也便是数据集市层，各个数据集市层，单独供数，乃至有单独的打算资源，这样可以避免由于打算任务代码混在一起、数据权限拆分等问题带来的数据变更本钱。

六、一个好的数仓模型分层，该当具备的要素

一个好的数仓模型分层，该当具备的要素是数据模型可复用，完善且规范的。

从完善度上来讲，紧张衡量DWD层和汇总层两块的完善度，DWD层完善度，紧张是希望DWD等尽可能被汇总层引用，ODS层被除了DWD层外的尽可能少的引用，最好是没有。

从复用度上来讲，我们希望80%需求由20%的表来支持。
直接点讲，便是大部分（80%以上）的需求，都用DWS的表来支持。

从规范度上来讲，紧张从表名、字段名来看，一个规范的表名该当包括层级、主题域、分区规则，抽取类型等信息。
字段规范该当是和词根同等，同字段同名等，详细这块可以看作者写得《数仓命名规范篇》

七、总结

数据仓库分层没有绝对的规范，适宜的便是最好的，数据仓库分层的核心逻辑是解耦，在有限韶光、资源等条件下知足业务需求，同时又要兼顾业务的快速变革。
以是我们作为数据架构师，须要兼顾业务的繁芜变革，以及开拓的繁芜度和可掩护性，在两者之间做一个平衡和取舍，选择得当的分层架构。

其余分层架构是须要不断的优化调度的，不能超前太多，也不能分开业务。
按照Inmon和Kimball吵了十几年的履历上看，建议架构设计时，按超越当前实际情形1~1.5年的设计是比较得当的。

本文由 @白程序员的自习室 原创发布于大家都是产品经理，未经作者容许，禁止转载。

题图来自Pexels，基于CC0协议。