数据仓库的前世今生

Posted 2021-04-24 dataman keyno

【1】EDW的前世今生

 

预计7分钟可以读完…

简单聊聊关于数据仓库的一些细碎，关于两位大神、两种模式和一些从业经验和感想

---

 

关于数据仓库（DW）的前身，有种说法是衍生自1980年代的DSS（Dicision Surport System，决策支持系统），一开始的DSS是企业内部一个面向管理、运营的决策分析应用系统，后面在DW慢慢普及之后，逐步衍生为DW的一个下游应用或者应用组件。

那说到DW，就绕不开两位老爷子 Bill Inmon和Ralph Kimbal提出的两种方法论。

 

先说下这两位大师级的人物：

（1）Bill Inmon，在他最出名的著作《Building the Data Warehouse》（1991年出版）中提出了数据仓库的概念，以及“DWDM（Data Warehouse Data Mart）”的建设主张（出名要赶早，由于第一个提出DW的概念，由此收获了The father of the DW的荣誉）。

（2）Ralph Kimbal，跟inmon“亦友亦敌”，提出“需求-驱动”和“DMDW（Data Mart Data Warehouse）”这种跟inmon不一样的建设思路，著有《The Data Warehouse Toolkit》等。

 

这是各类百科里的解释，keyno当年（2008）进入这个行当时，当时业界是有DWDM是自下而上、DMDW是自上而下的说法，后来细细对比着看了他们这两本最经典的书以及经历大大小小一些DW项目，发现其实也不是这么简单的两个方向就能说明白的。

 

那两者是怎么区别的呢？

打个比方吧，政府想在一块空地上面建一个村庄，Inmon的做法就是全盘统筹，先规划好每个区域要盖多少房子、街道、商铺、公共设施等如何分步再按部就班的开干，这俨然就是一个大工程了；而Kimbal则不用这么费劲，发动村民自发按需去盖房子，盖着盖着就成了一个村子了。

这么一说，两者的区别就差不多了

Inmon：周期长难度大，统筹规划，按步实施

Kimbal：周期短难度小，急用先行，按需建设

 

还是提下数据仓库的概念，业界目前用的最多的是Inmon提出的概念：

（1）“一个面向主题的、集成的、随时间变化的、非易变的用于支持管理的决策过程的数据集合”（最初提出）

（2）“数据仓库是在企业管理和决策中面向主题的、集成的、与时间相关的、不可修改的数据集合。”（后来更新）

 

这里有几个关键词简单说明下，面向主题，集成、不可修改，支持管理和决策。

其中，面向主题和集成：可以这么理解，企业是以各种业务主体来进行业务经营的，而这些主体相应的信息又是基于不同的业务条线，分散在不同的业务系统之中。在数据仓库建设时，可以将这些分散的主体信息，以主题的方式通过不同的视角进行抽象和归类，这就是主题的概念，而分散的数据以一定的关联索引关系进行集中和整合存储，这就是集成的概念。

 

以两个行业为例，比如：

高校：教师、学生、科研、教学、等这种就是常规的业务主体，以教师为例，他们的基本信息一般会在人事部门管理的系统，跟科研相关的信息一般会在科研部门的系统，同样教学相关的信息就会在教务系统，当这些分散而且互相隔离的信息进入数据仓库时，我们一般的做法就会找到一个业务视角进行主题抽象为“教师”。

 

银行：银行的业务主要是围绕客户的，同一个客户可以在银行办理不同的业务产品（存款、贷款、理财、基金等），这些产品的信息一般也是分散在不同的业务条线（部门）的系统里的，以不同的视角进行抽象，以人的视角进行抽象则会有“客户”这个主题，以银行产品的视角则会有“产品”这个主题，以客户在银行的所有行为信息（存、取款，贷、还款）则可以提炼成“事件”这个主题，不同的主题之间是不割裂的，可以进行相应的关联（如何设计这个关联，后续再专题展开）。

 

还有不可修改，怎么理解呢？这里就是操作型系统和分析型系统的区别了，业务系统一般都是面向业务经营的操作系统，会有数据的产生和修改等操作，而数据仓库是分析型系统，只存储来自源头的数据，自己不产生数据，也不能修改数据，两者的关系就像一条河流一样，只有上游变化了才能影响到下游，而没有下游的变化能影响到上游的（关于上下游的这种比喻，涉及到数据治理的话，也是一个道理，上游污染了，就应该治理上游，而不是跑到下游来处理）。

 

数据仓库当前发展如何

随着整个数据仓库行业的发展和相应技术的日益成熟，业界对数据仓库的概念和建设理念也在不断的改良、优化和拓展。比如Bill Inmon，2017年都已经推出最新力作《数据湖架构》了，感兴趣的可以了解下～

毕竟理论和概念终究是停留在纸面上的，真正的体会往往需要在实际建设中去领悟。

那么，后面我们就用高校的DW建设作为一个示例，一起来大话DW。

 

补充一点思考：

（1）数据仓库是否有好的建造模式，建造模式没有好坏之分，只有适用不适用

（2）如何界定企业的数据仓库建设成功与否，应该有几点：

• 满足业务应用需求

• 实现数据仓库建设之前无法或很难满足的功能

• 框架体系，运维便捷，扩展灵活

 

补充一些名词：

• DW（Data Warehouse，数据仓库，简单理解为企业级的数据中心，主要面向存储）

• DM（Data Mart，数据集市，简单理解为部门级的数据中心，主要面向应用）

• Stage（一般会叫Stage区或Stage层，临时存放数据传输过程中的文件或数据的过渡区域，详解后面再展开）

• 数据粒度（简单理解粒度是数据仓库中面向存储和分析的一种数据划分方法，如时间有年粒度，月粒度，日粒度，如果有小时粒度的分析需求，那可以细化到小时粒度）

• ETL（简单理解ETL是一种数据传输的技术，完成一次数据传输一般分为三个步骤：E是Extract从源头抽取数据，T是Trasform转换数据格式，L是Load装载数据到目标）

• 数据清洗（是源头数据通过ETL进入数据仓库过程中的一道工序，一般体现在Trasform转换这个环节，实现数据格式统一，代码标准化等操作）

 

 

拓展阅读：

1、深入对比数据仓库模式：Kimball vs Inmon

https://segmentfault.com/a/1190000006255954

2、书籍1《Building the Data Warehouse》

3、书籍2《The Data Warehouse Toolkit》