数据仓库考虑因素：何时以及为什么需要？

Question

数据仓库考虑因素：何时以及为什么需要？

databasedatabase-designdata-warehouse

51

一些背景知识:

我对数据仓库有一定的了解。我已经阅读了数十篇关于数据仓库的指南，并尝试使用SSAS进行操作。我知道什么是星型模式、维度表和事实表，知道ETL是什么以及如何实现。 这不是一个“如何”问题或者请求教程。

我的问题在于所有我所阅读的有关数据仓库的资料似乎都忽略了建立数据仓库的原因。它们通常从字面或者实际上开始于短语“所以你决定要建立一个数据仓库……”，然而我现在还没有做出这个决定。

因此，我希望Stack Overflow的成员能够指点我，或协助我设计一种半客观的测试方法。这样我便可以将它适应于特定的系统，并得到“是的，我们需要一个数据仓库”或者“不用，今天的回报太小”的结论。我认为我应该能够回答以下具体问题：

在什么时候考虑建立数据仓库？换句话说，哪些明显的迹象、指标或者其他标准应该引起我的注意，表明标准的事务环境已经不再足够？
什么是完全建立数据仓库的替代方案？在事务性数据库中去规范化和常规的复制“报告服务器”是其中两个，我应该在致力于数据仓库之前探索一下其他的选择吗？
为什么数据仓库比上述的替代方案更好？如果答案是“这要看情况”，那么它取决于什么？
在什么情况下不应该尝试建立数据仓库？我对任何宣称是“最佳实践”的事物都持怀疑态度，无论其上下文如何。肯定存在某些场景下数据仓库是错误的选择，请问哪些场景下是如此？

有没有实际的例子可以看，介绍引入数据仓库后系统改进的情况？我想要全面了解他们需要什么样的决策或分析来使用数据仓库，以及他们如何决定将什么放入其中，数据仓库最终是如何适应较大环境的？我不想要人为制造的“让我们从AdventureWorks数据库中创建一个立方体”之类的示例——对于我来说，实现并不重要，我感兴趣的是所涉及的规格和设计以及整体的思考过程。

我通常尽量避免问多个问题，但我认为这些问题都非常相关。我愿意接受至少回答前4个问题的任何答案，尽管最后一个问题确实会帮助我更好地理解这个问题。如果已经有人写过相关文章，链接也可以，只要它们足够简洁和具体（链接到Ralph Kimball的主页=没有帮助）。

希望我已经清楚地表达了问题 - 非常感谢您的答案！

- Aaronaught

7个回答

6

数据仓库的主要目的是加速（简化）报告和分析。它使商业用户可以以任何方式对数据进行切片和切块。
对于第一步数据仓库，您可以简单地实现Kimball星型模式并针对其运行SQL查询。如果这仍然太慢，请考虑预先计算的聚合（立方体）。
针对数据仓库的信息切片和切块比针对规范化数据库要简单得多。复制的报告服务器将提高性能，但不会简化切片和切块。还要记住，数据仓库属于商业用户，因此由他们随时提出各种切片/切块的想法——IT人员应该只提供这种环境。
如果您只是偶尔从操作系统中运行几个报告，并且对性能感到满意，则无需使用数据仓库。
我的所有经验都是与商业用户无休止地抱怨报告缓慢和无法编写“复杂查询”的系统有关，而生产人员则抱怨由于报告而使数据库变得拥挤。在所有情况下，一个简单的Kimball星型和具有缓存和快照的报告服务器就足够了。

- Damir Sudarevic

3

当以下两个条件中的两个符合时，您应该考虑构建数据仓库：
- 大量数据
- 许多复杂的查询（可能与少量插入、更新和删除相比）需要执行时间太长（并且编写起来很复杂）
- 需要合并来自不同系统的数据
实际上问题在于您如何考虑数据仓库。在许多情况下，您可以逐渐从带有一些报告的OLTP系统转移到完整的数据仓库，只要您能坚持使用关系型数据库管理系统。首先可以构建第一个事实表，并继续使用标准化表作为维度。然后添加更多的事实、更多的事实表或专用的维度表。首先在同一个数据库中（或相关系统的一个数据库中），可能稍后移动到单独的数据库。
完整的数据仓库（单独的数据库、星型模式）除了转向专业系统外，提供了调整选择语句的最佳选项。它还与OLTP系统彻底分离。考虑模式设计，以及资源（例如CPU、I/O和内存）和组织（例如新发布的调度）。当然，这是一项可能不需要的工作。
在上面的答案中已经提到：仅因为您有一些复杂的查询，不意味着您应该构建DWH，同样适用于其他标准，如果它们是孤立的。
这里不能提供太多建议，但是请采用敏捷方法。对DWH的要求极大地取决于用户所看到的可能性。因此，要求可能会发生变化。使用数据库自动化测试很痛苦，但在没有适当测试的生产系统中胡乱操作更糟糕。

- Jens Schauder

2

何时考虑构建数据仓库？换句话说，有哪些明显的迹象、指标或其他标准表明标准事务环境已不再足够？我建议在您观察到在事务数据存储中执行报告和分析活动对两者都有害时使用数据仓库。

除了完整的数据仓库之外，还有什么选择？在事务数据库中进行去范式化和基本的复制“报告服务器”是其中的两个，我应该在承诺DW之前探索其他任何东西吗？

