数据仓库工具箱1-1

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

信息用作两个目的：操作型记录的保存&分析型决策的制定

操作型系统

（1）要求：确保组织正常运转

（2）优化：更快地处理事务

（3）规律：一次处理一个事务记录，标准化流程执行，不必维护历史数据，只需修改数据反映最新状态

DW/BI系统

（1）要求：帮助组织分析运作情况

（2）优化：高性能地完成用户的查询

（3）规律：一次搜索成千上万条事务，将查询结果放入一个查询集合中，必须保留历史数据，用于分阶段统计及分析

DW/BI不是对操作型系统数据的直接拷贝，需要通过设计来满足更灵活的分析需求！

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

DW/BI系统的基本需求：

1、更方便的存取信息：符合业务用户的思维过程和词汇，对应用的访问要简单、快捷

2、一致性展现：精心组织和清洗不同数据源的数据，过程中，一致性建模，保证同名同义

3、适应变化：方便地处理用户需求、业务环节、数据技术等方面的变化，不因变化影响已经存在的数据和应用；即使影响，要通过适当的方式描述变化，使变化对用户透明

4、及时展现信息：前置清洗、验证数据，设计尽量满足长期诉求的指标，减少用户在使用数据时，大量自行加工的时间

5、信息安全：权限管理

6、决策支持：提高决策制定能力，数据权威、可信

7、被业务群体接受：更优的组合产品或平台，以“简单快捷”为目标，吸引更多用户接受

技能：数据库管理技能 及 商业分析师技能

1.3 维度建模简介

维度建模是展现分析数据的首选技术，why？

1、用户可理解

2、高效的查询性能

3、灵活多变

4、保持和规范化模型包含相同的信息

关键点：简单性！

简单模型->实现设计->避免业务扩张、变化后，模型过度复杂->查询性能低下->商业用户反感

即使维度模型是基于关系数据库产出的，但不需要必须满足3NF

什么是规范化的3NF？ 将数据划分为多个不同的实体，每个实体构成一个关系表，为满足3NF会有蜘蛛网状图的趋势，变成上百个规范化的表（3NF的主要目的是消除冗余），主要应用于操作型过程中。

不要混淆ER/ERD（实体关系图）与3NF ：

ER/ERD表示表间的交互关系，既可描述3NF 模型，也可描述维度模型（包含可连接的关系表即可），区别体现在规范化程度。

3NF不应该被称为ER模型，应该是规范化模型，且它难以满足对数据的高性能检索需求。

如何解决模式过分复杂的问题？ 维度建模！

维度建模核心原则：关注细节数据、根据业务过程而不是部门构建系统、利用一致性维度实现一致性和集成。

星型模型和OLAP是相同的逻辑设计，内容也相同，利用了维度概念，但物理实现上存在差异。

OLAP是通过性能聚集或预计算做汇总，并管理，以支持上卷和下钻操作，以获得良好的分析性能，甚至包含大量健壮的分析函数，比SQL函数更好，量级越大，优势越多。

星型模型是设计模式。

合体：将详细的、原子的信息加载到星型模式中，并将OLAP多维数据库移植到星型模式上。OLAP多维数据库通常是部署维度DW/BI系统的最后步骤，例： kylin/doris

基于关系型的星型模式！

关于OLAP多维数据库值得关注的几个点：

1、OLAP多维数据库方便地支持事务和周期性快照事实表，但由于重写数据的限制问题而无法处理累计快照事实表。

2、OLAP多维数据库支持具有层次不确定的复杂的不规则层次结构，并相较于关系数据库，能对实现下钻层次的维度关键词结构提供更详细的约束。

事实表：

尽量将来源于同一个业务过程的底层度量结果存储于一个维度模型中，确保多个组织访问同样的集中数据，保证一致性。

每行中的数据是一个特定级别的细节数据，称为粒度。

维度建模的核心原则之一：同一事实表中的所有 度量行必须具有相同的粒度。确保不会出现重复计算度量的问题。

事实表分为三种：事务、周期性快照、累积快照。

事实表一般具有两个或更多个外键，与维度表的主键关联。

维度表：

与业务过程度量事件有关的文本环境，用于描述与“谁、什么、哪里、何时、如何、为什么”有关的事件

维度表通常包含多列（多个属性），有50~100个属性的维度表并不稀奇。

包含较少的行，但是会存在大量文本列。

每个维度表由单一主键定义，用于在于事实表连接操作时实现参照完整性（如果事实表中的外键存在空值，则违反了参照完整性，可通过代理键代替空值，实现关联）。

维度属性可作为查询约束、分组、报表标识的主要来源。

DW/BI环境的分析能力（健壮的分片-分块分析能力）直接取决于维度属性的质量和深度。

层次描述信息的存储存在冗余，这样做的目的是为了方便使用和提高查询性能。

