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

我们有一个尺寸模型，每个实木地板的尺寸表为100-300 GB。我们在Azure Synapse（DirectQuery）的基础上构建PBI报告，并在切片/切割方面遇到性能问题，尤其是在计算多个KPI方面。同时，在Azure Analysis Services中保存数据量的成本非常高。由于维度的数量，事实表无法显著聚合，因此PBI导入模式或复合模型也不是一个选项

Azure Synapse分析，如分组汇总/多维数据集/分组集

我如何从Synapse的OLAP操作支持中获益

为了提高PBI报告的性能，可以在Synapse中预先计算OLAP多维数据集吗？怎么做

如果答案是“是”，是否建议预先计算KPI？意味着将KPI定义移动到DWH OLAP多维数据集级别-这是一种反模式吗

另外，对每个PBI可视化使用单独的聚合不是一个选项，它更像是规则的例外。Synapse足够聪明，即使在查询基表时也能从物化视图聚合中获益，但这种方式无法实现RLS，而且管理如此多的物化视图也显得很麻烦

@NickW的Upd 请回答以下子问题：

我说得对吗？OLAP操作支持主要针对下游多维数据集提供商，而不是仓库性能

使用物化视图生成仓库以提高性能是一种常见做法还是一种反模式？我发现（参见）PowerBI可以根据查询模式自动创建物化视图。但我仍然担心它将无法提供稳定的可测试解决方案，并再次支持RLS

仓库方面的KPI预计算是否被视为一种常见方法或反模式？据我所知，这通常是没有多维数据集提供程序端完成的，但如果我没有多维数据集提供程序端

您是否看到其他提高性能的选项？我只能考虑通过使用PBI复合模型和将所有维度导入PBI来降低查询并行性。不知道这是否有用

---

希望能回答你的一些问题

您不能在Synapse中预先计算OLAP多维数据集；最接近的方法是创建聚合表，您已经说过这不是一个可行的解决方案

OLAP操作可以在查询中使用，但不“预构建”其他查询可以使用的任何内容（忽略CTE、子查询等）。因此，如果您有不使用这些函数的现有查询，那么重新编写它们以使用这些函数可能会提高性能，但仅限于每个特定查询

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

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

我不完全确定我是否理解这个问题，所以这可能不是一个答案：OLAP函数存在，因此可以编写使用它们的查询。人们可能需要编写使用这些函数的查询的原因有很多

性能是创建具体化视图的主要（唯一？）原因。它们对于创建经常使用的数据集非常有效，即当基础数据处于日级别，但大量报告在周/月级别聚合时。正如另一位用户在评论中所说，Synapse可以自动管理这个过程，但它是否能够真正创建对大部分查询有用的聚合显然完全取决于您的特定情况

KPI预计算。在DW中，任何可以提前计算的度量值都应该是（通过ETL/ELT流程）。例如，如果您有使用净销售额（销售总额-税款）的报告，并且您的源系统仅提供总销售额和税款，那么您应该在加载事实表时计算净销售额作为度量。显然，有些KPI无法提前计算（即可能涉及平均值的任何内容），这些KPI需要在BI工具中定义

提高性能：我将在下一节介绍这一点，因为这是一个较长的主题

提高性能 性能调优是一个庞大的主题—有些领域是通用的，有些领域是特定于您的基础架构的；这将不是一个全面的审查，但将突出几个领域你可能需要考虑。 请记住以下几点：

基于您的基础架构，性能总是有一个绝对的限制，因此即使在一个经过完美调优的系统中，也总会有一个可能不是您希望达到的限制。然而，使用现代云基础设施，您达到这一极限的可能性非常低

性能要花钱。如果你能负担得起的只是一辆迷你车，那么不管你如何调整它，它永远不会像法拉利那么快

鉴于这些注意事项，您可以了解以下几点：

查询计划。看看您的查询是如何执行的，以及是否有任何明显的瓶颈可以关注。此链接提供了一些进一步的信息

扩大Synapse SQL池的规模。如果您在查询中投入更多资源，它们将运行得更快。显然，这是一种“直截了当”的方法，但一旦尝试了其他调优活动，就值得一试。如果这确实给了您可接受的性能，您需要决定是否值得额外的成本

确保您的统计数据是最新的

检查您对每个表使用的分发机制（循环、哈希）是否仍然合适，并在相关主题上检查每个表的倾斜

索引。添加适当的索引将通过