1. 数据仓库
数据仓库（Data Warehouse，简称数仓、DW）是一个用于存储、分析、报告的数据系统。数据仓库的目的是构建面向分析的集成化数据环境，为企业提供决策支持（Decision Support）。
数据仓库本身并不“生产”任何数据，其数据来源于不同外部系统；同时数据仓库自身也不需要“消费”任何的数据，其结果开放给各个外部应用使用，这也是为什么叫“仓库”，而不叫“工厂”的原因。
2. 数仓从何而来？
先下结论：为了分析数据而来，分析结果给企业决策提供支撑。
信息总是用作两个目的：操作型记录的保存和分析型决策的制定。数据仓库是信息技术长期发展的产物。
下面以中国人寿保险公司（chinalife）发展为例，阐述数据仓库为何而来？
2.1 操作型记录的保存
中国人寿保险（集团）公司下辖多条业务线，包括：人寿险、财险、车险，养老险等。各业务线的业务正常运营需要记录维护包括客户、保单、收付费、核保、理赔等信息。
联机事务处理系统（OLTP）正好可以满足上述业务需求开展, 其主要任务是执行联机事务和查询处理。其基本特征是前台接收的用户数据可以立即传送到后台进行处理，并在很短的时间内给出处理结果。关系型数据库是 OLTP 典型应用，比如：Oracle、Mysql、SQL Server 等。
2.2 分析型决策的制定
随着集团业务的持续运营，业务数据将会越来越多。由此也产生出许多运营相关的困惑：
- 能够确定哪些险种正在恶化或已成为不良险种？
- 能够用有效的方式制定新增和续保的政策吗？
- 理赔过程有欺诈的可能吗？
- 现在得到的报表是否只是某条业务线的？集团整体层面数据如何？
为了能够正确认识这些问题，制定相关的解决措施，瞎拍桌子是肯定不行的。最稳妥办法就是：基于业务数据开展数据分析，基于分析的结果给决策提供支撑。也就是所谓的数据驱动决策的制定。
2.3 OLTP 环境开展分析可行吗？
结论：可以，但是没必要。
OLTP 的核心是面向业务，支持业务，支持事务。所有的业务操作可以分为读、写两种操作，一般来说读的压力明显大于写的压力。如果在 OLTP 环境直接开展各种分析，有以下问题需要考虑：
- 数据分析也是对数据进行读取操作，会让读取压力倍增；
- OLTP 仅存储数周或数月的数据；
- 数据分散在不同系统不同表中，字段类型属性不统一；
当分析所涉及数据规模较小的时候，在业务低峰期时可以在 OLTP 系统上开展直接分析。但是为了更好的进行各种规模的数据分析，同时也不影响 OLTP 系统运行，此时需要构建一个集成统一的数据分析平台。
该平台的目的很简单：面向分析，支持分析，并且和 OLTP 系统解耦合。
基于这种需求，数据仓库的雏形开始在企业中出现了。
2.4 数据仓库的构建
如数仓定义所说，数仓是一个用于存储、分析、报告的数据系统，目的是构建面向分析的集成化数据环境。我们把这种面向分析、支持分析的系统称之为 OLAP（联机分析处理）系统。数据仓库是 OLAP 的一种。
中国人寿保险公司就可以基于分析决策需求，构建数仓平台。
3. 数仓主要特征
3.1 面向主题性
数据库中，最大的特点是面向应用进行数据的组织，各个业务系统可能是相互分离的。而数据仓库则是面向主题的。主题是一个抽象的概念，是较高层次上企业信息系统中的数据综合、归类并进行分析利用的抽象。在逻辑意义上，它是对应企业中某一宏观分析领域所涉及的分析对象。
操作型处理（传统数据）对数据的划分并不适用于决策分析。而基于主题组织的数据则不同，它们被划分为各自独立的领域，每个领域有各自的逻辑内涵但互不交叉，在抽象层次上对数据进行完整、一致和准确的描述。
3.2 集成性
确定主题之后，就需要获取和主题相关的数据。当下企业中主题相关的数据通常会分布在多个操作型系统中，彼此分散、独立、异构。因此在数据进入数据仓库之前，必然要经过统一与综合，对数据进行抽取、清理、转换和汇总，这一步是数据仓库建设中最关键、最复杂的一步，所要完成的工作有：
- 要统一源数据中所有矛盾之处，如字段的同名异义、异名同义、单位不统一、字长不一致，等等。
- 进行数据综合和计算。数据仓库中的数据综合工作可以在从原有数据库抽取数据时生成，但许多是在数据仓库内部生成的，即进入数据仓库以后进行综合生成的。
下图说明了保险公司综合数据的简单处理过程，其中数据仓库中与“承保”主题有关的数据来自于多个不同的操作型系统。这些系统内部数据的命名可能不同，数据格式也可能不同。把不同来源的数据存储到数据仓库之前，需要去除这些不一致。
3.3 非易失性
数据仓库是分析数据的平台，而不是创造数据的平台。我们是通过数仓去分析数据中的规律，而不是去创造修改其中的规律。因此数据进入数据仓库后，它便稳定且不会改变。
操作型数据库主要服务于日常的业务操作，使得数据库需要不断地对数据实时更新，以便迅速获得当前最新数据，不至于影响正常的业务运作。在数据仓库中只要保存过去的业务数据，不需要每一笔业务都实时更新数据仓库，而是根据商业需要每隔一段时间把一批较新的数据导入数据仓库。
数据仓库的数据反映的是一段相当长的时间内历史数据的内容，是不同时点的数据库快照的集合，以及基于这些快照进行统计、综合和重组的导出数据。
数据仓库的用户对数据的操作大多是数据查询或比较复杂的挖掘，一旦数据进入数据仓库以后，一般情况下被较长时间保留。数据仓库中一般有大量的查询操作，但修改和删除操作很少。
3.4 时变性
数据仓库包含各种粒度的历史数据，数据可能与某个特定日期、星期、月份、季度或者年份有关。
虽然数据仓库的用户不能修改数据，但并不是说数据仓库的数据是永远不变的。分析的结果只能反映过去的情况，当业务变化后，挖掘出的模式会失去时效性。因此数据仓库的数据需要随着时间更新，以适应决策的需要。从这个角度讲，数据仓库建设是一个项目，更是一个过程 。
数据仓库的数据随时间的变化表现在以下几个方面：
- 数据仓库的数据时限一般要远远长于操作型数据的数据时限。
- 操作型系统存储的是当前数据，而数据仓库中的数据是历史数据。
- 数据仓库中的数据是按照时间顺序追加的，它们都带有时间属性。
4. OLTP｜OLAP
当谈论到数据库和数据处理时，OLTP 和 OLAP 是两个常见的概念。
数据库系统可以在广义上分为联机事务处理（Online Transaction Process，OLTP）和联机分析处理（Online Analyze Process，OLAP）两种不同的数据处理方式。从产品上看，有专门面向 OLTP 的数据库，例如 MySQL、PostgreSQL、Oracle 等，也有专门面向 OLAP 的数据库，例如 Hive、Greenplum、HBase、ClickHouse 等。数据仓库是 OLAP 系统的一个典型示例，主要用于数据分析。
- OLTP 代表联机事务处理（Online Transaction Processing），它是用于处理实时交易和操作的数据库处理方式。它适用于日常业务操作，如银行交易、在线购物、航班预订等。OLTP 系统通常需要快速响应时间，能够处理大量的短期交易。它的主要特点是高并发、低延迟和事务一致性。OLTP 数据库以维护最新的数据状态为目标，因此它经常进行插入、更新和删除操作。
- OLAP 代表联机分析处理（Online Analytical Processing），它是用于分析和查询大量数据的数据库处理方式。它适用于业务智能、数据挖掘和决策支持等领域。OLAP 系统通常涉及复杂的分析查询和聚合操作，用于生成报告、制定策略和发现趋势模式。它的主要特点是高性能查询、复杂计算和数据分析能力。OLAP 数据库以提供快速、灵活的数据查询和汇总为目标，因此它通常不频繁进行插入、更新和删除操作。
下面从多个不同角度来对比 OLTP 和 OLAP：
| OLTP | OLAP | |
|---|---|---|
| 数据源 | 仅包含当前运行日常业务数据 | 整合来自多个来源的数据，包括 OLTP 和外部来源 |
| 目的 | 面向应用、面向业务，支撑事务 | 面向主题、面向分析，支撑分析决策 |
| 焦点 | 当下 | 主要面向过去、面向历史（new：实时数仓） |
| 任务 | 读写操作 | 大量读而很少写操作 |
| 响应时间 | 毫秒 | 秒、分钟、小时或者天取决于数据量和查询复杂性 |
| 数据量 | 小数据（MB/GB） | 大数据（TP/PB） |
| 使用场景 | 处理实时交易和日常业务操作，如银行交易、在线购物等 | 分析和查询大量数据以支持决策和业务智能 |
| 数据处理方式 | 注重事务处理，以保持最新的数据状态，频繁进行插入、更新和删除操作。 | 注重数据分析和查询，通常不频繁进行数据更新，主要进行复杂的查询和聚合操作。 |
简单来说，OLTP 主要关注处理实时交易和保持数据的一致性，而 OLAP 主要用于数据分析和查询，以支持决策和发现模式。
5. 数据·库/仓库/集市
5.1 数据库/数据仓库
数据库与数据仓库的区别实际讲的是 OLTP 与 OLAP 的区别。
- OLTP 系统的典型应用就是 RDBMS，也就是我们俗称的数据库，当然这里要特别强调此数据库表示的是关系型数据库，NoSQL 数据库并不在讨论范围内。
- OLAP 系统的典型应用就是 DW，也就是我们俗称的数据仓库。
因此数据仓库和数据库的区别就很好掌握了。但是有几点需要着重强调：
- 数据仓库不是大型的数据库，虽然数据仓库存储数据规模大；
- 数据仓库的出现，并不是要取代数据库；
- 数据库是面向事务的设计，数据仓库是面向主题设计的；
- 数据库一般存储业务数据，数据仓库存储的一般是历史数据；
- 数据库是为捕获数据而设计，数据仓库是为分析数据而设计。
5.2 数据仓库/数据集市
数据仓库是面向整个集团组织的数据，数据集市是面向单个部门使用的。可以认为数据集市是数据仓库的子集，也有人把数据集市叫做小型数据仓库。数据集市通常只涉及一个主题领域，例如市场营销或销售。因为它们较小且更具体，所以它们通常更易于管理和维护，并具有更灵活的结构。
如上图所示：
各种操作型系统数据和包括文件在内的等其他数据作为数据源，经过 ETL（抽取-转换-加载）填充到数据仓库中。
数据仓库中有不同主题数据，数据集市则根据部门特点面向指定主题，比如 Purchasing（采购）、Sales（销售）、Inventory（库存）。
用户可以基于主题数据开展各种应用：数据分析、数据报表、数据挖掘。
6. 数据仓库分层架构
6.1 数仓分层思想和标准
数据仓库的特点是本身不生产数据，也不最终消费数据。按照数据流入流出数仓的过程进行分层就显得水到渠成。
数据分层每个企业根据自己的业务需求可以分成不同的层次，但是最基础的分层思想，理论上数据分为三个层：操作型数据层（ODS）、数据仓库层（DW）和数据应用层（DA）。
企业在实际运用中可以基于这个基础分层之上添加新的层次，来满足不同的业务需求。
6.2 阿里数仓3层架构
ODS 层（Operation Data Store）
操作型数据层，也称之为源数据层、数据引入层、数据暂存层、临时缓存层。此层存放未经过处理的原始数据至数据仓库系统，结构上与源系统保持一致，是数据仓库的数据准备区。主要完成基础数据引入到数仓的职责，和数据源系统进行解耦合，同时记录基础数据的历史变化。
DW 层（Data Warehouse）
数据仓库层。内部具体包括 DIM 维度表、DWD 和 DWS，由 ODS 层数据加工而成。主要完成数据加工与整合，建立一致性的维度，构建可复用的面向分析和统计的明细事实表，以及汇总公共粒度的指标。
- 公共维度层（DIM）：基于维度建模理念思想，建立整个企业一致性维度。
- 公共汇总粒度事实层（DWS、DWB）：以分析的主题对象作为建模驱动，基于上层的应用和产品的指标需求，构建公共粒度的汇总指标事实表，以宽表化手段物理化模型。
- 明细粒度事实层（DWD）: 将明细事实表的某些重要维度属性字段做适当冗余，即宽表化处理。
数据应用层（DA / ADS）
面向最终用户，面向业务定制提供给产品和数据分析使用的数据。包括前端报表、分析图表、KPI、仪表盘、OLAP 专题、数据挖掘等分析。
6.3 ETL｜ELT
数据仓库从各数据源获取数据及在数据仓库内的数据转换和流动都可以认为是 ETL（抽取 Extra - 转化 Transfer - 装载 Load）的过程。但是在实际操作中将数据加载到仓库却产生了两种不同做法：ETL 和 ELT。
ETL：Extract - Transform - Load
首先从数据源池中提取数据，这些数据源通常是事务性数据库。数据保存在临时暂存数据库中。然后执行转换操作，将数据结构化并转换为适合目标数据仓库系统的形式。最后将结构化数据加载到仓库中，以备分析。
ELT：Extract - Load - Transform
使用 ELT，数据在从源数据池中提取后立即加载。没有临时数据库，这意味着数据会立即加载到单一的集中存储库中。数据在数据仓库系统中进行转换，以便与商业智能工具和分析一起使用。大数据时代的数仓这个特点很明显。
6.4 为什么要分层？
分层的主要原因是在管理数据的时候，能对数据有一个更加清晰的掌控，详细来讲，主要有下面几个原因：
（1）清晰数据结构
每一个数据分层都有它的作用域，在使用表的时候能更方便地定位和理解。
（2）数据血缘追踪
简单来说，我们最终给业务呈现的是一个能直接使用业务表，但是它的来源有很多，如果有一张来源表出问题了，我们希望能够快速准确地定位到问题，并清楚它的危害范围。
（3）减少重复开发
规范数据分层，开发一些通用的中间层数据，能够减少极大的重复计算。
（4）把复杂问题简单化
将一个复杂的任务分解成多个步骤来完成，每一层只处理单一的步骤，比较简单和容易理解。而且便于维护数据的准确性，当数据出现问题之后，可以不用修复所有的数据，只需要从有问题的步骤开始修复。
（5）屏蔽原始数据的异常
屏蔽业务的影响，不必改一次业务就需要重新接入数据。
7. 美团点评酒旅数仓建设实践
下面通过一线互联网企业真实的数仓建设实践案例，来从宏观层面感受：
- 数仓面向主题分析的特点
- 在企业中数仓是一个不断维护的工程
- 数仓分层并不局限于经典 3 层，可以根据自身需求进行调整
- 没有好的架构，只有适合自己业务需求的架构
7.1 技术架构变迁
在美团点评酒旅事业群内，业务由传统的团购形式转向预订、直连等更加丰富的产品形式，业务系统也在迅速的迭代变化，这些都对数据仓库的扩展性、稳定性、易用性提出了更高要求。基于此，美团采取了分层次、分主题的方式不断优化并调整层次结构，下图展示了技术架构的变迁。
第一代数仓模型层次中，由于当时美团整体的业务系统所支持的产品形式比较单一（团购），业务系统中包含了所有业务品类的数据，所以由平台的角色来加工数据仓库基础层是非常合适的，平台统一建设，支持各个业务线使用，所以在本阶段中酒旅只是建立了一个相对比较简单的数据集市。
第二代数仓模型层次的建设，由建设数据集市的形式转变成了直接建设酒旅数据仓库，成为了酒旅自身业务系统数据的唯一加工者。
随着美团和点评融合，同时酒旅自身的业务系统重构的频率也相对较高，对第二代数仓模型稳定性造成了非常大的影响，原本的维度模型非常难适配这么迅速的变化。核心问题是在用业务系统和业务线关系错综复杂，业务系统之间差异性明显且变更频繁。
第三代数仓在 ODS 与多维明细层中间加入了数据整合层，参照 Bill Inmon 所提出的企业信息工厂建设的模式，基本按照三范式的原则来进行数据整合，由业务驱动调整成了由技术驱动的方式来建设数据仓库基础层。
使用本基础层的最根本出发点还是在于美团的供应链、业务、数据它们本身的多样性，如果业务、数据相对比较单一、简单，本层次的架构方案很可能将不再适用。
7.2 业务主题建设
实际上在传统的一些如银行、制造业、电信、零售等行业里，都有一些比较成熟的模型，如耳熟能详的 BDWM 模型，它们都是经过一些具有相类似行业的企业在二三十年数据仓库建设中所积累的行业经验，不断的优化并通用化。
但美团所处的 O2O 行业本身就没有可借鉴的成熟的数据仓库主题以及模型，所以，在摸索建设两年的时间里，美团总结了下面比较适合现状的七大主题（后续可能还会新增）。
7.3 数仓整体架构
确定好技术和业务主题之后，数仓的整体架构就比较清晰了。美团酒旅数仓 7 个主题基本上都采用 6 层结构的方式来建设，划分主题更多是从业务的角度出发，而层次划分则是基于技术，实质上就是基于业务与技术的结合完成了整体的数据仓库架构。
比如，以订单主题为例。在订单主题的建设过程中，美团是按照由分到总的结构思路来进行建设，首先分供应链建设订单相关实体（数据整合中间层 3NF），然后再进行适度抽象把分供应链的相关订单实体进行合并后生成订单实体（数据整合层 3NF），后续在数据整合层的订单实体基础上再扩展部分维度信息来完成后续层次的建设。
