大数据从业者必读书籍《数据仓库工具箱》-第一章笔记

第一章：数据仓库、商业智能及维度建模初步

DW/BI系统应该死扣的是业务需求。

第一章讨论的内容：

• DW/BI系统的业务驱动目标
• 发布DW/BI系统的隐喻
• 维度建模的相关词汇与语义
• DW/BI架构的组件与原则
• 在不同架构中，维度建模的区别
• 关于维度建模的误解

1.1 数据获取与数据分析的区别

信息的两个目的：操作型记录的保存，分析型决策的制定。即数据的获取与数据的分析。

操作型系统无时无刻都在于用户发生交互，每一次交互都在产生数据（订单信息，浏览信息，浏览深度，系统状态等等）。对操作型系统的优化是为了更好的处理事务（更快，更准确，更多的积攒数据）。

分析型系统（也就是DW/BI系统）对操作型系统积攒的数据进行处理，这些处理的本质只有一个：操作型系统在当前是否处于一个正确的状态（注意，不是正常，是正确）。对分析型系统的优化是为了更好的发现业务痛点以来调整操作型系统。

这里，就能体会出数据获取与数据分析的区别，前者用来得到数据，后者考虑怎么让前者更好的得到数据。也就是基层与决策层的区别。

1.2 数据仓库与商业智能的目标

在说目标之前，先说说痛点：

• 我们收集了海量的数据，但是没有办法进行访问
• 我们需要各种方式方便对数据进行切片和切块
• 业务人员需要方便的获得数据
• 将最重要的事情展示出来
• 会议争论的是数字的正确，而不是指定决策
• 人们希望能够使用信息来支持更多的基于事实的决策指定

降维一下就是：

• 更迅速的访问数据
• 更统一的访问方式
• 更便捷的检索数据
• 更高效的数据挖掘
• 更准确的数据计算/统计
• 当然，这些功能要普遍化

然后我们再回头看DW/BI系统，发现他就是专门为了解决这些问题而诞生的。

① DW/BI系统可以更方便的存取信息：系统的内容必须是容易理解的，对业务人员来说，数据必须具有直观性。也就是说数据结构与数据标识必须符合业务人员的思维过程与词汇，即业务需求。

② DW/BI系统必须以一致的方式展示信息：一个系统能够接受多个信息源，系统管理员要求能够精心的组织不同来源的信息，进行数据清洗，确保质量。也就是说数据结构与数据标识应当可以兼容多个信息源，即数据源需求。

③ DW/BI系统必须能够适应变化：用户需求，业务环境，技术等等都很容易发生变化，设计数仓时要考虑使其能够方便的处理无法避免的变化，以便发生变化后依旧可以处理已有的数据。也就是说在进行修改时，已有的数据结构与数据标识应当不被改变或破坏，最好用适当的方式来描述改变，确保修改对于用户而言是透明的，即水平扩展需求。

④ DW/BI系统必须能够及时展示数据：如果原始数据需要超过有效的时间才能转换成可用的信息并展示出来，那么这个系统也没有存在的意义了，即及时性需求。

⑤ DW/BI系统必须成为信息的安全堡垒：如果我们千辛万苦收集的数据很容易就被别人获得了，那么无论可不可以封锁数据，管理员的下辈子都衣食无忧了，即安全需求。

⑥ DW/BI系统必须成为提高决策指定能力的权威和可信的基础：最开始DW/BI系统被称为决策支持系统，这应该可以表示出来他的出现是用来做什么的，基于分析证据所产生的的决策是其最重要的输出，也体现了其的价值与影响，即决策的可信度是其立身的根本。

⑦ DW/BI系统成功的标志是业务群体接收他：最先进的技术架构，最出色的设计文案，最优秀的技术人员，但是如果业务人员不接受这样的系统，那么就难以成功，即贴合业务，更人性化是其立身的主旨。

第⑥和第⑦才是至关重要的，他们是系统立身的根本与目的。对于初涉DW/BI系统的人，最好是信息技术与业务双头并重。

例子：以出版发行工作说明DW/BI管理者的职责

我们先来看看出版发行社主编的工作条目：

• 理解读者
  • 确认读者的人口统计学特征
  • 发现读者希望杂志应该呈现的内容
  • 识别哪些将会续订杂志并购买杂志广告中产品的“最佳”读者
  • 发现潜在的新读者并使他们意识到该杂志的存在
