【漫谈数据仓库】数据仓库的分层理论

 1.  数据仓库的概念

官方定义

数据仓库是一个面向主题的、集成的、随时间变化的、但信息本身相对稳定的数据集合，用于对管理决策过程的支持。

这个定义的确官方，但是却指出了数据仓库的四个特点。

特点

面向主题：数据仓库都是基于某个明确主题，仅需要与该主题相关的数据，其他的无关细节数据将被排除掉

集成的：从不同的数据源采集数据到同一个数据源，此过程会有一些ETL操作

随时间变化：关键数据隐式或显式的基于时间变化

信息本身相对稳定：数据装入以后一般只进行查询操作，没有传统数据库的增删改操作

个人理解

数据仓库就是整合多个数据源的历史数据进行细粒度的、多维的分析，帮助高层管理者或者业务分析人员做出商业战略决策或商业报表。

2.  数据仓库的用途

整合公司所有业务数据，建立统一的数据中心

产生业务报表，用于作出决策

为网站运营提供运营上的数据支持

可以作为各个业务的数据源，形成业务数据互相反馈的良性循环

分析用户行为数据，通过数据挖掘来降低投入成本，提高投入效果

开发数据产品，直接或间接地为公司盈利

…

3.  数据仓库与数据库对比

数据库是数据库概念的升级。从逻辑上理解，数据库和数据仓库没有区别，都是通过数据库软件实现的存放数据的地方，只不过从数据量来说，数据仓库要比数据库更庞大得多。

在IT的架构体系中，数据库是必须存在的。必须要有地方存放数据。数据仓库则是BI下的其中一种技术。由于数据库是跟业务应用挂钩的，所以一个数据库不可能装下一家公司的所有数据。数据库的表设计往往是针对某一个应用进行设计的。数据仓库主要用于数据挖掘和数据分析，辅助领导做决策。

数据库与数据仓库的区别实际讲的是OLTP与OLAP的区别。

操作型处理，叫联机事务处理OLTP（On-LineTransaction Processing），也可以称面向交易的处理系统，它是针对具体业务在数据库联机的日常操作，通常对少数记录进行查询、修改。用户较为关心操作的响应时间、数据的安全性、完整性和并发支持的用户数等问题。传统的数据库系统作为数据管理的主要手段，主要用于操作型处理。

分析型处理，叫联机分析处理OLAP（On-LineAnalytical Processing）一般针对某些主题的历史数据进行分析，支持管理决策。

面向业务的数据库常称作OLTP，面向分析的数据仓库亦称为OLAP。

4.  数据仓库分层理论

一般大公司为了数据安全和操作方便，都是自己封装的数据平台和任务调度平台，底层封装了大数据集群比如hadoop集群，spark集群，sqoop,hive,zookeepr,hbase等只提供web界面，并且对于不同员工加以不同权限，然后对集群进行不同的操作和调用。以数据仓库为例，将数据仓库分为逻辑上的几个层次。这样对于不同层次的数据操作，创建不同层次的任务，可以放到不同层次的任务流中进行执行（大公司一个集群通常每天的定时任务有几千个等待执行，甚至上万个，所以划分不同层次的任务流，不同层次的任务放到对应的任务流中进行执行，会更加方便管理和维护）。

原始数据层→ ODS（Operational Data Store）

原始数据层是最接近数据源中数据的一层，数据源中的数据，经过抽取、洗净、传输，也就说传说中的 ETL 之后，装入本层。本层的数据，总体上大多是按照源头业务系统的分类方式而分类的。但是，这一层面的数据却不等同于原始数据。在源数据装入这一层时，要进行诸如去噪(例如有一条数据中人的年龄是 300 岁，这种属于异常数据，就需要提前做一些处理)、去重(例如在个人资料表中，同一 ID却有两条重复数据，在接入的时候需要做一步去重)、字段命名规范等一系列操作。

我们的数据主要会有两个大的来源：

业务库：这里经常会使用 Sqoop 来抽取，比如我们每天定时抽取一次。在实时方面，可以考虑用 Canal 监听 Mysql 的Binlog，实时接入即可。

