一、什么是数据仓库
数据库 --> OLTP：（on-line transaction processing）翻译为联机事务处理
记录某类业务事件的发生，如购买行为，银行交易行为，当行为产生后，系统会记录是谁在何时何地做了何事，这样的一行（或多行）数据会以增删改的方式在数据库中进行数据的更新处理操作，要求实时性高、稳定性强、确保数据及时更新成功，像公司常见的业务系统如ERP，CRM，OA等系统都属于OLTP
数据仓库 --> OLAP：（On-Line Analytical Processing）翻译为联机分析处理
当数据积累到一定的程度，我们需要对过去发生的事情做一个总结分析时，就需要把过去一段时间内产生的数据拿出来进行统计分析，从中获取我们想要的信息，为公司做决策提供支持，这时候就是在做OLAP了，OLAP支持复杂的分析操作，侧重决策支持，并且提供直观易懂的查询结果
数据仓库（Data Warehouse）是一个面向主题的（Subject Oriented）、集成的（Integrated）、相对稳定的（Non-Volatile）、反映历史变化（Time Variant）的数据集合，用于支持管理决策(Decision Making Support)。
数据仓库是为企业所有决策制定过程，提供所有系统数据支持的战略集合。
通过对数据仓库中数据的分析，可以帮助企业，改进业务流程、控制成本、提高产品质量等。
数仓并不是数据的最终目的地，而是为主句最终的目的地做好准备。包括：清洗，转义，分类，充足，合并，拆分，统计等。
面向主题
操作型数据库的数据组织面向事务处理任务，各个业务系统之间各自分离，而数据仓库中的数据是按照一定的主题域——用户使用数据仓库进行决策时所关心的重点方面，一个主题通常与多个操作型信息系统相关
集成的
面向事务处理的操作型数据库通常与某些特定的应用相关，数据库之间相互独立，并且往往是异构的。而数据仓库中的数据是在对原有分散的数据库数据抽取、清理的基础上经过系统加工、汇总和整理得到的，必须消除源数据中的不一致性，以保证数据仓库内的信息是关于整个企业的一致的全局信息。
相对稳定的
操作型数据库中的数据通常实时更新，数据根据需要及时发生变化。数据仓库的数据主要供查询，数据进入数据仓库以后，一般将被长期保留，也就是数据仓库中一般有大量的查询操作，但修改和删除操作很少，通常只需要定期的加载、刷新。
反映历史变化
操作型数据库主要关心当前某一个时间段内的数据，而数据仓库中的数据通常包含历史信息，系统记录了企业从过去某一时点（如开始应用数据仓库的时点）到目前的各个阶段的信息，通过这些信息，可以对企业的发展历程和未来趋势做出定量分析和预测。
二、数据仓库架构
其实数据仓库很早之前就有了很多传统的数仓技术，例如基于Teradata的数据仓库，只不过在大数据背景下我们开始抛弃传统构建数仓的技术，转而选择了更能满足当前时代需求的大数据技术，当然大数据技术并没有完整的、彻底的取代传统的技术实现，我们依然可以在很多地方看见它们的身影
数仓问题
随着数据量暴增、数据源多样化、服务对象变化，传统经典数仓的不足凸显：
传统数据分析更注重对高密度、高价值的结构化数据的业务数据分析，对非结构化、半结构化数据的处理，如图像、文本、音频的存储和分析非常薄弱。
由于传统数据仓库采用结构化存储，当数据从其他系统导入数据仓库时，我们通常会引入ETL过程。ETL与具体的业务有很强的的绑定性，通常需要一个专门的人或者团队与业务部门进行连接，并决定如何进行数据清洗、转换及加载。
随着异构数据源的增加，如视频、文本、图片，要分析数据内容并进入数据仓库，就需要非常复杂的ETL，导致ETL过于庞大且臃肿
数据库范式等约束规则重点解决数据冗余问题，以确保数据的一致性。原则上，数据仓库原始数据是只读的，所以这些约束条件将成为影响性能的因素。
数据量过大时性能称为瓶颈。
离线数仓
Hadoop生态的出现从几个维度解决了传统数仓在数据分析中遇到的瓶颈：
分布式计算。多节点并行计算，强调数据的局部性，并尽量减少节点间的数据传输。
分布式存储。将一份大文件分成若干份，没分独立放在一个节点上。涉及到文件拷贝、碎片化、管理等操作。
检索与存储结合。早期大数据系统中，存储和计算比较单一。大数据框架下的存储不仅存储数据内容自身，还增加了很多元数据。
存算分离。数据库系统出于性能的考虑，主要采用“计算和存储紧耦合”的架构。而在分析大量级的数据时，往往结果间会相互影响，在这种情况下，单个计算引擎无法完全控制数据布局和文件系统。因此，需要存算分离。
离线数仓缺点
分布式存储强调数据的只读性，如HDFS的存储方式不支持更新、写操作不支持并行等。在应用上有一定局限性。
存储的耦合，副本机制造成了扩展和容灾发生时的成本压力和运维压力。
尚缺乏完整的cube工具。虽然目前有部分开源或者商业化的产品，担任存在局限性。如cube缺乏灵活性和稳定性，对于业务支持的灵活性不足。对于报表数量多或复杂的场景，就需要过多的人工定制。
离线处理为主，缺乏实时性。
Lambda架构
在离线大数据架构基础上增加一个加速层（增加一条实时计算链路，并对数据源进行流失改造，实时计算订阅消息完成计算，推送到下游），使用流处理技术直接完成那些实时性要求高的指标计算，然后和离线计算整合从而给用户一个完整的实时计算结果。
Lambda架构存在的问题：
同样的需求要开发两套一样的代码，开发成本、维护成本极高。
同样资源计算两次，资源占用多。
实时链路和离线链路计算结果容易让人误解，昨天和今天看到的数据不一致。
下游需整合实时和离线处理结果。
kappa架构:
使用不可改变的数据流作为主要的记录源，而不使用数据库或文件的时间点来表示。
Kappa架构将数据作为事件写入到持久化的流中，对代码的修改只需要重放过去的事件即可。
kappa架构解决了lambda架构中较冗余的部分，支持数据重放，架构简洁。但实现较为困难。
混合架构：
在实际应用上并不是完全规范的lambda或kappa架构，可以将两者混合，大部分实时指标采用kappa架构完成计算，少量关键指标（金额等）使用lambda架构用批处理重新计算，增加一次校对过程。
数仓整体架构
三、数仓建模
数仓分层
清晰数据结构、数据血缘追踪、减少重复开发、把复杂问题简单化、屏蔽原始数据的异常
ODS层
保持数据原貌不做任何修改，起到备份数据的作用。
数据采用压缩，减少磁盘存储空间
创建分区表，防止后续的全表扫描
DWD层
DWD层需构建维度模型，一般采用星型模型，呈现的状态一般为星座模型。
DWS层
DWS层统计各个主题对象的当天行为，构建主题对象的全量宽表。DWS层的宽表字段，是站在不同维度的视角去看事实表，重点关注事实表的度量值，通过与之关联的事实表，获得不同的事实表的度量值。
ADS层
分别对，如：设备主题、会员主题、商品主题和营销主题进行指标分析，其中营销主题是用户主题和商品主题的跨主题分析案例
维度建模
维度建模一般步骤：选择业务过程→声明粒度→确认维度→确认事实
（1）选择业务过程
在业务系统中，如果业务表过多，挑选我们感兴趣的业务线，比如下单业务，支付业务，退款业务，物流业务，一条业务线对应一张事实表。
（2）声明粒度
数据粒度指数据仓库的数据中保存数据的细化程度或综合程度的级别。
声明粒度意味着精确定义事实表中的一行数据表示什么，应该尽可能选择最小粒度，以此来应各种各样的需求。
（3）确定维度
维度的主要作用是描述业务是事实，主要表示的是“谁，何处，何时”等信息。例如：时间维度、用户维度、地区维度等常见维度
。
（4）确定事实
此处的“事实”一词，指的是业务中的度量值，例如订单金额、下单次数等。
在DWD层，以业务过程为建模驱动，基于每个具体业务过程的特点，构建最细粒度的明细层事实表。事实表可做适当的宽表化处理。
