hive数据仓库中的建模方式，为什么选择这种建模方式？

Hive作为数据仓库，同关系型数据库开发过程类似，都需要先进行建模，所谓建模，就是对表之间指定关系方式。建模在hive中大致分为星型、雪花型和星座型。要对建模深入理解，首先需要对hive数仓中的几种表概念进行界定。hive中的表从形态上分内部表、外部表、桶表、分区表。在数据逻辑上划分为维度表和事实表。维度表等价于我们常说的字典表。事实表就是字典表之外的数据表。

1.1 星型模型

多张维度表，一张事实表，维度表之间没有关系。查询性能要好些,存储有冗余的。星型模型使用的比较多。

1.2 雪花型模型

雪花型是星型建模的扩展，维度表之间有关系。存储减少冗余，查询性能有损失，需要多级连接。和星型模型的共性就是只有一张是事实表。

1.3 星座型模型

星座型也是星型模型的扩展，存在多张事实表。

 

问题扩展

比如说某个业务系统的信息没有提供汇总表，而是新增一种新的业务，就需要新增一张数据表。我们统计业务量的时候，就要拿大几十张数据表进行关联，报表执行效率很差，后面就直接在数据仓库上帮源系统做了张新业务的汇总表，提高了后续报表的加工效率，也屏蔽了新增业务品种时对报表的影响。

这里我们可以结合我们能书仓管设计的基本特性来考虑，这里考虑的就是分层的概念：

1. 清晰数据结构
2. 数据血缘追踪
3. 减少重复开发
4. 把复杂问题简单化
5. 屏蔽原始数据的异常
6. 屏蔽业务的影响，不必改一次业务就需要重新接入

这里我们就可以依照这些概念，我们的哪些基本数据分到数仓层，再结合我们的业务需求逐层构建各个业务上的集市层；可以有效减少我们后期运营维护的各项成本；

 

（四）应用场景

星型模型的设计方式主要带来的好处是能够提升查询效率，因为生成的事实表已经经过预处理，主要的数据都在事实表里面，所以只要扫描实时表就能够进行大量的查询，而不必进行大量的join，其次维表数据一般比较少，在join可直接放入内存进行join以提升效率，除此之外，星型模型的事实表可读性比较好，不用关联多个表就能获取大部分核心信息，设计维护相对比较简答。

雪花模型的设计方式是比较符合数据库范式的理念，设计方式比较正规，数据冗余少，但在查询的时候可能需要join多张表从而导致查询效率下降，此外规范化操作在后期维护比较复杂。

（五）总结

通过上面的对比，我们可以发现数据仓库大多数时候是比较适合使用星型模型构建底层数据Hive表，通过大量的冗余来提升查询效率，星型模型对OLAP的分析引擎支持比较友好，这一点在Kylin中比较能体现。而雪花模型在关系型数据库中如MySQL，Oracle中非常常见，尤其像电商的数据库表。在数据仓库中雪花模型的应用场景比较少，但也不是没有，所以在具体设计的时候，可以考虑是不是能结合两者的优点参与设计，以此达到设计的最优化目的。