宽表 VS 多表关联，谁才是大数据分析的最佳选择？（1） 各位数据的朋友，大家好，我是老周道数据，和你一起，用常人思维+数据分析，通过数据讲故事。 前段时间和一个客户就数据中台搭建的一些问题进行了交流，讨论最多的是到底是用宽表来实现业务需求，还是用多表关联来实现。今天就和大家来聊一下这个话题。 数据仓库构建过程中，有一个所谓数据集市的概念。数据集市是为了满足特定业务场景而推出的一个逻辑概念，是针对一组特定的某个主题域、部门或者特殊用户需求的数据集合。数据集市中数据的结构通常被描述为星型结构或雪花结构。通俗的理解，星型结构是一个事实表关联多个维度表，维度表之间是相对独立的，比如销售订单表关联客户维度表和产品维度表，而雪花型结构则复杂一些，维度表之间还有关联，比如销售订单表关联客户维度表和产品维度表，客户维度表还关联客户分类表，产品维度表还关联产品分类表。 这两种模型，都是多表关联的模式。但在实践中，多表关联因为数据库在执行join时会涉及多表扫描，效率上比较慢。有人针对这种场景进行了优化，于是，宽表出现了。它把某个分析场景要用到的所有维度表和事实表的字段，预先整合为一个大表，比如上例中，就将销售订单事实表、产品维度表、客户维度表等表先通过Join整合为一个大表，这个大表可能包含数十个字段。这样，使用的时候，就不再需要去多表关联，以提高查询的效率。 宽表VS多表关联 1、宽表 初衷是用空间换时间。 优势：效率 劣势：有许多冗余内容，占用空间大。 2、多表关联 优势：没有增加冗余 劣势：在数据库查询时，join会影响效率。 现在硬盘不值钱，大家更需要效率，所以，两种方式的优劣势就很明显了，越来越多的人开始使用宽表，并且有些数据库支持列式存贮，连冗余空间都给优化了。 但在老周看来，这仅仅是传统的观点。为什么这么说呢？主要有两点： 一、宽表的劣势其实不在冗余空间，而是在于开发与维护成本太高。 在第一次创建宽表时面临一个很大的挑战：这个宽表要多宽，也就说到底要包含多少个字段？如果建少了字段，后面要再增加，就需要将历史数据全部重跑一遍，如果数据量很大，每次维护时间很长，且维护期间无法使用这个数据集市。 （未完待续） 以上内容来自奥威BI软件