数据仓库：后台服务器就十几张表，为什么要建几十张表的数仓？

引言

初学数据仓库时，心中多少会有一个困惑。那就是后台服务器也就十几张表，为什么使用分层架构+维度建模搭建数仓时就要创建几十张甚至上百张表？这就好比发面馒头，放到蒸笼一蒸，个头就变大了不少。

那数据仓库是不是把一个简单的问题搞得更复杂了呀？

呵呵，这正是数据仓库的分层架构+维度建模的核心价值所在。让我详细解释这个现象背后的原理。

数据仓库到底有何价值？

我们知道，企业耗费精力搭建数据仓库，目的是为公司的服务或产品做分析数据，最终为公司决策者提供更可靠的数据依据，这就是所谓的商业BI（商业智能）。现在都信息时代了，如果公司老板还在靠拍脑袋做决定，想一想就很不靠谱。

如果公司没有数据仓库，那是不是就不能做分析数据呀？当然不是。

人家有些小微公司，就靠一张 excel 表格就搞定了，照样做数据分析。当然，那是因为小微公司的服务或产品规模小，数据量也就很有限，excel 表格本身就自带很多数据分析功能，足够小公司使用了。

如果觉得 excel 表格分析能力有限，那么就可以使用 python 做数据分析。因为 python 有更强大的数据分析库，比如 numpy、pandas等。不过，这需要你得有一定的 python 编程能力，这对于普通人来说是有门槛的。

那公司大了，数据量也更大，excel 表格就已经容纳不下了，那就要用专门的后台数据库来装，比如 MySQL、Oracle、PostgreSQL。

我们知道，这些都是关系型数据库，并且支持 SQL 语言，而 SQL 语句具有极强的查询能力，我们通过编写 SQL 语句就可以满足各种数据分析要求。

既然如此，那不就没数据仓库啥事了呀？别着急。

这里存在两个问题。

问题一：数据库不保存历史记录

也就是说，数据库里保存的数据永远是当前状态的数据。比如我修改一条数据库记录，那么它就会覆盖以前的记录。如果我想要查询修改前的记录，那肯定是查不到了。

而数据分析不仅要分析当前的数据，也要分析以前的数据。比如分析用户流失数，也就是之前活跃过的用户，最近一段时间未活跃。

问题二：随着数据量增大查询性能变差

一般表记录达到 2000 万行‌，当然，这个数字并非一个硬性规定，而是一个基于经验的性能拐点提示，全表扫描等操作的性能会显著下降。‌

而数据分析的需求中，有很多都需要做统计，需要全表扫描。如果表记录达到上亿，那数据分析的性能就会更差，耗时更久。

这两个问题对于企业来说，哪一个都是无法接受的。

随着大数据技术的兴起，分布式数据存储和并行计算，大大提升了数据存储和计算能力，为数据仓库提供了底层基座。

数据仓库的价值在于解决的数据库存在的两大问题。

OLTP 和 OLAP

难道数据库自身就无法解决这两大问题吗？是的。

因为 MySQL、Oracle、PostgreSQL 等数据库的设计并不是为数据分析而来，它们更在乎事务处理和数据一致性等，也就是所谓的 OLTP（联机事务处理），它更适合用于后台服务器的数据存储，以支撑业务交易。

而数据仓库的设计则是为数据分析而来，它能够存储海量的历史记录，支持复杂的聚合分析，数据分析性能更好，耗时更短，也就是所谓的 OLAP（联机分析处理）。

数据仓库分层架构

说了半天，似乎还是没有解释“后台服务器就十几张表，数仓为什么要建几十张表？” 是的。

我们知道，数据仓库是为数据分析而生，它自然要解决数据库存在的两大问题。

那它是如何解决的呢？或者说，它解决问题的思路如何？

来看第一个问题，数据仓库必须可以保存历史记录。

这个问题比较好办。首先，数据仓库采用分布式存储，比如 HDFS 是分布式文件系统，HBase、MongeDB 等也是分布式数据库，支持横向扩展，只要增加服务器，理论上可以支持无限存储。接着，就可以通过datax、flume、sqoop等采集工具将数据采集到数据仓库中。数据采集分为全量同步和增量同步，全量同步就是把数据库中所有数据都采集，增量同步就只采集有变化的数据，这样数据仓库就可以保存历史记录了。

来看第二问题，数据仓库必须有更好的查询性能。
这个问题，你可能会说也比较好办。因为大数据技术不是有并行计算引擎嘛，比如 Hadoop/MapReduce,Spark 以及Flink 等，数据分析不是分分钟的事情嘛。

