数据仓库漫谈-前世今生

数据仓库的内容非常多，每一个子模块拎出来都能讲很久。这里没法讲太多细节，大致思考了三个备选议题：

数据仓库的前世今生
数据仓库体系知识介绍
数仓开发者的路在何方？

既然是第一次分享，感觉还是跟大家普及下数仓的历史比较好，最终选了今天的这个话题，主要是给大家做个科普。

“前世今生”，拆解下来，我会从起源、发展、变化、展望四部分来给大家做个介绍。

数仓的起源，主要介绍下数据仓库概念诞生的大背景、大环境，数仓解决了实际场景中的什么问题，以及数仓的定义。

数仓的发展，我们主要介绍下数据仓库在我们国内的发展历程、在主要行业内的应用、我自己经历过的一些场景，以及当时产生的跟数据仓库相关的几个概念。

数仓的变化，随着大数据时代的到来，人们对数据资产更加重视，数据赋能业务能做的事情其实是更多了。那么传统数仓向大数据仓库的演变，对数仓人的基础能力要求有哪些变化呢？我会在第三部分给大家做个介绍。

目前为止，我们大致处在大数据仓库的阶段，并且已经有很多人在不断的做着新的尝试，第四部分我会基于我所看到的，跟大家共同探讨下数仓未来的演进方向。

做为科技进步的受益者，大家知道第一台计算机是什么时候发明的吗？

1946 年 2 月 14 日，诞生于美国的宾夕法尼亚大学。这台计算机重达 30 吨，占地 160 平方米，耗电174 千瓦，耗资 45 万美元，但每秒只能运行 5000 次加法运算。

第一代商用计算机，是 1951 年由雷明顿兰德公司（现 Unisys ）发售的，当时被美国人口普查部门用于人口普查。

但是当时的计算机太过笨重，成本高昂，且硬件损耗极大，比如里边的发光管，没几分钟就要烧坏一个。所以 1960 年，开发出来了第一款小型机，后续随着技术进步单台价格急剧下降，但性能却急剧上升。当年PC 机的升级速度——压根用不着像现在一样，通过软件降级旧手机的频逼你升级，当时电脑各方面参数都是每 18 个月翻一番；或者说，每三年，新出的机器每个方面都是你的旧机器性能的 4 倍，六年 16 倍。当然，最近几年更新换代速度已经开始降下来了。

讲到这里了，那么有没有人想过这样一个问题：什么是信息化？

百度百科的解释：

信息化是指培养、发展以计算机为主的智能化工具为代表的新生产力，并使之造福于社会的历史过程。

通俗点讲，就是以计算机网络为依托，将线下的各种依赖人力脑力的业务流程，使用软件工具实现，达到大幅度提高效率、节省人工的目的。

随着计算机科学的快速发展，使信息化的落地逐渐成为可能。

一条线是数据库技术的诞生发展与逐渐成熟。另一条线是各种 ERP、CRM、办公自动化、财务系统、供应链等软件解决方案的完善推广，数据库技术发展和各种软件产品推动，共同促使信息化进程不断的深入。

数据库技术，经过几年的三大数据模型（层次模型、网状模型、关系模型）角逐后，随着 SQL 语言的诞生使关系模型最终胜出，最终诞生了强大的 DB2、Oracle、SQLServer 等关系型数据库。。

这里简单提一下，IBM 最早的层次模型数据 IMS，全称是信息管理系统（Information Management System），所以数据库的诞生就是为了更方便的管理使用信息的。

另外，说到信息化的普及，各种相关软件供应商也功不可没。SAP 当然还是世界第一的位置，当时的世界五百强公司 80% 都使用了他们的 ERP，也就是企业资源管理产品，Oracle 当时很牛吧，他们一开始自研但好像不怎么样，最终还是买了 SAP 的产品。

SAP 直到 1994 年才引进中国，首先做的是自身产品的翻译工作，后来跟埃森哲、IBM 等咨询公司合作，快速打开了国内市场，同时也推进了国内的信息化进程。相关国内厂商起步稍晚，直到现在市场份额也小到可以忽略不计，08 年的统计 SAP 和 Oracle 都是百亿级年收入，用友是一两亿吧好像是。

那时候国内的有才华的人也都更倾向于进外企，没办法那时候人家确实强、福利待遇也很好。

那时候的设备也基本上清一色进口：IBM 的小型机、Oracle/IBM/TD 的数据库、EMC 的存储设备。

