从头开始构建OLAP解决方案时，我应该考虑什么？

Question

我正在为一家运行基于MS SQL数据库服务器的软件产品的公司工作，多年来我用PHP开发了20-30个非常先进的报告，直接从数据库中获取数据。这非常成功，人们对此感到满意。

但它有一些缺点：

• 对于新的更改，它可能非常耗费开发
• 用户无法对数据进行多少实验 - 它被锁定为硬编码视图
• 大报告可能会很慢

我正在考虑逐步采用基于OLAP的方法，可以从Excel或某些基于Web的服务查询。但我想以一种在IT环境中引入最少量新复杂性的方式来做到这一点 - 最少量的不同服务，同步工作等等！

我在这方面有一些问题：

1）与工作流程相关：

• 从“黑匣子SQL服务器”到“OLAP准备就绪”的良好发展路线是什么？
• 应该设置哪些服务器和服务，以及应该编写哪些脚本？
• 哪些是最难/最关键/最耗时的部分？

2）ETL：

• 我想最好为他们的数据仓库和生产SQL提供单独的服务器？
• 这些如何保持同步（推/拉）？使用哪些技术/语言？
• 对我来说，SSIS看起来过于复杂，而且图形工作流程对我来说并不吸引人 - 我宁愿喜欢基于文本的脚本来完成这项工作。这可行吗？
• 或者仅使用一个源和一个目的地的图形客户端是否有利？

3）发展：

• 从CLI工具可以有效维护多少（数据集成，分析服务）？
• 可以轻松地在生产和开发之间来回切换设置吗？

我对任何涵盖其中一部分的答案感到满意 - 即使它是MS环境，我也有兴趣了解其他技术的优势。

Answer 1

Answer 2

你基本上问的是“如何构建DWH”的百万美元问题。这不是一个可以果断回答的问题。

然而，这是一个kickstart：

如果您正在寻找可行的最低产品，请注意您处于数据环境中，而不是纯软件。在数据繁重的环境中，逐步构建产品要困难得多，因为在系统中引入更改的工作量要大得多。想想看，就好像你在一个软件中做出的每一个改变都必须以某种方式向后兼容你曾经做过的任何事情。现在你了解微软所处的地狱:-)。

此外，数据系统涉及许多第三方工具，如DB，ETL工具和报告平台。您所做出的选择对于系统的预期开发应该是可行的，否则您可能需要完全替换这些工具。

虽然您可以从基于简单复制SQL的数据库克隆开始，然后将其聚合或将其推送到OLAP，但我建议您从一开始就使用真正的ETL工具。如果您预见到需要增长，情况尤其如此。 10次​​中有9次，需要 。

如果您不介意成本，MS-SQL是数据库的不错选择。自然ETL工具将是SSIS，它也是一个可靠的工具。

即使您的第一次转换仅仅是“将此表转储到那里”，您仍然可以获得很多流程管理（工作运行？如果失败会发生什么？等）和调试。此外，由于必须处理要求和/或特殊情况，因此更容易有机增长。