数字化时代，数据仓库究竟是干什么的？

无论你是否专门从事大数据开发，作为一个开发人员，应该都听说过数据仓库的概念，那你知道为什么会出现数据仓库？数据仓库究竟是干嘛的吗？有什么价值和意义呢？那么本文就带到入门，揭开数据仓库的面纱。

数据仓库的由来

数据仓库为何而来，主要解决什么问题的？

先下结论：为了分析数据而来，分析结果为企业决策提供支撑。举个简单的例子，比如你们公司要要判断明年是否要进入生产口罩，那么就需要数据支撑，比如口罩市场的需求、饱和率、利润等等，然后借由分析结果，去做判断决策，而不是拍脑袋，不然大概率就是亏本的。

下面再以一个中国人寿保险公司发展为例，详细阐述数据仓库为何而来？

（1）OLTP系统处理业务数据

中国人寿保险（集团）公司下辖多条业务线，包括：人寿险、财险、车险，养老险等。各业务线的业务正常运营需要记录维护包括客户、保单、收付费、核保、理赔等信息。这么多业务数据存储在哪里呢？

这些通用的业务行为一般是发在联机事务处理系统（OLTP）, 其主要任务是执行联机事务处理，前台接收的用户数据可以立即传送到后台进行处理，并在很短的时间内给出处理结果。

通常来说，这些业务数据最终都是落在关系型数据库中的，关系型数据库（RDBMS）是OLTP典型应用，比如：Oracle、MySQL、SQL Server等

这只是最基础的业务，但是随着业务规模的不断发展，衍生出了更多的数据分析型需求，用OLTP可行吗？

（2）分析型决策需求衍生

随着集团业务的持续运营，业务数据将会越来越多。由此也产生出许多运营相关的需求问题：

• 能够确定哪些险种正在恶化或已成为不良险种？
• 能够用有效的方式制定新增和续保的政策吗？
• 理赔过程有欺诈的可能吗？
• 现在得到的报表是否只是某条业务线的？集团整体层面数据如何？

......

为了能够正确认识这些问题，制定相关的解决措施，瞎拍桌子是肯定不行的。最稳妥办法就是：基于业务数据开展数据分析，基于分析的结果给决策提供支撑。也就是所谓的数据驱动决策的制定。

OLTP环境开展分析可行吗？

可以，但是没必要。OLTP系统的核心是面向业务，支持业务，支持事务。所有的业务操作可以分为读、写两种操作，一般来说读的压力明显大于写的压力。如果在OLTP环境直接开展各种分析，有以下问题需要考虑：

• 数据分析也是对数据进行读取操作，会让读取压力倍增；
• OLTP仅存储数周或数月的数据；
• 数据分散在不同系统不同表中，字段类型属性不统一；

（3）数据仓库面世

当分析所涉及数据规模较小的时候，在业务低峰期时可以在OLTP系统上开展直接分析。但为了更好的进行各种规模的数据分析，同时也不影响OLTP系统运行，此时需要构建一个集成统一的数据分析平台。该平台的目的很简单：面向分析，支持分析，并且和OLTP系统解耦合。基于这种需求，数据仓库的雏形开始在企业中出现了。

数据仓库是一个用于存储、分析、报告的数据系统，目的是构建面向分析的集成化数据环境。我们把这种面向分析、支持分析的系统称之为OLAP（联机分析处理）系统。当然，数据仓库是OLAP系统的一种实现。

• 中国人寿保险公司就可以基于分析决策需求，构建数仓平台。

数据仓库介绍

数据仓库（英语：Data Warehouse，简称数仓、DW）,是一个用于存储、分析、报告的数据系统，主要目的是构建面向分析的集成化数据环境，分析结果为企业提供决策支持（Decision Support）。

• 数据仓库本身并不“生产”任何数据，其数据来源于不同外部系统；
• 同时数据仓库自身也不需要“消费”任何的数据，其结果开放给各个外部应用使用；
• 这也是为什么叫“仓库”，而不叫“工厂”的原因。

数仓四大特征

那么数据仓库都有什么特点呢？

面向主题性（Subject-Oriented）

• 主题是一个抽象的概念，是较高层次上企业信息系统中的数据综合、归类并进行分析利用的抽象。在逻辑意义上，它是对应企业中某一宏观分析领域所涉及的分析对象。
• 传统OLTP系统对数据的划分并不适用于决策分析。而基于主题组织的数据则不同，它们被划分为各自独立的领域，每个领域有各自的逻辑内涵但互不交叉，在抽象层次上对数据进行完整、一致和准确的描述。

集成性