信息化开展过程中，各种软件工具存储下来的数据，真实反应了业务开展过程中的各种信息，虽然会存在一些噪音或者缺失，人们还是开始尝试从留存数据中寻找各种有用信息，用来了解业务现状、分析潜在问题与机会、预测未来发展路径等等。

了解现状。主要是通过各种运营分析报表以及对应的图标展示，报表主要是各种维度下的日周月季年汇总，图标主要是占比分析、同比环比分析等。

辅助决策。经典案例就是“啤酒尿布的故事”。上世纪 90 年代（大概 1993-1995 年之间吧），沃尔玛尝试将 Aprior 算法引入到 POS 机数据分析中（实际上是一种商品的关联分析算法），当时发现跟尿布一起购买最多的商品竟然是啤酒，最后经过进一步市场调研发现，美国的太太们经常叮嘱她们的丈夫下班后为小孩买尿布，而丈夫在买完尿布后又随手带回了他们喜欢的啤酒。后来，沃尔玛把尿布与啤酒放到相邻的货架上从而实现了啤酒与尿布销量的双双增长。

预测未来。通过对现有数据的分析挖掘，有时候是可以预测出通过改变某个变量后对结果的影响的。比如通过对商品价格的调整，会引起销量的变化，最终通过合理的定价达到利润或销售额最大化的目的。这上边我还列了一个我刚毕业时候做过的一个案例：废水经过污水处理厂处理后最终都会流到附近的某条河里，污水处理厂的出口会有水质检测设备，每条河流上也会有若干个水质检测站，因为水质的自然净化因素，距离检测站点越远对水质检测结果的影响越小。当时我们通过一个数学模型去预测想要保证某个检测站点主要污染物含量达标，结合其上游临近的若干个污水处理厂的距离，反推各个污水处理厂出口需保证的水质标准。

看了上边的介绍我们了解到，合理的数据应用，是能够给业务提供非常多的支撑作用的。但是随着数据的深度使用，人们逐渐发现了一些问题，一句话描述就是：现有的数据存储模式不好用了。

总结下来，主要有四类问题：

影响业务。大批量长时间跨度的数据运算、复杂的分析挖掘，往往会占用很多的计算资源，
数据混乱。业务逻辑的变化，造成不同时间段的数据含义内容都会有差别，更要命的是没有人会告诉你这些。
数据缺失。业务库基于性能和硬件成本考虑，都会把历史数据归档并转移到更廉价的存储设备去。
数据孤岛。数据是业务开展过程中各个系统软件产生并存储下来的，系统软件直接往往存在隔离，同时由于缺少统一规划，同一主数据在不同系统内的定义描述编码都不一致。大家可以脑补下阿里的 ID-Mapping ，其实是一个道理。

接下来，我们本次分享的主角终于出场了！

事实上，在上世纪 70 年代已经有人提出来需要单独构建数据分析系统了，但是局限于技术发展一直无法落地（大家可以往前翻到第 4 页 PPT，那时候的关系型数据还处于启蒙阶段。），直到后来 1991 年“数据仓库之父”正式确立了数据仓库基本概念，但直到那时候数据仓库理论依然不太成熟。

数据仓库的概念确立以后，有关数据仓库的实施方法、实施路径和架构等引发了诸多争议。

第一阶段：直接构建数据仓库。1994 年前后，实施数据仓库的公司大都以失败告终（采用规范化的方式直接构建数据仓库，对数仓构建者的能力要求过高，Inmon 老爷子当时有 30 年数据从业经验了，他行其他人能行吗？）。

第二阶段：直接构建数据集市。由于数据集市仅仅是数据仓库的某一部分，实施难度大大降低，并且能够满足公司内部部分业务部门的迫切需求，在初期获得了较大成功。但随着数据集市的不断增多，这种架构的缺陷也逐渐显现：公司内部独立建设的数据集市由于遵循不同的标准和建设原则，导致多个数据集市的数据混乱和不一致。

第三阶段：灵者为先，两种建模思想的融合。解决问题的方法只能是回归到数据仓库最初的基本建设原则上来。1998 年，Inmon 提出了新的 BI 架构 CIF（Corporation Information Factory，企业信息工厂），新架构在不同架构层次上采用不同的构件来满足不同的业务需求。

大家看下右边这个架构图，展示的是 Inmon 1998 年提出的《企业信息工厂》。