埋点日志：线上系统会打入各种日志，这些日志一般以文件的形式保存，我们可以选择用 Flume 定时抽取，也可以用用 Spark Streaming 或者 Flink 来实时接入，当然，Kafka 也会是一个关键的角色。

其它数据源会比较多样性，这和具体的业务相关，不再赘述。

明细数据层-DWD（Data Warehouse Detail）

明细数据层DWD是对ODS层数据进行沉淀，减少了抽取的复杂性，同时DWD的信息模型组织主要遵循企业业务事务处理的形式，将各个专业数据进行集中，明细层跟ODS层的粒度一致，属于分析的公共资源。

数据服务层-DWS（Data Warehouse Service）

又称数据集市或宽表。按照业务划分，如流量、订单、用户等，生成字段比较多的宽表，用于提供后续的业务查询，OLAP分析，数据分发等。

数据服务层是对DWD层的生产数据进行综合和汇总统计(可以把复杂的清洗，处理包含，如根据PV日志生成的会话数据)。轻度综合层与DWD的主要区别在于二者的应用领域不同，DWD的数据来源于生产型系统，并未满意一些不可预见的需求而进行沉淀；轻度综合层则面向分析型应用进行细粒度的统计和沉淀。

数据应用层-ADS（Application Data Store）

应用层是根据业务需要，由前面三层数据统计而出的结果，可以直接提供查询展现，或导入至Mysql中使用。由明细层、轻度汇总层，数据集市层生成，一般要求数据主要来源于集市层。这层数据是完全为了满足具体的分析需求而构建的数据，也是星形或雪花结构的数据。从数据粒度来说是高度汇总的数据。

数据仓库标准上可以分为四层。但是注意这种划分和命名不是唯一的，一般数仓都是四层，但是不同公司可能叫法不同。比如京东叫BDM。同样阿里巴巴却是五层数仓结构，更加详细，但是核心的理念都是从四层数据模型而来。如下分别展示京东和阿里巴巴数仓的架构层次和命名。

下面是一个具体的四层数据仓库示例：

5.  元数据管理

描述数据的数据叫做元数据，元数据信息一般包括表名、表描述信息、所在数据库、表结构、存储位置等基本信息，另外还有表之间的血缘关系信息、每天的增量信息、表结构修改记录信息等等。

数据仓库中有大量的表，元数据管理系统就是用来收集、存储、查询数据仓库中元数据的工具，这个系统为数据使用方提供了极大的便利。

6.  星型模型和雪花模型

在多维分析的商业智能解决方案中，根据事实表和维度表的关系，又可将常见的模型分为星型模型和雪花型模型。在设计逻辑型数据的模型的时候，就应考虑数据是按照星型模型还是雪花型模型进行组织。

星型模型

当所有维表都直接连接到“ 事实表”上时，整个图解就像星星一样，故将该模型称为星型模型。

星型架构是一种非正规化的结构，多维数据集的每一个维度都直接与事实表相连接，不存在渐变维度，所以数据有一定的冗余，如在地域维度表中，存在国家A 省B的城市C以及国家A省B的城市D两条记录，那么国家A和省B的信息分别存储了两次，即存在冗余。

雪花模型

当有一个或多个维表没有直接连接到事实表上，而是通过其他维表连接到事实表上时，其图解就像多个雪花连接在一起，故称雪花模型。

雪花模型是对星型模型的扩展。它对星型模型的维表进一步层次化，原有的各维表可能被扩展为小的事实表，形成一些局部的" 层次" 区域，这些被分解的表都连接到主维度表而不是事实表。如图所示，将地域维表又分解为国家，省份，城市等维表。它的优点是：通过最大限度地减少数据存储量以及联合较小的维表来改善查询性能。雪花型结构去除了数据冗余。

星型模型因为数据的冗余所以很多统计查询不需要做外部的连接，因此一般情况下效率比雪花型模型要高。星型结构不用考虑很多正规化的因素，设计与实现都比较简单。雪花型模型由于去除了冗余，有些统计就需要通过表的联接才能产生，所以效率不一定有星型模型高。正规化也是一种比较复杂的过程，相应的数据库结构设计、数据的 ETL、以及后期的维护都要复杂一些。因此在冗余可以接受的前提下，实际运用中星型模型使用更多，也更有效率。