主题相关的数据通常会分布在多个操作型系统中，彼此分散、独立、异构。

• 因此在数据进入数据仓库之前，必然要经过统一与综合，对数据进行抽取、清理、转换和汇总，这一步是数据仓库建设中最关键、最复杂的一步，所要完成的工作有：
  • 要统一源数据中所有矛盾之处。如字段的同名异义、异名同义、单位不统一、字长不一致等等。

• • 进行数据综合和计算。数据仓库中的数据综合工作可以在从原有数据库抽取数据时生成，但许多是在数据仓库内部生成的，即进入数据仓库以后进行综合生成的。

下图说明了保险公司综合数据的简单处理过程，其中数据仓库中与“承保”主题有关的数据来自于多个不同的操作型系统。

非易失性、非异变性

• 数据仓库是分析数据的平台，而不是创造数据的平台。我们是通过数仓去分析数据中的规律，而不是去创造修改其中的规律。因此数据进入数据仓库后，它便稳定且不会改变。
• 数据仓库的数据反映的是一段相当长的时间内历史数据的内容，数据仓库的用户对数据的操作大多是数据查询或比较复杂的挖掘，一旦数据进入数据仓库以后，一般情况下被较长时间保留。
• 数据仓库中一般有大量的查询操作，但修改和删除操作很少。

时变性

• 数据仓库包含各种粒度的历史数据，数据可能与某个特定日期、星期、月份、季度或者年份有关。
• 当业务变化后会失去时效性。因此数据仓库的数据需要随着时间更新，以适应决策的需要。
• 从这个角度讲，数据仓库建设是一个项目，更是一个过程 。

数据仓库架构

通常情况下，为了把一个复杂的工作拆成了多个简单的工作，一般将数据仓库架构分为三层，即数据操作层、数据仓库层和应用数据层（数据集市层）。

ODS（Operation Data Store 数据准备区）

数据仓库源头系统的数据表通常会原封不动的存储一份，这称为ODS层，也称为准备区。它们是后续数据仓库层加工数据的来源。ODS层数据的主要来源是业务数据库、埋点日志、其他数据源。

• 业务数据库：可使用DataX、Sqoop等工具来抽取，每天定时抽取一次；在实时应用中，可用Canal监听MySQL的 Binlog，实时接入变更的数据。
• 埋点日志：线上系统会打入各种日志，这些日志一般以文件的形式保存，可以用 Flume 定时抽取。
• 其他数据源：从第三方购买的数据、或是网络爬虫抓取的数据。

DW（Data Warehouse 数据仓库层）

该层包含DWD、DWS、DIM层，由ODS层数据加工而成，主要是完成数据加工与整合，建立一致性的维度，构建可复用的面向分析和统计的明细事实表，以及汇总公共粒度的指标。

• DWD（Data Warehouse Detail 细节数据层），是业务层与数据仓库的隔离层。以业务过程作为建模驱动，基于每个具体的业务过程特点，构建细粒度的明细层事实表。可以结合企业的数据使用特点，将明细事实表的某些重要维度属性字段做适当冗余，也即宽表化处理。
• DWS（Data Warehouse Service 服务数据层），基于DWD的基础数据，整合汇总成分析某一个主题域的服务数据。以分析的主题为建模驱动，基于上层的应用和产品的指标需求，构建公共粒度的汇总指标事实表。
• DIM（公共维度层 ），基于维度建模理念思想，建立一致性维度。
• TMP层 ：临时层，存放计算过程中临时产生的数据。

ADS（Application Data Store 应用数据层）

该层是基于DW层的数据，整合汇总成主题域的服务数据，用于提供后续的业务查询等。

数据仓库开发语言

数仓作为面向分析的数据平台，其主职工作就是对存储在其中的数据开展分析，那么如何读取数据分析呢？

理论上来说，任何一款编程语言只要具备读写数据、处理数据的能力，都可以用于数仓的开发。比如大家耳熟能详的C、java、Python等。但是这些编程一员的学习成本和开发效率都不是十分友好，在数据分析领域中，SQL语言功能很强，十分简洁，用户也容易学习和使用，是主流的语言。比如比较常用的数据仓库工具Hive就是支持SQL的语法。

总结

本文通过例子讲清楚了数据仓库的来源，以及在企业应用中的必要性，主要是为了构建一个面向分析的集成化数据环境，分析结果可以为企业提供决策支持，真正实现数据驱动决策的目的。实际上数据仓库的建设远比上面提到的复杂，需要花费很大的成本，因此需要考虑清楚。

本文来自博客园，作者JAVA旭阳