说下自己的理解：

数据仓库是分层的，通常情况下都是进行三层建模(当然也不是绝对的)。

例如上次说的商品订单数据表，表字段可能有非常多个，但是我们使用的时候可能只用到UID，PayTime，CreateTime, PayMoney,等字段。这个过程需要不断的过滤。每过滤一层就需要在新的一层储存一次。类比在Hive中有个表分区的概念，把一张大表按照业务需求拆分为两张表，减少了扫描的量级。

下面说下常用的分层类型：

业务数据层：包含 STG(数据缓冲层)与 ODS(操作数据层)两层，这两层数据结构与业务数据几乎一致。

STG：也叫数据准备区，定位是缓存来自 DB 抽取、消息、日志解析落地的临时数据，结构与业务系统保持一致；负责对垃圾数据、不规范数据进行清洗转换；该层只为 ODS 层服务；

ODS：操作数据层定位于业务明细数据保留区，负责保留数据接入时点后历史变更数据，数据原则上全量保留。模型设计依据业务表数据变更特性采取拉链、流水表两种形式。(据我所知通常在大数据环境下，通常采取快照的形式，拉链表不好维度后期)

公共数据层：细分为 DWD(明细数据层)、DWS(汇总数据层)、DIM(公共维度层) 三层，主要用于加工存放整合后的明细业务过程数据，以及经过轻度或重度汇总粒度公共维度指标数据。公共数据层作为仓库核心层，定位于业务视角，提炼出对数据仓库具有共性的数据访问、统计需求，从而构建面向支持应用、提供共享数据访问服务的公共数据。

DWD：这一层是整合后的业务过程明细数据，负责各业务场景垂直与水平数据整合、常用公共维度冗余加工，以及明细业务标签信息加工；

DWS：汇总数据层按照主题对共性维度指标数据进行轻度、高度聚合；

DIM：对维度进行统一标准化定义，实现维度信息共享。

下面这两层容易混淆，其实企业在搭建后的作用是基本一样的：

DM：数据集市层，DM层只关心自己需要的数据，不会考虑企业整体的业务架构，所以也可以单独建立

ADS:  数据应用层，也叫DM(数据集市)也叫APP(数据应用层)，面向实际的数据需求，以DWD或者DWS层的数据为基础，组成的各种统计报表。

通常这个是数据仓库的最后一层数据，为应用层数据，直接可以给业务人员使用。比如某日某个日的支付成功率是多少、某专场的总的销售金额多少

为什么分层？：

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

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

分层的好处：

清晰数据结构：每一个数据分层都有它的作用域和职责，在使用表的时候能更方便地定位和理解

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

统一数据口径：通过数据分层，提供统一的数据出口，统一对外输出的数据口径

复杂问题简单化：将一个复杂的任务分解成多个步骤来完成，每一层解决特定的问题

我在工作当中技术所才采取的分层架构如下图：

数据模型的设计：

目前业界主要的模型设计方法论有两种，

一是Inmon 的范式建模方法，又叫 ER 建模，主张站在企业角度自上而下进行数据模型构建

二是Kimball的维度建模方法，主张从业务需求出发自下而上构建数据模型。

简单说下两种方法的对比：

我们采取的是第二种类。通常在实际的大数据环境下，业务系统数据体系庞杂，数据结构多样、变更频繁，并且需要快速响应各种复杂的业务需求，以上两种传统的理论都已无法满足互联网数仓需求。大多企业(我所了解的)会采用混合模型设计方式，以需求驱动为主、数据驱动为辅

在大数据环境下的数据分层中不同的层次中用的计算引擎和存储系统如下：

分别的作用为：

ODS：原始数据层

数据来源可能是通过Flume监控、Sqoop导入.......，Flume可以定义拦截器，进行数据ETL。Sqoop通过sql语句，进行数据ETL。

所以很多情况下ods存放的ETL之后的原始数据。

这样就在在业务系统和数据仓库之间形成一个隔离层，保存的是原始数据或者ETL之后的原始数据，而且以后DW层需要使用数据则直接从ODS抽取，不用从源数据系统拿，很方便

DWD：数据明细层

是为企业所有级别的决策制定过程，提供所有类型数据支持的集合，包含所有主题的通用的集合

会在ods层基础上，可能做三件事：

1.结构和粒度与ods保持一致，对ods层数据进行再次清洗(去空、去脏数据，去超过极限的数据)

2.调整压缩算法、存储格式，在Hive中文件存储格式有四种：TEXTFILE 、SEQUENCEFILE、ORC、PARQUET，前面两种是行式存储，后面两种是列式存储。通常都使用ORC，parquet这两种进行存储，起码我这边是。

行式存储比较类似MYSQL的形式，符合面向对象的思想，相关的数据是保存在一起，比较符合面向对象的思维，因为一行数据就是一条记录。

列式存储则是：查询时只有涉及到的列才会被查询，不会把所有列都查询出来，即可以跳过不必要的列查询。由于每列的数据格式一样，所以压缩率高效，不仅节省储存空间也节省计算，提高效率。

查询速度：当数据量较大时，列式存储快，数据量小的时候，查询速度无明显区别。

3.看是否会进行维度退化，比如说地区这个维度，在mysql中分了国家、省份、城市三个维度，那么将其合并成一个维度！ sql语句比较好实现，也就是三张表合并为一张表。

DWS：数据服务层

以dwd为基础，进行轻度汇总，一般聚集到以用户当日、设备当日、商家当日、商品当日等等的粒度。

在这层通常会有组成跨主题的宽表，比如一个用户的当日签到数、收藏数、评论数、抽奖数、订阅数、浏览商品数、添加购物车数、下单数、支付数等组成的多列表

这一层通常就是一张行为宽表，以时间(每天、每周、每月)统计用户(商品、商家)所做的所有事！！！(是最重要的中间表)

如果有了这一层，那么对于DM层的什么地区签到、收藏、总评论数等指标都能灵活实现

原始数据到ADS层：

由于随着业务需求的不断变化，对于实时计算的要求越来越高(数仓分为实时数仓和离线数仓)。比如大屏数据实时展示，实时监控系统，实时交易数据....等

这时后采用Spark streaming等实时计算引擎，把需要接收到的实时数据灌入Kafka里面(消息中间件)，然后Spark streaming 去拉取Kafka里面的数据。

如果要做数据量大的实时处理，需要用分布式，否则数据量大的时候，一点一点去处理会处理到猴年马月

以后会粗略总结下大数据生态下的各个组件成员，【(￣へ￣)因为我没到达不精通】