SQL 分析服务-SSAS

要考虑的最重要的平衡行为是，您对实时报告的需求是否超过了您的 OLAP 和 OLTP 系统直接将 OLTP 数据源用作事实表和维度表，然后弹回 ROLAP/HOLAP 查询所带来的性能损失他们中的。如果表都非常小，并且服务器负载不重，那么损失可能可以忽略不计。如果 SSAS 查询要启动 500MB+ 读取，那就是个问题。

除非您正在进行某种高频交易，否则您可能不需要让 SSAS 数据库保持最新状态。似乎 SSAS 对于大图类型的摘要更有用，如果过去几个小时的数据还没有包括在内，它不会对运行报告的人产生太大影响（显然，四处询问以确保).

我们每晚加载数据仓库并处理多维数据集，这通常足够了。我们还有一些针对 OLTP 表构建的简单报告，用于查看更有针对性的最新数据（本质上 OLTP 比 OLAP 更重要的数据）。

运营报告与分析报告

针对操作系统的临时报告不是一个好主意，因此答案取决于您的实时要求。

• 在大多数情况下，实际的实时要求是针对少数操作报告。这些通常不是汇总或统计性质的，往往是异常报告、状态报告或待办事项列表。他们通常不应访问大量数据，而是选择符合报告标准的特定记录。
  
  运营报告几乎总是与特定流程相关联，从本质上从不进行分析。通常，分析报告可以定期加载运行，不需要最新数据。有一些例外情况，例如市场数据提要，但这些都是例外情况。
  
  在这种情况下，您应该定期加载数据集市、数据提取或数据仓库系统以获取分析报告，并将运营报告构建为定制的、经过调整的报告。如果可能，在复制的数据库实例中运行它们以减少操作系统数据库上的瞬时负载。

• 某些应用程序确实需要将实时或近实时（低延迟）数据加载到分析系统中。此类要求的几个示例是市场数据分析系统或账户报告系统。在前一种情况下，交易员使用该系统对数据进行统计分析，而在后一种情况下，通常要求会计师能够准备和输入日记账，然后立即报告。
  
  这些实际上是经过伪装的运营报告，并且往往会将其 SLA 绑定到源系统。这些系统的一个共同点是它们往往对底层数据有一个相对简单的模型。

• 您可以使用查询底层模式的 ROLAP 工具来处理某些操作数据库。使用操作系统数据库执行此操作很少是一个好主意，因为它们往往不适合高效的聚合查询。
  
  我曾经用一个账户系统和一个报告模型完成过这个——理论上也可以使用一个多维数据集。Oracle 还为 Oracle Financials 提供了一个基于发现者的临时报告工具，其工作方式与此类似。然而，会计系统的本机数据模型实际上非常接近雪花模式，因此您可以避免这种情况。然而，报告往往很慢，如果加载，它们仍然会使系统陷入困境。

• 如果您真的想要对低延迟源进行临时分析，您可以构建一个填充数据集市的低延迟 ETL 过程。这种事情比传统的 ETL 过程更繁琐和复杂，因此您不想为没有真正需求的应用程序执行此操作。您可以在其上放置一个带有前导 ROLAP 分区的多维数据集，并将历史数据存储为 MOLAP。我参与了构建一个像这样工作的系统。

低延迟分析系统

根据您的数据源，您可以使用更改数据捕获机制或轮询机制来识别新事务。然后，此过程可以将数据滴入数据集市。如果您想要非常低的延迟并控制源数据库，您可以实施将事务推送到数据集市的触发器，尽管此选项可能会给您的系统带来巨大的负载。

多维数据集上的前导 ROLAP 分区

可以使用混合架构来完成低延迟立方体。可以通过 ROLAP 分区查询前导数据（例如，当前开放会计期间的数据），该分区将针对基础数据发出查询。关闭或历史数据通过具有聚合的 MOLAP 分区进行管理。这为您提供了近乎实时的数据，而无需对大量数据发出数据库查询，以及对历史数据进行聚合的性能优势。

这有一些注意事项。纯 ROLAP 维度实质上限制了可以在度量值组上使用的特性（例如，除了 SUM 或 COUNT 之外没有聚合）。如果您希望对维度数据进行增量更新，您最好使用 MOLAP 维度，并且从更新基础维度表的作业中触发增量更新过程。如果您以增量方式处理维度，这是非常有效的。

测试这种类型的系统有些繁琐，因为您必须确保更改的数据捕获或增量加载机制正常工作。您可能需要创建一个可以将事务发布到系统中的测试工具，以便运行单元测试。

如果您在 MOLAP 存储模式下使用 SSAS，则必须处理多维数据集以刷新使用多维数据集作为数据源的报表。无论您使用“实时”数据库还是通过 ETL 过程生成的“非实时”版本，您都必须处理多维数据集以使多维数据集保持最新。如果您使用 SSAS 来获得高性能聚合的优势，那么您将不得不接受一定程度的数据延迟。

SSAS 存储模式的另一端是 ROLAP。ROLAP 不需要处理多维数据集，因为它实际上并不生成多维数据集数据存储。相反，它所做的只是在您运行 MDX 查询时针对源系统数据库生成 SQL 查询。这意味着它直接针对您的基础数据库。因此，如果您有一个“实时”数据库，并且您的存储模式是 ROLAP，则无需处理多维数据集即可从中获取当前数据。我自己的个人经验是，潜在的查询通常是可怕的。例如，如果我想查询一个事实和一个维度的一些属性，MDX 将产生一个 SELECT DISTINCT * FROM Dimimension.Table JOIN Fact.Table ON Key.Column = Key2.Column2。这基本上使 ROLAP 对我毫无用处，因为它的性能比任何替代方案都差。

在中间你有 HOLAP 存储模式。对于某些维度和事实表，这基本上是 MOLAP，而对于其他维度和事实表，这基本上是 ROLAP。所以你必须处理你的立方体的一部分，另一部分是来自数据库的实时数据。对我来说，这不是一个可行的解决方案，因为它仍然遇到与 ROLAP 相同的性能问题，并且像 MOLAP 一样增加了一些延迟。

如果您真的想在不强迫用户学习 SQL 的情况下查询您的实时数据，您可以在 BIDS 中创建一个报表数据模型，将其部署到您的 Reporting Services 服务器，然后将其用作数据源。数据模型是后来的元数据，几乎与 SSAS 中的模型相同——它只是不允许您从中生成预缓存的多维数据集。这可能是 SSAS 的合理替代方案。但是，报表数据模型仅适用于 SSAS——它们不适用于 Excel。如果您的用户想要一个不需要编写 SQL 的 Excel 高速数据源，那么您唯一可行的解​​决方案是 MOLAP SSAS。如果您的用户想要“实时”数据并且不需要 Excel 作为起点，那么请使用 SSRS 和报表数据模型。

如果您使用的是 Cognos、Business Objects、Microstrategy 或其他一些 BI 解决方案，请注意它们都具有类似于报表数据模型的数据模型元数据层，并且它们还可以使用生成的 SQL 语句查询“实时”源系统。

忠告：不要针对生产数据库编写报告解决方案，除非您将报告构建到底层生产应用程序的界面中。即使那样，您可能仍希望将报告查询卸载到某些复制的数据源而不是生产 OLTP 系统。您不希望某人对过去销售的查询阻止实际的新销售。如果你只为内部用户构建一个报告系统，那么花时间通过复制、日志传送、镜像、备份/恢复等将数据加载到另一台服务器，然后通过 SSIS 将数据加载到数据仓库或其他一些 ETL 解决方案。您真的不希望报告成为生产系统中断或延迟问题的原因。