• 确保杂志对读者具有吸引力
  • 杂志刊出的内容要有趣且引人入胜
  • 杂志的布局和渲染要给读者带来最大的快乐
  • 杂志要支持高质量的写作和编辑标准，同时采用一致的展现风格
  • 不断地监控杂志中文章的准确性以及广告商的要求
  • 根据读者和撰稿人网络的新情况适时改变读者信息及保证修改及时可用
• 维持出版
  • 吸引广告商，为杂志带来更多利润
  • 定期出版杂志
  • 保持读者对杂志的信任
  • 让投资人对杂志满意

条目很多，但是有些条目并不是主编的目的，而是有附加性的，例如过分关心杂志的布局与渲染情况，对撰稿人网络情况的关注或者因为一些细枝末节的事情而投入管理层的精力。

如果说将管理层的目标从这三项变成有效的服务读者，杂志成功的可能性肯定会大大增加。你可以仔细浏览上述的条目，假想如果少了哪一条，会造成什么样的后果。

然后我们来看一下一个DW/BI管理员关心的条目：

• 理解业务用户
  • 理解他们的工作责任、目标和任务
  • 确定商业用户在指定哪些决策时需要DW/BI系统的帮助
  • 识别出那些制定出高效率、高影响力的决策的“最佳”用户
  • 发现潜在的新用户，并让他们意识到DW/BI系统能够给他们带来什么能力
• 对业务用户发布高质量、相关的、可访问的信息和分析
  • 选择最健壮的、可操作性的数据放入DW/BI系统中，从组织机构的各种数据源中仔细选择
  • 简化用户接口与应用，采用模板驱动方式，与用户的认知过程轮廓匹配
  • 确保数据精确、可信，使其标识在整个企业具有一致性
  • 不间断的监控数据与分析的准确性
  • 适应用户不断变化的思维方式、需求和业务优先级，及新数据源的可用性
• 维护DW/BI环境
  • 采用DW/BI系统指定的成功的业务决策，验证人员配置及要投入的开支
  • 定期对DE/BI系统进行更新
  • 保持业务用户的信任
  • 保持业务用户、执行赞助商和IT管理层满意度

可以看出来，主编和DW/BI管理员之间由很强的相似性，目的都是为了服务用户，只不过主编采取的手段是靠一些经验和提升自己杂志的品味来适应读者；而管理员是通过为用户提供适合他的服务，为能为出版社带来更多回报的优质用户提供更优质的服务。

这样看来，管理员好像也不是一个纯技术人员，这不就是DW/BI系统的魅力吗？

1.3维度建模简介

首先，维度建模是用来干什么的，他被用来解决两个问题：1、以商业用户可理解的方式公布数据。2、提供高效的查询性能。

维度建模其实不是一个新技术，他最早被用来简化关系型数据库。在数十年的时间里经受了大量案例的考验，人们自然而然的就被这种以单一维度结构满足人们基本需求的技术的简单性所吸引。

注意：维度模型包含的信息和关系数据库的3NF模型（规范化模型）所包含的信息相同，但是维度模型以一种用户可理解的、满足查询性能要求、灵活多变的方式进行了包装。

1.3.1 星型模式与OLAP多维数据库

在关系数据库管理系统中实现的维度模型被称为星型模式，因为其结构类似星型结构。

在多维数据库环境中实现的维度模型通常被称为联机分析处理（OLAP）多维数据库。

如果DW/BI环境包括星型模式或者OLAP多维数据库，则可以说是利用了维度概念。虽然他们的逻辑设计是相同的，但是物理实现上存在差异。

当数据被加载到OLAP多维数据库时，对这些数据的存储和索引，采用了为维度设计的格式和技术。性能聚集或预计算汇总表通常由OLAP多维数据库引擎建立并管理，因此，多维数据库可实现高性能查询。

OLAP多维数据库还提供大量健壮的分析函数，特别是针对大数据集合时，分析函数体现的优势更加明显。

OLAP部署的注意事项

