列式数据库中的数据建模与多维模型相比，可用于报告

如何解决列式数据库中的数据建模与多维模型相比，可用于报告

在学习Redshift（我的第一个列式数据库）的方式中，我正在努力找出设计模型的方法。柱状数据库确实促进了平面表设计，但承认在某些情况下星型模式或雪花可能是更好的选择。

这是我在哪里挣扎的简单例子

如您所见，多维方法几乎没有维，只有1个事实表。我本可以使它成为雪花设计，但对于星型架构却保持简单。

方法1：表中使用的公共列（在这种情况下，人口统计信息）。这样可以减少“客户和商店”的表格大小，但会包括额外的维度。

方法2：具有所有列的平板设计

我的问题：

数据建模者在Redshift等列数据库中使用哪种方法来设计数据模型？还是他们使用不同的方法？
考虑这个示例，为数据仓库设计数据模型的最佳方法是什么。
哪种方法最适合报告（考虑到客户端PC \ Laptop的内存有限）。甚至当使用大量数据集时，甚至云报告也可能变得昂贵。方法3将产生大量数据集以进行报告。如果进行报告（使用Power BI或Tableau或任何其他自报告工具），这可能是一项代价高昂的事情。多维方法最适合于自我报告（成本和性能），但是却违反了柱状数据库的目的。方法1同样适用于报告，但具有更多的联接和复杂性。

解决方法

对不起，晚到了聚会。

我将发布答案作为答案，因为评论太长了。

我在聊天中看到测试结果表明星型架构更好。但是它是在常规（MSSQL）而非列式数据库（如vertica，redshift，snowflare，bigquery ..）上进行测试的。

从项目实施中获得了一些经验，我测试了两种方法-OBT和星型模式，同时实现了dwh进行报告。这已经超过2年了，所以不要指望太多细节。数据库：dc2.8xlarge的Redshift 2个节点。可能有点过大，但是另一种选择是拥有一堆较低级别的节点，这不会更具成本效益。此示例仅用于一个数据区域。

数据：〜6个表，可以像星型模式一样进行连接。包含3个事实表，并基于非规范化级别5-8维度。

在采用星型模式的情况下，采用各种方法和不同的优化路径通常会达到30秒钟左右的SQL时间。这还不错，但从用户角度来看也不太敏感。平面非规范化事实表上的SQL很少超过5秒。有些表包含超过100列，行数在50M和100M之间。为了避免过于复杂，我们对所有列使用zstd压缩。在列式数据库中，数据压缩非常好，因为在单个列中使用了许多相似或相同的值。

我们采用OBT表方法，但有一些优点和缺点：

优点：

报告工具中的响应报告（最重要的一个）
更少的对象可供ETL开发人员处理。
直接查询数据库的分析师可以使用更少的表来创建更简单的查询。
如果某些维度已过时，则不必担心数据不一致，这可能会在星型模式中发生。
更简单的报告工具缓存清除方法。
更轻松地调整报告性能。
在报表工具中简化建模，不需要定义表连接策略。

缺点：

可能占用更多空间。由于存储空间对我们来说不是问题，因此并未对此进行严格的测试。
报表工具中的过滤器可能需要更长的时间才能提供值列表（从表中选择不同的one_column）
与多个较小的表相比，一个大表的表刷新可能需要更长的时间。

希望这会有所帮助。