数据仓库系列一：数仓的前世今生

前言：笔者自2019年硕士毕业，先后任职于两家一线互联网大厂，加上实习经历在数据行业已经摸爬滚打近5年。近来愈发认识到工作中自我沉淀的重要性，既是对自己日常工作的梳理总结，也可以帮助到一些数据新人少走弯路。本篇从数据库引申到数据仓库，用一个生动形象的例子来介绍数据仓库的特性与必要性。了解数据底层可以帮助我们更好的去做数据相关工作，如果本篇文章能帮助到屏幕前困惑的你，会让我很开心。

 

01

 什么是数据库？

当我们说起‘数据仓库’这个词时可能感受并不很直观。相比之下，大家更熟悉的可能是 ‘数据库’这个词。在我们的主题开始之前，我想先着重介绍一下什么是数据库。

 

日常的工作、生活中会产生各种各样的数据，这些海量数据是需要被记录的，因为这些数据中往往蕴含着非常大的价值。我们拿办公最常用的数据处理工具Excel举例，大家日常工作一定少不了和Excel接触，会用Excel对数据进行记录、存储及运算。Excel其实可以被粗略看成一种微型数据库，因为事实上它的确承载了办公者对数据进行记录、存储及运算的需求。然而这种微型数据库存在很多不足：

• Excel 能存储的数据量有限，一般以一百万条为界限，超过这个数量级运行起来就很慢且会程序崩溃；

• Excel稳定性并不好，我相信大家肯定都有过 Excel卡死然后数据丢失的经历； 

为什么Excel会有诸如此类这些缺点呢？说白了，因为像Excel这种工具它根本不是为了存储数据而生，它的主要功能是对小量级的数据做一些轻量级处理加工，使用门槛低。但也决定了它绝对不可能被工业界应用于大量级数据的记录、存储及运算。

相比被大众广泛使用的Excel，数据库这种东西则显得更加小众和专业化一些。和上者比起来，数据库的优势在于存储的数据量更加庞大、运行起来更加稳定。我们实在无法想象类似淘宝、天猫这种巨大的互联网电商平台，在使用时突然存储数据的工具崩了，将会造成多大量级的损失。

从某种程度来讲，数据库这种工具就是为数据的安全、稳定兜底而存在的。此外，还需要同外部系统工具有良好的交互性，毕竟数据不是存进去就完事，如何应对频繁地增、删、改、查所带来的IO压力，以及在高并发场景下所能承受的数据洪流压力，都是数据库的系统设计者需要考虑的问题。可以说 ，数据库这个方向在整个计算机科学领域内，都占有重要的地位，而数据库方向的研究者也历来是图灵奖的得奖大户。

在如今高度信息化、智能化的社会里，无处不在的信息系统背后都少不了数据库的身影，你在各种APP中的每一次浏览、每一次上传、每一次下载、每一次下单，每一次行为，背后可能都对应着数据库的一条数据变化，是数据库帮我们承载了人类社会越来越多、越来越庞大的数据流量洪峰。

02

 数据库or数据仓库？

说到这里，大家应该已经对数据库有了一个基本认知。但是数据库与数据仓库有什么本质区别呢？我先用专业术语来描述一下这两者的区别，数据处理大致可以分成两大类：联机事务处理OLTP（On-line transaction processing ）、联机分析处理OLAP（On-Line Analytical Processing）。我们所说的数据库属于OLTP类型，侧重于基本的、日常的事务处理，例如银行交易。而本文的主角数据仓库则属于OLAP类型，侧重于复杂的分析、查询操作，为业务提供决策支持。

当然以上这一大段专业描述，不是数据相关从业者没有数据仓库基础的人基本看不懂。所以接下来我会带大家进入一个具体业务场景，结合实际的例子去讲解数据仓库的前世今生。

在打造业务场景之前，我们先总结一下数据仓库的几个特点，供大家在接下来的业务场景中慢慢体会：

• 数据仓库的诞生，其本质目的是将两种不同作用的库分开，让数据的采集与计算解耦；
  

• 数据仓库的数据产出具有T+1的特性，即今天看到的是昨天的报表（本文主要针对传统离线数仓）；

• 数据仓库起到了对不同平台、不同来源的数据，进行整合的作用；

• 数据仓库顺应了大数据时代数据爆炸的现状与趋势，以分布式存储与计算的方法，提高了计算机对数据的处理能力；
  
  

03

 一个栗子

有一个程序猿，我们叫他小明。小明就职于一家电商公司，负责电商系统中很重要的一个子模块—— “订单交易”模块的开发与维护。既然系统中存着大量订单数据，老板自然想根据这些订单数据做一些报表，以便运营和管理者更直观、更方便地探查业务现状。小明根据老板的需求，写了几个SQL脚本，直接查询线上数据导入BI系统，方便老板可以随时随地跟踪、观测公司的业务经营状况。老板很满意，并期望可以将这种数据能力输出到全公司，让下游相关的同学都有自己所需数据可以看。

