大数据02-数据仓库

零、文章目录

大数据02-数据仓库

1、数据仓库介绍

（1）基本概念

数据仓库，英文名称为Data Warehouse，可简写为DW或DWH。数据仓库的目的是构建面向分析 的集成化数据环境，为企业提供决策支持（Decision Support）。它出于分析性报告和决策支持目的而创建。
数据仓库本身并不"生产"任何数据，同时自身也不需要"消费"任何的数据，数据来源于外部，并且开放给外部应用，这也是为什么叫"仓库"，而不叫"工厂"的原因。

（2）主要特征

面向主题

传统数据库中，最大的特点是面向应用进行数据的组织，各个业务系统可能是相互分离的。而数据仓库则是面向主题的。主题是一个抽象的概念，是较高层次上企业信息系统中的数据综合、归类并进行分析利用的抽象。在逻辑意义上，它是对应企业中某一宏观分析领域所涉及的分析对象。
操作型处理（传统数据）对数据的划分并不适用于决策分析。而基于主题组织的数据则不同，它们被划分为各自独立的领域，每个领域有各自的逻辑内涵但互不交叉，在抽象层次上对数据进行完整、一致和准确的描述。一些主题相关的数据通常分布在多个操作型系统中。

集成性

通过对分散、独立、异构的数据库数据进行抽取、清理、转换和汇总便得到了数据仓库的数据，这样保证了数据仓库内的数据关于整个企业的一致性。
数据仓库中的综合数据不能从原有的数据库系统直接得到。因此在数据进入数据仓库之前，必然要经过统一与综合，这一步是数据仓库建设中最关键、最复杂的一步，所要完成的工作有：
- （1）要统一源数据中所有矛盾之处，如字段的同名异义、异名同义、单位不统一、字长不一致，等等。
- （2）进行数据综合和计算。数据仓库中的数据综合工作可以在从原有数据库抽取数据时生成，但许多是在数据仓库内部生成的，即进入数据仓库以后进行综合生成的。
下图说明一个保险公司综合数据的简单处理过程，其中数据仓库中与"保险"主题有关的数据来自于多个不同的操作型系统。这些系统内部数据的命名可能不同，数据格式也可能不同。把不同来源的数据存储到数据仓库之前，需要去除这些不一致。

非易失性（不可更新性）

操作型数据库主要服务于日常的业务操作，使得数据库需要不断地对数据实时更新，以便迅速获得当前最新数据，不至于影响正常的业务运作。在数据仓库中只要保存过去的业务数据，不需要每一笔业务都实时更新数据仓库，而是根据商业需要每隔一段时间把一批较新的数据导入数据仓库。
数据仓库的数据反映的是一段相当长的时间内历史数据的内容，是不同时点的数据库快照的集合，以及基于这些快照进行统计、综合和重组的导出数据。
数据非易失性主要是针对应用而言。数据仓库的用户对数据的操作大多是数据查询或比较复杂的挖掘，一旦数据进入数据仓库以后，一般情况下被较长时间保留。数据仓库中一般有大量的查询操作，但修改和删除操作很少。因此，数据经加工和集成进入数据仓库后是极少更新的，通常只需要定期的加载和更新。

时变性

数据仓库包含各种粒度的历史数据。数据仓库中的数据可能与某个特定日期、星期、月份、季度或者年份有关。数据仓库的目的是通过分析企业过去一段时间业务的经营状况，挖掘其中隐藏的模式。虽然数据仓库的用户不能修改数据，但并不是说数据仓库的数据是永远不变的。分析的结果只能反映过去的情况，当业务变化后，挖掘出的模式会失去时效性。因此数据仓库的数据需要更新，以适应决策的需要。从这个角度讲，数据仓库建设是一个项目，更是一个过程。数据仓库的数据随时间的变化表现在以下几个方面。
- （1）数据仓库的数据时限一般要远远长于操作型数据的数据时限。
- （2）操作型系统存储的是当前数据，而数据仓库中的数据是历史数据。
- （3）数据仓库中的数据是按照时间顺序追加的，它们都带有时间属性。

（3）数据仓库VS数据库

