一、数据仓库概述
前言
阅读本文前，请先回答下面两个问题：
1. 数据库和数据仓库有什么区别？
2. 某大公司Hadoop Hive里的关系表不完全满足完整/参照性约束，也不完全满足范式要求，甚至第一范式都不满足。这种情况正常吗？
如果您不能五秒内给出答案，那么本文应该是对您有帮助的。
数据库的"分家"
随着关系数据库理论的提出，诞生了一系列经典的RDBMS，如Oracle，MySQL，SQL Server等。这些RDBMS被成功推向市场，并为社会信息化的发展做出的重大贡献。然而随着数据库使用范围的不断扩大，它被逐步划分为两大基本类型：
1. 操作型数据库
主要用于业务支撑。一个公司往往会使用并维护若干个数据库，这些数据库保存着公司的日常操作数据，比如商品购买、酒店预订、学生成绩录入等；
2. 分析型数据库
主要用于历史数据分析。这类数据库作为公司的单独数据存储，负责利用历史数据对公司各主题域进行统计分析；
那么为什么要"分家"？在一起不合适吗？能不能构建一个同样适用于操作和分析的统一数据库？
答案是NO。一个显然的原因是它们会"打架"......如果操作型任务和分析型任务抢资源怎么办呢？再者，它们有太多不同，以致于早已"貌合神离"。接下来看看它们到底有哪些不同吧。
操作型数据库 VS 分析型数据库
因为主导功能的不同(面向操作/面向分析)，两类数据库就产生了很多细节上的差异。这就好像同样是人，但一个和尚和一个穆斯林肯定有很多行为/观念上的不同。
接下来本文将详细分析两类数据库的不同点：
1. 数据组成差别 - 数据时间范围差别
一般来讲，操作型数据库只会存放90天以内的数据，而分析型数据库存放的则是数年内的数据。这点也是将操作型数据和分析型数据进行物理分离的主要原因。
2. 数据组成差别 - 数据细节层次差别
操作型数据库存放的主要是细节数据，而分析型数据库中虽然既有细节数据，又有汇总数据，但对于用户来说，重点关注的是汇总数据部分。
操作型数据库中自然也有汇总需求，但汇总数据本身不存储而只存储其生成公式。这是因为操作型数据是动态变化的，因此汇总数据会在每次查询时动态生成。
而对于分析型数据库来说，因为汇总数据比较稳定不会发生改变，而且其计算量也比较大(因为时间跨度大)，因此它的汇总数据可考虑事先计算好，以避免重复计算。
3. 数据组成差别 - 数据时间表示差别
操作型数据通常反映的是现实世界的当前状态；而分析型数据库既有当前状态，还有过去各时刻的快照，分析型数据库的使用者可以综合所有快照对各个历史阶段进行统计分析。
4. 技术差别 - 查询数据总量和查询频度差别
操作型查询的数据量少而频率多，分析型查询则反过来，数据量大而频率少。要想同时实现这两种情况的配置优化是不可能的，这也是将两类数据库物理分隔的原因之一。
5. 技术差别 - 数据更新差别
操作型数据库允许用户进行增，删，改，查；分析型数据库用户则只能进行查询。
6. 技术差别 - 数据冗余差别
数据的意义是什么？就是减少数据冗余，避免更新异常。而如5所述，分析型数据库中没有更新操作。因此，减少数据冗余也就没那么重要了。
现在回到开篇是提到的第二个问题"某大公司Hadoop Hive里的关系表不完全满足完整/参照性约束，也不完全满足范式要求，甚至第一范式都不满足。这种情况正常吗？"，答曰是正常的。因为Hive是一种数据仓库，而数据仓库和分析型数据库的关系非常紧密(后文会讲到)。它只提供查询接口，不提供更新接口，这就使得消除冗余的诸多措施不需要被特别严格地执行了。
7. 功能差别 - 数据读者差别
操作型数据库的使用者是业务环境内的各个角色，如用户，商家，进货商等；分析型数据库则只被少量用户用来做综合性决策。
8. 功能差别 - 数据定位差别
这里说的定位，主要是指以何种目的组织起来。操作型数据库是为了支撑具体业务的，因此也被称为"面向应用型数据库"；分析型数据库则是针对各特定业务主题域的分析任务创建的，因此也被称为"面向主题型数据库"。
数据仓库(data warehouse)定义
聪明的读者应该已经意识到这个问题：既然分析型数据库中的操作都是查询，因此也就不需要严格满足完整性/参照性约束以及范式设计要求，而这些却正是关系数据库精华所在。这样的情况下再将它归为数据库会很容易引起大家混淆，毕竟在绝大多数人心里数据库是可以关系型数据库画上等号的。
那么为什么不干脆叫"面向分析的存储系统"呢？
Bingo！~这就是关于数据仓库最贴切的定义了。事实上数据仓库不应让传统关系数据库来实现，因为关系数据库最少也要求满足第1范式，而数据仓库里的关系表可以不满足第1范式。也就是说，同样的记录在一个关系表里可以出现N次。但由于大多数数据仓库内的表的统计分析还是用SQL，因此很多人把它和关系数据库搞混了。
知道了什么是数据仓库后，再来看看它有哪些特点吧。某种程度上来说，这也是分析型数据库的特点：
1. 面向主题
面向主题特性是数据仓库和操作型数据库的根本区别。操作型数据库是为了支撑各种业务而建立，而分析型数据库则是为了对从各种繁杂业务中抽象出来的分析主题(如用户、成本、商品等)进行分析而建立；
2. 集成性
集成性是指数据仓库会将不同源数据库中的数据汇总到一起；
3. 企业范围
数据仓库内的数据是面向公司全局的。比如某个主题域为成本，则全公司和成本有关的信息都会被汇集进来；
4. 历史性
较之操作型数据库，数据仓库的时间跨度通常比较长。前者通常保存几个月，后者可能几年甚至几十年；
5. 时变性
时变性是指数据仓库包含来自其时间范围不同时间段的数据快照。有了这些数据快照以后，用户便可将其汇总，生成各历史阶段的数据分析报告；
数据仓库组件
数据仓库的核心组件有四个：各源数据库，ETL，数据仓库，前端应用。如下图所示：
1. 业务系统
业务系统包含各种源数据库，这些源数据库既为业务系统提供数据支撑，同时也作为数据仓库的数据源(注：除了业务系统，数据仓库也可从其他外部数据源获取数据)；
2. ETL
ETL分别代表：提取extraction、转换transformation、加载load。其中提取过程表示操作型数据库搜集指定数据，转换过程表示将数据转化为指定格式并进行数据清洗保证数据质量，加载过程表示将转换过后满足指定格式的数据加载进数据仓库。数据仓库会周期不断地从源数据库提取清洗好了的数据，因此也被称为"目标系统"；
3. 前端应用
和操作型数据库一样，数据仓库通常提供具有直接访问数据仓库功能的前端应用，这些应用也被称为BI(商务智能)应用；
数据集市(data mart)
数据集市可以理解为是一种"小型数据仓库"，它只包含单个主题，且关注范围也非全局。
数据集市可以分为两种，一种是独立数据集市(independent data mart)，这类数据集市有自己的源数据库和ETL架构；另一种是非独立数据集市(dependent data mart)，这种数据集市没有自己的源系统，它的数据来自数据仓库。当用户或者应用程序不需要/不必要/不允许用到整个数据仓库的数据时，非独立数据集市就可以简单为用户提供一个数据仓库的"子集"。
数据仓库开发流程
下图为数据仓库的开发流程：
较之数据库系统开发，数据仓库开发只多出ETL工程部分。然而这一部分极有可能是整个数据仓库开发流程中最为耗时耗资源的一个环节。因为该环节要整理各大业务系统中杂乱无章的数据并协调元数据上的差别，所以工作量很大。在很多公司都专门设有ETL工程师这样的岗位，大的公司甚至专门聘请ETL专家。
小结
在大数据时代，数据仓库的重要性更胜以往。Hadoop平台下的Hive，Spark平台下的Spark SQL都是各自生态圈内应用最热门的配套工具，而它们的本质就是开源分布式数据仓库。
在国内最优秀的互联网公司里(如阿里、腾讯)，很多数据引擎是架构在数据仓库之上的(如数据分析引擎、数据挖掘引擎、推荐引擎、可视化引擎等等)。不少员工认为，开发成本应更多集中在数据仓库层，不断加大数据建设的投入。因为一旦规范、标准、高性能的数据仓库建立好了，在之上进行数据分析、数据挖掘、跑推荐算法等都是轻松惬意的事情。反之如果业务数据没梳理好，各种脏乱数据会搞得人焦头烂额，苦不堪言。
二、数据仓库与数据集市建模
前言
本文将详细介绍数据仓库维度建模技术，并重点讨论三种基于ER建模/关系建模/维度建模的数据仓库总体建模体系：规范化数据仓库，维度建模数据仓库，以及独立数据集市。
维度建模的基本概念
维度建模(dimensional modeling)是专门用于分析型数据库、数据仓库、数据集市建模的方法。
它本身属于一种关系建模方法，但和之前在操作型数据库中介绍的关系建模方法相比增加了两个概念：
1. 维度表(dimension)
表示对分析主题所属类型的描述。比如"昨天早上张三在京东花费200元购买了一个皮包"。那么以购买为主题进行分析，可从这段信息中提取三个维度：时间维度(昨天早上)，地点维度(京东), 商品维度(皮包)。通常来说维度表信息比较固定，且数据量小。
2. 事实表(fact table)
表示对分析主题的度量。比如上面那个例子中，200元就是事实信息。事实表包含了与各维度表相关联的外码，并通过JOIN方式与维度表关联。事实表的度量通常是数值类型，且记录数会不断增加，表规模迅速增长
维度建模的三种模式
1. 星形模式
星形模式(Star Schema)是最常用的维度建模方式，下图展示了使用星形模式进行维度建模的关系结构：
可以看出，星形模式的维度建模由一个事实表和一组维表成，且具有以下特点：
a. 维表只和事实表关联，维表之间没有关联；
b. 每个维表的主码为单列，且该主码放置在事实表中，作为两边连接的外码；
c. 以事实表为核心，维表围绕核心呈星形分布；
2. 雪花模式
雪花模式(Snowflake Schema)是对星形模式的扩展，每个维表可继续向外连接多个子维表。下图为使用雪花模式进行维度建模的关系结构：
星形模式中的维表相对雪花模式来说要大，而且不满足规范化设计。雪花模型相当于将星形模式的大维表拆分成小维表，满足了规范化设计。然而这种模式在实际应用中很少见，因为这样做会导致开发难度增大，而数据冗余问题在数据仓库里并不严重。
3. 星座模式
星座模式(Fact Constellations Schema)也是星型模式的扩展。基于这种思想就有了星座模式：
前面介绍的两种维度建模方法都是多维表对应单事实表，但在很多时候维度空间内的事实表不止一个，而一个维表也可能被多个事实表用到。在业务发展后期，绝大部分维度建模都采用的是星座模式。
4. 三种模式对比
归纳一下，星形模式/雪花模式/星座模式的关系如下图所示：
雪花模式是将星型模式的维表进一步划分，使各维表均满足规范化设计。而星座模式则是允许星形模式中出现多个事实表。本文后面部分将具体讲到这几种模式的使用，请读者结合实例体会。
实例：零售公司销售主题的维度建模
在进行维度建模前，首先要了解用户需求。而笔者在数据库系列的第一篇就讲过，ER建模是当前收集和可视化需求的最佳技术。因此假定和某零售公司进行多次需求PK后，得到以下ER图：
随后可利用建模工具将ER图直接映射到关系图： 
需求搜集完毕后，便可进行维度建模了。本例采用星形模型维度建模。但不论采取何种模式，维度建模的关键在于明确下面四个问题：
1. 哪些维度对主题分析有用？
本例中，根据产品(PRODUCT)、顾客(CUSTOMER)、商店(STORE)、日期(DATE)对销售额进行分析是非常有帮助的；
2. 如何使用现有数据生成维表？
a. 维度PRODUCT可由关系PRODUCT，关系VENDOR，关系CATEGORY连接得到；
b. 维度CUSTOMER和关系CUSTOMER相同；
c. 维度STORE可由关系STROE和关系REGION连接得到；
d. 维度CALENDAR由关系SALESTRANSACTION中的TDate列分离得到；
3. 用什么指标来"度量"主题？
本例的主题是销售，而销量和销售额这两个指标最能直观反映销售情况；
4. 如何使用现有数据生成事实表？
销量和销售额信息可以由关系SALESTRANSACTION和关系SOLDVIA，关系PRODUCT连接得到；
明确这四个问题后，便能轻松完成维度建模：
细心的读者会发现三个问题：1. 维表不满足规范化设计(不满足3NF)；2. 事实表也不满足规范化设计(1NF都不满足)； 3. 维度建模中各维度的主码由***ID变成***Key；
对于前两个问题，由于当前建模环境是数据仓库，而没有更新操作，所以不需要严格做规范化设计来消除冗余避免更新异常。
因此虽然可以以雪花模型进行维度建模，如下所示： 
但这样会加大查询人员负担：每次查询都涉及到太多表了。因此在实际应用中，雪花模型仅是一种理论上的模型。星座模型则出现在"维度建模数据仓库"中，本文后面将会讲到。
对于第三个问题，***Key这样的字段被称为代理码(surrogate key)，它是一个通过自动分配整数生成的主码，没有任何其他意义。使用它主要是为了能够处理"缓慢变化的维度"，本文后面会仔细分析这个问题，这里不纠结。
更多可能的事实属性
除了对应到维度的外码和度量属性，事实表中还常常考虑另外两个属性：事务标识码(transaction identifier)和事务时间(transaction time)。
事务标识码通常被命名为TID，其意义就是各种订单号，事务编号...... 为什么将这个属性放到事实表而不是维表中呢？一个主要原因是它的数量级太大了，这样每次查询都会耗费很多资源来Join。这种将某些逻辑意义上的维度放到事实表里的做法被称为退化维度(degenerate dimension)。
将事务时间维度放到事实表中的考虑也是出于相同考虑。然而这么设计又一次"逆规范化"了：事务标识码非主码却决定事务标识时间，显然违背了3NF。但现在我们是为数据仓库建模，所以这样做是OK的。另外在分布式的数据仓库中，这个字段十分重要。因为事实表的数量级非常大，Hive或者Spark SQL这类分布式数据仓库工具都会对这些数据进行分区。任何成熟的分布式计算平台中都应禁止开发人员建立非分区事实表，并默认分区字段为(当天)日期。
前文已经讲过，有多个事实表的维度模型被称为星座模型。星座模型主要有以下两大作用：共享维度和设置细节/聚集事实表。下面分别对这两种情况进行分析：
1. 共享维度
以前文提到的零售公司为例，假如该公司质量监管部门希望用分析销售主题同样的方法分析劣质产品，那么此时不需要重新维度建模，只需往模型里加入一个新的劣质产品事实表。之后新的数据仓库维度建模结果如下：
2. 细节/聚集事实表
细节事实表(detailed fact tables)中每条记录表示单一事实，而聚集事实表(aggregated fact tables)中每条记录则聚合了多条事实。从表的字段上看，细节事实表通常有设置TID属性，而聚集事实表则无。
两种事实表各有优缺点，细节事实表查询灵活但是响应速度相对慢，而聚集事实表虽然提高了查询速度，但使查询功能受到一定限制。一个常见的做法是使用星座模型同时设置两种事实表(可含多个聚集事实表)。这种设计方法中，聚集事实表使用和细节事实表细节事实表的维度。如下维度建模方法采用星座模型综合了细节事实表和两种聚集事实表：
缓慢变化维度问题
虽然，维表的数据比事实表更稳定。但不论如何维度在某些时候总会发生一些变化。在之前曾抛出一个问题：为什么维度建模后的关系不是***ID，而是***Key了。这样做的目的其实就是为了解决一种被称为缓慢维度变化(slowly changing dimension)的问题。在维度变化后，一部分历史信息就被丢掉了。比如张三是某公司会员。
但仅仅这么做还是不够的，代理码需要配合时间戳，以及行标识符使用才能解决缓慢维度变化的问题。如下CUSTOMER表使用该方法避免缓慢维度变化：
可以看到用户张三对应新维度的TaxBracket状态由Low变成了High。如果需要统计张三的相关行为，那么可以让所有记录用CustomerID字段Join事实表；如果要统计当前TaxBracket为Low的用户状态，则可将Row Indicator字段为Current的记录用CustomerKey字段Join事实表；如果要统计历史TaxBracket状态为Low的用户情况，则只需要将TaxBracket属性为Low的用户记录的CustomerKey属性与事实表关联。
数据仓库建模体系之规范化数据仓库
所谓"数据仓库建模体系"，指的是数据仓库从无到有的一整套建模方法。最常见的三种数据仓库建模体系分别为：规范化数据仓库，维度建模数据仓库，独立数据集市。很多书将它们称为"数据仓库建模方法"，但笔者认为数据仓库建模体系更能准确表达意思，请允许我自作主张一次吧：）。下面首先来介绍规范化数据仓库。
规范化数据仓库(normalized data warehouse)顾名思义，其中是规范化设计的分析型数据库，然后基于这个数据库为各部门建立数据集市。总体架构如下图所示：
该建模体系首先对ETL得到的数据进行ER建模，关系建模，得到一个规范化的数据库模式。然后用这个中心数据库为公司各部门建立基于维度建模的数据集市。各部门开发人员大都从这些数据集市提数，通常来说不允许直接访问中心数据库。
数据仓库建模体系之维度建模数据仓库
非维度建模数据仓库(dimensionally modeled data warehouse)是一种使用交错维度进行建模的数据仓库，其总体架构如下图所示：
该建模体系首先设计一组常用的度集合(conformed dimension)，然后创建一个大星座模型表示所有分析型数据。如果这种一致维度不满足某些数据分析要求，自然也可在数据仓库之上继续构建新的数据集市。
数据仓库建模体系之独立数据集市
独立数据集市的建模体系是让公司的各个组织自己创建并完成ETL，自己维护自己的数据集市。其总体架构如下图所示：
从技术上来讲这是一种很不值得推崇的方式，因为将使信息分散，影响了企业全局范围内数据分析的效率。此外，各组织之间的ETL架构相互独立无法复用，也浪费了企业的开发资源。然而出于某些公司制度及预算方面的考虑，有时也会使用到这种建模体系。
三种数据仓库建模体系对比
规范化数据仓库和维度建模数据仓库分别是Bill Inmon和Ralph Kimball提出的方法。关于哪种方法更好，哪种方法更优秀的争论已经由来已久。但随着这两种数据仓库应用越来越多，人们也逐渐了解到两种数据仓库的优劣之处，如下表所示：
产生这些区别的根本之处在于规范化数据仓库需要对企业全局进行规范化建模，这将导致较大的工作量。但这一步必须完成好，才能继续往上建设数据集市。因此也就导致规范化数据仓库需要一定时间才能投入使用，敏捷性相对后者来说略差。但是规范化数据仓库一旦建立好了，则以后数据就更易于管理。而且由于开发人员不能直接使用其中心数据库，更加确保了数据质量。还有由于中心数据库是采用规范化设计的，冗余情况也会更少。
然而另一方面维度建模数据仓库除了敏捷性更强，而且适用于业务变化比较频繁的情况，对开发人员的要求也没有规范化数据仓库那么高。总之各有利弊，具体实施时需要仔细的权衡。
小结
数据仓库建模是一个综合性技术，需要使用到ER建模、关系建模、维度建模等技术。而且当企业业务复杂的时候，这部分工作更是需要专门团队与业务方共同合作来完成。因此一个优秀的数据仓库建模团队既要有坚实的数据仓库建模技术，还要有对现实业务清晰、透彻的理解。
三、数据仓库系统的实现与使用（olap讲解）
前言
上一章节重点讲解了数据仓库建模，它是数据仓库开发中最核心的部分。然而完整的数据仓库系统还会涉及其他一些组件的开发，其中最主要的是ETL工程，在线分析处理工具(OLAP)和商务智能(BI)应用等。
本文将对这些方面做一个总体性的介绍(尤其是OLAP)，旨在让读者对数据仓库的认识提升到一个全局性的高度。
创建数据仓库
数据仓库的创建方法和数据库类似，也是通过编写DDL语句来实现。在过去，数据仓库系统大都建立在RDBMS上，因为维度建模其实也可以看做是关系建模的一种。但如今随着开源分布式数据仓库工具如Hadoop Hive，Spark SQL的兴起，开发人员往往将建模和实现分离。使用专门的建模软件进行ER建模、关系建模、维度建模，而具体实现则在Hive/Spark SQL下进行。没办法，谁让这些开源工具没有提供自带的可视化建模插件呢:-(。
话说现在的开源分布式工具都是"散兵作战"，完成一个大的项目要组合N个工具，没有一个统一的开发平台。还有就是可视化效果比较差，界面很难看或者没有界面。个人建议在资金足够的情况下尽量使用商用大数据平台来开发，虽然这些商用产品广告打得多少有点夸张，但是它们的易用性做的是真好。这里笔者推荐阿里云的数加平台，附链接：https://data.aliyun.com/。
ETL：抽取、转换、加载
ETL工作的实质就是从各个数据源提取数据，对数据进行转换，并最终加载填充数据到数据仓库维度建模后的表中。只有当这些维度/事实表被填充好，ETL工作才算完成。接下来分别对抽取，转换，加载这三个环节进行讲解：
1. 抽取(Extract)
数据仓库是面向分析的，而操作型数据库是面向应用的。显然，并不是所有用于支撑业务系统的数据都有拿来分析的必要。因此，该阶段主要是根据数据仓库主题、主题域确定需要从应用数据库中提取的数。
具体开发过程中，开发人员必然经常发现某些ETL步骤和数据仓库建模后的表描述不符。这时候就要重新核对、设计需求，重新进行ETL。任何涉及到需求的变动，都需要重头开始并更新需求文档。
2. 转换(Transform)
转换步骤主要是指对提取好了的数据的结构进行转换，以满足目标数据仓库模型的过程。此外，转换过程也负责数据质量工作，这部分也被称为数据清洗(data cleaning)。
3. 加载(Load)
加载过程将已经提取好了，转换后保证了数据质量的数据加载到目标数据仓库。加载可分为两种L：首次加载(first load)和刷新加载(refresh load)。其中，首次加载会涉及到大量数据，而刷新加载则属于一种微批量式的加载。
多说一句，如今随着各种分布式、云计算工具的兴起，ETL实则变成了ELT。就是业务系统自身不会做转换工作，而是在简单的清洗后将数据导入分布式平台，让平台统一进行清洗转换等工作。这样做能充分利用平台的分布式特性，同时使业务系统更专注于业务本身。
OLAP/BI工具
数据仓库建设好以后，用户就可以编写SQL语句对其进行访问并对其中数据进行分析。但每次查询都要编写SQL语句的话，未免太麻烦，而且对维度建模数据进行分析的SQL代码套路比较固定。于是，便有了OLAP工具，它专用于维度建模数据的分析。而BI工具则是能够将OLAP的结果以图表的方式展现出来，它和OLAP通常出现在一起。(注：本文所指的OLAP工具均指代这两者。)
在规范化数据仓库中OLAP工具和数据仓库的关系大致是这样的： 
这种情况下，OLAP不允许访问中心数据库。一方面中心数据库是采取规范化建模的，而OLAP只支持对维度建模数据的分析；另一方面规范化数据仓库的中心数据库本身就不允许上层开发人员访问。而在维度建模数据仓库中，OLAP/BI工具和数据仓库的关系则是这样的：
在维度建模数据仓库中，OLAP不但可以从数据仓库中直接取数进行分析，还能对架构在其上的数据集市群做同样工作。
数据立方体(Data Cube)
在介绍OLAP工具的具体使用前，先要了解这个概念：数据立方体(Data Cube)。
很多年前，当我们要手工从一堆数据中提取信息时，我们会分析一堆数据报告。通常这些数据报告采用二维表示，是行与列组成的二维表格。但在真实世界里我们分析数据的角度很可能有多个，数据立方体可以理解为就是维度扩展后的二维表格。下图展示了一个三维数据立方体：
尽管这个例子是三维的，但更多时候数据立方体是N维的。它的实现有两种方式，本文后面部分会讲到。其中上一篇讲到的星形模式就是其中一种，该模式其实是一种连接关系表与数据立方体的桥梁。但对于大多数纯OLAP使用者来讲，数据分析的对象就是这个逻辑概念上的数据立方体，其具体实现不用深究。对于这些OLAP工具的使用者来讲，基本用法是首先配置好维表、事实表，然后在每次查询的时候告诉OLAP需要展示的维度和事实字段和操作类型即可。
下面介绍数据立方体中最常见的五大操作：切片，切块，旋转，上卷，下钻。
1. 切片和切块(Slice and Dice)
在数据立方体的某一维度上选定一个维成员的操作叫切片，而对两个或多个维执行选择则叫做切块。下图逻辑上展示了切片和切块操作：
这两种操作的SQL模拟语句如下，主要是对WHERE语句做工作：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
|
# 切片
SELECT
Locates.地区, Products.分类,
SUM
(数量)
FROM
Sales, Dates, Products, Locates
WHERE
Dates.季度 = 2
AND
Sales.Date_key = Dates.Date_key
AND
Sales.Locate_key = Locates.Locate_key
AND
Sales.Product_key = Products.Product_key
GROUP
BY
Locates.地区, Products.分类
# 切块
SELECT
Locates.地区, Products.分类,
SUM
(数量)
FROM
Sales, Dates, Products, Locates
WHERE
(Dates.季度 = 2
OR
Dates.季度 = 3)
AND
(Locates.地区 =
'江苏'
OR
Locates.地区 =
'上海'
)
AND
Sales.Date_key = Dates.Date_key
AND
Sales.Locate_key = Locates.Locate_key
AND
Sales.Product_key = Products.Product_key
GROUP
BY
Dates.季度, Locates.地区, Products.分类
|
2. 旋转(Pivot)
旋转就是指改变报表或页面的展示方向。对于使用者来说，就是个视图操作，而从SQL模拟语句的角度来说，就是改变SELECT后面字段的顺序而已。下图逻辑上展示了旋转操作：
3. 上卷和下钻(Rol-up and Drill-down)
上卷可以理解为"无视"某些维度；下钻则是指将某些维度进行细分。下图逻辑上展示了上卷和下钻操作：
这两种操作的SQL模拟语句如下，主要是对GROUP BY语句做工作：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
|
# 上卷
SELECT
Locates.地区, Products.分类,
SUM
(数量)
FROM
Sales, Products, Locates
WHERE
Sales.Locate_key = Locates.Locate_key
AND
Sales.Product_key = Products.Product_key
GROUP
BY
Locates.地区, Products.分类
# 下钻
SELECT
Locates.地区, Dates.季度, Products.分类,
SUM
(数量)
FROM
Sales, Dates, Products, Locates
WHERE
Sales.Date_key = Dates.Date_key
AND
Sales.Locate_key = Locates.Locate_key
AND
Sales.Product_key = Products.Product_key
GROUP
BY
Dates.季度.月份, Locates.地区, Products.分类
|
4. 其他OLAP操作
除了上述的几个基本操作，不同的OLAP工具也会提供自有的OLAP查询功能，如钻过，钻透等，本文不一一进行讲解。通常一个复杂的OLAP查询是多个这类OLAP操作叠加的结果。
OLAP的架构模式
1. MOLAP(Multidimensional Online Analytical Processing)
MOLAP架构会生成一个新的多维数据集，也可以说是构建了一个实际数据立方体。其架构如下图所示：
在该立方体中，每一格对应一个直接地址，且常用的查询已被预先计算好。因此每次的查询都是非常快速的，但是由于立方体的更新比较慢，所以是否使用这种架构得具体问题具体分析。
2. ROLAP(Relational Online Analytical Processing)
ROLAP架构并不会生成实际的多维数据集，而是使用星形模式以及多个关系表对数据立方体进行模拟。其架构如下图所示：
显然，这种架构下的查询没有MOLAP快速。因为ROLAP中，所有的查询都是被转换为SQL语句执行的。而这些SQL语句的执行会涉及到多个表之间的JOIN操作，没有MOLAP速度快。
3. HOLAP(Hybrid Online Analytical Processing)
这种架构综合参考MOLAP和ROLAP而采用一种混合解决方案，将某些需要特别提速的查询放到MOLAP引擎，其他查询则调用ROLAP引擎。
笔者发现一个有趣的现象，很多工具的发展都满足这个规律：工具A被创造，投入使用后发现缺点；然后工具B为了弥补这个缺点而被创造，但是带来了新的缺点；然后就会用工具C被创造，根据不同情况调用A和B。比较无语......
小结
本文是数据仓库系列的最后一篇。一路下来，读者有木有发现数据仓库系统的开发是一个非常浩大的工程呢？
确实，整个数据仓库系统的开发会涉及到各种团队：数据建模团队，业务分析团队，系统架构团队，平台维护团队，前端开发团队等等。对于志在从事这方面工作的人来说，需要学习的还有很多。但对于和笔者一样志在成为一名优秀"数据科学家"的人来说，这些数据基础知识已经够用了。笔者看来，数据科学家的核心竞争优势在三个方面：数据基础，数据可视化，算法模型。这三个方面需要投入的时间成本递增，而知识的重要性递减。因此，数据库系列和数据仓库系列是性价比最高的两个系列哦。
接下来，我将把目光聚焦到数据可视化系列，以及酝酿了很久的数据挖掘系列上来。数据管理好了，需要酷炫的show出来吧！需要进一步挖掘其价值吧！欢迎继续关注！！
本文整理自：穆晨博客
二、数据仓库与数据集市建模
前言
本文将详细介绍数据仓库维度建模技术，并重点讨论三种基于ER建模/关系建模/维度建模的数据仓库总体建模体系：规范化数据仓库，维度建模数据仓库，以及独立数据集市。
维度建模的基本概念
维度建模(dimensional modeling)是专门用于分析型数据库、数据仓库、数据集市建模的方法。
它本身属于一种关系建模方法，但和之前在操作型数据库中介绍的关系建模方法相比增加了两个概念：
1. 维度表(dimension)
表示对分析主题所属类型的描述。比如"昨天早上张三在京东花费200元购买了一个皮包"。那么以购买为主题进行分析，可从这段信息中提取三个维度：时间维度(昨天早上)，地点维度(京东), 商品维度(皮包)。通常来说维度表信息比较固定，且数据量小。
2. 事实表(fact table)
表示对分析主题的度量。比如上面那个例子中，200元就是事实信息。事实表包含了与各维度表相关联的外码，并通过JOIN方式与维度表关联。事实表的度量通常是数值类型，且记录数会不断增加，表规模迅速增长
维度建模的三种模式
1. 星形模式
星形模式(Star Schema)是最常用的维度建模方式，下图展示了使用星形模式进行维度建模的关系结构：
可以看出，星形模式的维度建模由一个事实表和一组维表成，且具有以下特点：
a. 维表只和事实表关联，维表之间没有关联；
b. 每个维表的主码为单列，且该主码放置在事实表中，作为两边连接的外码；
c. 以事实表为核心，维表围绕核心呈星形分布；
2. 雪花模式
雪花模式(Snowflake Schema)是对星形模式的扩展，每个维表可继续向外连接多个子维表。下图为使用雪花模式进行维度建模的关系结构：
星形模式中的维表相对雪花模式来说要大，而且不满足规范化设计。雪花模型相当于将星形模式的大维表拆分成小维表，满足了规范化设计。然而这种模式在实际应用中很少见，因为这样做会导致开发难度增大，而数据冗余问题在数据仓库里并不严重。
3. 星座模式
星座模式(Fact Constellations Schema)也是星型模式的扩展。基于这种思想就有了星座模式：
前面介绍的两种维度建模方法都是多维表对应单事实表，但在很多时候维度空间内的事实表不止一个，而一个维表也可能被多个事实表用到。在业务发展后期，绝大部分维度建模都采用的是星座模式。
4. 三种模式对比
归纳一下，星形模式/雪花模式/星座模式的关系如下图所示：
雪花模式是将星型模式的维表进一步划分，使各维表均满足规范化设计。而星座模式则是允许星形模式中出现多个事实表。本文后面部分将具体讲到这几种模式的使用，请读者结合实例体会。
实例：零售公司销售主题的维度建模
在进行维度建模前，首先要了解用户需求。而笔者在数据库系列的第一篇就讲过，ER建模是当前收集和可视化需求的最佳技术。因此假定和某零售公司进行多次需求PK后，得到以下ER图：
随后可利用建模工具将ER图直接映射到关系图：
需求搜集完毕后，便可进行维度建模了。本例采用星形模型维度建模。但不论采取何种模式，维度建模的关键在于明确下面四个问题：
1. 哪些维度对主题分析有用？
本例中，根据产品(PRODUCT)、顾客(CUSTOMER)、商店(STORE)、日期(DATE)对销售额进行分析是非常有帮助的；
2. 如何使用现有数据生成维表？
a. 维度PRODUCT可由关系PRODUCT，关系VENDOR，关系CATEGORY连接得到；
b. 维度CUSTOMER和关系CUSTOMER相同；
c. 维度STORE可由关系STROE和关系REGION连接得到；
d. 维度CALENDAR由关系SALESTRANSACTION中的TDate列分离得到；
3. 用什么指标来"度量"主题？
本例的主题是销售，而销量和销售额这两个指标最能直观反映销售情况；
4. 如何使用现有数据生成事实表？
销量和销售额信息可以由关系SALESTRANSACTION和关系SOLDVIA，关系PRODUCT连接得到；
明确这四个问题后，便能轻松完成维度建模：
细心的读者会发现三个问题：1. 维表不满足规范化设计(不满足3NF)；2. 事实表也不满足规范化设计(1NF都不满足)； 3. 维度建模中各维度的主码由***ID变成***Key；
对于前两个问题，由于当前建模环境是数据仓库，而没有更新操作，所以不需要严格做规范化设计来消除冗余避免更新异常。
因此虽然可以以雪花模型进行维度建模，如下所示：
但这样会加大查询人员负担：每次查询都涉及到太多表了。因此在实际应用中，雪花模型仅是一种理论上的模型。星座模型则出现在"维度建模数据仓库"中，本文后面将会讲到。
对于第三个问题，***Key这样的字段被称为代理码(surrogate key)，它是一个通过自动分配整数生成的主码，没有任何其他意义。使用它主要是为了能够处理"缓慢变化的维度"，本文后面会仔细分析这个问题，这里不纠结。
更多可能的事实属性
除了对应到维度的外码和度量属性，事实表中还常常考虑另外两个属性：事务标识码(transaction identifier)和事务时间(transaction time)。
事务标识码通常被命名为TID，其意义就是各种订单号，事务编号...... 为什么将这个属性放到事实表而不是维表中呢？一个主要原因是它的数量级太大了，这样每次查询都会耗费很多资源来Join。这种将某些逻辑意义上的维度放到事实表里的做法被称为退化维度(degenerate dimension)。
将事务时间维度放到事实表中的考虑也是出于相同考虑。然而这么设计又一次"逆规范化"了：事务标识码非主码却决定事务标识时间，显然违背了3NF。但现在我们是为数据仓库建模，所以这样做是OK的。另外在分布式的数据仓库中，这个字段十分重要。因为事实表的数量级非常大，Hive或者Spark SQL这类分布式数据仓库工具都会对这些数据进行分区。任何成熟的分布式计算平台中都应禁止开发人员建立非分区事实表，并默认分区字段为(当天)日期。
前文已经讲过，有多个事实表的维度模型被称为星座模型。星座模型主要有以下两大作用：共享维度和设置细节/聚集事实表。下面分别对这两种情况进行分析：
1. 共享维度
以前文提到的零售公司为例，假如该公司质量监管部门希望用分析销售主题同样的方法分析劣质产品，那么此时不需要重新维度建模，只需往模型里加入一个新的劣质产品事实表。之后新的数据仓库维度建模结果如下：
2. 细节/聚集事实表
细节事实表(detailed fact tables)中每条记录表示单一事实，而聚集事实表(aggregated fact tables)中每条记录则聚合了多条事实。从表的字段上看，细节事实表通常有设置TID属性，而聚集事实表则无。
两种事实表各有优缺点，细节事实表查询灵活但是响应速度相对慢，而聚集事实表虽然提高了查询速度，但使查询功能受到一定限制。一个常见的做法是使用星座模型同时设置两种事实表(可含多个聚集事实表)。这种设计方法中，聚集事实表使用和细节事实表细节事实表的维度。如下维度建模方法采用星座模型综合了细节事实表和两种聚集事实表：
缓慢变化维度问题
虽然，维表的数据比事实表更稳定。但不论如何维度在某些时候总会发生一些变化。在之前曾抛出一个问题：为什么维度建模后的关系不是***ID，而是***Key了。这样做的目的其实就是为了解决一种被称为缓慢维度变化(slowly changing dimension)的问题。在维度变化后，一部分历史信息就被丢掉了。比如张三是某公司会员。
但仅仅这么做还是不够的，代理码需要配合时间戳，以及行标识符使用才能解决缓慢维度变化的问题。如下CUSTOMER表使用该方法避免缓慢维度变化：
可以看到用户张三对应新维度的TaxBracket状态由Low变成了High。如果需要统计张三的相关行为，那么可以让所有记录用CustomerID字段Join事实表；如果要统计当前TaxBracket为Low的用户状态，则可将Row Indicator字段为Current的记录用CustomerKey字段Join事实表；如果要统计历史TaxBracket状态为Low的用户情况，则只需要将TaxBracket属性为Low的用户记录的CustomerKey属性与事实表关联。
数据仓库建模体系之规范化数据仓库
所谓"数据仓库建模体系"，指的是数据仓库从无到有的一整套建模方法。最常见的三种数据仓库建模体系分别为：规范化数据仓库，维度建模数据仓库，独立数据集市。很多书将它们称为"数据仓库建模方法"，但笔者认为数据仓库建模体系更能准确表达意思，请允许我自作主张一次吧：）。下面首先来介绍规范化数据仓库。
规范化数据仓库(normalized data warehouse)顾名思义，其中是规范化设计的分析型数据库，然后基于这个数据库为各部门建立数据集市。总体架构如下图所示：
该建模体系首先对ETL得到的数据进行ER建模，关系建模，得到一个规范化的数据库模式。然后用这个中心数据库为公司各部门建立基于维度建模的数据集市。各部门开发人员大都从这些数据集市提数，通常来说不允许直接访问中心数据库。
数据仓库建模体系之维度建模数据仓库
非维度建模数据仓库(dimensionally modeled data warehouse)是一种使用交错维度进行建模的数据仓库，其总体架构如下图所示：
该建模体系首先设计一组常用的度集合(conformed dimension)，然后创建一个大星座模型表示所有分析型数据。如果这种一致维度不满足某些数据分析要求，自然也可在数据仓库之上继续构建新的数据集市。
数据仓库建模体系之独立数据集市
独立数据集市的建模体系是让公司的各个组织自己创建并完成ETL，自己维护自己的数据集市。其总体架构如下图所示：
从技术上来讲这是一种很不值得推崇的方式，因为将使信息分散，影响了企业全局范围内数据分析的效率。此外，各组织之间的ETL架构相互独立无法复用，也浪费了企业的开发资源。然而出于某些公司制度及预算方面的考虑，有时也会使用到这种建模体系。
三种数据仓库建模体系对比
规范化数据仓库和维度建模数据仓库分别是Bill Inmon和Ralph Kimball提出的方法。关于哪种方法更好，哪种方法更优秀的争论已经由来已久。但随着这两种数据仓库应用越来越多，人们也逐渐了解到两种数据仓库的优劣之处，如下表所示：
产生这些区别的根本之处在于规范化数据仓库需要对企业全局进行规范化建模，这将导致较大的工作量。但这一步必须完成好，才能继续往上建设数据集市。因此也就导致规范化数据仓库需要一定时间才能投入使用，敏捷性相对后者来说略差。但是规范化数据仓库一旦建立好了，则以后数据就更易于管理。而且由于开发人员不能直接使用其中心数据库，更加确保了数据质量。还有由于中心数据库是采用规范化设计的，冗余情况也会更少。
然而另一方面维度建模数据仓库除了敏捷性更强，而且适用于业务变化比较频繁的情况，对开发人员的要求也没有规范化数据仓库那么高。总之各有利弊，具体实施时需要仔细的权衡。
小结
数据仓库建模是一个综合性技术，需要使用到ER建模、关系建模、维度建模等技术。而且当企业业务复杂的时候，这部分工作更是需要专门团队与业务方共同合作来完成。因此一个优秀的数据仓库建模团队既要有坚实的数据仓库建模技术，还要有对现实业务清晰、透彻的理解。
三、数据仓库系统的实现与使用（olap讲解）
前言
上一章节重点讲解了数据仓库建模，它是数据仓库开发中最核心的部分。然而完整的数据仓库系统还会涉及其他一些组件的开发，其中最主要的是ETL工程，在线分析处理工具(OLAP)和商务智能(BI)应用等。
本文将对这些方面做一个总体性的介绍(尤其是OLAP)，旨在让读者对数据仓库的认识提升到一个全局性的高度。
创建数据仓库
数据仓库的创建方法和数据库类似，也是通过编写DDL语句来实现。在过去，数据仓库系统大都建立在RDBMS上，因为维度建模其实也可以看做是关系建模的一种。但如今随着开源分布式数据仓库工具如Hadoop Hive，Spark SQL的兴起，开发人员往往将建模和实现分离。使用专门的建模软件进行ER建模、关系建模、维度建模，而具体实现则在Hive/Spark SQL下进行。没办法，谁让这些开源工具没有提供自带的可视化建模插件呢:-(。
话说现在的开源分布式工具都是"散兵作战"，完成一个大的项目要组合N个工具，没有一个统一的开发平台。还有就是可视化效果比较差，界面很难看或者没有界面。个人建议在资金足够的情况下尽量使用商用大数据平台来开发，虽然这些商用产品广告打得多少有点夸张，但是它们的易用性做的是真好。这里笔者推荐阿里云的数加平台，附链接：https://data.aliyun.com/。
ETL：抽取、转换、加载
ETL工作的实质就是从各个数据源提取数据，对数据进行转换，并最终加载填充数据到数据仓库维度建模后的表中。只有当这些维度/事实表被填充好，ETL工作才算完成。接下来分别对抽取，转换，加载这三个环节进行讲解：
1. 抽取(Extract)
数据仓库是面向分析的，而操作型数据库是面向应用的。显然，并不是所有用于支撑业务系统的数据都有拿来分析的必要。因此，该阶段主要是根据数据仓库主题、主题域确定需要从应用数据库中提取的数。
具体开发过程中，开发人员必然经常发现某些ETL步骤和数据仓库建模后的表描述不符。这时候就要重新核对、设计需求，重新进行ETL。任何涉及到需求的变动，都需要重头开始并更新需求文档。
2. 转换(Transform)
转换步骤主要是指对提取好了的数据的结构进行转换，以满足目标数据仓库模型的过程。此外，转换过程也负责数据质量工作，这部分也被称为数据清洗(data cleaning)。
3. 加载(Load)
加载过程将已经提取好了，转换后保证了数据质量的数据加载到目标数据仓库。加载可分为两种L：首次加载(first load)和刷新加载(refresh load)。其中，首次加载会涉及到大量数据，而刷新加载则属于一种微批量式的加载。
多说一句，如今随着各种分布式、云计算工具的兴起，ETL实则变成了ELT。就是业务系统自身不会做转换工作，而是在简单的清洗后将数据导入分布式平台，让平台统一进行清洗转换等工作。这样做能充分利用平台的分布式特性，同时使业务系统更专注于业务本身。
OLAP/BI工具
数据仓库建设好以后，用户就可以编写SQL语句对其进行访问并对其中数据进行分析。但每次查询都要编写SQL语句的话，未免太麻烦，而且对维度建模数据进行分析的SQL代码套路比较固定。于是，便有了OLAP工具，它专用于维度建模数据的分析。而BI工具则是能够将OLAP的结果以图表的方式展现出来，它和OLAP通常出现在一起。(注：本文所指的OLAP工具均指代这两者。)
在规范化数据仓库中OLAP工具和数据仓库的关系大致是这样的：
这种情况下，OLAP不允许访问中心数据库。一方面中心数据库是采取规范化建模的，而OLAP只支持对维度建模数据的分析；另一方面规范化数据仓库的中心数据库本身就不允许上层开发人员访问。而在维度建模数据仓库中，OLAP/BI工具和数据仓库的关系则是这样的：
在维度建模数据仓库中，OLAP不但可以从数据仓库中直接取数进行分析，还能对架构在其上的数据集市群做同样工作。
数据立方体(Data Cube)
在介绍OLAP工具的具体使用前，先要了解这个概念：数据立方体(Data Cube)。
很多年前，当我们要手工从一堆数据中提取信息时，我们会分析一堆数据报告。通常这些数据报告采用二维表示，是行与列组成的二维表格。但在真实世界里我们分析数据的角度很可能有多个，数据立方体可以理解为就是维度扩展后的二维表格。下图展示了一个三维数据立方体：
尽管这个例子是三维的，但更多时候数据立方体是N维的。它的实现有两种方式，本文后面部分会讲到。其中上一篇讲到的星形模式就是其中一种，该模式其实是一种连接关系表与数据立方体的桥梁。但对于大多数纯OLAP使用者来讲，数据分析的对象就是这个逻辑概念上的数据立方体，其具体实现不用深究。对于这些OLAP工具的使用者来讲，基本用法是首先配置好维表、事实表，然后在每次查询的时候告诉OLAP需要展示的维度和事实字段和操作类型即可。
下面介绍数据立方体中最常见的五大操作：切片，切块，旋转，上卷，下钻。
1. 切片和切块(Slice and Dice)
在数据立方体的某一维度上选定一个维成员的操作叫切片，而对两个或多个维执行选择则叫做切块。下图逻辑上展示了切片和切块操作：
这两种操作的SQL模拟语句如下，主要是对WHERE语句做工作：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
|
# 切片
SELECT
Locates.地区, Products.分类,
SUM
(数量)
FROM
Sales, Dates, Products, Locates
WHERE
Dates.季度 = 2
AND
Sales.Date_key = Dates.Date_key
AND
Sales.Locate_key = Locates.Locate_key
AND
Sales.Product_key = Products.Product_key
GROUP
BY
Locates.地区, Products.分类
# 切块
SELECT
Locates.地区, Products.分类,
SUM
(数量)
FROM
Sales, Dates, Products, Locates
WHERE
(Dates.季度 = 2
OR
Dates.季度 = 3)
AND
(Locates.地区 =
'江苏'
OR
Locates.地区 =
'上海'
)
AND
Sales.Date_key = Dates.Date_key
AND
Sales.Locate_key = Locates.Locate_key
AND
Sales.Product_key = Products.Product_key
GROUP
BY
Dates.季度, Locates.地区, Products.分类
|
2. 旋转(Pivot)
旋转就是指改变报表或页面的展示方向。对于使用者来说，就是个视图操作，而从SQL模拟语句的角度来说，就是改变SELECT后面字段的顺序而已。下图逻辑上展示了旋转操作：
3. 上卷和下钻(Rol-up and Drill-down)
上卷可以理解为"无视"某些维度；下钻则是指将某些维度进行细分。下图逻辑上展示了上卷和下钻操作：
这两种操作的SQL模拟语句如下，主要是对GROUP BY语句做工作：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
|
# 上卷
SELECT
Locates.地区, Products.分类,
SUM
(数量)
FROM
Sales, Products, Locates
WHERE
Sales.Locate_key = Locates.Locate_key
AND
Sales.Product_key = Products.Product_key
GROUP
BY
Locates.地区, Products.分类
# 下钻
SELECT
Locates.地区, Dates.季度, Products.分类,
SUM
(数量)
FROM
Sales, Dates, Products, Locates
WHERE
Sales.Date_key = Dates.Date_key
AND
Sales.Locate_key = Locates.Locate_key
AND
Sales.Product_key = Products.Product_key
GROUP
BY
Dates.季度.月份, Locates.地区, Products.分类
|
4. 其他OLAP操作
除了上述的几个基本操作，不同的OLAP工具也会提供自有的OLAP查询功能，如钻过，钻透等，本文不一一进行讲解。通常一个复杂的OLAP查询是多个这类OLAP操作叠加的结果。
OLAP的架构模式
1. MOLAP(Multidimensional Online Analytical Processing)
MOLAP架构会生成一个新的多维数据集，也可以说是构建了一个实际数据立方体。其架构如下图所示：
在该立方体中，每一格对应一个直接地址，且常用的查询已被预先计算好。因此每次的查询都是非常快速的，但是由于立方体的更新比较慢，所以是否使用这种架构得具体问题具体分析。
2. ROLAP(Relational Online Analytical Processing)
ROLAP架构并不会生成实际的多维数据集，而是使用星形模式以及多个关系表对数据立方体进行模拟。其架构如下图所示：
显然，这种架构下的查询没有MOLAP快速。因为ROLAP中，所有的查询都是被转换为SQL语句执行的。而这些SQL语句的执行会涉及到多个表之间的JOIN操作，没有MOLAP速度快。
3. HOLAP(Hybrid Online Analytical Processing)
这种架构综合参考MOLAP和ROLAP而采用一种混合解决方案，将某些需要特别提速的查询放到MOLAP引擎，其他查询则调用ROLAP引擎。
笔者发现一个有趣的现象，很多工具的发展都满足这个规律：工具A被创造，投入使用后发现缺点；然后工具B为了弥补这个缺点而被创造，但是带来了新的缺点；然后就会用工具C被创造，根据不同情况调用A和B。比较无语......
小结
本文是数据仓库系列的最后一篇。一路下来，读者有木有发现数据仓库系统的开发是一个非常浩大的工程呢？
确实，整个数据仓库系统的开发会涉及到各种团队：数据建模团队，业务分析团队，系统架构团队，平台维护团队，前端开发团队等等。对于志在从事这方面工作的人来说，需要学习的还有很多。但对于和笔者一样志在成为一名优秀"数据科学家"的人来说，这些数据基础知识已经够用了。笔者看来，数据科学家的核心竞争优势在三个方面：数据基础，数据可视化，算法模型。这三个方面需要投入的时间成本递增，而知识的重要性递减。因此，数据库系列和数据仓库系列是性价比最高的两个系列哦。
接下来，我将把目光聚焦到数据可视化系列，以及酝酿了很久的数据挖掘系列上来。数据管理好了，需要酷炫的show出来吧！需要进一步挖掘其价值吧！欢迎继续关注！！
本文整理自：穆晨博客
三、数据仓库系统的实现与使用（olap讲解）
前言
上一章节重点讲解了数据仓库建模，它是数据仓库开发中最核心的部分。然而完整的数据仓库系统还会涉及其他一些组件的开发，其中最主要的是ETL工程，在线分析处理工具(OLAP)和商务智能(BI)应用等。
本文将对这些方面做一个总体性的介绍(尤其是OLAP)，旨在让读者对数据仓库的认识提升到一个全局性的高度。
创建数据仓库
数据仓库的创建方法和数据库类似，也是通过编写DDL语句来实现。在过去，数据仓库系统大都建立在RDBMS上，因为维度建模其实也可以看做是关系建模的一种。但如今随着开源分布式数据仓库工具如Hadoop Hive，Spark SQL的兴起，开发人员往往将建模和实现分离。使用专门的建模软件进行ER建模、关系建模、维度建模，而具体实现则在Hive/Spark SQL下进行。没办法，谁让这些开源工具没有提供自带的可视化建模插件呢:-(。
话说现在的开源分布式工具都是"散兵作战"，完成一个大的项目要组合N个工具，没有一个统一的开发平台。还有就是可视化效果比较差，界面很难看或者没有界面。个人建议在资金足够的情况下尽量使用商用大数据平台来开发，虽然这些商用产品广告打得多少有点夸张，但是它们的易用性做的是真好。这里笔者推荐阿里云的数加平台，附链接：https://data.aliyun.com/。
ETL：抽取、转换、加载
ETL工作的实质就是从各个数据源提取数据，对数据进行转换，并最终加载填充数据到数据仓库维度建模后的表中。只有当这些维度/事实表被填充好，ETL工作才算完成。接下来分别对抽取，转换，加载这三个环节进行讲解：
1. 抽取(Extract)
数据仓库是面向分析的，而操作型数据库是面向应用的。显然，并不是所有用于支撑业务系统的数据都有拿来分析的必要。因此，该阶段主要是根据数据仓库主题、主题域确定需要从应用数据库中提取的数。
具体开发过程中，开发人员必然经常发现某些ETL步骤和数据仓库建模后的表描述不符。这时候就要重新核对、设计需求，重新进行ETL。任何涉及到需求的变动，都需要重头开始并更新需求文档。
2. 转换(Transform)
转换步骤主要是指对提取好了的数据的结构进行转换，以满足目标数据仓库模型的过程。此外，转换过程也负责数据质量工作，这部分也被称为数据清洗(data cleaning)。
3. 加载(Load)
加载过程将已经提取好了，转换后保证了数据质量的数据加载到目标数据仓库。加载可分为两种L：首次加载(first load)和刷新加载(refresh load)。其中，首次加载会涉及到大量数据，而刷新加载则属于一种微批量式的加载。
多说一句，如今随着各种分布式、云计算工具的兴起，ETL实则变成了ELT。就是业务系统自身不会做转换工作，而是在简单的清洗后将数据导入分布式平台，让平台统一进行清洗转换等工作。这样做能充分利用平台的分布式特性，同时使业务系统更专注于业务本身。
OLAP/BI工具
数据仓库建设好以后，用户就可以编写SQL语句对其进行访问并对其中数据进行分析。但每次查询都要编写SQL语句的话，未免太麻烦，而且对维度建模数据进行分析的SQL代码套路比较固定。于是，便有了OLAP工具，它专用于维度建模数据的分析。而BI工具则是能够将OLAP的结果以图表的方式展现出来，它和OLAP通常出现在一起。(注：本文所指的OLAP工具均指代这两者。)
在规范化数据仓库中OLAP工具和数据仓库的关系大致是这样的：
这种情况下，OLAP不允许访问中心数据库。一方面中心数据库是采取规范化建模的，而OLAP只支持对维度建模数据的分析；另一方面规范化数据仓库的中心数据库本身就不允许上层开发人员访问。而在维度建模数据仓库中，OLAP/BI工具和数据仓库的关系则是这样的：
在维度建模数据仓库中，OLAP不但可以从数据仓库中直接取数进行分析，还能对架构在其上的数据集市群做同样工作。
数据立方体(Data Cube)
在介绍OLAP工具的具体使用前，先要了解这个概念：数据立方体(Data Cube)。
很多年前，当我们要手工从一堆数据中提取信息时，我们会分析一堆数据报告。通常这些数据报告采用二维表示，是行与列组成的二维表格。但在真实世界里我们分析数据的角度很可能有多个，数据立方体可以理解为就是维度扩展后的二维表格。下图展示了一个三维数据立方体：
尽管这个例子是三维的，但更多时候数据立方体是N维的。它的实现有两种方式，本文后面部分会讲到。其中上一篇讲到的星形模式就是其中一种，该模式其实是一种连接关系表与数据立方体的桥梁。但对于大多数纯OLAP使用者来讲，数据分析的对象就是这个逻辑概念上的数据立方体，其具体实现不用深究。对于这些OLAP工具的使用者来讲，基本用法是首先配置好维表、事实表，然后在每次查询的时候告诉OLAP需要展示的维度和事实字段和操作类型即可。
下面介绍数据立方体中最常见的五大操作：切片，切块，旋转，上卷，下钻。
1. 切片和切块(Slice and Dice)
在数据立方体的某一维度上选定一个维成员的操作叫切片，而对两个或多个维执行选择则叫做切块。下图逻辑上展示了切片和切块操作：
这两种操作的SQL模拟语句如下，主要是对WHERE语句做工作：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
|
# 切片
SELECT
Locates.地区, Products.分类,
SUM
(数量)
FROM
Sales, Dates, Products, Locates
WHERE
Dates.季度 = 2
AND
Sales.Date_key = Dates.Date_key
AND
Sales.Locate_key = Locates.Locate_key
AND
Sales.Product_key = Products.Product_key
GROUP
BY
Locates.地区, Products.分类
# 切块
SELECT
Locates.地区, Products.分类,
SUM
(数量)
FROM
Sales, Dates, Products, Locates
WHERE
(Dates.季度 = 2
OR
Dates.季度 = 3)
AND
(Locates.地区 =
'江苏'
OR
Locates.地区 =
'上海'
)
AND
Sales.Date_key = Dates.Date_key
AND
Sales.Locate_key = Locates.Locate_key
AND
Sales.Product_key = Products.Product_key
GROUP
BY
Dates.季度, Locates.地区, Products.分类
|
2. 旋转(Pivot)
旋转就是指改变报表或页面的展示方向。对于使用者来说，就是个视图操作，而从SQL模拟语句的角度来说，就是改变SELECT后面字段的顺序而已。下图逻辑上展示了旋转操作：
3. 上卷和下钻(Rol-up and Drill-down)
上卷可以理解为"无视"某些维度；下钻则是指将某些维度进行细分。下图逻辑上展示了上卷和下钻操作：
这两种操作的SQL模拟语句如下，主要是对GROUP BY语句做工作：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
|
# 上卷
SELECT
Locates.地区, Products.分类,
SUM
(数量)
FROM
Sales, Products, Locates
WHERE
Sales.Locate_key = Locates.Locate_key
AND
Sales.Product_key = Products.Product_key
GROUP
BY
Locates.地区, Products.分类
# 下钻
SELECT
Locates.地区, Dates.季度, Products.分类,
SUM
(数量)
FROM
Sales, Dates, Products, Locates
WHERE
Sales.Date_key = Dates.Date_key
AND
Sales.Locate_key = Locates.Locate_key
AND
Sales.Product_key = Products.Product_key
GROUP
BY
Dates.季度.月份, Locates.地区, Products.分类
|
4. 其他OLAP操作
除了上述的几个基本操作，不同的OLAP工具也会提供自有的OLAP查询功能，如钻过，钻透等，本文不一一进行讲解。通常一个复杂的OLAP查询是多个这类OLAP操作叠加的结果。
OLAP的架构模式
1. MOLAP(Multidimensional Online Analytical Processing)
MOLAP架构会生成一个新的多维数据集，也可以说是构建了一个实际数据立方体。其架构如下图所示：
在该立方体中，每一格对应一个直接地址，且常用的查询已被预先计算好。因此每次的查询都是非常快速的，但是由于立方体的更新比较慢，所以是否使用这种架构得具体问题具体分析。
2. ROLAP(Relational Online Analytical Processing)
ROLAP架构并不会生成实际的多维数据集，而是使用星形模式以及多个关系表对数据立方体进行模拟。其架构如下图所示：
显然，这种架构下的查询没有MOLAP快速。因为ROLAP中，所有的查询都是被转换为SQL语句执行的。而这些SQL语句的执行会涉及到多个表之间的JOIN操作，没有MOLAP速度快。
3. HOLAP(Hybrid Online Analytical Processing)
这种架构综合参考MOLAP和ROLAP而采用一种混合解决方案，将某些需要特别提速的查询放到MOLAP引擎，其他查询则调用ROLAP引擎。
笔者发现一个有趣的现象，很多工具的发展都满足这个规律：工具A被创造，投入使用后发现缺点；然后工具B为了弥补这个缺点而被创造，但是带来了新的缺点；然后就会用工具C被创造，根据不同情况调用A和B。比较无语......
小结
本文是数据仓库系列的最后一篇。一路下来，读者有木有发现数据仓库系统的开发是一个非常浩大的工程呢？
确实，整个数据仓库系统的开发会涉及到各种团队：数据建模团队，业务分析团队，系统架构团队，平台维护团队，前端开发团队等等。对于志在从事这方面工作的人来说，需要学习的还有很多。但对于和笔者一样志在成为一名优秀"数据科学家"的人来说，这些数据基础知识已经够用了。笔者看来，数据科学家的核心竞争优势在三个方面：数据基础，数据可视化，算法模型。这三个方面需要投入的时间成本递增，而知识的重要性递减。因此，数据库系列和数据仓库系列是性价比最高的两个系列哦。
接下来，我将把目光聚焦到数据可视化系列，以及酝酿了很久的数据挖掘系列上来。数据管理好了，需要酷炫的show出来吧！需要进一步挖掘其价值吧！欢迎继续关注！！
本文整理自：穆晨博客