• 构建于关系数据库之上的星型模式是建立OLAP多维数据库的良好物理基础。通常也被认为是备份与恢复的良好的、稳定的基础。
• 传统上，一般认为OLAP多维数据库比RDBMS具有更好的性能，但这一优越性随着计算机硬件(内存，CPU，磁盘)和软件(行式数据库)的发展变得不那么重要。
• 由于供应商多，OLAP多维数据库数据结构比关系数据库管理系统变化更大，因此，最终的部署细节通常与选择的提供商有关。通常在不同OLAP工具之间建立BI应用比不同关系数据库之间建立BI更困难。
• OLAP多维数据库通常比RDBMS提供更多的复杂安全选型。例如，限制访问细节数据，但对汇总数据往往能够提供更开放的接口。
• OLAP多维数据库显然能够提供比RDBMS更加丰富的分析能力，因为后者受SQL的制约。这也可以作为选择OLAP产品的主要依据。
• OLAP多维数据库方便地支持缓慢变化维度类型2变化，但当需要使用其他缓慢变化维度技术重写数据时，多维数据库通常需要被全部或部分地重新处理。
• OLAP多维数据库方便地支持事物和周期性快照事实表，但是由于前一点所描述的重写数据的限制问题而无法处理累计快照事实表。
• OLAP多维数据库通常支持具有层次不确定的复杂的不规则层次结构，例如，组织结构图或物料表等。使用自身查询语法比使用RDBMS的方法更优越。
• OLAP多维数据库与关系数据库比较，能对实现下钻层次的维度关键词结构提供更详细的约束。
• 一些OLAP产品无法确保实现维度角色和别名，因此需要定义不同的物理维度。

1.3.2 用于度量的事实表

事实表用来存储组织机构业务过程事件的性能度量结果，应该尽量将来源于一个业务系统的度量结果存储在一个维度模型中。因为度量的数据量巨大，所以不应该为满足多个组织功能的需要而将这些数据存放在多个地方。应该确保多个组织的用户能在整个企业中使用一致的数据。

事实这一术语表示某个业务度量。例如在扫描商品二维码后，可以获得一些度量，如图。

事实表中的每一行对应一个度量事件。每行中的数据是一个特定级别的细节数据，被称为粒度。比如在销售事实表中用一行来表示每个卖出的产品。

维度建模的核心原则之一是同一事物表中的所有度量行必须具有相同的粒度。

物理世界的每一个度量事件与对应的事实表行具有一对一的关系，这一思想是建模的基本原则。

所有事实表的粒度可划分为3类，事务、周期性快照和累积快照，其中事务粒度最常见。

1.3.3 用于描述环境的维度表

维度表是事实表不可或缺的组成部分。维度表包含业务过程度量事件有关的文本环境。他用来描述与"谁、什么、哪里、何时、如何、为什么"有关的事件。

每个维度表由单一主键定义，用于在与事实表连接操作时实现参照完整性的基础。

维度属性作为查询约束、分组、报表标识的主要来源。对于查询或报表请求来说，属性以词或词组加以区分。例如当用户希望按照品牌来查看销售额时，要查看的品牌必须存在于维度属性中。

同时，维度属性对构建DW/BI系统的可用性和可理解性也起着非常重要的作用。属性应该包含真实使用的词汇而不是令人感到迷惑的缩写；应该尽量减少在维度表中使用代码（不是程序代码）；应该将代码替换为详细的文本属性，这是因为要尽量减少他们对代码转换注释的依赖。

代码应该以清晰的维度属性出现，辅以对用户友好的文本描述符。有时代码中有一些智能含义，例如代码前两个数字表示业务类型，3-4位数字表示业务区域，与其培训业务人员记住他们，倒不如直接将他们分成两个维度属性。

多数情况下，数据仓库的好坏直接取决于维度属性的设置，DW/BI环境的分析能力直接取决于维度属性的质量和深度。强大的维度属性带来的回报是健壮的分片-分块分析能力。

• 为维度属性提供详细的业务术语
• 为属性列填充领域值
• 确保属性值的质量

维度是提供数据的入口点，提供所有DW/BI分析的最终标识和分组。

表明维度表通常以层次关系表示。例如，产品抽象为品牌，然后抽象为类别。在产品维度的每行中，存储的是有关品牌和分类的描述。层次描述信息的存储存在冗余，这样做的目的主要是为了方便使用和提高查询性能。

维度模型不是被某人发明了，而是当设计者需要将可理解和性能作为最重要的目标时，维度模型是设计数据库时必然产生的结果。

1.3.4 星型模式中维度与事实的链接

对维度模型首先需要注意的是其简单性和对称性，简单性是为了数据易于理解和查询，对称性是为了设计出的图表易于客户理解。

粒度最小的数据和原子数据具有最多的维度。

1.4 Kimball的DW/BI架构

Kimball的DW/BI架构由4个不同的，各具特色的组成部分。