数据库与数据仓库的区别实际讲的是OLTP与OLAP的区别。
- 操作型处理，叫联机事务处理OLTP（On-Line Transaction Processing，），也可以称面向交易的处理系统，它是针对具体业务在数据库联机的日常操作，通常对少数记录进行查询、修改。用户较为关心操作的响应时间、数据的安全性、完整性和并发支持的用户数等问题。传统的数据库系统作为数据管理的主要手段，主要用于操作型处理。
  - 分析型处理，叫联机分析处理OLAP（On-Line Analytical Processing）一般针对某些主题的历史数据进行分析，支持管理决策。
首先要明白，数据仓库的出现，并不是要取代数据库。数据仓库，是在数据库已经大量存在的情况下，为了进一步挖掘数据资源、为了决策需要而产生的，它决不是所谓的"大型数据库"
- 数据库是面向事务的设计，数据仓库是面向主题设计的。
  - 数据库一般存储业务数据，数据仓库存储的一般是历史数据。
  - 数据库设计是尽量避免冗余，一般针对某一业务应用进行设计，比如一张简单的User表，记录用户名、密码等简单数据即可，符合业务应用，但是不符合分析。数据仓库在设计是有意引入冗余，依照分析需求，分析维度、分析指标进行设计。
  - 数据库是为捕获数据而设计，数据仓库是为分析数据而设计。

2、数据仓库系统流程

（1）系统流程图

数据仓库提供企业决策分析的数据环境，数据从哪里获取？数据如何存储到数据仓库？决策分析系统如何从数据仓库获取数据进行分析？我们可以把数据从获取、存储到数据仓库、数据分析的所有部分称为一个数据仓库系统，本节讲解数据仓库系统的工作流程和系统架构。
下图是数据仓库系统的结构图：

以下系统各部分的执行流程是：
- 1、确定分析所依赖的源数据。
- 2、通过ETL将源数据采集到数据仓库。
  - 3、数据按照数据仓库提供的主题结构进行存储。
  - 4、根据各部门的业务分析要求创建数据集市（数据仓库的子集）。
  - 5、决策分析、报表等应用系统从数据仓库查询数据、分析数据。
  - 6、用户通过应用系统查询分析结果、报表。

（2）源数据

源数据是指用于分析的原始数据，这一步主要是根据分析需求确定源数据，这个数据分布在内部系统和外部分系统中，内部数据主要是企业ERP系统、外部数据是指企业外部分系统所产生的数据，通常是指行业数据。源数据最大的特点是格式不统一，如果要对源数据进行分析需要经过ETL对数据进行集中获取、过虑、转换等处理。

（3）ETL

ETL（Extra, Transfer, Load）包括数据抽取、数据转换、数据装载三个过程。
- 抽取：数据抽取是从各各业务系统、外部系统等源数据处采集源数据。
- 转换：采集过来的源数据如果要存储到数据仓库需要按照一定的数据格式对源数据进行转换，常见的转换方式有数据类型转换、格式转换、缺失值补充、数据综合等。
- 装载：转换后的数据就可以存储到数据仓库中，这个过程要装载。数据装载通常是按一定的频率进行的，比如每天装载当天的订单数据、每星期装载客户信息等。

（4）数据仓库与数据集市

**数据仓库是用于企业整体分析的数据集合，**比如分为：销售主题、客户主题、产品主题等。**数据集市是用于部门分析的数据集合，**从范围上来讲它属于数据仓库的子集，比如：销售部门的数据集市只有销售主题。
为什么会有数据集市的概念？
- 通常从企业整体出发去建数据仓库比较困难，所涉及到的业务及分析需求比较多，所以提出数据集市的概念，可以先从某个部门开始建设数据仓库，这样效率就比较高。
- 业界把从企业整体出发建设数据仓库的过程叫自顶向下，把从数据集市开始建设数据仓库再逐渐完善整个数据仓库的过程叫自下向上。通常建议自下向上建设数据仓库，不过这个在业界也存在争议。
数据仓库和数据集市具有什么区别？
- 范围的区别：数据仓库是针对企业整体分析数据的集合。数据集市是针对部门级别分析的数据集合。
- 数据粒度不同：数据仓库通常包括粒度较细的数据明细。数据集市则会在数据仓库的基础上进行数据聚合，这些聚合后的数据就会直接用于部门业务分析。

（5）应用系统

