一文读懂大数据环境下的数据仓库建设！

之前系统分享了数仓的几篇基础知识：

1、一文读懂数据仓库、数据集市、数据库的区别与关联

2、漫谈数据仓库之维度建模

3、数据仓库的ETL、OLAP和BI应用

但光说不练假把式，实际的数仓建设各有门道，从传统数仓到大数据平台，MPP数据集市，Hadoop集群，还有混合架构数仓，一直在不断演进，但是万变不离其宗，大框架和方法论终归是那一套。所以本文就来分享数仓建设的方法论，文中针对的例子是大数据环境下的数据仓库建设，从目前互联网行业数据的采集，存储，同步以及任务调度与监控方面阐述了相关技术，还专门针对数据仓库的维度建模技术做了详细的介绍。

一句话总结，这大概是全网最全思路最清晰的方法论了！

全文5600字，读完需要15分钟！

先从大数据数据仓库建设的整体架构说起。

下图是数据仓库的逻辑分层架构：

想看懂数据仓库的逻辑分层架构，必须先弄懂以下4大概念。

数据源：数据来源，互联网公司的数据来源随着公司的规模扩张而呈递增趋势，同时自不同的业务源，比如埋点采集，客户上报，API等。

ODS层：数据仓库源头系统的数据表通常会原封不动地存储一份，这称为ODS层, ODS层也经常会被称为准备区。这一层做的工作是贴源，而这些数据和源系统的数据是同构，一般对这些数据分为全量更新和增量更新，通常在贴源的过程中会做一些简单的清洗。

DW层：数据仓库明细层和数据仓库汇总层是数据仓库的主题内容。将一些数据关联的日期进行拆分，使得其更具体的分类，一般拆分成年、月、日，而ODS层到DW层的ETL脚本会根据业务需求对数据进行清洗、设计，如果没有业务需求，则根据源系统的数据结构和未来的规划去做处理，对这层的数据要求是一致、准确、尽量建立数据的完整性。

DWS层：应用层汇总层，主要是将DWD和DWS的明细数据在hadoop平台进行汇总，然后将产生的结果同步到DWS数据库，提供给各个应用。举个例子，从ODS层中对用户的行为做一个初步汇总，抽象出来一些通用的维度：时间、ip、id，并根据这些维度做一些统计值，比如用户每个时间段在不同登录ip购买的商品数等。这里做一层轻度的汇总会让计算更加的高效，在此基础上如果计算仅7天、30天、90天的行为的话会快很多。

DA应用层：

① 业务产品CRM、ERP等，业务产品所使用的数据，已经存在于数据共享层，直接从数据共享层访问即可；

② 报表FineReport、业务报表，同业务产品，报表所使用的数据，一般也是已经统计汇总好的，存放于数据共享层；

③ 即席查询即席查询的用户有很多，有可能是数据开发人员、网站和产品运营人员、数据分析人员、甚至是部门老大，他们都有即席查询数据的需求；

④ OLAP：目前，很多的OLAP工具不能很好的支持从HDFS上直接获取数据，都是通过将需要的数据同步到关系型数据库中做OLAP，但如果数据量巨大的话，关系型数据库显然不行；

⑤ 其它数据接口：这种接口有通用的，有定制的。比如一个从Redis中获取用户属性的接口是通用的，所有的业务都可以调用这个接口来获取用户属性。

1、数据采集

数据采集层的任务就是把数据从各种数据源中采集和存储到数据存储上，期间有可能会做一些ETL操作。数据源种类可以有多种：

日志：所占份额最大，存储在备份服务器上

业务数据库：如Mysql、Oracle

来自HTTP/FTP的数据：合作伙伴提供的接口

其他数据源：如Excel等需要手工录入的数据

2、数据存储与分析

随着公司的规模不断扩张，产生的数据也越来越到，像一些大公司每天产生的数据量都在PB级别，传统的数据库已经不能满足存储要求，目前hdfs是大数据环境下数据仓库/数据平台最完美的数据存储解决方案。

离线数据分析与计算，也就是对实时性要求不高的部分，Hive还是首当其冲的选择。丰富的数据类型、内置函数；压缩比非常高的ORC文件存储格式；非常方便的SQL支持，使得Hive在基于结构化数据上的统计分析远远比MapReduce要高效的多，一句SQL可以完成的需求，开发MR可能需要上百行代码。当然，使用Hadoop框架自然而然也提供了MapReduce接口，如果真的很乐意开发Java，或者对SQL不熟，那么也可以使用MapReduce来做分析与计算。

3、数据共享

这里的数据共享，其实指的是前面数据分析与计算后的结果存放的地方，其实就是关系型数据库和NOSQL数据库；

前面使用Hive、MR、Spark、SparkSQL分析和计算的结果，还是在HDFS上，但大多业务和应用不可能直接从HDFS上获取数据，那么就需要一个数据共享的地方，使得各业务和产品能方便的获取数据。和数据采集层到HDFS刚好相反，这里需要一个从HDFS将数据同步至其他目标数据源的工具，同样，DataX也可以满足。

