数据仓库分层架构深度讲解

Posted 2023-03-29

参考技术A

         分层的主要原因是在管理数据的时候，能对数据有一个更加清晰的掌控，详细来讲，主要有下面几个原因：

清晰数据结构：

         每一个数据分层都有它的作用域，这样我们在使用表的时候能更方便地定位和理解。

方便数据血缘追踪：

          简单来说，我们最终给业务呈现的是一个能直接使用业务表，但是它的来源有很多，如果有一张来源表出问题了，我们希望能够快速准确地定位到问题，并清楚它的危害范围。

减少重复开发：

          规范数据分层，开发一些通用的中间层数据，能够减少极大的重复计算。

把复杂问题简单化：

         将一个复杂的任务分解成多个步骤来完成，每一层只处理单一的步骤 ，比较简单和容易理解。而且便于维护数据的准确性，当数据出现问题之后，可以不用修复所有的数据，只需要从有问题的步骤开始修复。

屏蔽原始数据的异常:

         屏蔽业务的影响，不必改一次业务就需要重新接入数据

         数据分层每个企业根据自己的业务需求可以分成不同的层次，但是最基础的分层思想，理论上 数据分为三个层 ， 数据运营层 、 数据仓库层 和 数据服务层 。基于这个基础分层之上添加新的层次，来满足不同的业务需求。

数据运营层(ODS)

         Operate data store（操作数据-存储），是最接近数据源中数据的一层，数据源中的数据，经过抽取、洗净、传输，也就说传说中的ETL之后，装入ODS层 。本层的数据，总体上大多是按照源头业务系统的分类方式而分类的。例如：mysql里面的一张表可以通过sqoop之间抽取到ODS层ODS层数据的来源方式：

数据仓库层（DW）

         Data warehouse（数据仓库） 。在这里， 从ODS层中获得的数据按照主题建立各种数据模型 。例如 以研究人的旅游消费为主题的数据集中 ，便可以结合航空公司的登机出行信息，以及银联系统的刷卡记录，进行结合分析，产生数据集。在这里，我们需要了解四个概念：维（dimension）、事实（Fact）、指标（Index）和粒度（ Granularity）。

数据服务层/应用层（ADS）：         

Application Data Service(应用数据服务)。该层主要是提供数据产品和数据分析使用 的数据，一般会存放在ES、MySQL等系统中供线上系统使用，也可能会存在Hive或者Druid中供数据分析和数据挖掘使用。例如：我们经常说的报表数据，或者说那种大宽表，一般就放在这里。

ODS 数据准备层

功能：         

         ODS层是数据仓库准备区，为DWD层提供基础原始数据，可减少对业务系统的影响

建模方式及原则：     

        从业务系统增量抽取 、保留时间由业务需求决定、 可分表进行周期存储、数据不做清洗转换与业务系统数据模型保持一致 、按主题逻辑划分

DWD 数据明细层

功能：       

       为DW层提供来源明细数据，提供业务系统细节数据的长期沉淀 ，为未来分析类需求的扩展提供历史数据支撑

建模方式及原则：       

        数据模型 与ODS层一致，不做清洗转换处理 、为支持数据重跑 可额外增加数据 业务日期字段、可按年月日进行分表、用增量ODS层数据和前一天DWD相关表进行merge处理

DW(B/S) 数据汇总层

功能：         

       为DW、ST层提供细粒度数据，细化成DWB和DWS；       

        DWB是根据DWD明细数据进行转换 ，如维度转代理键、身份证清洗、会员注册来源清晰、字段合并、空值处理、脏数据处理、IP清晰转换、账号余额清洗、资金来源清洗等；      

         DWS是根据DWB层数据按各个维度ID进行高粒度汇总聚合 ，如按交易来源，交易类型进行汇合

建模方式及原则：

         聚合、汇总增加派生事实；

         关联其它主题的事实表，DW层可能会跨主题域；

         DWB保持低粒度汇总加工数据，DWS保持高粒度汇总数据；

         数据模型可能采用反范式设计，合并信息等。

Data Market (数据集市)层

功能：        

        可以是一些宽表，是根据DW层数据按照各种维度或多种维度组合把需要查询的一些事实字段进行汇总统计并作为单独的列进行存储 ；         

        满足一些特定查询、数据挖掘应用        

         应用集市数据存储

