大数据仓库还需要星型模式吗？

Posted 2023-03-29

【中文标题】大数据仓库还需要星型模式吗？

【英文标题】：Is star schema still necessary for a big-data-warehouse?

【发布时间】：2015-06-13 22:07:28

【问题描述】：

我正在使用 hive 设计一个新的基于 hadoop 的数据仓库，我想知道经典的星形/雪花模式在这种情况下是否仍然是“标准”。

大数据系统包含冗余，因此完全规范化的模式通常性能较差（例如，在 HBase 或 Cassandra 等 NoSQL 数据库中）。

使用 Hive 创建星型模式数据仓库仍然是最佳实践吗？

利用新的列文件格式设计行宽（冗余）表是否更好？

【问题讨论】：

如果我们谈论的是现代大数据 DWH，为什么不使用 Amazon Redshift？

你应该写下你的事实和暗淡

【参考方案1】：

在设计 NoSQL 数据库时，您倾向于通过预处理部分查询来优化特定查询，从而存储数据的非规范化副本（尽管以特定查询的方式非规范化）。

另一方面，星型模式是一种通用的非规范化，通常是合适的。

当您计划使用 hive 时，您实际上并没有将其用于优化，而是用于 SQL 的通用性 (?)，因此，我认为星型模式仍然合适。但是，对于具有非 SQL 接口的 NoSQL 数据库，我建议您使用更特定于查询的设计。

【参考方案2】：

联接是邪恶的。特别是在 Hadoop 上，我们无法保证数据的共存性，尤其是在我们需要连接两个大表的情况下。这是 Hadoop 与传统 MPP（如 Teradata、Greenplum 等）之间的差异之一。在 MPP 中，我基于散列键将数据均匀分布在集群中的所有节点上。 order 和 order_item 表的相关行最终会在我的集群中的相同节点上，这至少会消除跨网络的数据传输。在 Hadoop 中，您可以将 order_item 数据嵌套在 order 表中，这将消除对连接的需要。

另一方面，如果您有一个小的查找/维度表和一个大的事实表，您可以在集群中的所有节点上广播小表，从而消除网络传输的需要。

总之，星型模式仍然是相关的，但主要是从逻辑建模的角度来看。从物理上讲，您最好进一步去规范化以创建一个大的列压缩和嵌套事实表。

我写了一篇完整的博客文章，讨论了dimensional models on Hadoop and Big Data technologies 的目的和用途