共计 3124 个字符，预计需要花费 8 分钟才能阅读完成。
关注公众号：大数据技术派 ，回复“材料”，支付1024G 材料。
数据仓库系列文章
- 数仓架构发展史
- 数仓建模方法论
- 数仓建模分层实践
- 数仓建模—宽表的设计
- 数仓建模—指标体系
- 一文搞懂 ETL 和 ELT 的区别
- 数据湖知识点
- 技术选型 | OLAP 大数据技术哪家强？
- 数仓相干面试题
- 从 0 到 1 学习 Presto，这一篇就够了！
- 元数据管理在数据仓库的实际利用
- 做中台 2 年多了，中台到底是什么呢？万字长文来聊一聊中台
- 数据仓库之拉链表
- sqoop 用法之 mysql 与 hive 数据导入导出
宽表的设计
其实宽表是数仓外面十分重要的一块，后面咱们介绍过了维度表事实表，明天咱们介绍一下宽表，后面咱们说过了数仓是分层的，这是技术提高和时代变动相结合的产物，数仓的分层式为了更好地治理数仓以及更加高效地进行数据开发。
宽表次要呈现在 dwd 层和报表层，当然有的人说 dws 层也有，宽表，从字面意义上讲就是字段比拟多的数据库表，通常状况下是将很多相干的数据包含维度表、实时、已有的指标或者是 dws/dwd 表关联在一起造成的一张数据表。
因为把不同的内容都放在同一张表存储，宽表曾经不合乎范式设计的模型设计规范而且数仓外面也不强调范式设计，随之带来的就是数据的大量冗余，与之绝对应的益处就是查问性能的进步与便捷。
分层 请参考 数仓建模—分层建设实践
设计 请参考 数仓建模—建模方法论
为什么要建设宽表
就像咱们后面说过分层的目标是为了治理不便、开发高效、问题定位、节约资源等等，那么咱们建设宽表呢？后面学习建模方法论的时候，提到过维度模型的非强范式的，能够更好的利用大数据处理框架的解决能力，防止范式操作的过多关联操作，能够实现高度的并行化。数据仓库大多数时候是比拟适宜应用星型模型构建底层数据 Hive 表，通过大量的冗余来晋升查问效率，星型模型对 OLAP 的剖析引擎反对比拟敌对，这一点在 Kylin 中比拟能体现。
能够更好的施展大数据框架的能力
维度模型能够更好地利用大数据框架，体现在哪里的，体现在数据数据冗余，能够防止很多的关联，怎么体现的呢，宽表。然而这只是站在大数据框架层面上的了解，还有其余层面上的了解。
能够进步开发效率
个别状况下，咱们的宽表蕴含了很多相干的数据，如果咱们在宽表的根底上做一些开发，那就很不便，咱们间接从宽表外面取数据，防止了咱们从头计算，你构想一下你要是没次都从 ods 开发一张报表，那是多苦楚的体验啊。
能够进步数据品质
宽表的准确性，个别都是经验了工夫的测验的，逻辑谬误的可能性很小，能够间接应用，要是让你从头开发，那这个过程中可能因为对业务了解不透彻或者是书写的逻辑不正确，导致有数据品质问题
能够对立指标口径
其实这一点和下面一点有点反复，然而这两点的强调的方面是不一样的，因为如果咱们的报表要是都能从咱们的底层宽表出，那么咱们报表上的指标必定是一样的，其实这一点我置信很多人都深有体会，同一个指标的口径不统一，导致咱们提供的数据在不同的进口不一样，是业务部门常常提出的一个问题。其实这也就是咱们始终强调的外围逻辑下沉的起因。
宽表的益处和有余
宽表的益处就是咱们后面提到过的咱们为什么要建设宽表的起因，接下来咱们看一下宽表的有余
性能不高
因为咱们的宽表的计算逻辑往往很简单，再加上宽表的数据输出是有大量依赖的，也就是说须要解决的数据量很大，在负载逻辑 + 大数据量的起因下，导致咱们的宽表往往运行很慢，资源占用很多，尤其是重跑的时候。
稳定性不高
上面的最初一张表就是一张宽表，咱们晓得一个零碎的稳定性是取决于最差的一个环节的，这就是短板实践也叫木桶实践，咱们的宽表的稳定性也是很差的，这个次要是因为咱们的宽表依赖太多，每一个表的不稳定性都会传到到宽表。
假如 一张表依赖 A B C 三张表，并且这三张表的稳定性是 1/m 1/n 1/x, 那么咱们的宽表的稳定性就是 1/m*n*x , 至于表的稳定性你可用它胜利运行的次数 / 运行的总次数
如果性能不高和稳定性不高同时作用在一件事上的时候咱们晓得这其实是很致命的，例如你发现报表数据有问题，然而重跑须要几个小时，哈哈！
开发难度大 / 保护老本高
咱们说了基于宽表做报表开发才是正确的姿态，然而宽表自身也是咱们开发人员开发的，因为自身的逻辑很简单设计的业务逻辑繁多，所以给咱们的开发就带来了挑战，而且因为业务逻辑的变更咱们也须要去保护着简单的逻辑，例如每次都让你在几千行的 SQL 外面加逻辑。
如何设计宽表
宽表的益处和有余咱们都讲了，也就是说宽表虽好，然而带来的问题也很多，上面咱们就看一下如何从设计的角度来防止宽表的不足之处
宽表到底多宽
开始之前，咱们思考一个问题，那就是宽表到底有多宽，就想咱们后面讲分层的时候说其实咱们不分层也玩得转，早起的数仓就只有一层，当初咱们思考一个问题那就是宽表到底多宽才适合，其实你要把所有的数据装进去也能够。
所以咱们要思考到底多宽才适合的，后面咱们介绍过数据域的概念，咱们与其答复多宽这个问题，不如答复宽表都应该笼罩哪些数据，然而这个问题也不好答复，然而咱们能够反着思考，宽表不应该蕴含什么数据，这个问题很好答复，宽表不应该蕴含不属于它所在域的数据，例如会员域的宽表只应该蕴含会员相干的信息，同理咱们的宽表是针对某一个域而言的，也就是说它是有边界的。
这下咱们再来答复宽表到底多宽，只有不跨域，并且方便使用都是正当的。然而这仿佛并不能解决咱们下面提到的宽表的有余，只是指明了宽表的一个大抵的方向。有了方向之后咱们通过咱们的设计策略就能够让宽表瘦下来。
主次分类
主次拆散，其实咱们常常听到的一句话就是做事件要搞清楚主次，咱们看一下表设计的主次是什么，假如咱们做的是一个会员域的宽表，然而会员域是还是一个比拟大的概念，所以咱们还要发掘出咱们这个表的主题，例如咱们做的是一张会员域下的会员根本信息宽表，那么咱们专一的必定就是根本信息，例如会员信息买通。当让因为事宽表你可能还会冗余的其余信息进来，然而当这样的信息越来越多的时候，咱们这张表的主题就越来越弱，所以咱们就须要做拆分。
拆分能够让咱们更加聚焦表的主题，对于数仓开发人员而言能够更好的保护、对于应用方而言能够更加分明的了解这张表的主题。
冷热拆散
除了后面的主次拆散咱们还能够做冷热拆散，其实冷热拆散这个词我置信你不是第一次听到，然而怎么看这个事件呢，你想一下你在数据存储的时候是怎么做冷热拆散的，这里也是同样的理念。
假如我有一张宽表，外面有 200 个字段，有 30 张报表在应用它，然而我发现后面 150 个常常字段常常被应用，前面 50 个字段只有一两张报表应用到了，那么咱们就能够做一个冷热拆散，将宽表拆分。
稳固与不稳固拆散
其实后面的主次拆散、冷热拆散都能够进步稳定性，然而后面咱们不是为了稳定性拆散的。
咱们常常有这样的宽表，它依赖埋点数据，然而咱们的埋点数据的特点就是量大，导致计算常常提早，那么咱们的宽表就会受影响，从而咱们的报表就受影响，然而很多时候你发现报表基本没有用过埋点计算出来的指标，或者是只用了一两个。那咱们能够将其拆分，如果报表没有应用到那就最好了，如果应用到了，那就后推，在报表层面上做关联，这样咱们的埋点数据即便出不来，咱们的报表数据还是能够看的。
总结
次要解说了一下几个方面
- 为什么要建设宽表
- 宽表的有余
如何设计宽表
- 宽表到底多宽
- 主次拆散
- 冷热分类
- 稳固与不稳固分类
设计宽表的实践其实说白了就是一句话 高内聚低耦合 ，当然这几个字你在其余畛域可能很相熟了，然而这里你就好好思考一下能力想通，我始终新崇奉的是 一力降十会 一拙破万巧 也就是说你要学会基本的货色，能力触类旁通破万难。
猜你喜爱
Spark SQL 知识点与实战
Hive 计算最大间断登陆天数
Hadoop 数据迁徙用法详解
Hbase 修复工具 Hbck
数仓建模分层实践
Flink 是如何对立批流引擎的