来自多个不同数据源的数据，经 ETL 抽取清洗转换后，将原子粒度数据以一种规范化的格式集成进企业数据仓库中，直接对外提供数据服务。同时基于不同需求再往上构建数据集市，以部门级分析多维格式存储。

这里有两个重要的基础概念，大家可以多多理解下：

数仓的定义：

面向主题。主要是给数据分类方便理解和管理。
集成。汇总多个源端系统数据甚至是异构数据源，到一个统一的相互兼容的数据存储内，使后续的分析关联更加容易。

相对稳定。对数据的操作大多是 Insert，很少有 Update、Delete。
反应历史变化。存储大量的历史数据,保留历史所有数据的状态，进而找出企业经营管理中的规律。我觉得这里应该包含两个层面：业务的历史变化规律、维度数据的历史变化。
用于支持管理决策。这是构建数仓的目的。但是发展到现在，数仓已经在别的很多地方开始发挥作用了。

三范式：经典的关系数据模型规范理论

属性不可拆分。保证列的原子性。例如不能把学生的的学号、名称、班级号都塞在一个字段里面
每个属性有且仅依赖于主键（主键的定义：能够唯一确定一条数据的列或列组合）。
属性不能传递依赖于主键。如果有就分表。例如行政区划的省市县三层划分必须建三张表，省市的名称不能放到区县的那张表里（当然这种情况下，维度建模通常是反三范式的）。

范式建模理论是在数仓建设实践中演变出来的，因为直接构建数据仓库和直接构建数据集市都会存在一些问题。

大家请看上图，原始数据通过 ETL ，转换成维度指标的形式，以原子粒度存入维度数据仓库，在此之上汇总成数据集市（数仓的主题区域）。为了保证数据集市间的兼容性，在数据集市之上抽离出来一套标准，就是总线架构。

这里也有两个重要的基础概念：

总线架构：类似于主数据管理，就是把维度和指标单独抽离出来集中管理，各个数据集市只有使用权。

一致性维度：集中管理维度以及维度属性。保证相同的维度在不同数据集市间的一致性。

一致性事实：集中管理指标的定义、单位、计算方法等。保证统一指标在不同数据集市间的含义是相同的。

维度建模过程：事实上是单张表的构建过程。一张表只说一件事情。但根据此方法建完所有表之后，对于维度完全相同的表是否需要合并，得根据实际情况来定，比如业务相近的就可以合起来。

到这里，我们基本上把数仓概念诞生的历史背景、发挥的价值、怎么构建数据仓库大致讲完了。随着历史进程推进到上世纪九十年代中期，我们国内终于是参与进来了。

接下来，我继续给大家介绍下数据仓库引入我们国内后的发展状况。

请看上边这页 PPT，我入行的时候，传统数仓在国内其实已经非常成熟了。但当时有数仓需求的企业并不多，因为大多数 2B 的中小公司不需要啊，他们数据量也不大，最多也就出几张实时的业务报表，直连业务系统反而更合适些。

当时的数仓开发甚至大多数的数据从业者，基本都在电信、银行、保险行业，以及大型央企民企。同时以电信、银行居多。

传统数仓，从技术栈上大致分为三类：数据库+ETL工具+BI工具。并且都被国外企业所垄断，上图中我虽然列了 Kettle 这个开源软件，但当时它的市场份额可以忽略不计。

由于数仓的技术栈，基本被外国企业把控，市场竞争中，外企也是通杀国内企业的。

请看上边这张 PPT，从左到右，软硬件提供商+解决方案提供商+外包公司，这些都是传统数仓的主要参与者。大概场景是这样的：解决方案提供商拿着外企的一众产品简单包装以后，在国内接项目，然后带着一大堆外包公司做实施。当然上边的分界也不是特别明显，华为也提供硬件、TD 也会做实施。

再往细分的话，华为亚信在电信行业做的比较出名，TD 主要是金融行业，IBM 埃森哲等咨询公司在大型央企民企做的比较多。当然软通当时也有保险事业部也会直接接一些项目，文思这两年好像银行项目接了很多，这两年群里有人疯狂招人的。虽然近些年大家吐槽外包的很多，但当时确实也养活了不少数仓从业者，因为第一第二梯队毕竟能容纳的人也有限，不去外包公司也没别的选择了。数仓项目通常也都是长期做的，所以也没有现在说的这么差。