通透！全面剖析什么是数据仓库
一、数仓的准确定义
数据仓库之父比尔·恩门（Bill Inmon）在1991年出版的“Building the Data Warehouse”（《建立数据仓库》）一书中所提出的定义被广泛接受：
数据仓库（Data Warehouse）是一个面向主题的（Subject Oriented）、集成的（Integrated）、相对稳定的（Non-Volatile）、反映历史变化（Time Variant）的数据集合，用于支持管理决策(Decision Making Support)。
数仓具备以下特点：
1、数据仓库是面向主题的。
操作型数据库的数据组织面向事务处理任务，而数据仓库中的数据是按照一定的主题域进行组织。主题是指用户使用数据仓库进行决策时所关心的重点方面，一个主题通常与多个操作型信息系统相关。
2、数据仓库是集成的。
数据仓库的数据是将所需数据从原来的分散数据中抽取出数据仓库的核心来，进行加工与集成，统一与综合之后才能进入数据仓库；
数据仓库中的数据是在对原有分散的数据库数据抽取、清理的基础上经过系统加工、汇总和整理得到的，必须消除源数据中的不一致性，以保证数据仓库内的信息是关于整个企业的一致的全局信息。
数据仓库的数据主要供企业决策分析之用，所涉及的数据操作主要是数据查询，一旦某个数据进入数据仓库以后，一般情况下将被长期保留，也就是数据仓库中一般有大量的查询操作，但修改和删除操作很少，通常只需要定期的加载、刷新。
数据仓库中的数据通常包含历史信息，系统记录了企业从过去某一时点(如开始应用数据仓库的时点)到当前的各个阶段的信息，通过这些信息，可以对企业的发展历程和未来趋势做出定量分析和预测。（包含空间维度和时间维度的数据）
3、数据仓库是不可更改的，数据仓库主要是为决策分析提供数据，所涉及的操作主要是数据的查询；
4、稳定的数据以只读格式保存，且不随时间改变。
5、汇总的。将操作性数据映射成决策可用的格式。
6、大容量。时间序列数据集合通常都非常大。
7、非规范化的。Dw数据可以是而且经常是冗余的。
8、元数据。将描述数据的数据保存起来。
9、数据源。数据来自内部的和外部的非集成操作系统。
二、数仓长什么样？
某校园数据仓库逻辑架构案例：
有些互联网企业在用的实时数仓模式：
OPPO离线实时一体管理模式：
在实际的数据平台运营管理过程中，数据表的规模往往随着更多业务数据的接入以及数据应用的建设而逐渐增长到非常大的规模，数据管理人员往往希望能够利用元数据的分析来更好地掌握不同数据表的血缘关系，从而分析出数据的上下游依赖关系。
分析表的输入表输出表以及连接的作业ID，即每张表的血缘关系。形成类似的血缘关系图：
进而梳理成明确的数据依赖关系：
最后形成明确的血缘说明列表：
三、数仓的价值是什么？
我们以数仓和数据比较来看数仓的价值所在：
| 功能 | 数据库 | 数据仓库 |
| 数据范围 | 当前状态的数据 | 存储历史的、完整的、反映历史的 |
| 数据变化 | 支撑频繁的增删改查 | 可添加、无删除、无变更的、反映历史的数据 |
| 应用场景 | 面向交易系统、流程；OLTP场景 | 面向分析、支持运营决策；OLAP场景 |
| 设计理念 | 遵守第一、二、三范式，避免冗余 | 违范式、适当冗余 |
| 数据量 | 小批次、高并发、低延迟 | 大批量、高吞吐、有延迟 |
其中OLTP（On-Line Transaction Processing）指的是传统的关系型数据库，针对实时业务处理，面对的主要操作是随机读写，采用满足三范式的实体关系模型存储数据，从而在事务处理中解决数据的冗余和一致性问题；而OLAP（On-Line Analytical Processing）系统面向数据批量读写，OLAP不关注事务处理的一致性，主要在数据的整合，以及复杂大数据查询和处理性能，OLAP能够支持复杂的分析操作。
| 区分维度 | OLTP | OLAP |
| 用户 | 操作人员、低级管理人员 | 决策人员、高级管理人员 |
| 功能 | 日常查询 | 决策支撑查询 |
| DB设计 | 面向应用、事务驱动 | 面向主题、面向分析、分析驱动 |
| 数据特征 | 当前状态的、实时更新的、二维的数据 | 历史的、多维度的、综合性的、非实时更新的数据 |
| 查询特性 | 读写数据量小、频繁的DML操作、面向大规模并发查询、延迟低 | 读写数据量大、DML操作少、并发小、面向复杂的查询、延迟高 |
| 用户数 | 上千个 | 上百个 |
| 数据规模 | GB级别 | TB级别 |
综上， 数据库的设计是为了完成交易而设计的，不是为了而查询和分析的便利设计的。而数据仓库是为了大量的查询和分析所设计的。
四、数仓治理
数据治理：
业务实体数据的标识，在大数据领域，一个数仓可以有成百上千，甚至成千上万或更多的表。这些表的含义，表的每个字段的含义只有通过元数据才能知道。
业务产生的数据的数据内容，业务实体数据以外的数据表都是为其服务的。
保证业务实体数据完整性、准确性、一致性、时效性。每一个操作业务实体数据的任务都应该配置数据质量监控，严禁任务裸奔。可建设统一数据质量告警中心从以下四个方面进行监控、预警和优化任务。
即数据的保密性、真实性、完整性、未授权拷贝和所寄生系统的安全性。
对于某些数据，用完可以删除掉，以便减少存储空间，数据生命周期数据定义了每个业务实体数据的周期，是否为热数据或冷数据，是否需要永久保留还是完成对应功能即可删除等。
开发规范示例：
开发语言，传统数仓一般SQL/Shell为主，互联网数仓又对Python、Java、Scala提出了新的要求。不管是传统数仓，还是基于Hadoop生态的构建的(hive、spark、flink)数仓，SQL虽然戏码在下降，但依然是重头戏。
在数仓中sql的基本操作既简单又实用，sql中比较复杂和重要的就是join。
下面用一张图清晰的解释了各种join的逻辑。
SQL开发规范：
在大数据生态，不管哪种数据处理框架，总有一天都会孵化出强大SQL的支持。如Hive SQL，Spark SQL，Blink SQL 等。但本质上还是SQL。
五、数仓的技术架构
数仓的逻辑分层
六、数仓怎么实现：设计、建模
a.业务场景调研
需要明确业务场景的分类，比如行业类大概有电商场景，电信运营商场景，社交场景等等，这些场景不同带来的是需求不同，需求不同则带来的是模型之间的差异化
b.需求调研
不同的场景不同的需求，比如很多企业的数仓更多是服务于数据可视化BI,有的服务于应用系统，有的服务于2C端。这些业务需求在统计、用户画像，推荐上等等的功能都有差异化
c.模型调研
根据实际业务场景，将业务侧对齐，遵循关系型数据库建模方式，从概念模型（cdm）->逻辑模型（ldm）->物理模型（pdm）建模套路，完成从抽象到具体的不断细化完善的分析、设计和开发的过程。
d.什么是维度表？
维度表可以看成是用户用来分析一个事实的窗口，它里面的数据应该是对事实的各个方面描述，比如时间维度表，它里面的数据就是一些日，周，月，季，年，日期等数据，维度表只能是事实表的一个分析角度。
e.什么是事实表？
事实表其实质就是通过各种维度和一些指标值得组合来确定一个事实的，比如通过时间维度，地域组织维度，指标值可以去确定在某时某地的一些指标值怎么样的事实。事实表的每一条数据都是几条维度表的数据和指标值交汇而得到的
构建企业级数据仓库，必不可少的就是制定数仓规范。包括命名规范、流程规范、设计规范，开发规范等。
七、数仓的发展趋势
传统经典数仓架构->
离线数仓架构->
实时数仓架构->
Lambda数仓架构->
Kappa数仓架构->
混合数仓架构
a.传统数仓架构在大数据领域应用不多了，这类架构在早期数据量不大，对性能的要求不高，业务较单一的场景中应用比较多，这类数仓主要以oracle，mysql这种关系型数据库的范式设计原则设计
b.离线数仓架构是在大数据领域应运而生的。主要是基于hadoop生态组件的大数据技术架构方案中以hive为主的，在设计层面遵循和借鉴传统数仓的设计思路和规范，在计算上则以分布式计算为主提高数据的操作性能
c.实时数仓是近几年提出的一种数仓架构，与离线数仓方案有相似之处，不同之处在于数据是实时的。这也是整个大数据从离线分布式计算迈向实时流计算过程中产生的。但个人认为实时数仓方案还有很多不成熟的地方，在业务场景中还是有很多局限性
d.对于Lambda数仓架构，Kappa数仓架构，混合数仓架构这些架构更多的是应对与特定场景，这类数仓架构方案不具备一定的通用性。
数仓的未来演进：
最后我们来看一下王锋一分钟讲明白数仓，不得不说这哥们儿是有功夫有见地的：
参考资料：https://developer.aliyun.com/article/738779