EDW 金博尔 vs 英蒙

Posted 2023-03-29

【中文标题】EDW 金博尔 vs 英蒙

【英文标题】：EDW Kimball vs Inmon

【发布时间】：2016-12-12 22:42:56

【问题描述】：

我的任务是就如何进行 EDW 提出建议，我正在寻求澄清我所看到的内容。我所了解的一切都表明，与 Inmon 相比，Kimball 的方法将更快地为企业带来价值。我知道 Kimball 的方法是从 getgo 开始的维度模型，不同的数据集市（星型模式）通过一致的维度集成......因此理论上我可以简单地提出我的直接 DM 来解决业务需求并从那里继续.

我正在学习的内容表明，Inmon 的模型表明我有一个在 3NF 中设计的 EDW。 EDW 不是由源系统定义的，而是由业务结构、企业工厂（订单、人力资源等）定义的。因此，来自不同系统的数据映射到这种结构中。一旦数据采用这种形式，就会创建 ETL 以生成 DM。

我个人觉得 Inmon 的方法是更好的方法。我相信这种方式将确保数据保持一致，并且感觉您可以使用这些数据做更多事情。不过，这种方法让我望而却步的是，我读到的所有内容都表明，交付某些东西需要更多时间，但我不知道这是怎么回事。从我的狭隘观点来看，无论最终结果如何，我们都需要一个 DM。无论使用 Kimball 或 Inmon 的方法，最终结果都是相同的。

那么问题就变成了我们如何到达那里？在 Kimballs 方法中，我们将创建 ETL 到某个暂存位置，并且通常从那里创建一个 DM。在 Inmon 的方法中，我觉得我们只是添加了另一层……即从暂存区域，我们将这些数据加载到按功能组织的 3NF 中的另一个数据库中。我缺少的是这一步如何增加这么多时间。

我觉得我可以看看需要制作的最终 DM。将它们映射回 3NF 中的 DW，然后随着越来越多的 DM 被请求，继续使用越来越多的数据在 3NF 中构建 DW。但是，如果我在 Kimballs 模型中创建一个 DM，那么 DM 将围绕为该 DM 决定的粒度级别构建，如果下一个 DM 要求以更深的粒度进行报告怎么办（对我来说，感觉 Kimballs 方法需要更多工作）和Inmon的没关系。我拥有跨国级别的一切，因此需要不同谷物的 DM，我有数据，只需将其 ETL 给 DM，所有 DM 都会报告相同的数据，因为它们来自相同的数据。

我不知道...只是在寻找其他人的观点。我读到的所有内容都说金博尔的更快……我说肯定可能有一点，但走更快的路线肯定会产生成本。为了争论起见……假设让 DM 启动并运行 Kimballs 方法需要一周的时间……对我来说，使用 Inmon 的方法应该只需要 10% 甚至 20% 的时间。

如果有人对不同模型有任何实际经验，并且如果一个模型真的比另一个模型需要更长的时间...请分享。或者如果我有这个倒退也告诉我！

【问题讨论】：

不知道为什么这被否决了。没有评论，我想我们永远不会知道。如果您认为 OP 犯了错误，请告诉他/她，以便他们解决。

我想提供另一种我们成功使用的方法：使用 Data Vault 2.0 作为主要的 DWH 建模技术。它易于理解、可扩展、非常灵活……尤其是对于非常复杂的企业 DWH，我会不惜一切代价避免仅使用 Kimball 的方法（如果存在复杂的系统环境会变得非常昂贵）并实现另一个层，在我们的案例基于 Data Vault。

【参考方案1】：

对于上下文；我为一家大型跨国公司管理 30 亿条记录的数据仓库。我们的数据从各种源系统通过分期进入 3NF 数据库。从这里我们的 ELT 流程将数据移动到维度建模的星型模式数据库中。

如果我可以重新开始，我肯定会放弃 3NF 步骤。当我第一次构建该层时，我认为它会增加真正的价值。我确信标准化会保护我的数据的完整性。我同样相信 3NF 数据库将是运行大型/复杂查询的最佳场所。

但在实践中，它减缓了我们的发展。大多数更改都需要更新阶段、3NF 和星型模式数据库。

额外的层还增加了发布数据所需的时间。额外的转换、检查和对账全部加起来。

承诺的完整性改进从未实现。我现在意识到，因为我控制了 ETL 和其中的验证过程，我可以确保我的数据既非规范化又准确。在报告数据时，我们控制每个表格中的每个单元格。我越想越觉得这是一个真正的机会。

大而复杂的查询是另一个被经验打破的神话。我现在看到需要编写复杂的报告查询是我的明星数据库的失败。当这种情况发生时，我总是问自己：为什么这个问题不容易回答？答案通常是糟糕的桌子设计。转换数据时最好执行繁重的工作。

运行 3NF 和星号也会为两个系统产生分歧的机会。当这种情况发生时，它通常是一个非常微妙的差异。就其本身而言，两者都没有错。相反，3NF 和星号查询可能会问略微不同的问题，因此返回不同的结果。尽管在技术上是正确的，但这可能很难解释。随着时间的推移，即使是微小且可解释的差异也会削弱信心。

