云平台
在线体验
免费下载

宽表 VS 多表关联,谁才是大数据分析的最佳选择?

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

 

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

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

奥威BI数据可视化软件

 

奥威BI数据可视化软件

 

      这两种模型,都是多表关联的模式。但在实践中,大家会发现,多表关联因为数据库在执行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则非常灵活,运维成本非常低,更加适合企业级多变的应用场景。

 

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

 

往期内容:

ETL到底是什么?

为什么要建数据库,而不是直连数据源?

一文看懂数据分析必备计算功能—内存计算

报表VS分析:为什么报表做不完?老板到底想要什么?

【BI软件】零编程构建财务分析模型(行计算模型)

BI数据可视化报表开发:分析模型VS自定义SQL