本文主要是介绍企业级宽表建设，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
1 宽表概述
宽表，从字面意义上讲就是字段比较多的数据库表，通常情况下是讲很多相关的数据，包括实时表、维度表、指标等格言录在一起形成的一张数据表。
2 宽表的优点
2.1 开发效率提升
- 由于把不同的信息放在同一张表存储，宽表已经不符合范式设计，当然数仓里也不强调范式设计，随之带来的就是数据的大量冗余，与之对应的好处就是查询新能的提高与便捷，从而带来开发效率的提高。
2.2 数据质量稳定
- 宽表沉淀后，其数据准确性在经历了时间的校验后，逻错误的可能性很小，基于宽表的开发可以一定程度的规避对业务理解不透彻或者是书写的逻辑不正确，减少数据质量问题的发生
2.3 指标口径统一
- 宽表的设计带有核心逻辑下沉的倾向，假设报表都是基于底层宽表产出，那么报表上的指标天然是一致的，从数据可解释角度，能够天然免去业务之于数据准确性的挑战。
3 宽表的缺点
3.1 性能不高
- 宽表的计算逻辑往往很复杂，再加上宽表的数据输入是有大量依赖的，也就是说需要处理的数据量很大，导致宽表往往运行很慢，资源占用很多，尤其是重跑的时候。
3.2 稳定性不高
- 短板理论提出：系统的稳定性取决于最差的一个环节，宽表的稳定性也是很差的，主要是因为宽表依赖太多，每一个表的不稳定性都会传到宽表。
- 如果性能不高和稳定性不高同时作用在一起，其实是很致命的，例如你发现报表数据有问题，但是重跑需要几个小时。
3.3 开发难度大&维护成本高
- 虽说基于宽表做报表开发才是正确的姿势，但是宽表本身的逻辑往往很复杂、设计的业务逻辑繁多，所以后带来较大的开发难度和维护成本，想想下每次需要再几千航的SQL里面加逻辑！
4 如何设计宽表
4.1 不稳定与稳定分离
- 对于依赖外部大表补维度，导致计算经常延迟的case，可以考虑关联后推，即在报表层面做关联，这样即使维度出不来，报表数据还是可以看的，从而弱化宽表对不稳定的外部依赖的耦合。
4.2 主次分类
- 宽表往往会存储冗余信息，但是当这样的信息越来越多的时候，宽表的主题也就越来越弱，此时就需要做拆分，从而更加聚焦表的主题、也便于开发维护。
4.3 冷热分离
假设一张宽表里面有200个字段，有30张报表在使用它，但是只有前面150个字段被经常使用，后面50个字段只有一两张报表使用到了，那么就可以做冷热分离，将宽表拆分。
这篇关于企业级宽表建设的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