很快，运营同学也根据自己的需要，提出了相关的数据需求，并且各业务线的运营同学提出的需求千差万别、口径纷繁不一，小明只能硬着头皮开发各种SQL脚本上线。同时，各业务线的数据分析师也通过申请，直连线上数据库进行各种探索、分析查询。大家都根据自己的需求用上了数据，俨然一副 “数字化转型”成功的样子，但是身为后端程序猿的小明却隐隐觉得事情不对劲。

因为最近，越来越多人反馈线上的系统变慢，小明一查后台监控吓了一跳。原来是自己开发的各类报表、以及分析师的SQL查询挤占了本应属于线上库的计算、IO资源，影响了其正常运行。这可不行啊，虽然大家看数据用数据重要，但线上系统的稳定性更重要。舍弃线上系统稳定而去追逐数字化，是本末倒置。于是小明思考，如何在满足大家取数用数的同时，还能兼顾线上系统的稳定运行呢？

 

这样就引出了我们对数据仓库总结的特性一：数据仓库的诞生，其本质目的是将两种不同作用的库分开，让数据的采集与计算解耦。如果数据的采集用一个库，数据的探索、分析查询用另一个库，是不是就能最大程度避免对线上系统的影响呢？于是小明定时将线上库的数据copy一份到另一个拷贝库，以后所有探索、分析查询都在拷贝库进行，那么所有的计算、IO压力都被转嫁到拷贝库了。线上库其实只需要承受一次数据copy带来的IO压力，其他的压力则都烟消云散。

此外，由于数据的 采集与计算 解耦了，所带来的另一个变化是——线上数据库（OLTP）逐渐偏重于针对单条数据的高频操作；而拷贝库（OLAP）则逐渐偏重于大范围的整表扫描、聚合等复杂的分析、查询操作。

想象一下，OLTP最典型的应用场景：热门商品秒杀、火车票抢购、支付宝双十一支付，这些场景都有一个共同特点：在极短的时间内进行极高频次地增、删、改、查。要在与数据流量洪峰交互的同时，还要保证系统稳定性和数据线程安全，但其操作对象仅仅是针对单条数据或多条数据。

而OLAP最典型的应用场景：制作数据报表、供分析师和运营做数据探查、对全量数据做核心挖掘，这些场景则具有另一个共同的特点：低频，但对数据的运算量、吞吐量要求高，可以容忍一定时间的延迟和等待，但每执行一次查询，其操作对象针对的则是十万、百万、千万甚至上亿的数据量级。

事实上，由于应用场景不同，工业界对其不断地更新、优化、迭代，这两种不同工具之间的差异已经愈发明显，就像生物界的物种分化一样，虽然拥有相同的祖先，但在不同环境下逐渐进化成了两个物种。虽然都是用来处理数据的，虽然看上去都能存储结构化的表数据，虽然都支持SQL查询，但在其本质和内核层面，已经完全是两个不同的 “物种” 。

 

话题说回小明的场景，在引入拷贝库以后，虽然解决了挤占线上系统资源的问题，但又带来了另一个问题——数据更新的实时性，这便引出了我们对数据仓库总结的特性二：数据仓库的数据产出具有 T+1的特性，即今天所看到的是昨天的报表（本文仅针对传统离线数仓，实时数仓并不包含在内）。因为数据的采集与计算解耦了，所带来的另一个结果就是——承载计算、IO压力的拷贝库无法实时更新。

从线上库copy数据到拷贝库，一天只发生一次（业内通常采用的做法是copy的时间定为凌晨12点，该时间段内用户热度小，数据copy带来的IO压力能被有效减轻），线上库新增、更新的数据，要等到第二天才能被拷贝库获取，所以在这种模式下，基本是T+1的数据产出模式。

自从大批量复杂的分析、查询操作被从线上库剥离出去之后，线上系统的稳定性得到了强保障，让老板甚是满意。各方源源不断的数据需求被提了过来，小明所负责的数据域开始不仅仅局限于订单交易系统了，这虽然是好事，但与此同时也伴随着更大的挑战。其中面临的一个重要挑战是，新纳入小明负责范围的系统，底层并不都是采用相同的数据库。以订单系统交易为例，数据库采用的是互联网常用的MySQL，而公司的人力资源系统PeopleSoft的底层数据库则是Oracle，除此之外，一些边缘系统的底层还采用了SQLServer、PostgreSQL，甚至在一些特定的业务场景下还会采用MongoDB、Redis这种非关系型NoSQL数据库。

