这里有一点背景：
我知道what a data warehouse is，或多或少 . 我用SSAS玩了，我知道星型模式和维度表以及事实表是什么，我知道ETL是什么以及如何做到这一点 . This is not a "how" question or a request for tutorials.
我的问题是，我读过的关于数据仓库的所有材料似乎都掩盖了构建数据仓库的基本原理 . 它们都具有象征性，或者在某些情况下字面上以“所以你决定 Build 一个数据仓库......”这句话开头 . 除了我还没有做出那个决定 .
因此，我希望SO成员可以指出或帮助提出某种半客观测试 . 我可以适应特定系统并最终得到“是的，我们需要一个数据仓库”或“不，今天的收益太小了” . 我认为我应该能够回答的具体问题是：
-
在什么时候构建数据仓库值得考虑？换句话说，我应该注意哪些标志，指标或其他标准可能表明标准的交易环境不再足够？
-
全面数据仓库有哪些替代方案？事务数据库中的非规范化和沼泽标准复制的“报告服务器”是我想到的两个;在进入DW之前，还有其他我应该探索的吗？
-
为什么数据仓库比上述备选方案更好？如果答案是“它取决于”，那么它依赖于什么？
-
shouldn't 我试图 Build 一个数据仓库？无论背景如何，我都对所谓的"best practice"持怀疑态度 . 肯定有一些情况下DW是错误的选择 - 它们是什么？
-
有没有 practical 例子我可以看一下通过引入数据仓库改进的系统？可以向我解释的东西，端到端，他们需要仓库的决策或分析，他们如何决定放入什么，以及仓库最终如何适应更大的环境？我对所涉及的规格和设计以及整体思维过程感兴趣 .
我一般不会问多方，但我认为这些都是非常密切相关的 . 我愿意接受至少解决前4个问题的任何答案，尽管最后一个问题确实有助于在我的脑海中明白这一点 . 如果有人已经写过关于这一点的链接很好，只要它们相当简洁和具体（链接到Ralph Kimball的主页=无用） .
希望我已经明确了问题 - 提前感谢你的答案！
7 回答
根据我的经验，开始考虑数据仓库的第一个标志是当您拥有（或正在开发）事务数据库并且用户开始添加大量报告和数据历史记录要求时 . 这几乎总是如此 . 拥有一个单独的数据仓库或报告数据库比尝试设计一个处理最终用户始终拥有的报告需求的事务系统更容易 . 在事务系统中存储历史记录（用于业务实体）会增加复杂性并使数据库膨胀，该数据库应尽可能响应 .
另一方面，我一直在大型公司中，许多团队创建数据仓库，因为感兴趣的数据分布在许多系统中，因此难以查询 . 问题是每个组都创建了自己的数据仓库，因为公司中的所有现有仓库都没有正确的信息子集，或者数据模型被认为是非最佳或不正确的 . 通过创建更难以比较的不同数据系统，情况变得更糟 .
我会看看我是否可以尽力回答你的问题 .
一个 . 如果发现报告和监视会影响 生产环境 系统和/或脱机数据存储的性能 .
湾如果您发现获得业务问题的答案需要每次都构建大量复杂的SQL .
C . 如果您发现每次对事务架构进行更改时，都必须返回并重新编写所有报告查询 .
d . 如果您想汇集来自多个来源的数据 .
我会一起回答这些问题 . 我不认为数据仓库是一个全有或全无的冒险 . 它只是一个简洁的短语，意思是“以一种允许您更轻松快速地回答业务问题的方式存储您的数据 . ”
事务数据库旨在有效地与应用程序进行交互 . 如果有意义的话，数据仓库，数据集市，运营数据存储和报告表可以有效地与人们进行交互 .
好问题 . 如果您的交易系统为您提供了足够的业务洞察力，那么您可能不需要仓储 .
如果您只有一个数据源并且性能不是问题，那么您可以通过创建简单的报表来获得洞察力 .
这是一个很大的问题，比我在这里分配的空间要多得多 .
在这一点上，我可以指出一些可能提供您所寻求的洞察力的地方 .
布鲁斯·乌瑞（Bruce Ullrey）撰写的一本书记录了一位没有高度抛光的男人，这使得它更加真实 . 它读起来就像一本有大量模型和其他视觉效果的期刊，很好地说明了他的努力 .
由Larissa Moss撰写的
Steve Williams撰写的
DW的主要目的是加速（简化）报告和分析 . 它可以以业务用户可以想到的任何方式切片和切割数据 .
对于第一步DW，您只需实现一个Kimball星型模式并对其运行SQL查询 . 如果这证明仍然太慢，请开始考虑预先计算的聚合（立方体） .
针对DW的信息切片和切割比标准化DB更简单 . 复制的报表服务器将提高性能，但不会简化切片和切块 . 另外请记住，DW属于业务用户，因此他们可以随时提出各种切片/骰子的想法 - IT人员应该只提供这样的环境 .
如果您只是在操作系统上不时运行少量报告并且对性能感到满意，则不需要DW .
我所有的经验都是系统，业务用户无休止地抱怨报告缓慢和无法编写“复杂查询”，而 生产环境 人员则抱怨数据库因报告而陷入困境 . 在所有情况下，简单的Kimball星和具有缓存和快照的报表服务器都足够好 .
当满足以下两个条件时，您应该考虑构建数据仓库：
大量数据
许多大型复杂选择（可能与少量插入，更新和删除相比）只需要很长时间才能执行（并且编写起来很复杂）
来自不同系统的数据需要合并
这是您认为数据仓库的问题 . 在许多情况下，只要您可以坚持使用关系数据库管理系统，就可以逐步从具有某些报告的OLTP系统移动到完整的数据仓库 . 首先可以是构建第一个事实表，并继续使用规范化的表进行维度 . 然后向游戏添加更多事实，更多事实表或专用维度表 . 首先在同一个数据库（或所涉及系统的一个数据库）中，可能稍后转移到单独的数据库 .
完整的数据仓库（单独的数据库，星型模式）提供了调整选择语句的最佳选项，除了转到专门的系统 . 它也与OLTP系统完全分离 . 考虑架构设计，还有CPU，I / O和内存以及组织等资源，例如新版本的安排 . 当然，你可能不需要做很多工作 .
这是上面的答案：只是因为你有一些复杂的查询，并不意味着你应该 Build 一个DWH，如果它们是孤立的，那么其他标准也是如此 .
这里不能提供太多，但建议：敏捷 . DWH的要求极大地取决于用户看到的可能性 . 需求可能会发生变化 . 使用数据库自动化测试很痛苦，但在 生产环境 系统中却无所适从没有适当的测试更糟糕 .
当您发现在事务数据存储中执行报告和分析活动对两者都有害时，我建议使用数据仓库 .
我在这里没什么好提的 . 我要说保持交易和报告数据库对我来说似乎是明智的，无论你是否称它为仓库 . 数据挖掘可能是一项非常耗费CPU的活动 .
我在这里没什么好提的 .
我要说的是，如果您不需要保留很长的历史记录，不对数据进行深入分析，并且您的报告需求不时仅限于临时查询，那么数据仓库可能不是必要 .
我的雇主在我到达之前已经使用了多年的数据仓库，所以在我到达之前我无法说出事情是什么样的 .
如果一个人长期使用“交易系统”，可以考虑使用DW . 后来，他们意识到他们需要执行一些数据挖掘，以确定业务的不同数据模式 . 最后，在确定的数据模式的帮助下，人们希望帮助最高管理层做出有利于公司的进一步决策 .
需要采取以下步骤来构建数据仓库：
需要为数据库确定ETL平台和数据库 .
需要为可视化选择SSRS，Tableau等报告工具 .
可以选择像R这样的数据分析语言，以供进一步使用 .
最后，所有这些将有助于开发数据仓库和报告工具 .
“我认为为什么有些项目会失败？”
主要有五个原因：
IT部门与业务用户之间缺乏合作关系;
错误的数据仓库架构;
没有经验丰富的人;
不正确的计划，例如未使用经过验证的方法和计划以确保不遗漏任何细节;
并且取决于前沿技术 .