呵呵，问题就出现分分钟的事情上。虽然大数据并行计算引擎越来越牛逼，但是人们对查询性能，也就是查询速度，要求也越来越高。数据查询哪怕要等上一分钟，估计很多用户都受不了。我所知道的很多公司要求是 1s 内返回查询结果。

聪明的你，估计会想到，那还不简单嘛，不是可以并行计算，多搞几台服务器，查询性能不就上来了。坊间有句玩笑，即“能用钱解决的问题，千万别花时间”。呵呵，那还不如直接搞一台超级计算器，问题不都解决了嘛。

硬件升级行不通，那么就得另辟蹊径。怎么办呢？

解决办法就数据仓库的数据分层架构。你随便看一本关于数仓的书，都会告诉你，数仓一般分为 ODS、DIM、DWD、DWS、ADS 这几层。但是为什么要分这几层，却少有提及，似乎地球人都知道。

其实呀，数据仓库的分层架构，无论分几层，其目的都是为了解决查询性能问题。它解决查询性能问题的思路其实很简单，就是空间换时间的思想。

以空间换时间，是性能优化最常见的办法，在数仓中如何体现的呢？

比如我们有一张学生信息表，里面包含学生的信息字段（姓名、年龄、性别、身高、体重）等信息。如果要为学生信息表做数据分析，那么就可以针对年龄、性别、身高、体重几个维度做基础统计分析，比如统计学生年龄段分布、统计性别比例、统计身高分布等。

除了基础统计分析，可能我们还想要做更为复杂的统计分析，比如学生健康度评分（综合年龄、性别、体重、身高等数据），那就需要使用到基础统计分析结果。

如果我们直接编写一段 SQL 语句，让它做学生健康度评分（综合年龄、性别、体重、身高等数据）的统计分析，那么它就要先做基础统计分析，然后再做复杂统计分析。

如果我们把基础统计分析结果提前做好，并存储起来。这样，当我们要做学生健康度评分（综合年龄、性别、体重、身高等数据）的统计分析，是不是就可以直接把基础统计分析结果拿来使用，这样速度是不是就快多了。

虽然这个案例非常简单，但是想必你已经明白了数仓分层架构的作用了。

那么，后台服务器就十几张表，数仓为什么要建几十张表？想必答案就再明显不过了，数仓分层架构的必然结果。

以下为数仓分层架构示例图：

后台业务库 (10张表)
    ↓ 数据抽取转换
ODS层 (10张表) - 保持原样
    ↓ 清洗整合  
DWD层 (20张表) - 明细事实表 + 维度表
    ↓ 轻度汇总
DWS层 (30张表) - 主题宽表 + 汇总表  
    ↓ 高度聚合
ADS层 (15张表) - 应用指标表
    ↓ 维度退化
维度层 (15张表) - 独立维度表

其实，打一个不恰当的比方，数据仓库分层架构就好比预制菜，预制菜提前把你想要吃的菜配料都准备好，你只管选你喜欢的预制菜，下锅蒸煮即可，速度自然比你一步步从头自己做快多了。可能自己做菜要花一上午，预制菜只需要几分钟。

所以，数据仓库分层架构通过空间换时间，性能比直接数据查询快了 100 倍不止。

数据仓库维度模型

数据仓库维度模型，常见有星型模型、雪花模型等，这个东西是用于指导数据仓库建表的，其目的是为了方便做数据分析。为何维度模型比关系模型更方便做数据分析，这个你可以自行去研究。

数据仓库的弊端

数据仓库虽然解决了数据分析中数据库存在的两个问题，但是也引发了两个新问题。

问题一：数据仓库表急剧膨胀

为了空间换时间，提高查询性能，搭建数仓就需要创建大量中间层表，比如 DWD、DWS 层，数据表就会成几何倍数膨胀，复杂度也急剧提升。

问题二：数据仓库缺乏灵活性

由于数据仓库的中间层表是提前做好的，那么如果数据库中表的字段有所调整，那么数据仓库各层都要跟着调整，并重新做一遍。显然，数据仓库并不适用于数据表字段频繁变动的情况。就好比预制菜，配料是固定的，不太方便调整。

总之，虽然数据仓库存在弊端，但是遇到适合的场景，比如数据分析指标固定，数据表结构变化较小，数据仓库还是非常有用的。

思考

那是否存在既没有数据仓库的弊端，又具有数据仓库优点的解决办法呢？答案是，有！不过，请记住，凡事有利就有弊。虽然解决了数据仓库的弊端，但是也会存在新的问题。毕竟，天下没有白吃的午餐。

至于是什么，又存在什么新问题，请听下回分解！