这可让小明感到大为头疼，之前自己只负责订单交易系统，从线上库到拷贝库都是MySQL，所以数据同步很容易。而在不同数据库之间进行数据同步，必须要借助Kettle或Informatica这种ETL工具，这就引出了我们对数据仓库总结的特性三：数据仓库起到了对不同平台、不同来源的数据，进行整合的作用。事实上，在真正的工业界、大中型企业里绝不会仅仅采用一种数据库作为生产工具，一定是多种数据库并存的。这就带来一个问题，底层采用不同数据库的软件系统数据不能互通，造成了严重的数据孤岛现象。导致其本来应该发挥的重要作用被大打折扣，这将会严重地影响企业的数字化转型。所以整合不同平台的数据也是数仓诞生的重要使命之一。

 

在小明负责的拷贝库经过ETL工具整合了越来越多不同平台的数据以后，终于可以名正言顺的称其为数据仓库了。该数仓因为整合了公司各大平台的数据，所以可以进行各种复杂、多维度的统计分析工作，例如：统计各类不同渠道来源的流量数据PV、UV、DAU；结合公司的人力资源结构情况计算ROI；分析买家在不同垂类商品、不同时期下的复购情况等。

随着数据分析、探索工作的不断深入，越来越多的SQL脚本上线，也随着公司的电商业务不断做大，各类数据以指数型的速度爆炸式增长，终于有一天数据仓库承受不住了。

还记得上文我们讲过OLTP和OLAP的区别么？本质上小明所搭建的数据仓库是采用OLTP功能为主的MySQL为基石，大范围大批次的复杂分析、查询操作并不是它的强项。并且MySQL是单机的，更加难以承受日渐扩张的庞大运算量，也就引出了我们对数据仓库总结的特性四：数据仓库顺应了大数据时代 数据爆炸的现状与趋势，以分布式存储与计算的方法，提高了计算机对数据的处理能力。

小明想到市面上很火热的分布式计算系统架构Hadoop能利用廉价普通的PC机搭建集群，实现分布式数据存储和计算。通过查阅资料以后，小明发现Hadoop其中的一个组件Hive能将结构化的数据文件映射为一张数据库表。且能将复杂的Mapreduce程序翻译为简单的SQL语句，支持SQL查询，非常适合用来当作数据仓库（实际上，99%互联网公司的数据仓库是用 Hive搭建的，在很多人眼里 数据仓库 ≈ Hive，这种说法固然片面，但也侧面反映了 Hive的影响力之强大）。

小明在与公司商讨之后，对数据仓库的底层进行了大刀阔斧的改革，经历了种种阵痛，分布式基础架构的 Hive顺利上线，历史数据也成功迁移。至此以后，小明再也不用因为数据的存储、计算能力问题而发愁了。由于小明这段时间在数据搭建方向的出色贡献，其工作岗位也从后端开发工程师调整为全职负责数据的数据仓库工程师，小明的数据生涯之路其实才刚刚开始，不过这都是后话了。（敬请期待第二篇：Kimball建模的灵魂——维度与事实）

 

04

 归纳总结

通过以上这个巨漫长的栗子，不知道大家对数据仓库的认识有没有更加直观深入一丢丢呢。总而言之，我们还是给数据仓库再写一段归纳性的总结作为收尾：

 

数据库与数据仓库，本质上同宗同源，且存续相依，只是因为业务场景需求的不同，逐渐分化成了侧重点不同的两种工具。如果将数据库比做一艘海上快艇，那数据仓库则更像一艘巨型的货运邮轮，前者灵巧、轻便、好掉头且在海上穿梭自如，适合零碎货物的高频转运。而后者笨重、体型庞大、不便于频繁调整航行方向，且巨型邮轮本身的启动、运转就会耗费大量的时间，但是一旦启动完成，其所能容纳承载的货物量远非快艇可比。

数据仓库的本质，其实是大数据时代数据爆炸所衍生的产物。其作为一个大平台，整合各系统无序、杂乱、口径不一的数据，消除数据孤岛、提升可用的数据质量。另一方面借助分布式计算系统架构，让数据的采集与计算解耦，在保障线上系统正常运行的同时，还能有效支撑大批量复杂的分析、查询操作。在当今火热的 “大数据时代”，数据是一座金矿，更是各大互联网巨头赖以生存的血脉，而对于传统公司来讲，想要提高企业效率，数字化转型则是必不可少的。而数据仓库就是这一切所仰仗的基石，少了这块东西，在数据的世界里就如同人被抽走心脏。数据会像静止的血液一般，重要但却无法正常流转。

现在，你对数据仓库的前世今生，了解了么？

欢迎数据爱好者进一步交流数据仓库、数据开发相关话题，可通过小洛与我取得联系；

End