这里的应用系统是指使用数据仓库完成数据分析、数据查询、数据报表等功能的系统。应用系统需要从数据仓库中查询数据、分析数据，比如：OLAP 系统、数据查询系统等。

（6）用户

使用数据仓库系统的用户主要有数据分析人员、管理决策人员（公司高层）等。

3、维度分析

（1）介绍

对数据进行分析通常采取维度分析，比如：用户提出分析课程访问量的指标，为了满足不同的分析需求可以从时间维度分析课程访问量，分析每天、每小时的课程访问量；也可以从课程维度来分析课程访问量，分析每个课程、每个课程分类的访问量。

（2）指标与维度

指标是衡量事务发展的标准，也叫度量，如销售额，销量等，多为行为事实数据；指标可以求和、求平均值等计算。
维度是事务的特征，如颜色、区域、时间等，可以根据不同的维度来对指标进行分析对比。比如根据区域维度来分析不同区域的产品销量，根据时间来分析每个月产品的销量，同一个产品销量指标从不同的维度分析会得出不同的结果。
用具体的指标数值, 来度量不同的维度。x轴和y轴的关系。

（3）下钻与上卷

维度中有不同的层次，每个层次可以有多个级别，这样就可以根据多个维护层次和级别进行分析，可以灵活获取高级别的汇总信息，获取低级别的明细信息。
把获取高级别的汇总信息的过程叫上卷，把获取低级别的明细信息的过程叫下钻，比如：课程访问量分析，时间维度有四个级别，分别是年、月、天、小时，现在我们某个级别分析每天的课程访问量，比如按天分析课程访问量，此时我们可以按小时下钻分析，得出一天内每小时的课程访问量，也可以按月上卷，得到月度的课程访问量。
比如下钻维度：天、小时上卷维度：年、月

4、数仓模型

（1）数仓建模方法

数据仓库建模的方法常用的有两种：三范式建模法、维度建模法
- 三范式建模法主要是应用于传统的企业级数据仓库，这类数据仓库通常使用关系型数据库实现，是由Inmon提出的，应用于自顶向下的数据仓库架构;
- 维度数据模型就是基于维度分析来创建模型，是由Kimball提出，应用于自下向上的数据仓库架构。我们主要介绍维度建模。
维度建模，简称DM（Dimensional modeling），数据仓库大师Kimball的观点：维度数据模型是一种趋向于支持最终用户对数据仓库进行查询的设计技术 ，是围绕性能和易理解性构建的。维度模型是按照用户看待或分析数据的角度来组织数据。

（2）维度建模：事实表&维度表

事实表

事实表记录了特定行为事件的数字化信息 ，一般由数值型数字 和指向维度表的外键组成。此类数据的数据量较大，更新比较频繁。
事实表的设计依赖于业务系统，事实表的数据可以计算出业务系统的指标数据 。数据分析的实质就是基于事实表开展的计算操作。

维度表

维度是指观察数据的角度 ，一般是一个名词，比如对于销售金额这个事实，我们可以从销售时间、销售产品、销售店铺、购买顾客等多个维度来观察分析。维度表的记录数比事实表少，但是每条记录可能会包含很多字段。
维表层主要包含两大类数据：
- 高基数维度数据：一般是用户资料表、商品资料表类似的资料表。数据量可能是千万级或者上亿级别。
- 低基数维度数据：一般是配置表，比如枚举值对应的中文含义，或者日期维表、地理维表等。数据量可能是个位数或者几千条几万条。
- 基数指的是一个字段中不同值的个数，比如主键列具有唯一值，所以具有最高的基数，而性别枚举值（日期、地区等）这样的列的基数就很低。

案例

时间维度表：描述事件发生的时间，数据仓库就是一个随时间变化的数据集合，因此可能需要一个时间维度表。年月日时分秒。
地理维度表：描述地理位置信息数据，国家、省市县镇村、邮编等。
产品维度表：描述产品属性。比如书的分类，有科技、教育、小说等分类属性。
人员维度表：描述人员相关信息，销售人员、市场人员、开发人员等。

事实数据一般是Y轴，维度数据一般是X轴

（3）维度模型：星型模型&雪花模型

星型模型

