1. 构建宽表的目的

讲宽表我想从为什么需要宽表入手，而不是一上来就抠概念。因为我觉得一门知识叫什么名字并不是最核心的，关键是搞清楚它的诞生背景以及如何在特定场景用好它。
构建宽表的目的很简单,就是为了"一站式"尽可能多的展示我们需要的数据。因为在数据库中，不同的数据通常是存放在不同的数据表中的，关联起来非常不方便，既费时又费力还容易犯错。那么如果我们将数据提前串联好存在一张数据表中,岂不是完美的解决了这个问题?由于数据表一般是通过二维结构（行列）展示数据,既然要尽可能多的展示信息,那么相对其他普通表拥有的属性更多，需要存储属性的字段更多，所以表就变宽了。

2. 什么是宽表

接下来再回归概念，什么是宽表，我从两个维度来解释。
我们先对“宽”做一个定量，一张数据库表，超过多少个字段就叫宽表？假设我们设置100为分界线，一张表超出100个字段就叫宽表，那么宽表的第一个定义就来了。

1. 凡是字段数量超过100个的数据库表，我们将其定义为宽表。

上面是比较简单直观的定义，我个人觉得没啥毛病，但是如果就这么拿出去和别人说，显得有点粗糙，可能有人觉得逼格不够高，所以换个角度，我们可以从结果逆推概念：

可以得到关于宽表的两种解释：

2. 存放核心业务实体不同维度属性的数据库表，可以称之为宽表

3. 存放核心业务实体在业务履行流程中的信息&上下游的关联信息，可以称之为宽表

先解释概念2， 举个列子， 在物流公司中，运输单承载了很多业务信息，包括运单的基本信息（创建日期，大概重量等）、运单的财务信息、运单的货物信息、运单的取派信息等等，这些数据在业务系统的数据库中是分散在不同的数据表中的（甚至不同的系统），如果我们要想一站式看到我们关注的不同维度的核心属性，要先确定数据中在哪里，然后再写代码关联到我们想看的数据，效率低，风险高。
那么，我们可以在数据仓库中将相关的数据提前关联好，然后加载到一张“运单宽表”中，这样，下游的用户如果需要看运单相关的信息，只需要访问一张表就可以了， 是不是更方便更高效了？

类似于我们经常听说的用户画像，也是基于用户这个核心实体，将用户相关的基础数据&各个领域的行为数据做了加工，然后统一存放在标签表中，落地成了一张宽表。

再来解释概念3， 同样举运单的例子，在快递的履行流程中，我们有时候期望能够一站式追踪某个核心实体的状态，那么我们可以基于关注的核心实体将其核心属性&上下游核心属性串起来，落地为一张宽表。

3. 如何构建宽表

以第三种宽表为例，分为下面几步：

1、 选取想要构建宽表的业务流程，梳理业务流程中的所有活动；
2、 梳理参与这些活动的核心业务实体；
3、 选择业务最关注的实体来构建宽表；
4、 确定宽表的数据颗粒度；
5、 选取属性
	1、核心实体相关的属性
	2、上下游相关联的核心实体的属性（按需选择）
	3、先关的维度属性（时间、地点、客户、产品等）（按需选择）
	4、统计标签（按需选择）
6、 设计Mapping & 测试用例
7、 实施、测试、上线、回归测试

4. 宽表的缺点

1、 宽表做了大量的维度退化，一旦维表的属性发生了缓慢变化，那么需要重新刷新宽表的历史数据；
2、 宽表是多数据来源，一旦上游业务发生了调整，宽表必须随着调整，往往费时费力。
3、 宽表做了大量冗余，相对于范式设计的表，需要更多的存储空间，且在跨平台推数时（例如从Hdfs->ClickHouse），可能会对下游集群造成较大影响