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

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的影响力之强大）。

04 归纳总结

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

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

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

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

-END-