是一种多维的数据关系。一个事实表为中心，多个维度表环绕周围。
一个星型模型中可以有一个或多个事实表，每个事实表可以引用任意数量的维度表。
星型模型将业务流程分为事实和维度。事实是对业务的度量，是定量的数据，比如价格、销售数量、距离、速度、质量等。维度是对事实数据属性的描述，比如日期、产品、客户、地理位置等。

雪花模型

当有一个或多个维表没有直接连接到事实表上 ，而是通过其他维表连接到事实表上时，就像多个雪花连接在一起，故称雪花模型。雪花模型是对星型模型的扩展，它对星型模型的维表进一步层次化，原有的各维表可能被扩展为小的事实表，形成一些局部的 "层次 " 区域，这些被分解的表都连接到主维度表而不是事实表。

如何将维度表进行层次化处理呢？

即把低基数（重复比较多、辨识度比较低、维度数据少，比如性别）的属性从维度表中移除并形成单独的表。
比如之前讲到的案例，购买量指标有课程维度，课程维度又可以将课程分类进行层次化扩展为新的维度表。

层次化的影响

层次化的过程是将维度表中重复度比较高的字段组成一个新表，所以层次化不可避免增加了表的数量，减少了数据的存储空间，提高了数据更新的效率。但是查询时就需要连接更多的表。
总结，雪花模型中，一个维度被规范化成多个关联的表，星型模型中，每个维度由一个单一的维度表所表示。

（4）渐变维（SCD）

什么是渐变维

维度可以根据变化剧烈程度主要分为无变化维度 和变化维度。例如一个人的相关信息，身份证号、姓名和性别等信息数据属于不变的部分；而婚姻状态、工作经历、工作单位和培训经历等属于可能会变化的字段。
大多数维度数据随时间的迁移是缓慢变化的。比如增加了新的产品，或者产品的ID号码修改了，或者产品增加了一个新的属性，此时，维度表就会被修改或者增加新的记录行。这样，在设计维度和使用维度的过程中，就要考虑到缓慢变化维度数据的处理。
缓慢渐变维 ，即维度中的属性可能会随着时间发生改变 ，比如包含用户住址Address的DimCustomer维度，用户的住址可能会发生改变，进而影响业务统计精度，DimCustomer维度就是缓慢渐变维（SCD）。
我们这里以顾客表为例来进行说明：
- 假设在第一次从业务数据库中加载了一批数据到数据仓库中，当时业务数据库有这样的一条顾客的信息。
- 顾客 BIWORK ，居住在北京，目前是一名 BI 的开发工程师。假设 BIWORK 因为北京空气质量 PM2.5 等原因从北京搬到了三亚。那么这条信息在业务数据库中应该被更新了。
- 我们假设在数据仓库中实现了与业务数据库之间的同步，数据仓库中也直接将词条数据修改更新。后来我们创建报表做一些简单的数据统计分析，这时在数据仓库中所有对顾客 BIWORK 的销售都指向了 BIWORK 新的所在地 - 城市三亚，但是实际上BIWORK 在之前所有的购买都发生在BIWORK 居住在北京的时候。
- 通过这个简单的例子，描述了因一些基本信息的更改可能会引起数据归纳和分析出现的问题。

SCD1（缓慢渐变类型1）

通过更新维度记录直接覆盖 已存在的值。不维护记录的历史 。一般用于修改错误的数据，即历史数据就是错误数据，除此没有他用。
在数据仓库中，我们可以保持业务数据和数据仓库中的数据始终处于一致。可以在 Customer维度中使用来自业务数据库中的Business Key - CustomerID 来追踪业务数据的变化，一旦发生变化那么就将旧的业务数据覆盖重写。
DW 中的记录根据业务数据库中的 CustomerID 获取了最新的 City 信息，直接更新到 DW中。

SCD2（缓慢渐变类型2）

在源数据发生变化时，给维度记录建立一个新的"版本"记录 ，从而维护维度历史。SCD2不删除、不修改已存在的数据。SCD2也叫拉链表。
在数据仓库中有很多需求场景会对历史数据进行汇总和分析，因此会尽可能的维护来自业务系统中的历史数据，使系统能够真正捕获到这种历史数据的变化。
以上面的例子来说，可能需要分析的结果是 BIWORK 在 2012年的时候购买额度整体平稳，但是从2013年开始购买额度减少了。出现的原因可能与所在的城市有关系，在北京的门店可能比在三亚的门店相对要多一些。
像这种情况，就不能很简单在数据仓库中将 BIWORK 当前所在城市直接更新，否则此用户所有的购买额度都会归于三亚。
通过起始时间来标识，Valid To（封链时间）为 NULL 的标识当前数据，也可以用2999，3000，9999等等比较大的年份。数仓内部需要保持统一。每个版本都会产生一行新的数据。

