前言
无论你是否专门从事大数据开发,作为一个开发人员,应该都听说过数据仓库的概念,那你知道为什么会出现数据仓库?数据仓库究竟是干嘛的吗?有什么价值和意义呢?那么本文就带到入门,揭开数据仓库的面纱。
数据仓库的由来
数据仓库为何而来,主要解决什么问题的?
先下结论:为了分析数据而来,分析结果为企业决策提供支撑。举个简单的例子,比如你们公司要要判断明年是否要进入生产口罩,那么就需要数据支撑,比如口罩市场的需求、饱和率、利润等等,然后借由分析结果,去做判断决策,而不是拍脑袋,不然大概率就是亏本的。
下面再以一个中国人寿保险公司发展为例,详细阐述数据仓库为何而来?
(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旭阳
更多学习资料请移步:程序员成神之路