1.4.1 操作型源系统

简单来说就是产生数据的系统，比如主要的业务系统，需要数据大量反馈的用户系统等等。这些源系统应当关注处理性能和可用性。

1.4.2 ETL系统

ETL系统包括一个工作区间、实例化的数据结构以及一个过程集合。他是一个位于操作型源系统与DW/BI系统之间的组件，负责数据从一端到另一端的传输。

只要读取了ETL系统，数据就算进入数仓了。

ETL系统的职责：

• 清洗数据（清楚拼写错误，解决领域冲突，处理错误的元素，解析为标准格式）
• 合并来自不同数据源的数据
• 通过增强或转换，清洗和整合，增强数据的利用价值
• 通过元数据诊断系统改善源系统的数据质量
• 构建和加载数据到展现区域的目标维度模型
• 在交付过程中划分维度与事实

规范式的ETL过程不是最终的目标，因为规范化结构难以满足性能和可理解性两个目标。

1.4.3 用于支持商业智能决策的展现区

展现区用于组织、存储数据，支持用户、报表制作者以及其他分析型商业智能的查询。

第一要点：数据应当按照维度展现

这一要点当前已经完成统一

第二要点：必须包含详细的原子数据

为了满足用户无目的，无预期的随心所欲的查询，必须使用原子数据。

展现区的数据可以围绕业务过程度量事件来构建，采用这一方法可以自然的裁剪操作型源数据获取系统。维度模型应该对应物理数据获取事件。也就是说，应当考虑多部门或多功能之间的交叉数据。

第三要点：必须是公共的、一致性的维度建立维度结构。

遵守中线结构是展现区的最后一个要求。如果没有一种可共享的、一致性的维度，维度模型将会成为一种孤立的应用。

处于DW/BI系统的可查询展现区中的数据必须是维度化的、原子的、以业务过程为中心的。坚持使用总线结构的企业数据仓库，数据仓库不应该为某一个部门建立，他是整个公司的。

1.4.4 商业智能应用

BI应用泛指为商业用户提供利用展现区指定分析决策的能力。查询是使用数据提供决策能力的关键。

BI应用应该结合业务指定出合适的模板，来让业务人员访问时可以快捷的使用。

例子：以餐厅为例描述Kimball架构

数据的来源就不加以描述。

1. ETL系统与餐馆后厨

   ETL系统类似于后厨，自成体系，加工获取到的原始食材，有着大量的规划设计来布置工作场景与子区间(红案，白案，冷案，糕点等等)

   厨房的设计包含几个设计目标。首先布置要高效，接着口味一致性，最后还要有菜品的完整性。还有厨房整体的布局，总不能让炒大锅的和大蒸笼在一起。

   ETL系统与厨房类似，ETL系统也要合理的规划，以来承载从数据源获得的大量数据，同时兼具吞吐量，数据质量，完整性，一致性等等要素。

   输入数据在输入时要检查其质量，不断监视环境来确保输出的数据有高度的完整性(输入一只鸡输出俩鸡翅？)，使用业务规则与度量来确保ETL系统中数据的一致性（别在宫保鸡丁里面来两勺酸菜）。虽然这样肯定给ETL小组增加了额外的负担，但是这样会给ETL用户发布一个更好的、保持一致性的产品。

   最后的最后，ETL系统应该离用户远一点，比较没有厨师希望做菜的时候有人把手伸到锅里面尝尝酱汁的味道。ETL系统中的活动不应该展示给BI用户，当数据准备好之后自然会进入DW/BI系统。

2. 展现区与用餐区

   衡量一个餐厅的优劣，有四个指标：

   • 食物（质量，口味，色泽）
   • 装饰风格（独具特色，舒适的用餐环境）
   • 服务（上菜快捷，细致周到的餐厅服务人员，餐食与用餐者所需一致）
   • 就餐的开销

   在评价餐厅优劣时，最重要的是餐厅是否能够提供可口的食物，食物是餐厅主要的可交付产品。同时装饰风格、服务、就餐的开销是影响用餐者是否选择就餐的主要因素。

   DW/BI厨房交付的主要产品是展现区的数据。DW/BI系统提供的菜单是通过元数据、发布报表、参数化分析应用等告诉用户什么数据可用。

   DW/BI用户希望得到一致的、良好的数据质量。

   “装饰风格”应该让用户感到舒服，按照BI使用者的口味来设计。

   而食物，服务，菜品价格都需要“餐厅管理者”来衡量，管理者应该积极主动的检查就餐者对菜品与就餐体验的满意程度，并且进行更正。如果餐厅不被顾客所喜爱，那么投入大量资金，人员的DW/BI系统就会变成废品。