为了保护我们的 3NF 数据库，它确实使加载到星形中变得更容易。但我很乐意将更复杂的 SSIS 包换成少一层。

说了这么多；如果没有深入了解他们的系统、要求、文化、技能等，很难向任何人推荐一种方法。阅读您的问题后，我相信您已经与所有这些问题作斗争，毫无疑问还有更多！最后，只有您可以决定哪种方法最适合您的情况。一旦你下定决心，坚持下去。一致性、清晰性和定义明确的方法比其他任何事情都更重要。

【讨论】：

我正在考虑使用 Inmons 方法将我们的 DM 群体与源系统隔离开来。而不是从源系统到 Kimballs 方法的更复杂的 ETL，有两个。一个到 Inmons 3NF，然后一个到 Inmon 到 DM。随着新的源系统上线，3NF 只有一个新的 ETL，从 3NF 到 DM 没有任何变化。然而，我越想这个……似乎这确实需要付出更多的努力。

感谢@destination-data 的发言，这种实战经验是金！

谢谢尼克。也喜欢你的回答。你提出了一些好的观点。 User3776554 -> 我应该补充一下，我可以看到中间层的一些好处，特别是如果它仅供内部使用。如果我确实删除了我的 3NF，我仍然需要维护一些表（用于白名单、黑名单、可接受的值查找等）。但是我可以用比今天少得多的桌子来完成所有这些工作。在这种情况下，我认为少即是多！祝你的项目好运。我相信您很快就会拥有出色的在线报告解决方案。

添加到我的+1，这是一个很好的答案，传递了实践经验

【参考方案2】：

维度和度量是向最终用户展示和简化数据的一种行之有效的方法。

如果您向最终用户展示基于源系统 (3nf) 的架构，而不是向最终用户展示维度建模的星型架构 (Kimball)，他们将能够更了解维度建模的架构

我从未真正研究过 Inmon 决策支持系统，但对我来说，它似乎只是完整数据仓库的 ODS 部分。

您说得对：“EDW 不是由源系统定义的，而是由业务结构定义的”。星型模式反映了这一点，但 ODS（源系统的副本）没有

星型架构比仅构建 ODS 需要更长的时间，但具有许多好处，包括

缓慢变化的尺寸可以跟踪随时间的变化 非规范化简化了连接并提高了性能 代理键允许您与源系统断开连接 一致的维度让您可以跨业务部门报告（即人均利润）

如果您的 Inmon 3NF 数据库不仅仅是一个 ODS（源系统的副本），而是某种实际的业务模型，那么您有两层可以建模：3NF 层和星型模式层。

如今，当每个人都认为他们可以在“自助服务”工具中完成所有工作时，即使是一层数据建模的好处也很难出售！ （我认为这是一个谬误）。你的系统不应该比它需要的更复杂，因为所有这些复杂性都会增加维护，这才是真正的问题——当你必须更改许多层时，在构建中引入更改 12 个月

套用@destination-data：您的源系统到星型模式的转换（和分离）已经通过ETL实现，所以3nf对我来说似乎是多余的。您可以通过正确实现代理键和业务键并将其建模在业务而不是源系统上来将星型架构设计为独立于源系统

【讨论】：

我不一定会考虑将 3NF 暴露给用户。我试图做的是将 DM 群体与我们的源系统隔离开来（尤其是如果它们似乎发生了很大变化）。我的想法是，通过使用来自 Inmons 3NF 的 ETL，可以抽象出该层（一旦设置，这些 ETL 就永远不会改变）。新系统上线...只需将其映射到 3NF...但是我越想这个我看到所有需要维护的额外步骤以及所涉及的工作量的好处...所以...

【参考方案3】：

由于 ETL 和后端数据处理占用了大约 70% 的项目时间，因此额外的一层会产生很大的不同。它是从源到目标的额外转换层，以同意业务并进行测试。这一切都加起来了。

虽然我并不是说维度模型（Kimball 类型）总是很容易更改，但如果您想更改 BI 时必须始终更改很多层，那么您会变得更加不灵活。

事实上，我一直在有数据仓库的地方进行咨询，这些地方的数据仓库被认为不灵活且开发成本高昂，并且跟不上业务变化的步伐，他们无一例外地包括了 3NF 层。 DM。正如 Nick 提到的，如今很难推销“合适的”数据仓库而不是 Data Discovery Bi 工具的想法——而这些工具的吸引力通常是因为 DW 被认为开发缓慢且成本高昂。

Kimball 并不反对在他的 DW 之前有一个 3NF 层，如果这对某种情况有意义的话，他只是不同意 Inmon 的观点。

一个常见的误解是 Kimball 提出了不同的数据集市，因此每次有不同的报告请求时您都必须更改它。相反，Kimball 的 DM 基于现实生活中的业务流程并进行了相应建模。虽然这是真的，但您将尝试使它们适合报告，但您尝试使它们能够回答可预见的查询。您不只是聚合和存储聚合：您在 Kimball 维度模型中处理事务数据。 所以从这个角度来看，没有必要不情愿。

如果 ODS 适合您，那就去尝试吧 - 但 Kimball DW 将满足大多数要求。