Snowflake 云数据仓库中的多个数据集市架构/建模答案

【问题标题】：Multiple Datamarts Architecture / Modeling on Snowflake cloud datawarehouseSnowflake 云数据仓库中的多个数据集市架构/建模
【发布时间】：2019-01-06 19:39:39
【问题描述】：

上下文：

假设我们有多个数据集市（例如：人力资源、会计、营销......），并且它们都使用星型模式作为维度建模（Kimball 方法）。

问题：

由于 Snowflake 云数据仓库架构消除了分离单独的物理数据集市/数据库以保持性能的需要。那么，在 Snowflake 上构建多个数据集市的最佳方法是什么？

为每个数据集市创建数据库？创建一个具有多个架构的数据库（EDW），每个架构都引用一个数据集市？

谢谢！

【问题讨论】：

标签： schema data-modeling data-warehouse snowflake-cloud-data-platform datamart

【解决方案1】：

根本不需要单独的星型模式。

如果您在您的市场中使用共享/一致的维度，那么分离实际上是一种反模式。

如果您的问题是简化用户的隔离，那么每个市场的架构效果很好。

您建议的所有方法（DB/mart、DW/schema、...）都可以，我只是不清楚需要。

【讨论】：

你好@Ron Dunn，谢谢你的回答！所以，实际上，我的需要是简化用户的隔离/对数据的访问，以及如何使用雪花云仓库的最佳方法来实现它。因此，最好的方法是一个数据库 (DW)，其中包含所有业务单元（人力资源、营销、会计......）的所有数据集市表（事实和暗淡），并且这些数据集市由模式分隔，用于每个数据集的逻辑分组mart objects 最好的问候，Amine

【解决方案2】：

Ron 是正确的 - 答案取决于几件事：

如果有一致的维度，那么一个数据库和架构可能是要走的路
如果它们是完全非集成的数据集市，我会使用单独的模式甚至单独的数据库。它们都是 Snowflake 中的逻辑容器（而不是物理容器），具有可用于隔离用户的完全基于角色的访问控制。

真的 - 你今天是怎么做到的？这对您有用吗，或者您需要或想做的事情是您今天无法使用当前的物理设置完成的。您的 BI 工具如何设置安全性？它们是引用数据库名称还是仅引用模式名称？如果可以的话，尽量减少对数据管道和报告的更改，以减少可能需要重构的东西（至少对于您的第一个 POC 或迁移而言）。

需要注意的一点是，使用 Snowflake，您可以轻松地进行跨数据库连接（即 database.schema.table） - 您只需要 SELECT 访问权限，因此即使您通过数据库 oyu 分隔集市仍然可以如果需要，做跨市场报告。

希望对您有所帮助。

【讨论】：

肯特您好，感谢您的回答！实际上，我们正在从头开始构建我们的 BI 平台/数据管道，我们的需求是简化用户的隔离/对数据的访问。我选择了选项 1 一个数据库 (DW)，其中包含所有业务单位（人力资源、营销、会计......）的所有数据集市表（事实和暗淡），并且这些数据集市由架构分隔，用于每个的逻辑分组集市对象。谢谢
您可以避免星型模式的跨数据库连接的一个小原因是它限制了您在 BI 工具中的发现。当您通过工具 UI 选择表时，通常仅限于一个数据库和/或架构。
事后思考：您可以解决跨数据库实现的视图的可发现性问题。

【解决方案3】：

拥有独立数据集市的目标更多地与治理、保持数据井井有条以及预期可以找到的位置（即“销售数据集市”中的销售交易）相关，而与性能问题的相关性较小。

将单个数据库用作数据仓库的优势在于，您用于分析的所有数据都将存储在一个位置，使其更易于访问和查找。在这种情况下，您可以使用模式来实现（逻辑上）单独的数据集市。对于每个数据集市，您还可以使用数据库中的模式将开发数据与生产数据分开。

Snowflake 不同于传统的关系型数据库；鉴于其技术架构，在不同的数据库/模式之间连接大型表没有问题，因此您当然可以在不同的数据库中构建不同的数据集市，并将它们的事实或维度与其他一些 Snowflake 数据库/数据集市连接。

在您的特定情况下，如果您有大量数据集市（例如 10 个或更多）并且您使用 Snowflake 的目的不仅仅是数据仓库，我认为最好的方法是在它自己的数据库并使用模式来管理每个模式中的产品/开发数据。这将有助于保持数据井井有条，而不是快速达到在一个数据库中拥有数百个表（每个数据集市及其开发/产品版本）的程度，这不会是一个很好的开发或维护体验。

但是，从性能的角度来看，并没有明显的区别。

【讨论】：