Data Warehouse
Data Warehouse （DW），数据仓库的目的是构建面向分析的集成化数据环境，为企业提供决策支持（Decision Support）。它出于分析性报告和决策支持的目的而创建。数据仓库本身并不“生产”任何数据，同时自身也不需要“消费”任何的数据，数据来源于外部，并且开放给外部应用，这也是为什么叫“仓库”，而不叫“工厂”的原因。
业务痛点
- 无法应对频繁临时需求
- 数据资产模糊
- 数据质量低
- 重复建设
- 代码耦合性高
- 问题难定位，周期长
特点
面向主题（Subject Oriented）
传统数据库中，最大的特点是面向应用进行数据的组织，各个业务系统可能是相互分离的。而数据仓库则是面向主题的。主题是一个抽象的概念，是较高层次上企业信息系统中的数据综合、归类并进行分析利用的抽象。在逻辑意义上，它是对应企业中某一宏观分析领域所涉及的分析对象。
集成性（Integrate）
通过对分散、独立、异构的数据库数据进行抽取、清理、转换和汇总便得到了数据仓库的数据，这样保证了数据仓库内的数据关于整个企业的一致性。
非易失性（Non-Volatile）/不可更新性
数据仓库的数据反映的是一段相当长的时间内历史数据的内容，是不同时点的数据库快照的集合，以及基于这些快照进行统计、综合和重组的导出数据。数据非易失性主要是针对应用而言的，数据仓库的用户对数据的操作大多是数据查询或比较复杂的挖掘，一旦数据进入数据仓库以后，一般情况下被较长时间保留。
数据仓库中一般有大量的查询操作，但修改和删除操作很少。因此，数据经加工和集成进入数据仓库后是极少更新的，通常只需要定期的加载和更新。
时变性（Time Variant）
数据仓库包含各种粒度的历史数据。数据仓库中的数据可能与某个特定日期、星期、月份、季度或者年份有关。数据仓库的目的是通过分析企业过去一段时间业务的经营状况，挖掘其中隐藏的模式。
虽然数据仓库的用户不能修改数据，但并不是说数据仓库的数据是永远不变的。分析的结果只能反映过去的情况，当业务变化后，挖掘出的模式会失去时效性。因此数据仓库的数据需要更新，以适应决策的需要。从这个角度讲，数据仓库建设是一个项目，更是一个过程。数据仓库的数据随时间的变化表现在以下几个方面：
- 数据仓库的数据时限一般要远远长于操作型数据的数据时限。
- 操作型系统存储的是当前数据，而数据仓库中的数据是历史数据。
- 数据仓库中的数据是按照时间顺序追加的，它们都带有时间属性。
与数据库的区别
联机事务处理（OLTP）
（On-Line Transaction Processing），也可以称面向交易的处理系统，它是针对具体业务在数据库联机的日常操作，通常对少数记录进行查询、修改。用户较为关心操作的响应时间、数据的安全性、完整性和并发的支持用户数等问题。传统的数据库系统作为数据管理的主要手段，主要用于操作型处理。
联机分析处理（OLAP）
（On-Line Analytical Processing）一般针对某些主题历史数据进行分析，支持管理决策。
对比
数据库设计是尽量避免冗余，一般针对某一业务应用进行设计，符合业务应用，但是不符合分析。数据仓库在设计是有意引入冗余，依照分析需求，分析维度、分析指标进行设计。
数据库为捕获数据而设计，数据仓库为分析数据而设计。
数据仓库，是在数据库已经大量存在的情况下，为了进一步挖掘数据资源、为了决策需要而产生的，它决不是所谓的“大型数据库”。
架构
按照数据流入流出的过程，数据仓库架构可分为：
- 源数据
- 数据仓库
- 数据应用
源数据
此层数据无任何更改，直接沿用外围系统数据结构和数据，不对外开放；为临时存储层，是接口数据的临时存储区域，为后一步的数据处理做准备。
数据仓库
也称为细节层，DW 层的数据应该是一致的、准确的、干净的数据，即对源系统数据进行了清洗（去除了杂质）后的数据。
数据应用
前端应用直接读取的数据源；根据报表、专题分析需求而计算生成的数据。
ETL 过程
数据仓库从各数据源获取数据及在数据仓库内的数据转换和流动都可以认为是 ETL 的过程，ETL 是数据仓库的流水线，也可以认为是数据仓库的血液，它维系着数据仓库中数据的新陈代谢，而数据仓库日常的管理和维护工作的大部分精力就是保持 ETL 的正常和稳定。
意义
用空间换时间，通过大量的预处理来提升应用系统的用户体验（效率），因此数据仓库会存在大量冗余的数据；不分层的话，如果源业务系统的业务规则发生变化将会影响整个数据清洗过程，工作量巨大。
通过数据分层管理可以简化数据清洗的过程，因为把原来一步的工作分到了多个步骤去完成，相当于把一个复杂的工作拆成了多个简单的工作，把一个大的黑盒变成了一个白盒，每一层的处理逻辑都相对简单和容易理解，这样我们比较容易保证每一个步骤的正确性，当数据发生错误的时候，往往我们只需要局部调整某个步骤即可。
建模方法
范式建模 （Third Normal Form，3NF）
- 所有表中的数据都为原子数据，不可再分
- 所有表中的所有字段都必须依赖主关键字
- 所有表中的非主关键字段之间不能函数依赖关系
第一范式（1NF）
在关系模式 R 中的每一个具体关系 r 中，必须要有主键,并且每个属性值都是不可再分的最小数据单位，则称 R 是第一范式的关系。
第二范式（2NF）
如果关系模式 R 中的所有非主属性都完全依赖于主关键字，则称关系 R 是属于第二范式的。
第三范式（3NF）
关系模式 R 中的非主关键字不能依赖于其他非主关键字。即非主关键字之间不能有函数（传递）依赖关系。则称关系 R 是属于第三范式的。
维度建模
维度建模是一种将数据结构化的逻辑设计方法，它将客观世界划分为度量和上下文。度量是常常是以数值形式出现，事实周围有上下文包围着，这种上下文被直观地分成独立的逻辑块，称之为维度。
事实表
发生在现实世界中的操作型事件，其所产生的可度量数值，存储在事实表中。事实表表示对分析主题的度量。
事实表的特征：表里没有存放实际的内容，他是一堆主键的集合，这些 ID 分别能对应到维度表中的一条记录。事实表包含了与各维度表相关联的外键，可与维度表关联。事实表的度量通常是数值类型，且记录数会不断增加，表数据规模迅速增长。它一般是行多列少，占了数据仓库的90%的空间。
事务事实表
它是面向事务的，其粒度是每一行对应一个事务，它是最细粒度的事实表。
周期快照事实表
它是按照良好的时间周期间隔(每天，每月)来捕捉业务活动的执行情况，一旦装入事实表就不会再去更新，它是事务事实表的补充，而非替代品。
累积快照事实表
它用于描述业务过程中某个不确定时间跨度里的活动，它随着业务活动的发生会不断的更新。
明细表（宽表）
宽表从字面意义上讲就是字段比较多的数据库表。通常是指业务主题相关的指标、维度、属性关联在一起的一张数据库表。由于把不同的内容都放在同一张表存储，宽表已经不符合三范式的模型设计规范，随之带来的主要坏处就是数据的大量冗余，与之相对应的好处就是查询性能的提高与便捷。
这种宽表的设计广泛应用于数据挖掘模型训练前的数据准备，通过把相关字段放在同一张表中，可以大大提高数据挖掘模型训练过程中迭代计算时的效率问题。
维度表
每个维度表都包含单一的主键列。维度表的主键可以作为与之关联的任何事实表的外键，当然，维度表行的描述环境应与事实表行完全对应。维度表通常比较宽，是扁平型非规范表，包含大量的低粒度的文本属性。
维度表示你要对数据进行分析时所用的一个量，比如你要分析产品销售情况， 你可以选择按类别来进行分析，或按区域来分析。每个类别就构成一个维度。
它是进入事实表的入口，丰富的维度属性给出了对事实表的分析切割能力，它一般是行少列多。
事实表 & 维度表
用于度量的事实表，事实表一般会有两个或者多个外健与维度表的主键进行关联。事实表的主键一般是组合健，表达多对多的关系。
用于描述环境的维度表，单一主键，维度表的属性是所有查询约束和报表标示的来源。维度提供数据的入口点，提供所有 DW/BI 分析的最终标识和分组。
事实表的设计是以能够正确记录历史信息为准则，维度表的设计是以能够以合适的角度来聚合主题内容为准则。
如果属性值是离散的，用于过滤和标记的，就放到维度表里，如果是属性值是连续取值，用于计算的，就放到事实表中。
星型模型
星型模式是以事实表为中心，所有的维度表直接连接在事实表上，像星星一样。 星形模式的维度建模由一个事实表和一组维表成。
雪花模型
当有一个或多个维表没有直接连接到事实表上，而是通过其他维表连接到事实表上时，其图解就像多个雪花连接在一起，故称雪花模型。雪花模型是对星型模型的扩展。它对星型模型的维表进一步层次化，原有的各维表可能被扩展为小的事实表，形成一些局部的 “层次 “ 区域，这些被分解的表都连接到主维度表而不是事实表。
虽然这种模型相比星型更规范一些，但是由于这种模型不太容易理解，维护成本比较高，而且性能方面需要关联多层维表，性能也比星型模型要低，所以一般不是很常用。
星座模式
星座模式由星型模式延伸而来，星型模式基于一张事实表，而星座模式基于多张事实表，而且共享维度信息。 在很多时候维度空间内的事实表不止一个，而一个维表也可能被多个事实表用到。在业务发展后期，绝大部分维度建模都采用的是星座模式。
星型模型 & 雪花模型
查询性能
OLTP-DW环节，由于雪花型要做多个表联接，性能会低于星型架构；
DW-OLAP环节，由于雪花型架构更有利于度量值的聚合，因此性能要高于星型架构。
模型复杂度
星型架构更简单方便处理。
层次结构
雪花型架构更加贴近OLTP系统的结构，比较符合业务逻辑，层次比较清晰。
存储角度
雪花型架构具有关系数据模型的所有优点，不会产生冗余数据。
星型架构会产生数据冗余。
总结
一般建议使用星型模型。因为在实际项目中，往往最关注的是查询性能问题，至于磁盘空间一般都不是问题。
在维度表数据量极大，需要节省存储空间的情况下，或者是业务逻辑比较复杂、必须要体现清晰的层次概念情况下，可以使用雪花型模型。
建模过程
1. 选择业务过程
维度建模是紧贴业务的，所以必须以业务为根基进行建模，根据运营提供的需求及日后的易扩展性等进行选择业务。
2. 声明粒度
在同一事实表中，必须具有相同的粒度（存在一对一的关系），同一事实表中不要混用多种不同的粒度，不同的粒度数据建立不同的事实表。并且从给定的业务过程获取数据时，强烈建议从关注原子粒度开始设计，也就是从最细粒度开始，因为原子粒度能够承受无法预期的用户查询。但是上卷汇总粒度对查询性能的提升很重要的，所以对于有明确需求的数据，我们建立针对需求的上卷汇总粒度，对需求不明朗的数据我们建立原子粒度。
3. 确认维度
如果该列是对具体值的描述，是一个文本或常量，某一约束和行标识的参与者，此时该属性往往是维度属性。牢牢掌握事实表的粒度，就能将所有可能存在的维度区分开，并且要确保维度表中不能出现重复数据，应使维度主键唯一。
4. 确认事实
事实表是用来度量的，基本上都以数量值表示，事实表中的每行对应一个度量，每行中的数据是一个特定级别的细节数据，称为粒度。维度建模的核心原则之一是同一事实表中的所有度量必须具有相同的粒度。这样能确保不会出现重复计算度量的问题。有时候往往不能确定该列数据是事实属性还是维度属性。记住最实用的事实就是数值类型和可加类事实。所以可以通过分析该列是否是一种包含多个值并作为计算的参与者的度量，这种情况下该列往往是事实。
元数据管理
元数据
元数据（Meta Date），主要记录数据仓库中模型的定义、各层级间的映射关系、监控数据仓库的数据状态及 ETL 的任务运行状态。一般会通过元数据资料库（Metadata Repository）来统一地存储和管理元数据，其主要目的是使数据仓库的设计、部署、操作和管理能达成协同和一致。元数据是数据仓库管理系统的重要组成部分，元数据管理是企业级数据仓库中的关键组件，贯穿数据仓库构建的整个过程，直接影响着数据仓库的构建、使用和维护。
ETL 中的应用
构建数据仓库的主要步骤之一是 ETL。这时元数据将发挥重要的作用，它定义了源数据系统到数据仓库的映射、数据转换的规则、数据仓库的逻辑结构、数据更新的规则、数据导入历史记录以及装载周期等相关内容。数据抽取和转换的专家以及数据仓库管理员正是通过元数据高效地构建数据仓库。
技术元数据
技术元数据为开发和管理数据仓库的 IT 人员使用，它描述了与数据仓库开发、管理和维护相关的数据，包括数据源信息、数据转换描述、数据仓库模型、数据清洗与更新规则、数据映射和访问权限等。
业务元数据
业务元数据为管理层和业务分析人员服务，从业务角度描述数据，包括商务术语、数据仓库中有什么数据、数据的位置和数据的可用性等，帮助业务人员更好地理解数据仓库中哪些数据是可用的以及如何使用。
总结
元数据不仅定义了数据仓库中数据的模式、来源、抽取和转换规则等，而且是整个数据仓库系统运行的基础，元数据把数据仓库系统中各个松散的组件联系起来，组成了一个有机的整体。
分层
ODS (Operation Data Store) 操作数据层
数据仓库准备区，主要将各个业务数据导入到大数据平台，作为业务数据的快照存储。为 DWD 层提供基础原始数据，可减少对业务系统的影响。
建模方式及原则：
- 从业务系统增量抽取
- 保留时间由业务需求决定
- 可分表进行周期存储
- 数据不做清洗转换与业务系统数据模型保持一致
- 按主题逻辑划分
DWD (Data Warehouse Detail) 数据明细层
对 ODS 层数据进行清洗、维度退化、脱敏等，并基于维度建模，设计事实表和维度表，这个时候可以设计面向分析的大宽表。
DWS(Data Warehouse Summary) 公共汇总层
基于 DWD 层上的基础数据，整合汇总成分析某一个主题域的服务数据，一般是也是面向分析宽表或者是面向某个注意的汇总表。DWS层应覆盖80%的应用场景，这样我们才能快速响应数据需求
为DW层提供细粒度数据，DWS按各个维度ID进行粗粒度汇总聚合，如按交易来源，交易类型进行汇合 。
建模方式及原则：
- 聚合、汇总增加派生事实；
- 关联其它主题的事实表，DW层可能会跨主题域；
- 保持高粒度汇总数据；
- 数据模型可能采用反范式设计，合并信息等。
ADS(Application Data Service) 应用数据层
ADS 层面向用户应用和分析需求，包括前端报表、分析图表、KPI、仪表盘、OLAP、专题等分析，面向最终结果用户；适合作OLAP、报表模型；根据DW层经过聚合汇总统计后的粗粒度事实表。
建模方式及原则：
- 保持数据量小；
- 维度建模，星形模型；
- 各位维度代理键+度量；
- 增加数据业务日期字段，支持数据重跑；
- 不分表存储
DM （Data Market) 数据集市层
主要是提供数据产品和数据分析的数据，一般会存放在ES、Mysql、也可能直接存储在 hive 中或者 druid 供数据分析和数据挖掘使用。主要解决部门用户报表和分析需求而建立数据库，数据集市就代表数据仓库的主题域。
DM 是面向单个主题的，所以它不会从全局考虑进行建设，只专注于自己的数据、往往是某个业务线，例如流量主题、社交主题、电商主题等等。
DIM，维度层
维表层，所以其实维度层就是大量维表构成的，为了统一管理这些维度表，所以我们就建设维度层，维度表本身也有很多类型，例如稳定维度维表，渐变维度维表。
建模方式及原则：
- 尽可能生成丰富的维度属性。
- 尽可能多的给出包含一些富有意义的文字性描述。
- 区分数值型属性和事实。
- 尽量沉淀出通用的维度属性。
数据一致性
CAP 理论
Consistency，Availability和Partition Tolerance，理论认为数据一致性（C）、系统可用性（A）和网络分区容忍性（P），在系统中的任何时刻三个性质中只能同时保证两个性质成立，而网络常常又是不可靠的。
数据一致性模型
一些分布式系统通过复制数据来提高系统的可靠性和容错性，并且将数据的不同的副本存放在不同的机器。
由于维护数据副本的一致性代价高，因此许多系统采用弱一致性来提高性能。
强一致性： 要求无论更新操作实在哪一个副本执行，之后所有的读操作都要能获得最新的数据。
弱一致性：用户读到某一操作对系统特定数据的更新需要一段时间，我们称这段时间为“不一致性窗口”。
最终一致性：是弱一致性的一种特例，保证用户最终能够读取到某操作对系统特定数据的更新。
维度退化
不可能将所有与业务相关的维度分类到一个紧凑的表集合中。类似这样的情况，将一个或者多个维度存储到事实表中是合适的选择。采用这种方法，存储事实表中的维度列被称为退化维度，退化维度的过程称为维度退化。
当一个维度没有数据仓库需要的任何数据的时候就可以退化此维度，需要把退化的相关数据迁移到事实表中，然后删除退化的维度。与其他存储在维度表中的维度一样，退化维度也可以进行事实表的过滤查询，实现聚合操作等。
优点
- 减少事实表和维度表的关联
- 减少维度的数量， 简化维度数据仓库模式。
- ETL 过程简化。
- 更好的查询性能，可以让
group by等操作变得更快。