从头开始构建 OLAP 解决方案时我应该记住什么？

Question

我在一家运行基于 MS SQL 数据库服务器的软件产品的公司工作，多年来，我已经用 PHP 开发了 20-30 个相当高级的报表，直接从数据库中获取数据。这非常成功，人们对此很满意。

但它有一些缺点：

• 对于新的更改，它可能是开发密集型的
• 用户无法对数据进行太多试验 - 它被锁定在硬编码视图中
• 大型报告可能会很慢

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

我有这方面的一些问题：

1) 工作流程相关：

• 从“黑盒SQL服务器”到“OLAP即用型”有什么好的开发路线？
• 应该设置哪些服务器和服务，应该编写哪些脚本？
• 哪些是最难/最关键/最耗时的部分？

2) ETL：

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

3) 开发：

• 可以通过 CLI 工具有效地维护其中的多少（数据集成、分析服务）？
• 是否可以轻松地在生产和开发之间来回传输设置？

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

Answer 1

我只有 Microsoft OLAP 方面的经验，所以这里是我所知道的两分钱：

1. 如果您正在实施多维数据集，则将生产 SQL Server 与多维数据集的源分开。多维数据集需要大量的 SELECT DISTINCT column_name FROM source.table。您不希望多维数据集处理阻塞您的关键任务生产系统。

2. 虽然您可以使用标准关系表实现 OLAP 多维数据集，但您很快会发现，除非您的数据是分类帐式系统，否则您可能需要完全重新处理事实和维度表，这将需要重新查询源数据库一遍又一遍。这是构建一个使用分类帐样式事务处理事实表的单独数据仓库的一个重要论据。例如，如果客户订购了某物然后取消了它，您的源系统可能会将此作为状态更改进行跟踪。在您的事实表中，您可能需要将其显示为具有正数量和收入流的订购行和具有负数量和收入流的取消行。

3. OLAP 对您的环境来说可能是多余的。您似乎提出的主要问题是您的报告是静态的，用户希望直接访问数据。您可以构建数据模型并在 SSRS 中授予用户 Report Builder 访问权限，或者在 Cognos、Business Objects 等其他 BI 套件中授予用户报告编写访问权限。我通常不推荐这种方法，因为它超出了大多数用户应该拥有的范围要知道获取数据，但在小商店这可能就足够了，而且很容易实现。让我们面对现实吧——用户通常只想将数据导入 Excel 以进一步操作它。因此，如果您不想为他们提供 Web 前端，而只想让他们从 Excel 中获取数据，您可以让他们直接访问数据库以访问生产数据的副本。这种方法的缺点是用户通常不了解 SQL 或数据库关系。 OLAP 可帮助您避免强迫用户学习 SQL 或关系，但在您的最终实施并不容易。如果您只有几个需要这种访问权限的高级用户，那么教少数高级用户如何在 Excel 中对数据库进行基本查询可能很容易，他们明天会很高兴得到这个。 OLAP 明天还没有准备好。

4. 如果您只有几种源数据系统，您可以轻松构建超动态静态报表。例如，我有一个用 C# 编写的报告，它基本上允许用户从 30 列的列表中选择任意数量的列，并在几个日期范围字段和字段过滤器列表中过滤数据。这个简单的报告涵盖了来自最终用户的所有临时报告请求的大约 40%，因为它涵盖了所有基本的核心客户指标和字段。我们最近将此报告移至 SSRS，这使我们能够将字段数量增加到大约 100 个，并改善了整体用户体验。无论报告平台如何，即使在静态报告系统的范围内，也可以为用户提供一些动态灵活性。

