Power BI 优化指南
04/02/2021
本文内容
本文提供的指南使开发人员和管理员能够优化生产和维护 Power BI 解决方案。 可优化不同系统结构层的解决方案。 这些层包括：
数据源
数据模型
可视化效果(包括仪表板，Power BI 报表和 Power BI 分页报表)
环境(包括容量、数据网关和网络)
优化数据模型
支持整个可视化体验的数据模型。 数据模型可以是外部托管或内部托管 Power BI 它们被称为数据集 。 请务必了解您的选择，并为解决方案选择合适的数据集类型。 导入、DirectQuery 和复合。 详情请参考 Power BI 服务中的数据集和 Power BI 服务中的数据集模式。
请参考具体数据集模式的指南：
优化可视化效果
Power BI 可视化效果可以是仪表板，Power BI 报表或 Power BI 分页报表。 每种视觉效果都有不同的系统结构，所以具体的指南也不同。
仪表板
请务必了解，Power BI 对仪表板磁贴的缓存进行维护，但不包括磁贴和流式处理磁贴。 详情请参考 Power BI 数据刷新(磁贴刷新)。 如果您的数据集被迫实施动态行级安全 (RLS)，请务必了解性能的影响，因为磁贴会根据每个用户缓存。
将实时报表磁贴固定到仪表板后，查询缓存中不会提供这些磁贴。 但执行类似报表的操作，动态查询后端核心。
从缓存中检索数据可以提供更好、更稳定的性能，而不是依赖数据源。 使用此功能的一种方法是将仪表板作为用户的第一个登录页。 在仪表板上固定常用且要求较高的视觉对象。 通过这种方式，仪表板成为有价值的“第一道防线”，可通过容量上的较低负载提供稳定的性能。 用户仍然可以单击查看报告来分析细节。
对于 DirectQuery 通过查询数据源定期更新并实时连接数据集。 它每小时查询一次，但您可以在数据集设置中配置不同的频率。 每查询发送到基本数据源进行缓存更新。 查询数量取决于固定在依赖数据源的仪表板上的视觉对象数量。 请注意，如果使用行级安全性，将生成每个不同安全性的查询。 例如，假设有两个不同的角色来分类用户，它们有两个不同的数据视图。 查询缓存刷新期间，Power BI 将生成两组查询。
Power BI 报表
对于优化 Power BI 对报告设计有一些建议。
应用限制最强的级别
视觉对象需要显示的数据越多，加载视觉对象的速度就越慢。 虽然这个道理很明显，但很容易忘记。 假设你有一个大数据集。 基于这个数据集，可以生成一表格的报告。 最后，用户在这个页面上使用切片上获取他们需要的行，通常他们只对几十行感兴趣。
常见的错误是使用未经筛选的默认视图，即显示1亿多行。 每次刷新时，这些行的数据都会加载到内存中并减压。 这种处理对存储器有很大的需求。 解决方案:使用Top N减少筛选器显示的最大项数。 例如，最大项数可以设置为大于用户需要的数量 10,000。 因此，最终用户体验不会改变，但内存使用会大幅下降。 最重要的是提高性能。
对于报告中的所有视觉对象，建议采用上述类似的设计方法。 问问自己，这个视觉对象中是否需要所有的数据？ 有没有办法在不影响最终用户体验的情况下过滤掉视觉对象中显示的数据量？ 请注意，特别是手表可能很贵。
限制报表页上的视觉对象
上述原则也适用于报表页面上添加的视觉对象数量。 强烈建议将特定报表页面上的视觉对象数量限制为只包括必要的视觉对象。 钻取页面和报表页工具提示是提供更多详细信息而不显示太多视觉对象的好方法。
评估自定义视觉对象的性能
通过节奏保证每个自定义的视觉对象的高性能。 Power BI 视觉对象优化不良可能对整个报表的性能产生负面影响。
Power BI 分页报表
将最佳实践设计应用到报告的数据检索中，可以优化 Power BI 设计分页报表。 详情请参阅分页报表数据检索指南。
另外，请确保能力有足够的内存分配到分页报表的工作负载。
优化环境
通过配置容量设置，调整数据网关大小，减少网络延迟，可以优化 Power BI 环境。
容量设置
使用容量(通过 Power BI Premium (P SKU)、Premum Per User (PPU) 许可证或 Power BI Embedded (A SKU, A4-A6) 容量设置可在提供时进行管理。 有关详细信息，请参阅管理高级容量。 请参考如何优化容量的指南 Premium 容量。
调整网关大小
当 Power BI 必须必须不能直接通过 Internet 访问数据时，需要网关。 本地数据网关也可以安装在本地服务器上 VM 托管的基础设施是服务 (IaaS) 上。
了解网关工作负荷及调整规模的建议，请参考当地数据网关规模的调整。
网络延迟
网络延迟可以增加到达的请求 Power BI 影响报表性能所需的服务和传输响应时间。 Power BI 租户被分配到特定区域。
来自租户的用户访问 Power BI 在服务时，他们的请求将永远路过这个区域。 请求到达 Power BI 服务结束后，服务可以发送其他请求(如基础数据源或数据网关的请求)，这也会受到网络延迟的影响。
诸如 Azure 速度测试等工具可以提供客户端和 Azure 网络延迟在区域之间的指示。 一般来说，为了尽量减少网络延迟的影响，请努力使数据源、网关和 Power BI 尽可能接近集群。 它们最好位于同一区域。 如果网络延迟成为问题，请尝试将网关和数据源放入云托管的虚拟机中进行搜索 Power BI 收集更近的网关和数据源。
监视性能
瓶颈可以通过监控性能来确定。 应重点不断优化慢速查询或报告的视觉对象。 设计时可以进行监控 Power BI Desktop 也可以在中间完成 Power BI Premium 完成容量中的生产负荷。 详情请参阅 Power BI 监控报表性能。
后续步骤
本文详情请参考以下资源：