1. 宽表设计原理
- 宽表设计其实体现的是架构设计的思想，即高内聚松耦合，只不过发生在数据领域而已。
- 之所以要建设宽表，更多地是要利用大数据强大的计算能力，避免范式建模带来过多的关联操作，可以实现计算效率的高度并行化。
- 在大数据数仓中更多地是使用星型模型构建hive表，通过大量的冗余来提升查询效率，同时OLAP的数据计算引擎也能更好地支持星型模型的开发。
-
因为是把许多的字段内容集中存储在同一张表里，宽表很明显已经不符合范式模型设计的规范，并且在目前的数仓体系中，也早已抛弃了范式建模思路，带来的好处是高效与便捷的查询，当然也带来了宽表的脆弱性，如果有太多的底层表与宽表产生联系，同时又有许多上层应用被宽表所绑架，那么宽表的出错就会是数据体系的致命一环，不得不面临拆分的下场。
- 宽表带来便利的同时也带来了脆弱性。底层每张表都跟宽表的生成有千丝万缕的逻辑关系。这意味着宽表出错、延时的概率大幅增加。这个时候，大量具体应用都被宽表落库的时间、质量和数量绑架了，即使它仍然遵循高内聚松耦合的特点，也不得不面临拆分的下场。
2. 宽表模型优点
- 建模方法论中维度模型非强范式，就可以更好的利用大数据处理框架的并行处理能力，避免单一范式操作的过多线性操作，可以实现高度的并行化。
- 数据仓库大多数时候，比较适用星型模型，构建底层数据Hive表，通过大量的冗余来提升查询效率。星型模型对OLAP的分析引擎支持比较友好，这一点在Kylin、Guess中比较能体现。
2.1 更好的发挥大数据框架的能力
- 宽表可以更好地利用大数据框架，宽表用数据数据冗余避免很多的“额外”关联、节点服务器、集群之间的通讯资源、负载均衡软硬请求。
2.2 提高开发效率
一般情况下，宽表包含了很多相关的数据。如果在宽表的基础上做一些业务场景的数据应用开发，就很方便。可以直接从宽表里面取数据，避免每次从ODS层开始，从头计算。
2.3 提高数据质量
- 宽表的准确性，一般都经历了业务管理系统实践、时间检验，逻辑错误的可能性很小，可以直接使用。如果是从头开发，在这个过程中，有极大可能因为对业务理解不透彻，或者书写的逻辑不正确，导致结果数据驴头不对马嘴的交付问题。
2.4 统一指标口径
- 如果报表都能从底层宽表出，那么报表指标肯定是一样的。在数仓建设过程中，经常会遇到同一个指标口径不一致，导致抽数据在不同的出口不一样，这是业务部门经常诟病的一个数据口径不一致问题。
3. 宽表模型的不足
3.1 数据冗余较多
由于把不同的内容都放在同一张表存储，宽表已经不符合三范式模型设计规范，随之带来的主要坏处就是数据的大量、重复冗余和成本投入。
3.2 性能不高
由于宽表计算逻辑往往很复杂，再加上宽表数据输入有大量依赖。需要处理的数据量很大，在负载逻辑+数据存储量大的情景下，导致宽表往往运行效率不高，资源常态占用很高，尤其是在数据重跑的时候。
3.3 稳定性不高
- 一般一个系统的稳定性取决于最差的一个环节或部件，遵循木桶理论。
- 宽表的稳定性很差，主要是因为宽表依赖“源表”、“中间表”太多，每一个表的不稳定性都会传到宽表。
3.3 开发难度大/维护成本高
- 宽表的可用性与业务的变化速度成反比，宽表越复杂，越没人愿意去优化那些可能带来极大业务风险的宽表。因为业务本身逻辑繁多，异源异构的库表字段映射的逻辑很复杂，对于不懂业务的数据工程师来说，数据平台设计挑战巨大。并且，由于业务逻辑的随时变更，也需要随时响应跟进、持续维护、映射字段之间复杂的物理逻辑。
- 业内的普遍做法是基于宽表做顶层的报表设计，但是宽表也是由底层的开发人员开发，本身的逻辑也很复杂，所以一旦涉及到业务逻辑的变更也就是要去维护复杂的逻辑，宽表的内部sql逻辑可能涉及到几千行的代码，可能是由数个开发人员协调完成，人员的变动和离职都以为着维护成本的加大，甚至上层业务逻辑的改变，也会影响到最后的数据质量，这时候我们只能祈祷完备的代码注释能够帮助我们第一时间发现问题。
4. 宽表模型设计原则
核心原则：宽表不应该包含不属于它所在域的数据。
4.1 主次分离
- 主次分离式的拆分，可以确保聚焦表主题域，确保单一主题域不随着项目推进而产生走形变样。
- 对于数仓开发人员而言，可以简单、可靠、敏捷的智能维护、对于终端用户，也可以更加清楚的理解这张宽表的业务观点和视角。
- 例如：
- 做一张会员域下会员基本信息宽表，专注的肯定就是基本信息，作为主数据管理，将不同应用调用的会员信息做强一致性打通。
- 当然，事实宽表可能还会冗余其他信息进来，当这样的信息越来越多的时候，这张表的业务域、数据域边界就越来越弱化，所以需要继续拆分。
4.2 冷热分离
- 假设有一张宽表，里面有200个字段，有30张报表在使用它，但是发现前面150个经常字段经常被使用，后面 50个字段只有一两张报表偶尔使用到。那么就可以做一个冷热分离，将宽表拆分。
4.3 稳定与不稳定分离
- 上面说的主次分离、冷热分离都可以提高稳定性，但并不是为了稳定性而分离的。
- 例如：
- 经常有这样的宽表，例如对金融客户在移动终端设备上的行为分析，通常，它依赖埋点数据。 但是埋点数据的特点就是高并发、高通量，单点业务价值密度低。量大导致“全量遍历”计算经常延迟。那么，宽表落库的及时性就会受影响，从而导致报表出表时间点设计受影响。但是，很多时候发现要出的报表，根本没有用过埋点计算出来的指标，或者是只用了一点点。
- 这时候，可以将其拆分，如果没有用到最好，如果用到了，那就后推，在报表主外键层面上做逻辑关联，这样，我们的埋点数据即使出不来，我们的报表数据、模型算法实现结果还可以看到。这也是一种用冗余确保稳定性的设计。