5. 如果您只有几个数据库，您可以将数据库作为 ETL 进行备份和恢复。但是，如果您想做除此之外的任何事情，那么您不妨硬着头皮使用 SSIS（或其他一些 ETL 工具）。一旦您进入 ETL 进行数据仓库，您将使用面向图形的设计工具。编码适用于应用程序，但 ETL 更多的是关于工作流，这就是为什么这些工具倾向于集中在图形 UI 上的原因。您可以解决这个问题并尝试从文本编辑器编写数据仓库，但最终您会失去很多。 See this post for more details on the differences between loading data from code and loading data from SSIS。

关于如何使用具有关系数据存储的多维数据集的反馈

可以在关系数据存储上实现多维数据集，但使用这种方法存在一些主要问题。它在技术上可行的主要原因与您如何配置 DSV 有关。 DSV 本质上是物理数据库和多维数据集/维度定义之间的逻辑层。您可以定义命名查询或在数据库中创建视图以展平数据，而不是将关系表导入 DSV。

这种方式的优点如下：

1. 实施起来相对容易，因为您不必构建整个 ETL 子系统即可开始使用 OLAP。

2. 这种方法非常适用于制作您希望如何构建更长期解决方案的原型。您可以在 1-2 天内对其进行原型制作，并展示 OLAP 的一些优势。

3. 一些非常非常大的表不必为了支持 OLAP 多维数据集而完全复制。我有几个几乎完全标准化的事实表的数十亿行表。他们唯一没有的列是日期键，并且它们还包含一些根本不应该有空值的字段上的空值。您可以创建代理日期键并为视图或命名查询中的空值设置值，而不是复制这些非常庞大的表。如果您不会看到复制表的巨大性能提升，那么这可能是在数据库本身中保留更原始格式的候选者。

这种方式的缺点如下：

1. 如果您还没有构建真正的 Kimball 方法数据仓库，那么您可能没有以分类帐样式跟踪交易。 Kimball 方法事实表（至少据我了解）总是通过添加和减去行来更改值。如果有人取消了部分订单，您将无法更新多维数据集中的单笔交易值。相反，您必须用负值来平衡交易。如果必须更新事务，则必须完全重新处理多维数据集的分区以替换值，这可能是一项非常昂贵的操作。除非您的源系统是分类帐式交易系统，否则您可能必须在 ETL 子系统中构建分类帐式副本。

2. 如果您不构建 Kimball 方法数据仓库，那么您可能在数据库中使用了未模糊且可能非整数的主键。这直接影响多维数据集中的查询性能。它还使您拥有理论上不灵活的数据仓库。例如，如果您有一个使用整数键的产品订购系统，并且您开始使用第二个产品订购系统作为旧系统的替代品或与旧系统一起使用，您可能很难仅通过以下方式将数据组合在一起DSV，因为每个系统都有不同的数据点、指标、工作流、数据类型等。更糟糕的是，如果它们具有相同的订单 ID 数据类型并且订单 ID 值在系统之间重叠，那么您必须声明一个代理键，您可以跨两个系统使用。如果不使用扁平化数据仓库，这可能很难实现，但并非不可能。

3. 如果您从关系数据存储开始，然后迁移到扁平数据库，您可能需要构建两次系统。坦率地说，我认为重复工作的数量是微不足道的。您从关系数据存储中构建多维数据集所学到的大部分内容将转化为设置新的 OLAP 多维数据集。但是，主要问题是您可能会完全创建一个新多维数据集，然后旧多维数据集的任何用户都必须迁移到新多维数据集。任何在 SSRS 或 Excel 中构建的报告都可能会在此时中断，需要从头开始重写。所以重建多维数据集的主要成本实际上是重建依赖对象——而不是重建多维数据集本身。

如果您希望我对上述任何一点进行扩展，请告诉我。祝你好运。

Answer 2

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

尽管如此，这里是一个启动：

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

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

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

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

即使您的第一次转换只是“获取此表并将其转储到那里”，您仍然在流程管理（作业是否运行？如果它失败会发生什么？等等）和调试方面获得很多收益。此外，由于必须处理需求和/或特殊情况，因此更容易进行有机增长。