列式数据库中的数据建模与用于报告的多维答案

【问题标题】：Data modeling in columnar database vs multi-dimensional for reporting列式数据库中的数据建模与用于报告的多维
【发布时间】：2021-01-16 05:00:06
【问题描述】：

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

这是一个我正在苦苦挣扎的简单例子

如您所见，多维方法的维度很少，只有 1 个事实表。我本可以让它成为雪花设计，但我为星型模式保持简单。

方法 1：使用表格中的常用列（在此场景中为人口统计数据）。这可能会减少 Customer & Store 的表大小，但会包含额外的维度。

方法 2：包含所有列的平面表格设计

我的问题：

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

【问题讨论】：

否 - 多维不会破坏柱状报告的目的。您每次使用完全非规范化的平面表的唯一时间是您没有时间进行数据建模。我看不出有任何理由不使用星型模式。
有趣的问题。我一直认为星型模式基本上是一个平面表，它不情愿地允许与连接相关的性能损失作为一种节省磁盘空间的方法。不过，列式数据库以其他方式处理存储空间。所以，一张大平桌对我来说似乎是一个很好的方法。您应该尝试两者并发布您找到的查询性能。但是有一个问题：Redshift 表中的列数是否有限制？如果是这样，那可能会推动您的设计理念。
@Nick.McDermaid 但我看到有人推荐为列式数据库设计平面表。我也很困惑，因为我没有看到报告的好处，但是是的，我可以看到很大的存储节省（这对于云上的数据库很有意义）
@Ben 虽然 Redshift 说有 1,600 列限制，同时我听说他们说不要为了提高性能而制作大表（这对我来说没有意义，因为列式数据库都是关于列的，所以如何降低性能）。保留一个大表将大大降低存储和处理的成本，但我担心报告部分，因为它可能需要一个大数据集来处理？（我不确定报告工具如何从 redshift 中获取数据）
@Zerotoinfinity 我只是在考虑这个问题，并且在某些方面，列存储无论如何都会像星型模式一样工作 - 正如您所说，每列都作为自己的“表”实现.仅供参考，我不确定它如何影响您的情况，但我会避免 select * 查询 b/c 那些会迫使数据库将所有这些“列表”“加入”在一起。

标签： amazon-redshift data-modeling data-warehouse dimensions

【解决方案1】：

抱歉，聚会迟到了。

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

我在聊天中看到测试结果表明星型模式更好。但它是在常规 (MSSQL) 上测试的，而不是列式数据库（就像 vertica、redshift、snowflake、bigquery..）。

有一些项目实施经验，我在实施 dwh 报告时测试了这两种方法 - OBT 和星型模式。这已经是两年多前的事了，所以不要期望太多细节。数据库：dc2.8xlarge 的 Redshift 2 个节点。可能有点矫枉过正，但其他选择是拥有一堆较低级别的节点，这不会更具成本效益。此示例仅适用于一个数据区域。

数据：~ 6 个表，可以连接起来，有点类似于星型模式。包含 3 个事实表并基于非规范化级别 5-8 维度。

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

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

优点：

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

缺点：

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

希望这会有所帮助。

【讨论】：

感谢您对这个问题的深入了解。但是有一个问题，假设我们有一个产品销售 KPI，业务要求我们找出从未售出的产品。因为平面表只有销售的产品行，所以除非我们有产品维度，否则我们无法进行分析。也可能有其他情况。您是如何解决这些问题的？
我不会将未售出的产品列表称为 KPI。您描述的报告要求也不会通过星型模式来解决。您是否建议将维度作为驱动表和左连接事实表？那么你将无法使用任何其他维度。还是笛卡尔连接所有维度，然后连接事实表？我看到的唯一解决方案是为此目的在数据库或报告工具端创建自定义视图。然后客户要求报告哪些产品在 2018 年未售出，或者在某个国家/地区或任何其他组合中未售出。如果没有针对每种情况的自定义解决方案，我认为没有办法有效地做到这一点。