SCD3（缓慢渐变类型3）

实际上SCD1 and 2 可以满足大多数需求了，但是仍然有其它的解决方案，比如说 SCD3。SCD3希望只维护更少的历史记录。
比如说把要维护的历史字段新增一列，然后每次只更新 Current Column 和 Previous Column。这样，只保存了最近两次的历史记录，历史数据都在同一行数据中。但是如果要维护的字段比较多，就比较麻烦，因为要更多的 Current 和 Previous 字段。所以 SCD3 用的还是没有SCD1 和 SCD2 那么普遍。它只适用于数据的存储空间不足并且用户接受有限历史数据的情况。

5、数据仓库分层

（1）为什么要分层

作为一名数据的规划者，我们肯定希望自己的数据能够有秩序地流转，数据的整个生命周期能够清晰明确被设计者和使用者感知到。直观来讲就是如图这般层次清晰、依赖关系直观。

但是，大多数情况下，我们完成的数据体系却是依赖复杂、层级混乱的。如下图，在不知不觉的情况下，我们可能会做出一套表依赖结构混乱，甚至出现循环依赖的数据体系。

因此，我们需要一套行之有效的数据组织和管理方法来让我们的数据体系更有序，这就是谈到的数据分层。数据分层并不能解决所有的数据问题，但是，数据分层却可以给我们带来如下的好处：
- 清晰数据结构：每一个数据分层都有它的作用域和职责，在使用表的时候能更方便地定位和理解。
- 复杂问题简单化：将一个复杂的任务分解成多个步骤来完成，每一层解决特定的问题。
- 便于维护：当数据出现问题之后，可以不用修复所有的数据，只需要从有问题的步骤开始修复。
- 减少重复开发：规范数据分层，开发一些通用的中间层数据，能够减少重复开发的工作量。
- 高性能：数据仓库的构建将大大缩短获取信息的时间，数据仓库作为数据的集合，所有的信息都可以从数据仓库直接获取，尤其对于海量数据的关联查询和复杂查询，所以数据仓库分层有利于实现复杂的统计需求，提高数据统计的效率。

（2）常规分层方法

尽管不同的公司和业务线的层级有的是四层，有的是五层，但究其本质都是三层结构，按照数据流入流出的过程，数据仓库架构可分为三层------源数据层（ODS） 、数据仓库层（DW） 、数据应用层（DA 或 APP）。

源数据层ODS（Operation Data Store）

此层数据无任何更改，直接沿用外围系统数据结构和数据，不对外开放；为临时存储层，是接口数据的临时存储区域，为后一步的数据处理做准备。

数据仓库层DW（Data Warehouse）

DW 层的数据应该是一致的、准确的、干净的数据，即对源系统数据进行了清洗（去除了杂质）后的数据。此层可以细分为三层：
- 明细层DWD（Data Warehouse Detail）：存储明细数据，此数据是最细粒度的事实数据。该层一般保持和ODS层一样的数据粒度，并且提供一定的数据质量保证。同时，为了提高数据明细层的易用性，该层会采用一些维度退化手法，将维度退化至事实表中，减少事实表和维表的关联。
- 中间层DWM（Data WareHouse Middle）：存储中间数据，为数据统计需要创建的中间表数据，此数据一般是对多个维度的聚合数据，此层数据通常来源于DWD层的数据。
- 业务层DWS（Data WareHouse Service）：存储宽表数据，此层数据是针对某个业务领域的聚合数据，应用层的数据通常来源与此层，为什么叫宽表，主要是为了应用层的需要在这一层将业务相关的所有数据统一汇集起来进行存储，方便业务层获取。此层数据通常来源与DWD和DWM层的数据。
在实际计算中，如果直接从DWD或者ODS计算出宽表的统计指标，会存在计算量太大并且维度太少的问题，因此一般的做法是，在DWM层先计算出多个小的中间表，然后再拼接成一张DWS的宽表。由于宽和窄的界限不易界定，也可以去掉DWM这一层，只留DWS层，将所有的数据在放在DWS亦可。