我这里没有其他建议。无论是否称其为仓库，保留事务和报告数据库似乎对我来说都是合理的。数据挖掘可能是一项非常消耗CPU的活动。

为什么数据仓库比上述替代方案更好？如果答案是“取决于”，那么它取决于什么？

我这里没有其他建议。

什么情况下不应尝试构建数据仓库？我对任何声明为“最佳实践”的东西持怀疑态度，而与上下文无关。肯定有一些场景不适用于DW - 它们是什么？

我会说，如果您不需要保留长时间的历史记录，不进行数据的深入分析，并且您的报告需求仅限于偶尔的自适应查询，那么也许不需要数据仓库。

是否有任何实际的示例可以让我查看引入数据仓库后改进的系统？某些内容将向我解释他们需要仓库进行哪些决策或分析，他们如何决定放入其中的内容以及仓库最终如何适合更大的环境？我不想要一个人为的“让我们从AdventureWorks数据库制作一个立方体” - 实现对我来说无关紧要，我感兴趣的是涉及的规格、设计和整体思考过程。

我的雇主在我到达之前就使用数据仓库多年，因此我无法说明在我到达之前的情况。

- duffymo

2

根据我的经验，开始考虑数据仓库的第一个信号是当您拥有（或正在开发）事务性数据库时，用户开始添加大量报告和数据历史需求。这几乎总是如此。拥有单独的数据仓库或报告数据库总是比尝试设计处理最终用户始终需要的报告需求的事务系统更容易。在事务系统中存储历史记录（针对业务实体）会增加复杂性并使应该尽可能响应的数据库膨胀。

另一方面，我曾经在大公司中工作，许多组创建了数据仓库，因为感兴趣的数据分散在许多系统中，因此难以查询。问题在于每个组都创建了自己的数据仓库，因为公司中所有现有的仓库都没有正确的信息子集，或者具有被认为是非最佳或不正确的数据模型。这通过创建更多难以比较的不同数据系统使情况变得更糟。

- goheen

0

如果一个人长期使用“事务性系统”，那么可以考虑使用DW。后来，他们意识到需要进行一些数据挖掘，以确定业务的不同数据模式。最后，借助确定的数据模式，希望能够帮助高层管理层做出进一步有利于公司的决策。

构建数据仓库需要采取以下步骤：

需要选择ETL平台和数据库。
需要选择报表工具，如SSRS、Tableau等，用于可视化。
可以选择数据分析语言R进行进一步使用。
最终，所有这些将有助于开发数据仓库和报表工具。

- Deepesh Tiwari

-1

我认为为什么有些项目会失败呢？

主要有以下五个原因：

IT部门和业务用户之间缺乏合作伙伴关系；
数据仓库架构不正确；
没有足够经验的人员；
计划不当，例如未使用经过验证的方法和计划以确保不遗漏任何细节；
依赖于尖端技术。

- Jayron Soares

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- Data Monk · Accepted Answer

我会尽力简要回答您的问题：

1.什么情况下建立数据仓库是值得考虑的选项？换句话说，有哪些告示牌、指标或其他标准应该引起注意，可能表明标准事务环境已不再足够？

a. 如果您发现报告和监控正在影响生产系统和/或离线数据存储的性能。

b. 如果您发现回答业务问题需要每次构建大量复杂的 SQL。

c. 如果您发现每次更改事务模式，都必须返回并重新处理所有报告查询。

d. 如果您想要汇集来自多个来源的数据。

2.除了全面数据仓库之外，还有哪些选择？在事务数据库中进行去规范化和常规复制的“报告服务器”是其中两个，在承诺DW之前，是否还有其他选择？

3.为什么数据仓库比其它选择更好？如果答案是“取决于”，那么取决于什么？

我会一起回答这些问题。我不认为数据仓库是一个全面的冒险。它只是一个简洁的短语，意思是“以一种让您更轻松、更快速地回答业务问题的方式存储您的数据。”

事务数据库旨在有效地与应用程序接口。数据仓库、数据集市、运行数据存储和报告表被构建为有效地与人交互，如果这有意义。

4.何时不应尝试构建数据仓库？我对任何宣布为“最佳实践”的东西持怀疑态度，不考虑上下文。肯定有一些场景，DW不是正确的选择 - 它们是什么？

好问题。如果您的事务系统为您提供了足够的业务洞察力，您可能不需要仓库。

如果您只有一种数据来源且性能不是问题，那么您可能可以通过创建简单的报告表来获得洞察力。

5.有没有任何实际的例子可以展示引入数据仓库后提高了哪些系统的效率？我想要一个从头到尾解释他们需要什么样的决策或分析，他们如何决定要放什么，以及数据仓库最终如何适应更大环境的东西。我不希望是人为制造的“让我们用AdventureWorks数据库制作一个立方体” - 实现对我来说并不重要，我对涉及的规格、设计和整体思考过程感兴趣。

这是一个庞大的问题，超出了我在此处可提供的空间。

在这个问题上，我可以指向一些可能提供您所需洞察的地方。

Bruce Ullrey的《实施数据仓库：一种有效的方法》记录了一个人构建数据仓库的旅程。这本书并不是非常精致，因此更具现实感。它读起来像一本日志，有很多模型和其他视觉材料，很好地说明了他的努力。
Larissa Moss的《商业情报路线图》。标准的内容，以高层次指导您构建商业情报实践的过程。
Steve Williams的《商业智能的利润影响》提供了许多案例研究，展示了构建数据仓库的价值。