1.5 其他DW/BI系统

1.5.1 独立数据集市架构

数据仓库应当以企业为单位进行构建，以部门为单位进行构建的话，第一是成本过高，第二是企业内数据会停滞，第三是会形成数据孤岛，影响企业发展。

但是这样唯一的好处是快速，如果只是短期内需要一个数据仓库，可以参考这样的搭建方式。

不过，我们反对这样的架构。

1.5.2 辐射状企业信息工厂架构

辐射状企业信息工厂(CIF)由Bill Inmon及业界人士提倡，他和Kimball架构的区别在于，前者希望一个足够规范化的EDW来作为龙骨，后者是寄托于具有一致性维度的企业总线。

数据工厂的痛点在于如何解决不同数据源的强一致性问题，如何保证在杂乱无序的数据源中找到一个多方兼顾同时不太影响性能与成本的解决方案。

采用CIF架构的企业通常允许业务用户根据数据细节程度和数据可用性直接对EDW进行访问。这也造成了数据工厂的核心是部门而不是业务。如果发生了部门职能的更改，那么EDW就要进入重构。

纯CIF架构是不能实现数据仓库的功能的，这也的架构将原子数据固定成难以查询的结构化数据。同时以部门为核心很容易造成数据仓库的割裂。

1.5.3 辐射状架构与Kimball架构

这样的架构很适合从零开始架设数据仓库的公司，只要预算足够且有足够的耐心，这样的架构也可以尝试。

底层对数据的汇总可以使用EDW架构，但是与用户交互最好还是使用Kimball架构。

1.6 关于维度建模的一些神话

1.6.1 神话1：维度模型仅包含汇总数据

这是设计有问题维度模型的根源，由于不可预测业务用户的需求，所以对外提供细节数据的查询访问，这样业务用户才能根据业务问题进行操作。

汇总数据虽然可以提高查询性能，但是不能替代细节数据。

我们只需要在数据仓库中存储有限的历史数据，而这正是数据仓库要做的工作，数据仓库的历史数据的数量必须由业务来驱动。

1.6.2 神话2：维度模型是部门级而不是企业级

维度模型应当按照企业的业务过程来进行组织，而不是部门的职责来划分。

多个部门必然会导致同一数据源的数据被多次分析，这样会产生多个不一致的分析数据库。

1.6.3 神话3：维度模型是不可扩展的

维度模型是非常容易扩展的。市场上存在2万亿行以上的事实表，同时数据库厂商也在积极迎合DW/BI系统，不断增强自身能力来提高其可优化性与可扩展性。

1.6.4 神话4：维度模型仅仅用于预测

维度模型的建立不仅仅关于预定义的报表或分析。

设计应当以度量为中心，考虑BI应用的过滤与表示需求。

构建数据仓库时增加最细粒度的数据可以增加最大级别的灵活性和扩展性。

如果没有这些数据，将会成为破坏维度模型健壮性的元凶。

1.6.5神话5：维度模型不能被集成

如果遵循企业数据仓库总线架构，维度模型多数应该是可以集成的。

1.7使用维度模型的理由

敏捷性考虑
当前，DW/BI行业内非常青睐敏捷开发实践。敏捷方法存在过度简化的风险，这种方法关注构建大小可管理的工作增量，这些工作增量可在合理时间框架下完成，例如，以周来度量，而不是跨越更大的范围（造成的风险也越大），项目及发布物保证在数月或数年内完成，听起来很好，的确如此吗？
多数敏捷方法的核心原则与Kimball最佳实践契合，包括：
•关注发布业务值。这是多年来Kimball广受赞誉的原则之一。
•开发小组与业务相关方之间的值合作。类似敏捷小组，应该与业务构成紧密合作关系。
•强调与业务相关方开展面对面的沟通、反馈、优化。
•快速适应不可避免的需求变化。
•以迭代、增量方式处理开发过程。

小结：
建设数据仓库的核心是建设根据一致性维度的企业总线的维度模型，维度模型必须包含最细粒度的数据来保证健壮性，必须以业务来驱动保证其可用性，应该避免形成部门级别的维度模型来保证其完整性，我们必须保证其敏捷性，避免其形成烟囱式的数据孤岛。