数据仓库漫谈之前世今生

点击上方 蓝字关注我们

✎ 编 者 按 

上世纪 90 年代，随着企业信息化及 CRM、ERP 等信息化系统的出现，数据仓库的概念诞生。关于数据仓库的内容五花八门，为了让大家对其有基本的了解，《数仓与大数据》作者李朋波（波哥）对数仓在国内的发展历程、在主要行业内的应用、亲身经历场景，以及当时产生的跟数据仓库相关的概念做了一次深入浅出的科普。

跟着文章 get 新知识吧！

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

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

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

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

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

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

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 机数据分析中（实际上是一种商品的关联分析算法），当时发现跟尿布一起购买最多的商品竟然是啤酒，最后经过进一步市场调研发现，美国的太太们经常叮嘱她们的丈夫下班后为小孩买尿布，而丈夫在买完尿布后又随手带回了他们喜欢的啤酒。后来，沃尔玛把尿布与啤酒放到相邻的货架上从而实现了啤酒与尿布销量的双双增长。

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

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

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

1. 影响业务。大批量长时间跨度的数据运算、复杂的分析挖掘，往往会占用很多的计算资源。

2. 数据混乱。业务逻辑的变化，造成不同时间段的数据含义内容都会有差别，更要命的是没有人会告诉你这些。

3. 数据缺失。业务库基于性能和硬件成本考虑，都会把历史数据归档并转移到更廉价的存储设备去。

4. 数据孤岛。数据是业务开展过程中各个系统软件产生并存储下来的，系统软件直接往往存在隔离，同时由于缺少统一规划，同一主数据在不同系统内的定义描述编码都不一致。大家可以脑补下阿里的 ID-Mapping ，其实是一个道理。

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

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

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

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

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

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

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

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

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

数仓的定义：

1. 面向主题。主要是给数据分类方便理解和管理。

2. 集成。汇总多个源端系统数据甚至是异构数据源，到一个统一的相互兼容的数据存储内，使后续的分析关联更加容易。

1. 相对稳定。对数据的操作大多是 Insert，很少有 Update、Delete。

2. 反应历史变化。存储大量的历史数据,保留历史所有数据的状态，进而找出企业经营管理中的规律。我觉得这里应该包含两个层面：业务的历史变化规律、维度数据的历史变化。

3. 用于支持管理决策。这是构建数仓的目的。但是发展到现在，数仓已经在别的很多地方开始发挥作用了。

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

1. 属性不可拆分。保证列的原子性。例如不能把学生的的学号、名称、班级号都塞在一个字段里面

2. 每个属性有且仅依赖于主键（主键的定义：能够唯一确定一条数据的列或列组合）。

3. 属性不能传递依赖于主键。如果有就分表。例如行政区划的省市县三层划分必须建三张表，省市的名称不能放到区县的那张表里（当然这种情况下，维度建模通常是反三范式的）。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

相信很多人都对数仓有所了解，那么大家有没有仔细想过，什么是数仓？数仓的边界在哪里？

数据管理大体可以分为四部分：集成、计算、存储、应用。狭义的数仓只包含集成计算和存储。但是没有上层应用的数仓根本毫无意义，所以数据应用对数仓来说也是至关重要的。

基于以上的原因，我们在谈项目的时候通常会提一些高大上的概念，比如我们要建设一个企业级的数据中心，我们要搭建一个数据平台等等，其实实质上都是：数据仓库+上层应用。

数据中心：就是把散落在组织各个地方的数集起来统一存储、分发、应用。

运营分析系统：是在数据中心的基础之上，根据业务需要做一些运营分析报表，直接服务于各个业务部门。

数据平台：这个概念更大，在数据中心的基础之上，考虑引入外部数据。基于数据平台开放各种内外部账户，所有用户都可以基于该平台做数据交换或者数据买卖。

数据中台：是最近几年提出的概念，已数据仓库和大数据技术平台为底座，以能力复用为目标构建。

伴随大数据时代的到来，带来了数据技术架构的重大变革，同时赋予分析挖掘更大的能力。

比如华尔街根据民众情绪抛售股票、谷歌根据网民搜索关键词的变化提前预测流感。

这个时候人们的思维方式已经开始慢慢发生变化了，同时数据仓库已经不仅仅局限于之前的分析挖掘了，数据开始更直接的参与到业务活动中来了。

互联网、大数据、云计算，带来了新的业务形态、新的开发氛围。所有互联网企业都开始认识到数据的重要价值，都开始构建自己的数仓或者数据集市了。

上边这页 PPT 提到的零散内容，相信互联网从业者都深有体会吧？