建模方式及原则：         

      尽量减少数据访问时计算 (优化检索)        

      维度建模，星型模型；         

      分表存储

ST 数据应用层（ADS层）

功能：        

        ST层面向用户应用和分析需求 ，包括前端报表、分析图表、KPI、仪表盘、OLAP、专题等分析， 面向最终结果用户          

     适合做OLAP、报表模型，如ROLAP,MOLAP

         根据DW层经过聚合汇总统计后的粗粒度事实表

建模方式及原则：         

         本篇文章主要讲解数仓项目中为什么分层，比如 我们在完成一个需要的需求的时候也许只需要一个复杂的SQL语句就可以完成。但一个复杂的SQL语句方便后面维护吗？当出现了问题方便追踪吗？ 这时候就体现出分层的好处。顺便给大家分享阿里的数仓模型是什么样的。信自己，努力和汗水总会能得到回报的。我是大数据老哥，我们下期见~~~

数据仓库的分层架构与演进

简介：分层架构很容易在各种书籍和文档中去理解，但是把建模方法和分层架构放在一起就会出现很多困惑了。接下来，我会从数据研发与建模的角度，演进一下分层架构的设计原因与层次的意义。

分层架构很容易在各种书籍和文档中去理解，但是把建模方法和分层架构放在一起就会出现很多困惑了。

一、分层的演进

之所以会有分层架构，最主要的原因还是要把复杂冗长的数据吹流程分拆成一些有明确目的意义的层次，这样复杂就被拆解为一些相对简单小的模块。那么分层架构中各层都是怎么产生的呢，我们可以简化看一下。

第一个数据加工任务

我要进行第一个数据加工任务，一切平台层次都没有，我只有一个MaxCompute。我该怎么做呢？

第一步，我需要自己做一下数据集成，把源系统的数据集成到MaxCompute。

第二步，我需要把增量合并全量生成ODS层，这样我就得到了与业务系统一样的表结构和全量的数据。

第三步，因为我对业务系统的数据表关联关系有了解，所以，我可以根据业务需求使用ODS的全量表做表关联，加工出我想要的数据结果。

第一个数据应用

如果我不只是做一个业务需求，我是有很多业务需求，这样我就形成了我的第一个数据应用。所以，我会集成更多的数据，做更多的数据合并全量的工作，并且我的全量ODS的表可以在多个业务场景复用。

但是试想一下，如果不是一个人在开发，那么团队内部是不是要协调一下，对工作进行一下分工。做集成的和做合并的是不是可以分给一部分人，然后把后面业务需求开发再分给另外一部分人。这样就避免了重复工作，和便于工作的专业性。

于是就可以拆分出来上图中的第一个方块“集成”（STG）和第二个方块 “全量”（ODS），这部分是纯技术性的工作，还没有涉及到业务需求。对于实际业务需求计算部分，就是我们的应用层集市层（ADM）。

第二个数据应用

随着第二个数据应用的出现，各自做集成合并已经是非常不适合的做法了，于是就有个独立的STG和ODS层。

很多时候，做完ODS就可以做业务数据加工了。并且这种情况从数据处理技术发展之初，数据仓库概念提出之前就存在了，现在依然很普遍。集市各自依赖ODS会遇到的多源加工指标不一致的问题逐渐遭人诟病，而造成指标不一致的主要原因重复加工。不同的人对同一业务的理解都很难保障一致性，更何况不同的部门的应用。对于这个问题，可以在各个大型企业早期的数据场景都会遇到，所以，在阿里对外宣传大数据平台的时候也会提到这个早期各个业务部门数据口径不一致的问题。这个问题在ODS的层面无法解决，必须要独立出一个团队来做公共的这部分数据，让各个应用集市去做各自独立的部分，这也是公共层（CDM）的由来。

二、分层与建模

通过上面的内容，我们终于知道了数据加工过程为什么要分层。那么数据建模应该如何来做呢？因为在数据仓库领域，在数据建模一直有两种争锋相对的观点，就是范式建模还是维度建模。我们在目前大数据这个场景，一般就只提一种方法了，就是维度建模。