数据应用层（DA 或 APP）

前端应用直接读取的数据源；根据报表、专题分析的需求而计算生成的数据。

维表层DIM（Dimension）

最后补充一个维表层，维表层主要包含两部分数据：
- 高基数维度数据：一般是用户资料表、商品资料表类似的资料表。数据量可能是千万级或者上亿级别。
- 低基数维度数据：一般是配置表，比如枚举值对应的中文含义，或者日期维表。数据量可能是个位数或者几千几万。

（3）ETL、ELT

数据仓库从各数据源获取数据及在数据仓库内的数据转换和流动都可以认为是ETL（抽取Extract, 转化Transform , 装载Load）的过程。
但是在实际操作中将数据加载到仓库却产生了两种不同做法：ETL和ELT。

ETL

首先从数据源池中提取数据，这些数据源通常是事务性数据库。数据保存在临时暂存数据库中（ODS）。然后执行转换操作，将数据结构化并转换为适合目标数据仓库系统的形式。然后将结构化数据加载到仓库中，以备分析。

ELT

使用ELT，数据在从数据源中提取后立即加载。没有专门的临时数据库（ODS），这意味着数据会立即加载到单一的集中存储库中。数据在数据仓库系统中进行转换，以便与商业智能工具（BI工具）一起使用。大数据时代数仓这个特点很明显。

（4）数仓分层设计案例

这里我们以电商网站的数据仓库为例，针对用户访问日志这一部分数据进行举例说明。
在ODS层中，由于各端的开发团队不同或者各种其它问题，用户的访问日志被分成了好几张表上报到了我们的ODS层。
在DWD层做了一张用户访问行为天表，在这里，我们将PC网页、H5、小程序和原生APP访问日志汇聚到一张表里面，统一字段名，提升数据质量，这样就有了一张可供大家方便使用的明细表了。
在DWM层，我们会从DWD层中选取业务关注的核心维度来做聚合操作，比如只保留人、商品、设备和页面区域维度。类似的，我们这样做了很多个DWM的中间表。
在DWS层，我们将一个人在整个网站中的行为数据放到一张表中，这就是我们的宽表了，有了这张表，就可以快速满足大部分的通用型业务需求了。
在APP应用层，根据需求从DWS层的一张或者多张表取出数据拼接成一张应用表即可。

6、阿里巴巴数仓分层

在阿里巴巴的数据体系中，建议将数据仓库分为三层，自下而上为：数据引入层（ODS，Operation Data Store）、数据公共层（CDM，Common Data Model）和数据应用层（ADS，Application Data Service）。

（1）数据引入层ODS（Operation Data Store）

存放未经处理的原始数据至数据仓库系统，结构上与源系统保持一致，是数据仓库的数据准备区。主要完成基础数据引入到MaxCompute(阿里云大数据计算服务，原名ODPS)的职责，同时记录基础数据的历史变化。

（2）数据公共层CDM（Common Data Model）

又称通用数据模型层。包括DIM维度表、DWD和DWS，由ODS层数据加工而成。主要完成数据加工与整合，建立一致性的维度，构建可复用的面向分析和统计的明细事实表，以及汇总公共粒度的指标。

公共维度层（DIM）

基于维度建模理念思想，建立整个企业的一致性维度。降低数据计算口径和算法不统一风险。
公共维度层的表通常也被称为逻辑维度表，维度和维度逻辑表通常一一对应。

公共汇总粒度事实层（DWS）

以分析的主题对象作为建模驱动，基于上层的应用和产品的指标需求，构建公共粒度的汇总指标事实表，以宽表化手段物理化模型。构建命名规范、口径一致的统计指标，为上层提供公共指标，建立汇总宽表、明细事实表。
公共汇总粒度事实层的表通常也被称为汇总逻辑表，用于存放派生指标数据。

明细粒度事实层（DWD）

以业务过程作为建模驱动，基于每个具体的业务过程特点，构建最细粒度的明细层事实表。可以结合企业的数据使用特点，将明细事实表的某些重要维度属性字段做适当冗余，即宽表化处理。
明细粒度事实层的表通常也被称为逻辑事实表。