大数据时代，数据仓库相关技能反而更重要了。

数仓技能重要性提高的同时，对数仓从业者的能力要求，应该也是更高了。除了需要熟悉数仓理论、熟悉业务外，还需要足够的开发功底，而且大数据组件太多了，根本学不过来。

我是从传统数仓转型过来了，之前基本没写过代码，转型大数据一开始根本没有方向，甚至到后来我还学习了两周的 Spring。

不过现在回头看看，这才是最优的学习路线：

1. 通过 Hive 先入大数据的门，这个没啥难度，都是 SQL 嘛。

2. 学习 Hadoop、Hive、Spark 等的基本原理，同时多多实践。

1. 恶补 Java 基础，多敲代码。同时可以看看 Hadoop、Hive 源码（网上源码讲解的太多了）。

2. 大数据计算组件看的差不多了，可以再学学大数据存储组件，主要是一些 OLTP 组件，比如 CK 等等。

3. 离线计算掌握差不多了，可以再学习下流式计算，直接上手 Flink 就好了。

数仓转大数据的一点心得：

1. 大数据组件千万别贪多，抓住几个主流的学透就好了。

2. 开发能力很重要，但不用啥都学，掌握 JavaSE 足够了。

3. 基本盘是数据仓库，一定要绝对精通。面试时候开发相关不一定会问，但数仓绝对少不了。

最后，大家有没有想过，数据仓库的未来会是哪里呢？

只要数据还有价值，那么数仓就不会消亡，只会不断进化。

数仓背后的这一套数据管理和应用的方法论，以及数仓从业者的数据思维，必将使其终身受益。

实时数仓，离我们已经很近了，甚至很多企业已经在做了，但是想要完全替代离线数仓，还是有很多路要走的，比如数据准确性、数据的更新插入问题、不可加累积数据的计算问题等。

批流一体方面，目前 Flink、Spark 都实现了公用一套计算框架。但是公用一套存储还不太成熟，公用一套代码还没有实现。

数据湖概念，已经提出好多年了，虽然阿里华为也在吹，但目前市面上还没有出来真正意义上的方案。用网友的话说就是：我看好数据湖的未来，但不看好它的现在。

就像我 PPT 上总结的，数据湖还有很多问题没有解决。就算以后数据湖普及了，那么核心数据还是要进数据仓库的。因为数据湖里数据准确性很难保证，同时查询性能、对计算资源的消耗，数据仓库也是完败数据湖的。

---

社区官网
 
https://dolphinscheduler.apache.org/
 
 
代码仓地址
https://github.com/apache/dolphinscheduler
 
 
您的 Star，是 Apache DolphinScheduler 为爱发电的动力❤️ ～

添加小助手微信

(Leonard-ds)

加入社区

Apache DolphinScheduler

Apache DolphinScheduler 是 Apache 基金会孵化的顶级项目。作为新一代大数据任务调度系统，致力于“解决大数据任务之间错综复杂的依赖关系，使整个数据处理流程直观可见”。DolphinScheduler 以 DAG(有向无环图) 的方式将 Task 组装起来，可实时监控任务的运行状态，同时支持重试、从指定节点恢复失败、暂停及 Kill 任务等操作，并专注于可视化 DAG、调用高可用、丰富的任务类型依赖、任务日志/告警机制和补数 6 大能力。

迄今为止，Apache DolphinScheduler 社区已经有 260+ 位代码贡献者，70+ 位非代码贡献者，其中也不乏其他 Apache 顶级项目的 PMC 或者 Committer。开源社区也在不断发展壮大，微信用户群近 6000 人。截止 2021 年 9 月，已经有 600 + 家公司及机构在生产环境中采用 DolphinScheduler。

欢迎更多伙伴也能参与到开源社区建设中来，让未来 DolphinScheduler 的规划中也有你的一份贡献！

☞4 亿用户，7W+ 作业调度难题，Bigo 基于 Apache DolphinScheduler 巧化解☞在生鲜零售业，DolphinScheduler 还能这么玩！☞荔枝机器学习平台与大数据调度系统“双剑合璧”，打造未来数据处理新模式！
☞最佳实践｜联通数科基于 DolphinScheduler 的二次开发
☞DolphinScheduler 荣获 2021 中国开源云联盟优秀开源项目奖！
☞重构、插件化、性能提升 20 倍，Apache DolphinScheduler 2.0 alpha 发布亮点太多！☞巨变！a16z 关于新一代数据基础设施架构的深度洞察

点击阅读原文，报名预约！

点个在看你最好看