各位数据的朋友，大家好，我是老周道数据，和你一起，用常人思维+数据分析，通过数据讲故事。

(相关资料图)

前段时间和一个客户就数据中台搭建的一些问题进行了交流，其中讨论最多的是到底是用宽表来实现业务需求，还是用多表关联来实现。今天就和大家来聊一下这个话题。（点击观看视频）

数据仓库构建过程中，有一个所谓数据集市的概念。数据集市是为了满足特定业务场景而推出的一个逻辑概念，是针对一组特定的某个主题域、部门或者特殊用户需求的数据集合。数据集市中数据的结构通常被描述为星型结构或雪花结构。通俗的理解，星型结构是一个事实表关联多个维度表，维度表之间是相对独立的，比如销售订单表关联客户维度表和产品维度表，而雪花型结构则复杂一些，维度表之间还有关联，比如销售订单表关联客户维度表和产品维度表，客户维度表还关联客户分类表，产品维度表还关联产品分类表。

这两种模型，都是多表关联的模式。但在实践中，大家会发现，多表关联因为数据库在执行join时，会涉及多表扫描，效率上比较慢。就有人针对这种场景进行了优化，于是，宽表就出现了。它把某个分析场景要用到的所有维度表和事实表的字段，预先整合为一个大表，比如上例中，就将销售订单事实表、产品维度表、客户维度表等表先通过Join整合为一个大表，这个大表可能包含数十个字段。这样，使用的时候，就不再需要去多表关联，以提高查询的效率。

宽表VS多表关联

1、宽表

初衷是用空间换时间。

优势：效率

劣势：有许多冗余内容，占用空间大。

2、多表关联

优势：没有增加冗余

劣势：在数据库查询时，join会影响效率。

现在硬盘不值钱，大家更需要效率，所以，两种方式的优劣势就很明显了，越来越多的人开始使用宽表，并且，有些数据库支持列式存贮，连冗余空间都给优化了。

但是，在老周看来，这仅仅是传统的观点。为什么这么说呢？主要有两点：

一、宽表的劣势其实不在冗余空间，而是在于开发与维护成本太高。

为什么这么说呢？因为我们在第一次创建宽表时，面临一个很大的挑战，就是到底这个宽表要多宽，也就说到底要包含多少个字段。如果建少了字段，后面要再增加，就需要将历史数据全部重跑一遍，如果数据量真的很大，每次的维护时间会很长，且维护期间，用户无法使用这个数据集市。

有的聪明人就会说，那很简单啊，包含全部字段不就行了吗？这个方法当然不行，一是当宽表的字段多到一定程度，效率也会降低，另外，这个方法也无法避免后续增加字段。举个简单的例子，比如当时客户表里没有客户区域这个字段，后来增加了这个字段，亦或者，原来客户区域这个字段有些客户没有填写，现在重新填写了，那么，仍然需要重新跑一遍历史数据。

如果有很多宽表都需要用到客户区域这个字段，那你可以想像一下，小强可能是需要通宵加班了。

二、多表join原来可能是比较慢，但随着大数据技术的快速发展，现在多表join的效率已经与单表查询不相上下了，比如starrocks mpp数据库，多表join的效率与clickhouse单表查询效率相差无几。

经过上述的此消彼长，宽表的优势不再存在，而多表join则有更多的优势体现出来：

一、多表join更灵活，对于需求的变化，运维的工作量很小。

如上述客户表增加客户区域这个例子，对于多表join情况下，只需要在客户维度表中增加客户区域这个字段，并且将客户维度表重新抽取一下即可。一旦客户维度表更新，所有用到客户表的数据集市也就一并都更新了，不需要一个集市一个集市的维护；

二、如果放在奥威BI的平台上，多表join还有更多的优势可以体现出来。

1、在奥威BI数据可视化平台中，系统会根据最终使用的场景来动态构建join语法，并不会将所有的表都join，比如仅按客户维度分析销售订单，此时，就只会join客户表，而不把产品表也join上。在这种情况下，就可以最大限度的减少对效率的影响；

2、奥威BI数据可视化平台支持多事实表，也就是说，在同一个数据集市（分析模型）中，可以包含多个事实表，既可以包含销售订单，还可以包含销售出库单，这样，就可以很方便的实现分别从订单及出库单取数来计算订单出库率，而如果用宽表，这种场景还需要另外构建一个大表，将订单与出库表的所有字段都包含进来，又会造成开发与运维成本的大幅增加。

3、奥威BI数据可视化平台中有一个非常受欢迎的功能，就是智能钻取，即可以在任意报表之间穿透钻取，系统会自动传递参数，比如在看客户销售订单报表的时候，可以钻取到客户的应收账款报表，系统会自动将客户名称传递过去。如果用宽表的模式，就无法实现了。因为奥威BI数据可视化平台无法自动识别销售订单宽表与应收宽表，到底是哪个字段代表客户名称。但多表join就可以实现，因为大家都关联了客户这个维度表。

其实，对一般的生产制造企业来说，如不涉及到生产设备物联网数据，生产经营的数据量都不是很大，最大的事实表一年下来一般也不会超过500万条。在这样的数据量下，多表join与宽表的效率相差也不是很明显。

如果是零售企业，最大的事实表可能会超过5000万条记录，这种情况下，推荐使用starrocks，但不推荐使用clickhouse，因为clickhouse就是基于宽表来提升性能的，基本不支持多表join，请谨慎使用！

最后我们再总结一下宽表与多表join的优劣势对比：

宽表虽然在效率上有一定优势，但在现今大数据技术下，优势已经不明显，但其劣势却是非常明显且致命的，即在企业级应用时，需求多变的情况下，运维成本非常高；而多表join则非常灵活，运维成本非常低，更加适合企业级多变的应用场景。

老周道数据，和你一起，用常人思维+数据分析，通过数据讲故事，我们下一讲再见！