另外，一些实时计算的结果数据可能由实时计算模块直接写入数据共享。

4、维度建模

维度建模是专门用于分析型数据库、数据仓库、数据集市建模的方法。这里牵扯到两个基本的名词：维度，事实。

① 维度

维度是维度建模的基础和灵魂，在维度建模中，将度量成为事实，将环境描述为维度，维度是用于分析事实所需的多样环境。例如，在分析交易过程中，可以通过买家、卖家、商品和时间等维度描述交易发生的环境。

② 事实

事实表作为数据仓库维度建模的核心，紧紧围绕着业务过程来设计，通过获取描述业务过程的度量来表达业务过程，包含了引用的维度和与业务过程有关的度量。事实表中一条记录所表达的业务细节被称之为粒度。通常粒度可以通过两种方式来表述：一种是维度属性组合所表示的细节程度，一种是所表示的具体业务含义。

简单的说，维度表就是你观察该事物的角度（维度)，事实表就是你要关注的内容。例如用户使用滴滴打车，那么打车这件事就可以转化为一个事实表，即打车订单事实表，然后用户对应一张用户维度表，司机对应一张司机维度表。

维度建模的三种模式：

1.星型模式

星型模型架构是一种非正规化的结构，特点是有一张事实表，多张维度表，是不存在渐变维度的，事实表和维度表通过主外键相关联，维度表之间是没有关联，因为维度表的数据冗余，所以统计查询时不需要做过多外部连接

2.雪花模式

雪花模型架构就是将星型模型中的某些维度表抽取成更细粒度的维度表，然后让维度表之间也进行关联，通过最大限度的减少数据存储量以及联合较小的维度表来改善查询性能。

下图为使用雪花模式进行维度建模的关系结构：

星形模式中的维表相对雪花模式来说要大，而且不满足规范化设计。雪花模型相当于将星形模式的大维表拆分成小维表，满足了规范化设计。然而这种模式在实际应用中很少见，因为这样做会导致开发难度增大，而数据冗余问题在数据仓库里并不严重。

3.星座模式

数据仓库由多个主题构成，包含多个事实表，而维表是公共的，可以共享，这种模式可以看做星型模式的汇集，因而称作星系模式或者事实星座模式。

事实上，星座模式是数据仓库最长使用的数据模式，尤其是企业级数据仓库（EDW）。这也是数据仓库区别于数据集市的一个典型的特征，从根本上而言，数据仓库数据模型的模式更多是为了避免冗余和数据复用，套用现成的模式，是设计数据仓库最合理的选择。

维度表设计：

维度的设计过程就是确定维度属性的过程，如何生成维度属性，以及所生成维度属性的优劣，决定了维度是用的方便性，成为数据仓库易用性的关键。

数据仓库的能力直接与维度属性的质量和深度成正比。

维度表基本设计方法：

以商品维度为例对维度设计放发进行详细说明。

第一步：确定维度，具备唯一性

作为维度建模的核心，在企业级数据仓库中，必须保证维度的唯一性。以商品维度为例，有且只有一个维度定义。

第二步：确定主维表，确定描述维度的主表

此处的主维表一般是ODS表，直接与业务系统同步。

第三步：确定相关表，根据业务之间的关联性，确定维度的相关表

数据仓库是业务源系统的数据整合，不同业务系统或者同一业务系统中的表之间存在关联性，根据业务系统的梳理，确定哪些表和主维表存在关联关系，并选择其中的某些表用于生成维度属性。以商品维度为例，根据业务逻辑的梳理，可以得到商品与类目、sku、买家、卖家、店铺等维度存在的关联关系。

第四步：确定维度属性

包含两个阶段，第一个阶段从主维表中选择维度属性，第二阶段从相关维表中选择维度属性。确定维度有以下原则：

① 尽可能丰富的维度属性，为下游分析、统计提供良好的基础

② 维度属性提供编码+文字的描述，编码用于表关联，文字表示真正的标签

③ 沉淀出通用的维度属性，一来减少下游使用的复杂度，二来避免下游口径不一致

以商品维度为例，从主维表和类目、sku、卖家、店铺等相关维表中选择维度属性或者生成新的维度属性。

该模式就属于雪花模式。

对于商品维度，如果采用反规范化，将表现为下图所示的形式：

采用雪花模式，除了可以节约一部分存储之外，对于OLAP系统来说没有其他的效用。而现阶段存储的成本非常低。出于易用性和性能的考虑，维表一般设计成不规范化的。在实际应用中，几乎总是使用维表的空间来换取简明性和查询性能。

事实表设计：

事实表作为数据仓库维度建模的核心，紧紧围绕着业务过程来设计，通过获取描述业务过程的度量来表达业务过程，包含了引用的维度和业务过程有关的度量。

相对维表来说，事实表要细长的多，行的增加速度也比维表快很多。事实表分为三种类型：事务事实表，周期快照事实表，累计快照事实表。本文主要讨论事务事实表，不做词义赘述。

事实表设计原则及基本设计方法：

尽可能包括所有业务过程相关的事实