维度建模的经典方法与教程中没有中间层的概念，也没有主题域划分的概念。维度建模一般用在数据集市场景，也就是ODS+ADM场景，各个业务通过一致性维度实现企业级的数据一致性。在传统的被IOE统治的时代，Teradata、IBM、Oracle都有基于关系型数据库（包括MPP数据库），在某些重要的行业，例如金融这些企业都会构建大型的企业级的维度模型来给集市提供公共数据服务，这就是公共层。因为范式模型导致实体都比较窄，跟实际的分析型业务需求（维度模型）差异太大，所以需要做一层中间层（相对范式模型更宽的表，这也是宽表说法的由来）来做为应用集市层共性加工工作的层次，这就是现在我们在架构中提到的ODS+CDM+ADM的架构。

那么问题就在这里出来了，我们全部使用维度模型建模，如何使用范式模型的架构与概念。这也是我们在分层架构设计中目前最难以讲清楚的问题，也是我们实际在项目里面做的很别扭的原因：缺乏理论与实践支撑。

维度模型的构建是以实际业务需求为导向，模型是不断的需求累积出来的，适应快速的业务变化。而且维度模型不是一个建议一开始就进行企业级的思考设计的模型设计方法，是由局部业务逐渐扩张构建的。所以，我认为维度模型的架构不太适宜一开始做太重的太业务化公共层。反而应该强调在公共层构建共性加工的集合，去协调同步多个应用集市的计算，从而实现全局性的一致性维度和一致性事实。因为维度建模的建设也不是简单一蹴而就的，也是需要多次和多种数据处理以后才能最终变成符合业务需求的结果。多个不同的应用集市有大量的共性的加工需求，这些需求就是我们公共层的收集的建模需求。把这些共性需求在公共层使用维度建模的方法实现才是建设公共层的合理方法，而不是越俎代庖的去建设面向具体某个业务场景的指标标签（就是虽然实际是做了指标和标签的计算，但是我只是一个中间加工过程）。

接下来，我们继续利用上面讲解分层的方法来讲解公共层与集市层的关系。

第一个应用

随着第一个应用出现，就可以基于部分的需求构建第一个公共层了。共性加工需求在一个中型的应用集市就很明显了。一、数据清洗。一个表的数据清洗后，会有多个数据加工任务都会使用这个清洗后的表，这就是最简单的共性加工的理解。二、多表关联。多张表的关联也是多个数据加工任务中可以提炼出来的，一次把需要关联使用的字段都关联合并到一张新表，后续的任务就可以直接用这个新表。三、共性汇总。对于数据从明细到汇总的group by，统一根据多个常用条件进行汇总，生成一张新表，后续的任务就可以直接用这个新表。一致性维度是维度建模中最关键的部分，直接影响到各个应用集市的数据标准与一致性问题，是公共层最重要的工作。

第二个应用

随着应用的增加，需求也在不断的扩充，临时层和镜像层集成的表更多了。在公共层的明细和汇总也出现了多个应用集市都在共用的数据需求，会扩展补充到公共层。并且随着时间的变化，公共层的逻辑的正确性和公共性也需要在多个应用进入后整体考虑。

公共层与应用关系

通过上面两步演进，我们已经看到了公共层与应用层的关系了，是一体的。并不是各做各的，而是一件事情从专业化分工上做了切分。公共层与应用层只有一个共同目标，就是为满足业务需求而做数据加工。不同侧重的是应用层只需要关注自己部门的最终业务目标，公共层则需要从企业级的全局一致性、资源经济性上全盘考虑。

公共层与应用层的关系就是后勤部队与前方作战部队的关系，一个负责基础的材料准备工作，一个负责利用这些输出投入到真实战场。公共层是高效的数据复用和综合更低的资源代价，应用层则就是实际的业务需求。所以，最终的业务模型在应用层才有完整的针对性业务场景，在公共层是模型是多种场景业务需求的一个复合，代表了平台最基础和最通用的模型。

从层次上来说，公共层向下是一块整体，负责跟上游多个交易型业务系统对接，对应用集市屏蔽了上游变化带来的影响，使得应用层能只关注于利用公共层的模型解决自己的业务需求。

原文链接

本文为阿里云原创内容，未经允许不得转载。