（3）数据应用层ADS（Application Data Service）

存放数据产品个性化的统计指标数据。根据CDM与ODS层加工生成。

（4）总结

该数据分类架构在ODS层分为三部分：数据准备区、离线数据和准实时数据区。整体数据分类架构如下图所示。

从交易数据系统的数据经过数据集成，同步到数据仓库的ODS层。经过数据开发形成事实宽表后，再以商品、地域等为维度进行公共汇总。

7、美团数仓分层

（1）ODS（数据源）

数据源层，主要职责是接入数据源，并做多数据源的整合。从数据源落地到 Hive 表，同时与数据来源保持一致，尽量还原业务。主要由四类数据源：业务库数据、流量日志、集团数据、三方数据。

（2）IDL（集成明细层）

数据集成层，主要是明细数据，与上一层数据源层是有对应关系的。主要职责是：业务主题的划分、数据规范化，比如商家、交易、用户等多个主题。这一层主要起到缓冲的作用，屏蔽底层影响，尽量还原业务，统一数据标准，敏感字段脱敏，字段名称标准化、Json字段拉平等。

（3）CDL（中间组件层）

数据组件层，主要职责是建设基础指标的多维明细模型、轻度汇总模型。比如商家交易、用户活动等多个主题的基础指标模型。这样针对同一个分析对象统一了指标口径，同时避免重复计算。
数据组件层生成的指标主要是原子指标，原子指标形成数据组件，方便下游的集市层以及应用层拼接数据表。

多维明细模型

以商家信息表建设过程为例：
- 识别分析对象：首先明确分析对象为商家实体
- 圈定分析边界：多维明细不需要关联实体行为，只需要识别出实体之后圈定商家属性信息作为分析边界
- 丰富对象属性：提取商家属性信息，比如商家的品类信息、组织结构信息等
以上信息就形成了一个由商家主键和商家多维信息组成的商家实体的多维明细模型

轻度汇总模型

以商家交易表假设过程为例：
- 识别分析对象：分析实体是商家，业务行为是交易，分析对象是商家交易
- 圈定分析边界：圈定提交表、商家信息表、订单状态表、会员表作为商家交易的边界
- 丰富对象属性：将城市、组织结构等维度信息冗余进来，丰富维度属性信息
- 轻度汇总模型：汇总商家粒度、交易额等原子指标最终建立商家交易表。

（4）MDL（集市层）

数据集市层，主要职责是建设宽表模型、汇总表模型，比如商家宽表、商家时段汇总表等。主要作用是支撑数据分析查询以及支持应用所需数据。
宽表模型和汇总模型两者的区别是：宽表模型是唯一主键，基于主键拼接各种信息；汇总模型的主键类型为联合主键，根据公共维度关联生成派生指标，丰富信息。

宽表模型

订单宽表为例，建设过程为：选定订单实体作为实体对象，然后圈定订单明细、订单状态、订单活动、订单收购等分析对现象通过订单 id 进行关联。这里的宽表模型与数据组件层的多维明细模型的区别在于多维明细模型里的实体对象粒度更细，例如订单宽表中分析对象：订单明细、订单状态、订单活动等都是多维明细模型里的一个个数据组件，这几个数据组件通过订单 id 关联拼接形成了宽表模型。

汇总模型

商家时段汇总表为例，建设过程为：选定商家、时段维度作为维度组合，圈定商家和时段维度相关的表，通过公共维度进行关联、维度冗余，支持派生指标、计算指标的建设。这里区别于组件层的轻度汇总模型，在数据组件层建设的是原子指标，而数据集市层建设的是派生指标。

（5）ADL（应用层）

数据应用层，主要职责是建设应用分析、支撑多维分析应用，比如城市经营分析等。
应用层一般的操作有：数据裁剪、上卷聚合、模型拼接、指标计算（不可加事实指标，如比率）等。
应用层的查询引擎要根据应用场景来选择，比如：Mysql、Presto、Hbase、Redis、ES、Kylin、Doris等。
其中 ODS/IDL/CDL，以及部分 MDL 集市由数据基建组来做，另外部分数据集市以及 ADL应用层由数据应用组支撑，分工标准是涉及一些公共的数据集市由数据基建组来完成；数据应用组会围绕应用建设应用数据集市，如流量集市、城市经营集市。