文章目录一、前言二、数仓建模三、数仓层次四、数仓基本特征五、数据仓库用途六、数仓层次优势七、如何分层
一、前言
现在，说到数仓，更多的东西跨越数据平台和基础架构，融入到整个基础架构的构建中。 在此，我们将简要介绍数仓分层的含义和如何设计分层，而不是说Hadoop的各个组件之间的协作。
二、数仓建模说到数仓建模，必须提出经典的两个理论。
正规模型化
Inmon提倡的集线器自上而下(EDW-DM )数据仓库体系结构。
维度建模
Kimball提倡的总线式自下而上(DM-DW )数据仓库体系结构。
数仓的建模或分层实际上是为了更好地组织、管理和维护数据，实际开发时将两种方式合并使用。 当然，有些还没有应用，例如Data Vault模型、Anchor模型等。
维度建模中一般提到星型模型、雪花模型，星型模型对进行OLAP分析很有用。
三、数仓分层简单，直接ODS DM就可以了。 同步所有数据并直接开发APP应用层报告是最容易的。 当DM层的内容变多后，想要再利用的话，就会分割出另一个公共层，形成三层结构。 最近我读了本蚂蚁的书，《大数据之路》。 里面有很多与数仓相关的内容，很好。 参考后，现在使用的分层模型如下。
根据这种分层方式，我们的开发重点在DWD层，是详细数据层，这里主要是几个大表，存储的是详细数据DWS层，我们就针对不同的维度，聚合数据。 怪不得，DWS层是市场层，这里一般按主题分类，属于维度建模范畴； ADS是偏应用层、各种报告的输出。
四、数仓的基本特征数据仓库有四个基本特征。 在面向主题的、集成的、相对稳定的、记录历史的上，数据仓库的价值基于这四个特点体现出来。
1、高效的数据组织和管理
面向主题的特性决定了数据仓库具有业务数据库中没有的高效数据组织格式、更完整的数据体系以及明确的数据分类和分层机制。 在进入数据仓库之前，所有数据都将被清洗和过滤，从而避免了原始数据杂乱，优化了查询组织格式，提高了数据检索、统计和分析的效率。
2、时间价值
数据仓库的构建大大减少了获取信息所需的时间。 数据仓库是一组数据，可以直接从数据仓库获取所有信息。 数据仓库的最大优点是，基于各种数据源到数据仓库的ETL过程，每天都有来自各方面的信息以自动任务调度的形式流入数据仓库，因此基于这些基础信息的所有数据获取的效率都很高
从APP应用来看，使用数据仓库可以大大提高数据查询效率。 特别是对于大量数据的相关查询和复杂查询，数据仓库有助于提供复杂的统计需求并提高数据统计的效率。
3、集成价值
数据仓库是所有数据的集合，包括日志信息、数据库数据、文本数据和外部数据，它们为APP应用程序提供了各种数据关联，便于多维分析，并从多角度进行数据分析和决策
4、历史累积价值
记忆历史是数据仓库的特性之一，数据仓库可以恢复历史时刻的产品状态、用户状态、用户行为等，可以更好地追溯历史，分析历史，跟踪用户的历史行为，更好地比较历史
五、整合数据仓库用途公司的所有业务数据，建立统一的数据中心编制业务报告，为网站运营提供运营上的数据支持，可作为各项业务的数据来源，以便作出决策， 形成业务数据相互反馈的良性循环分析用户行为数据，通过数据挖掘降低投入成本，提高投入效益开发数据产品，直接或间接给公司带来六、数仓分层的好处对数据进行分层的一个主要原因就是希望在管理数据的时候，能对数据有一个更加清晰的掌控
清晰数据结构:每个数据层都有一个范围，便于定位和理解使用表。数据血缘追踪简单来说，可以这样理解。 我们最终向业务出示的是可以直接使用的业务表，但其来源有很多。 如果某个出处表有问题的话，我想迅速且正确地确定问题，明确其危害范围。减少重复开发:规范数据分层，开发通用中间层数据，可以大大减少重复计算。把复杂问题简单化:将一个复杂的任务分解为多个步骤完成，每一层只处理一个步骤，所以比较简单易懂。 它还易于保持数据的准确性，在数据出现问题后，只需从有问题的步骤开始进行修复，而无需修复所有数据。屏蔽原始数据的异常:需要屏蔽业务影响，在不更改业务的情况下重新访问数据。 数据体系各表的依赖就像电线的流动，我们希望它规则、流程清晰、便于管理。 如下图所示。
但是，最终的结果大多依赖于复杂的分层混乱，如下图所示，很难整理表的生成路径
七、如何划分
层理论抽象
我们可以从理论上对数仓来做一个抽象，可以把数据仓库分为下面三个层，即：数据运营层、数据仓库层和数据产品层。
1. 操作数据层（ODS）
“面向主题的”，数据运营层，也叫ODS层，是最接近数据源中数据的一层，数据源中的数据，经过抽取、洗净、传输，也就说传说中的 ETL 之后，装入本层。
本层的数据，总体上大多是按照源头业务系统的分类方式而分类的。但是，这一层面的数据却不等同于原始数据。在源数据装入这一层时，要进行诸如去噪(例如有一条数据中人的年龄是 300 岁，这种属于异常数据，就需要提前做一些处理)、去重(例如在个人资料表中，同一 ID 却有两条重复数据，在接入的时候需要做一步去重)、字段命名规范等一系列操作。
2. 数据仓库层(DW/CDM)
这是数据仓库的主体。在这里，从 ODS 层中获得的数据按照主题建立各种数据模型，在这一层和维度建模会有比较深的联系。
3. 数据产品/集市层(APP/ADS)
这一层是提供为数据产品使用的结果数据。在这里，主要是提供给数据产品和数据分析使用的数据，一般会存放在 ES、MySQL等系统中供线上系统使用，也可能会存在 Hive 或者 Druid 中供数据分析和数据挖掘使用。如我们经常说的报表数据，或者说那种大宽表，一般就放在这里。
另外，我们在实际分层过程中，也可以根据我们的实际数据处理的流程进行分层。
八、举个例子网上的例子很多，以下是某位mndhb早期参与设计的数据分层例子。
我们分析一下当初的想法，以及这种设计的缺陷。
大佬当初的设计总共分了 6 层，其中去掉元数据后，还有5层。下面分析一下当初的一个设计思路。
缓冲层(buffer)
概念：又称为接口层(stage)，用于存储每天的增量数据和变更数据，如Canal接收的业务变更日志。
数据生成方式：直接从kafka接收源数据，需要业务表每天生成update、delete、inseret数据，只生成insert数据的业务表，数据直接入明细层。
讨论方案：只把canal日志直接入缓冲层，如果其它有拉链数据的业务，也入缓冲层。
日志存储方式：使用Impala外表，parquet文件格式，方便需要MR处理的数据读取。
日志删除方式：长久存储，可只存储最近几天的数据。讨论方案：直接长久存储
表schema：一般按天创建分区库与表命名。库名：buffer、表名：初步考虑格式为：buffer日期业务表名，待定。
明细层(ODS, Operational Data Store,DWD: data warehouse detail)
概念：是数据仓库的细节数据层，是对STAGE层数据进行沉淀，减少了抽取的复杂性，同时ODS/DWD的信息模型组织主要遵循企业业务事务处理的形式，将各个专业数据进行集中，明细层跟stage层的粒度一致，属于分析的公共资源
数据生成方式：部分数据直接来自kafka，部分数据为接口层数据与历史数据合成。
canal日志合成数据的方式待研究。
讨论方案：canal数据的合成方式为：每天把明细层的前天全量数据和昨天新数据合成一个新的数据表，覆盖旧表。同时使用历史镜像，按周/按月/按年 存储一个历史镜像到新表。
日志存储方式：直接数据使用impala外表，parquet文件格式，canal合成数据为二次生成数据，建议使用内表，下面几层都是从impala生成的数据，建议都用内表+静态/动态分区。
日志删除方式：长久存储。
表schema：一般按天创建分区，没有时间概念的按具体业务选择分区字段。
库与表命名：库名：ods、表名：初步考虑格式为ods日期业务表名，待定。
旧数据更新方式：直接覆盖
轻度汇总层(MID或DWB, data warehouse basis)
概念：轻度汇总层数据仓库中DWD层和DM层之间的一个过渡层次，是对DWD层的生产数据进行轻度综合和汇总统计(可以把复杂的清洗，处理包含，如根据PV日志生成的会话数据)。轻度综合层与DWD的主要区别在于二者的应用领域不同，DWD的数据来源于生产型系统，并未满意一些不可预见的需求而进行沉淀；轻度综合层则面向分析型应用进行细粒度的统计和沉淀。
数据生成方式：由明细层按照一定的业务需求生成轻度汇总表。明细层需要复杂清洗的数据和需要MR处理的数据也经过处理后接入到轻度汇总层。
日志存储方式：内表，parquet文件格式。
日志删除方式：长久存储。
表schema：一般按天创建分区，没有时间概念的按具体业务选择分区字段。
库与表命名：库名：dwb，表名：初步考虑格式为：dwb日期业务表名，待定。
旧数据更新方式：直接覆盖。
主题层(DM，data market或DWS, data warehouse service)
概念：又称数据集市或宽表。按照业务划分，如流量、订单、用户等，生成字段比较多的宽表，用于提供后续的业务查询，OLAP分析，数据分发等。
数据生成方式：由轻度汇总层和明细层数据计算生成。
日志存储方式：使用impala内表，parquet文件格式。
日志删除方式：长久存储。
表schema：一般按天创建分区，没有时间概念的按具体业务选择分区字段。
库与表命名：库名：dm、表名：初步考虑格式为：dm日期业务表名，待定。
旧数据更新方式：直接覆盖。
应用层(App)
概念：应用层是根据业务需要，由前面三层数据统计而出的结果，可以直接提供查询展现，或导入至Mysql中使用。
数据生成方式：由明细层、轻度汇总层，数据集市层生成，一般要求数据主要来源于集市层。
日志存储方式：使用impala内表，parquet文件格式。
日志删除方式：长久存储。
表schema：一般按天创建分区，没有时间概念的按具体业务选择分区字段。
库与表命名：库名：暂定apl，另外根据业务不同，不限定一定要一个库。
旧数据更新方式：直接覆盖。
前面提到的一种设计其实相对来讲已经很详细了，但是可能层次会有一点多，而且在区分一张表到底该存放在什么位置的时候可能还有不小的疑惑。我们可以再设计一套数据仓库的分层，同时在前面的基础上加上维表和一些临时表的考虑，来让我们的方案更优雅一些。
下图，做了一些小的改动，我们去掉了上一节的Buffer层，把数据集市层和轻度汇总层放在同一个层级上，同时独立出来了维表和临时表。
这里解释一下DWS、DWD、DIM和TMP的作用。
DWS：轻度汇总层，从ODS层中对用户的行为做一个初步的汇总，抽象出来一些通用的维度：时间、ip、id，并根据这些维度做一些统计值，比如用户每个时间段在不同登录ip购买的商品数等。这里做一层轻度的汇总会让计算更加的高效，在此基础上如果计算仅7天、30天、90天的行为的话会快很多。我们希望80%的业务都能通过我们的DWS层计算，而不是ODS。
DWD：这一层主要解决一些数据质量问题和数据的完整度问题。比如用户的资料信息来自于很多不同表，而且经常出现延迟丢数据等问题，为了方便各个使用方更好的使用数据，我们可以在这一层做一个屏蔽。
DIM：这一层比较单纯，举个例子就明白，比如国家代码和国家名、地理位置、中文名、国旗图片等信息就存在DIM层中。
TMP：每一层的计算都会有很多临时表，专设一个DWTMP层来存储我们数据仓库的临时表。