只选择与业务过程相关的事实

分解不可加事实为可加的组件

选择维度和事实之前必须先声明粒度

在同一个事实表中不可以有多重不同粒度的事实

事实的单位要保持一致

对事实的null值要处理

使用退化维提高事实表的易用性

任何类型的事件都可以被理解成一种事务。比如交易过程中的创建订单，买家付款，物流中的发货，签收，付款等。事务事实表针对这些过程创建的一种事实表。

下面店铺交易事务为例，阐述事务事实表的一般设计过程。

1.选择业务过程及确定事实表类型：

交易的过程分为：创建订单、买家付款、卖家发货、买家确认收货，即下单、支付、发货和成功完结四个业务过程。Kimball维度建模理论认为，为了便于进行独立的分析研究，应该为每一个业务过程建立一个事实表。

2.声明粒度：

业务过程选定之后，就要对每个业务过程确定一个粒度，即确定事实表每一行所表达的细节层次。需要为四个业务过程确定粒度，其中下单、支付和成功完结选择交易子订单粒度，即每个子订单为事实表的一行，买家收货的粒度为物流单。

3.确定维度：

完成粒度声明以后，也就意味着确定了主键，对应的维度组合以及相关的维度字段就可以确定了，应该选择能够描述清楚业务过程所处的环境的维度信息。在店铺交易事实表设计过程中，按照经常用于统计分析的场景，确定维度包含：买家、卖家、商品、商品类目、发货地区、收货地址、父订单维度以及杂项维度。

4.确定事实：

作为过程度量的核心，事实表应该包含与其描述过程有关的所有事实。以店铺交易事实表为例，选定三个业务过程:下单、支付、成功完结，不同的业务过程有不同的事实。比如在下单业务过程中，需要包含下单金额、下单数量、下单分摊金额；

经过以上四步店铺交易事务事实表已成型，如下图所示：

在确定维度时，包含了买卖家维度，商品维度，类目维度，收发货等。Kimball维度建模理论建议在事实表中只保留这个维度表的外键，但是在实际的应用中，可以将店铺名称、商品类型、商品属性、类目属性冗余到事实表中，提高对事实表的过滤查询，减少表之间的关联次数，加快查询速度，该操作称之为退化维。

经过以上的操作，基本完成了店铺交易事务事实表的设计工作。

5、元数据管理

元数据通常定义为”关于数据的数据”,在数据仓库中是定义和描述DW/BI系统的结构，操作和内容的所有信息。

元数据贯穿了数据仓库的整个生命周期，使用元数据驱动数据仓库的开发，使数据仓库自动化，可视化。

在操作数据仓库时，操作的都是元数据，而元数据分为技术元数据和业务元数据。

业务元数据是为管理层和业务分析人员服务，从业务的角度描述数据，包括行业术语、数据的可用性、数据的意义等。常用的业务元数据有：

维度和属性、业务过程、指标等规范化定义，用于更好的管理和使用数据。数据应用元数据，数据报表、数据产品等配置和运行元数据。

技术元数据是指数据仓库开发、管理、维护相关的数据，描述了数据的原信息，转换描述、数据映射、访问权限等。常用的技术元数据有：

存储位置、数据模型、数据库表、字段长度、字段类型、ETL脚本、SQL脚本、接口程序、数据关系等。

元数据的存储有常用的两种，一种是以数据集为基础，每一个数据集有对应的元数据文件，每一个元数据文件对应数据集的元数据内容，另一种是以数据库为基础，由若干项组成，每一项标识元数据的一个元素。

6、任务调度与监控

在数据仓库建设中，有各种各样非常多的程序和任务，比如：数据采集任务、数据同步任务、数据清洗任务、数据分析任务等。这些任务除了定时调度，还存在非常复杂的任务依赖关系。

比如：数据分析任务必须等相应的数据采集任务完成后才能开始；数据同步任务需要等数据分析任务完成后才能开始；这就需要一个非常完善的任务调度与监控系统，它作为数据仓库的中枢，负责调度和监控所有任务的分配与运行。

目前有能力的公司都是自己开发调度工具，如中国平安（linkdu），银行行业用的较多是Control-M，一些互联网公司可能会选择airflow作为自己的调度工具。

具体采用哪种工具，可以根据自己公司的本身现状去做定夺。

最后，在我看来，数据仓库建设是一个综合性技术，而且当企业业务复杂的时候，这部分工作更是需要专门团队与业务方共同合作来完成。

因此一个优秀的数据仓库建模团队既要有坚实的数据仓库建模技术，还要有对现实业务清晰、透彻的理解。

另外，架构并不是技术越多越新越好，而是在可以满足需求的情况下，越简单越稳定越好。

很显然在目前的信息时代，借助类似于FineBI的这些工具，可以让企业加速融入企业数据分析的趋势。备受市场认可的软件其实有很多，选择时必须要结合实际的情况。一般的情况下，都建议选择市面上较主流的产品，比较容易达到好的效果，目前企业数据分析BI软件市场占有率前列的，就是帆软BI软件——FineBI。