规范化的维度表设计是雪花模型，但是没有必要，因为维度表相对事实表来说，要小得多，权衡下来，更需要通过冗余来实现简单性和可访问性。

如何理解适于变化？

对维度模型来说，可以将全新维度增加到模式中，只要该维度的单一值被定义到已经存在的事实表行中。也可以将新的事实增加到事实表中，前提是其细节级别与当前事实表保持一致。

1.4 Kimball的DW/BI架构

四个组成部分：

1、操作型源系统：处于数仓之外，一条一条查询，事务流

2、ETL系统：Extract（从操作型系统导入数据到数仓，认知并初步理解数据）、Transformation（多种转换操作，如数据清洗、合并不同数据源的数据，增加数据的利用价值。本阶段还可以建立诊断元数据，逐步建立业务过程再工程以改进源系统的数据质量）、Load（存储）；实际构建和加载数据到展现区域的目标维度模型中。将维度模型中的维度表和事实表更新、索引、适当聚集。并确保良好质量，供业务用户使用。尽量避免不规范到规范化到不规范，否则会获取、转换、加载两次，一次到规范化数据库，一次到维度模型。需要开发人员更多工时实现周期性加载或更新数据，也需要更多存储空间保留多个拷贝。所以，过度关注构建规范化结构，会导致DW/BI工作的失败。尽管保持一致性是必须的，但不是仅通过规范化结构才能实现，会有成本更低的方法。

规范化结构难以同时满足可理解性和性能这两个目标！

3、数据展现：上面两层对用户屏蔽，这一层开始面向出口。数据要以维度模型来展现，要么采用星型模式，要么采用OLAP多维数据库。 必须包含详细的原子数据，以满足用户无法预期的、随意的查询（且需要非规范化，易于理解和性能好）。也可以按需存在一些聚集数据。必须使用公共的、一致性的维度建立维度结构。将总线结构作为基本框架，可采用敏捷的、分散的、范围合适的、迭代的方式建立企业数据仓库。

4、商业智能应用：支持报表固化或者少数业务的自助使用

1.5 其他DW/BI架构

无论选择哪种架构，都会涉及维度建模。

独立数据集市架构：部门为单位，不考虑企业级别信息共享和集成。如果对相同的数据源及核心业务过程感兴趣，不可以跨部门依赖，只能自行生产，会导致指标含义和取值的不一致问题。这种方式在大型组织很常见，因为不需要跨组织控制和协调，短期来看，有利于以较低成本实现快速开发。长期来看，除质量问题外，还会由于冗余存储造成资源浪费。

Inmon企业信息工厂（CIF）：将操作型数据源中获取的数据，通过ETL系统进行满足3范式的规范化处理、且保留原子数据。规范化的EDW是CIF中强制性的构件。相比于独立集市架构，Kimball与Inmon都强调数据协调和集成，但CIF是利用规范化的EDWl来实现。而Kimball是通过具有一致性维度的企业总线架构来实现。

Inmon规范化不能解决集成问题（数据多源不一致，规范了也没有效果），必须通过Kimball矩阵来解决不一致性实现集成（但不保证规范化）

CIF允许业务直接访问EDW仓库，只能以部门为中心（不是围绕业务过程组织），包含聚集数据（非原子级），若发生变化，将分析数据库与EDW原子数据联系起来将非常困难，极度不灵活。纯CIF架构最极端的形式是不能实现数据仓库的功能，因为将原子数据固定为了难以查询的规范化结构。

混合辐射状架构与Kimball架构： 将kimball与架构与Inmon CFI架构嫁接。利用了CIF的EDW，但是与分析和报表用户隔离，仅作为Kimball风格的展现区的数据来源。整体呈现维度的、原子的（辅以聚集数据）、以过程为中心的，与企业数据仓库总线架构保持一致。

Q：规范化的好处？

1.6 维度建模神话

关键要点：

1、要保留最细粒度数据，汇总数据只是在针对公共查询时能够比细粒度数据提供更好的性能，但它不能取代细节数据。

2、维度建模围绕业务过程组织，而非按部门划分，对于相同业务过程或数据源，最好只保留一份，并以共享的方式跨部门应用。

3、维度模型非常易于扩展，记录数在事实表里以行的形式自动递增，新增维度在维表里以列的方式通过设计及更新表结构来迭代。

4、面对不断变化的分析，不要固化一些关键报表，要通过业务过程度量来设计，以支持更大的灵活性。细粒度可以确保更好的灵活性及可扩展性。

5、维度模型是可以基于总线结构进行集成的。一致性维度是集中的、持久的主数据。跨维度模型的重用能实现数据集成和语义一致性。数据集成依赖于标准标识、值和定义。 不能保证一致性维度和总线结构，带来的问题是烟囱式建设。