在Azure Synapse中预先计算OLAP多维数据集

问题描述

我们有Dimeninal模型，每个模型都有100-300 GB的事实表。我们在Azure Synapse（DirectQuery）之上构建PBI报告，并在切片/切块（尤其是在计算多个KPI方面）遇到性能问题。同时，将数据量保存在Azure Analysis Services中非常昂贵。由于维数众多，因此无法对事实表进行汇总，因此也不能选择PBI导入模式或复合模型。

Azure Synapse Analytics faciliates OLAP operations，例如GROUP BY ROLLUP / CUBE / GROUPING SETS。

1. 如何从Synapse的OLAP操作支持中受益？
2. 是否可以预先计算Synapse中的OLAP多维数据集以提高PBI报告的性能？怎么样？
3. 如果答案是肯定的，那么是否建议将其建议为预先计算KPI？意味着将KPI定义转移到DWH OLAP多维数据集级别-是反模式吗？

P.S。不能为每个PBI可视化使用单独的聚合，这是规则的例外。 Synapse足够聪明，即使在查询基表时也能从物化视图聚合中受益，但是这种方式您无法实现RLS，并且管理该物化视图的数量也很麻烦。

为@NickW更新

能否请您回答以下子问题：

1. 我是否正确-OLAP操作支持主要是针对下游多维数据集提供程序，而不是针对仓库性能？
2. 产卵仓库是否具有物化视图以提高性能被认为是常见做法还是反模式？我发现（请参阅the link）Power BI可以基于查询模式自动创建实例化视图。仍然恐怕它将无法提供稳定的可测试解决方案，而RLS将再次提供支持。
3. 在仓库端进行KPI预先计算是一种常见方法还是一种反模式？据我了解，通常不需要任何多维数据集提供程序方，但是如果我还没有，那么
4. 您是否看到其他选择来提高性能？我只能考虑通过使用PBI复合模型并将所有维导入PBI来减少查询并行性。不确定是否有帮助。

解决方法

希望能回答您的一些问题...

1. 您无法在Synapse中预先计算OLAP多维数据集；您可以得到的最接近的方法是创建聚合表，并且您已经说过这不是可行的解决方案
可以在查询中使用
2. OLAP操作，但不要“预构建”其他查询可以使用的任何内容（忽略CTE，子查询等）。因此，如果您有不使用这些功能的现有查询，那么重写它们以使用这些功能可能会提高性能-但仅针对每个特定查询

我意识到您的问题是关于OLAP的，但根本的问题显然是性能。鉴于OLAP不太可能解决您的性能问题，如果您愿意，我很乐意谈论性能调整吗？

更新1-其他编号问题的答案

1. 我不太确定我是否理解这个问题，因此这可能不是答案：OLAP函数在那里，因此可以编写使用它们的查询。人们可能需要编写使用这些功能的查询的原因有很多，
2. 性能是创建实例化视图的主要原因（唯一？）。它们对于创建经常使用的数据集非常有效，即，当基础数据处于日级别时，但许多报告在周/月级别中汇总。正如另一位用户在评论中所述，Synapse可以自动管理此过程，但是它是否可以实际创建对很大一部分查询有用的聚合，显然完全取决于您的特定情况。
3. KPI预先计算。在DW中，应预先计算任何度量（通过ETL / ELT流程）。例如，如果您有使用净销售额（总销售额-税额）的报表，而源系统仅提供总销售额和税额，那么您在加载事实表时应将净销售额作为一种度量。显然，有些KPI不能预先计算（即可能涉及平均值），并且需要在您的BI工具中进行定义
4. 提升性能：由于这是一个较长的主题，我将在下一部分中介绍

提升效果

性能调优是一个非常大的主题-有些领域是通用的，而某些领域将特定于您的基础架构；这将不会是一个全面的评论，但将突出显示您可能需要考虑的一些领域。

请记住以下几点：

1. 性能始终受到绝对限制-基于您的基础结构-因此，即使在完美调整的系统中，也始终会有一个限制，这可能不是您希望达到的。但是，在现代云基础架构中，达到此极限的机会非常低
2. 性能要花钱。如果您能买得起的只是Mini，那么不管您对其调音的程度如何，它都不会像法拉利那样快

鉴于这些警告，您可以看一下几件事：

1. 查询计划。看一下查询的执行方式以及是否有明显的瓶颈可以集中精力。该链接提供了更多信息Monitor SQL Workloads
2. 扩展您的Synapse SQL池。如果您在查询中投入更多资源，它们将更快地运行。显然，这有点“过时”，但是一旦尝试了其他调音活动，就值得尝试。如果确实可以为您提供令人满意的性能，则需要确定是否值得额外花费。 Scale Compute
3. 确保您的统计信息是最新的
4. 检查您用于每个表的分配机制（Round Robin，哈希）是否仍然合适，并在相关主题上检查每个表的偏斜
5. 索引。添加适当的索引将加快您的查询速度，尽管它们也具有存储含义，并且会减慢数据加载速度。当您查看索引时，本文是一个合理的起点：Synapse Table Indexing
6. 材料化视图。先前已涵盖，但值得调查。我认为MV的自动管理可能尚未推出（或仅在公共预览中），但可能需要考虑一下
7. 数据模型。如果您有一些相当通用的事实和维度可以支持很多查询，那么您可能需要考虑创建其他事实/维度以仅支持特定报告。我总是（如果可能）从现有事实/维度派生它们，但是您可以通过从事实中删除未使用的SK，减少数据量，对表中的列进行子设置，合并表等来创建新表。

希望这为您至少提供了一个调查性能问题的起点。

,

突触Result Set Caching和Materialized Views都可以提供帮助。

将来，物化视图的创建和维护将自动进行。

Azure Synapse将自动创建和管理实例化视图 适用于DirectQuery模式下的较大Power BI Premium数据集。的 物化视图将基于用法和查询模式。他们 将自动维护为自我学习，自我优化的 系统。在DirectQuery模式下对Azure Synapse的Power BI查询将 自动使用实例化视图。此功能将提供 增强的性能和用户并发性。

https://docs.microsoft.com/en-us/power-platform-release-plan/2020wave2/power-bi/synapse-integration

Power BI Aggregations也可以提供帮助。如果有很多维度，请选择最常用于创建聚合的内容。