Power BI 容量规划：调整 Premium 和 Fabric 的大小

选择错误的 Power BI 容量层是组织可能犯下的最昂贵的分析错误之一。规模过小会导致高峰期出现限制、查询缓慢和刷新失败。规模过大需要为一天中大部分时间闲置的计算付出代价。获得正确的容量需要了解 Power BI 如何使用计算资源、工作负载的实际需求以及 SKU 选项如何满足这些需求。

本指南涵盖了 Power BI Premium 和 Microsoft Fabric 容量规划 - 从了解计算模型、监控当前利用率，到调整新部署的规模以及通过自动缩放管理成本。

要点

• Power BI Premium 容量以管理内存和计算吞吐量的虚拟核心 (v-core) 来衡量
• Microsoft Fabric 使用容量单位 (CU) 作为基本计费单位，取代了 SKU 层
• 后台工作负载（数据集刷新）和交互式工作负载（查询执行）竞争容量资源
• 容量指标应用程序是了解资源利用率的重要监控工具
• 24 小时内的 CPU 平滑意味着对突发进行平均 - 短高峰期不会立即触发限制
• 自动缩放（Premium Gen2）在高峰期自动添加计算，并在需求下降时删除它
• 数据集内存消耗是容量性能不佳的最常见原因
• 正确的容量规划需要在调整规模之前进行基线测量

---

Power BI 高级容量模型

Power BI Premium 提供专用计算资源，与 Pro 工作区使用的共享基础设施隔离。无论其他 Power BI 租户在做什么，这种隔离都可以提供一致的性能。

资源模型： 高级容量以虚拟核心 (v-core) 来衡量。每个 v 核心提供特定数量的内存和 CPU 计算。 v 核心和功能之间的关系决定了该功能可以同时处理哪些工作负载。

Microsoft Fabric 将 P-SKU 模型替换为 Fabric 容量单位 (CU)。面料F64大致相当于P1，F128相当于P2，以此类推。 Fabric 模型允许更细粒度的调整和按需付费计费（暂停/恢复），这通常比按月订阅 P-SKU 更具成本效益。

（价格约为美元；实际价格因地区和协商协议而异。）

---

工作负载类别

Power BI 容量可处理两类工作负载，并且它们争夺相同的计算资源：

后台工作负载无需用户交互即可运行：

• 数据集刷新（导入模式刷新）
• 数据流刷新
• AI工作负载（模型训练、推理）
• 由订阅触发的分页报告渲染
• 出口业务

交互式工作负载响应用户交互：

• 查询执行（用户打开报告页面）
• DirectQuery/实时连接查询
• 仪表板磁贴刷新
• 由用户触发的报告导出
• 自然语言问答

当两种类型的工作负载竞争相同的 v 核心时，容量必须有足够的资源来处理峰值重叠。在工作日夜间运行 20 个并发数据集刷新，同时在工作日处理 200 个并发用户查询的容量可能需要针对两个高峰进行调整。

---

容量指标应用程序

Microsoft Fabric 容量指标应用（以前称为 Power BI Premium 容量指标应用）是容量监控和规划的基本工具。从 AppSource 安装它并将其连接到您的容量。

它显示的内容：

CPU 和内存利用率（按工作负载类型划分）。利用率图表显示了一段时间内的 CPU 消耗情况，并为交互式和后台工作负载提供了单独的系列。平滑线显示 24 小时平滑平均值（Power BI 用于限制决策的平均值）。

限制事件：当 24 小时平滑的 CPU 超过容量资源的 100% 时，Power BI 开始限制后台工作负载（延迟刷新）。当它显着超过平滑阈值时，交互式工作负载也会受到限制。指标应用程序显示限制事件的持续时间和严重性。

数据集内存：内存瀑布显示哪些数据集被加载到内存中、它们消耗了多少内存以及它们何时被逐出。不断逐出和重新加载（高“逐出”计数）的数据集对于可用内存来说太大，导致用户等待数据集在每个查询上重新加载时出现延迟。

按资源消耗排名靠前的数据集和报告：指标应用程序可识别哪些数据集和报告消耗最多的资源 - 这些是在扩展之前进行优化的候选数据集和报告。

要监控的关键指标：

---

调整新部署的规模

首次调整 Power BI Premium 部署规模（没有现有指标数据）时，估计过程使用以下输入：

第 1 步：统计用户和使用模式

• 总共有多少用户将访问 Power BI 报告？
• 峰值并发用户数是多少？ （通常占总用户的 10-20%）
• 高峰使用时间是几点？ （营业时间通常为上午 9-11 点和下午 2-4 点）

步骤 2：估计数据集内存需求

• 将同时处于活动状态的所有数据集的未压缩大小相加
• 应用 5:1 的平均 VertiPaq 压缩比来估计内存大小
• 查询操作增加 20% 的开销
• 总数据集内存需求 = 大多数实现的主要大小限制

步骤 3：估计刷新工作负载

• 峰值时需要同时刷新多少数据集？
• 每个的预期刷新持续时间是多少？
• 峰值刷新资源消耗=（同时刷新次数×每次数据集刷新平均内存）

步骤 4：添加 DirectQuery/实时连接吞吐量

• 有多少用户将通过 DirectQuery 使用报表？
• 每秒的预期峰值查询是多少？
• 与 SKU 吞吐量限制进行比较（P1 每秒处理 30 个 DQ 查询）

尺寸计算示例：

拥有 500 个 Power BI 用户的组织：

• 高峰时有 50 个并发用户（占总数的 10%）
• 15 个活动数据集，平均 4 GB 未压缩 → 每个内存约 0.8 GB = 12 GB 总数据集内存
• 10 个数据集在夜间同时刷新，每个数据集在刷新期间消耗 2 GB = 20 GB 刷新内存
• 峰值时 20 个 DirectQuery 报告页面 = 每秒约 5 个查询

分析：32 GB 峰值内存（12 GB 数据集 + 20 GB 刷新）+ 开销 = 需要 P1 (25 GB) 可能很紧张 → 考虑 P2 (50 GB)。 DirectQuery 吞吐量在 P1 的 30 qps 限制之内，因此内存决定了大小调整决策。

从 P1 开始，使用 Metrics 应用程序进行 30 天的监控将揭示 P2 是否必要。

---

自动缩放配置

Power BI Premium Gen2（和 Fabric）支持自动缩放 - 当需求超过预配容量时自动添加计算资源，然后在需求下降时删除它们。

高级版自动缩放 (P-SKU)： 在 Power BI 管理门户 → 容量设置 → 高级容量 → 自动缩放中进行配置。设置可添加的附加 v 核心的最大数量（P1 为 1–71）。当容量利用率接近极限时，自动缩放会增量添加 v 核心。

自动缩放计费：额外的 v 核心按每个 v 核心的费率每小时计费。在高峰时段添加 8 个 v 核心 2 小时的 P1 将支付 16 个 v 核心小时的费用。

结构自动缩放： 结构容量可以暂停和恢复（对于开发/测试来说具有成本效益），并且具有可在购买的 CU 限制内扩展的突发计算能力。 Fabric 还支持预订（承诺支出以获得大幅折扣）以及即用即付定价。

何时使用自动缩放：

• 您有可预测的每日峰值（例如，月末财务报告产生 3 倍的正常负载）
• 您不想永久配置仅偶尔需要的峰值容量
• 您希望通过安全阀来预测成本，以应对意外的需求激增

何时不使用自动缩放：

• 持续的高利用率（您始终处于满负荷状态）- 升级基础层
• 非常大的一次性报告渲染负载 - 自动缩放可能反应不够快
• 严格的预算限制，任何可变计费都是不可接受的

---

扩容前的容量优化

在升级到更大容量之前，请优化现有工作负载。大多数性能问题都可以修复，无需花费更多资金。

数据集优化：

• 运行 DAX Studio 的 VertiPaq 分析器来识别可以删除或汇总的大型表和列
• 检查未使用的列并测量消耗的内存，而不会在任何报告中引用
• 优化数据类型（使用整数代替文本作为日期键，使用布尔代替字符串作为标志）
• 应用增量刷新以减少刷新周期期间的刷新持续时间和内存消耗

报告优化：

• 减少每个报告页面的视觉效果数量 - 每个视觉效果在加载时至少生成一个 DAX 查询
• 用生成更简单查询的卡片或 KPI 替换低价值的视觉效果
• 避免双向关系和生成多个存储引擎查询的复杂 DAX
• 使用字段参数代替许多类似的计算列

刷新时间表优化：

• 错开刷新时间以避免同时刷新多个大型数据集
• 在非高峰时段安排较低优先级的数据集
• 使用增量刷新来缩短大型数据集的刷新窗口
• 暂停或禁用很少使用的数据集的刷新

---

多容量架构

大型组织有时会使用多种容量来隔离工作负载、分离成本中心或提供地理冗余。

常见的多容量模式：

• 层隔离：P2 上的生产，F8 上的开发/测试。防止开发刷新消耗生产能力。
• 工作负载隔离：财务在一个 P1 上，HR 在另一个 P1 上。防止部门工作量相互影响。
• 地理分布：美国用户使用美国东部容量，欧盟用户使用西欧容量。减少区域用户群体的延迟。
• 成本中心分离：每个业务单元都有自己的产能，实现精确的成本扣款。

跨容量注意事项：数据集和报告必须发布到分配给特定容量的工作区。报表只能使用相同容量的数据集（或从不同容量导入，这会影响性能）。在发布之前规划工作空间到容量的分配，以避免跨容量数据访问模式。

---

常见问题

供企业使用的最低 Power BI 容量层是多少？

Power BI Premium P1（或 Fabric F64）是支持完整企业功能集的最低层：分页报告、部署管道、XMLA 终结点访问、AI 见解、数据流计算实体以及高达 400 GB 的模型大小。对于较小的组织或部门实施，Power BI Premium Per User (PPU) 的价格为 20 美元/用户/月，可提供大多数功能，而无需容量承诺。对于开发和测试，Fabric F2 或 F4 就足够了。

24小时CPU平滑对容量规划有何影响？

Power BI 使用 24 小时 CPU 平滑算法来确定容量是否过载。短暂的高 CPU 消耗突发（30 分钟内完成的大型刷新）不会立即导致限制 — 该突发是 24 小时窗口内的平均值。这意味着您可以处理中等突发工作负载，而无需调整峰值大小。然而，持续的高CPU（3小时以上的密集工作负载）将使平滑平均值超过限制阈值。尺寸适合您的持续峰值，而不是您的瞬时最大值。

对于新部署，Microsoft Fabric 是否比 Power BI Premium 更好？

对于2026年的新企业部署，Fabric通常是推荐的路径。它提供与 Premium 相同的 Power BI 功能以及额外的工作负载（数据工程、数据科学、数据仓库、实时分析）、更灵活的计费（暂停/恢复、预订）和统一的治理模型。已经使用 Premium P-SKU 并签订长期合同的组织可能会发现继续使用 Premium，直到续订具有经济意义为止。所有 Power BI Premium 内容都与 Fabric 兼容。

如何在不降低用户体验的情况下降低容量成本？

影响最大的成本降低杠杆是：(1) 在调整规模之前优化数据集以减少内存占用，(2) 错开刷新计划以防止同时发生资源竞争，(3) 使用具有暂停/恢复功能的 Fabric 来提高开发能力（仅在工作时间内付费），(4) 启用生产能力自动缩放，而不是永久配置高峰，以及 (5) 审核未使用的报告和数据集的工作区，这些报告和数据集在没有活跃用户的情况下消耗刷新资源。

Microsoft 为容量运行状况提供哪些监控工具？

主要工具是 Microsoft FabricCapacity Metrics 应用程序（可在 AppSource 上获取）。它提供 CPU 利用率、内存利用率、限制事件、数据集活动和查询性能指标。为了进行更深入的诊断，XMLA 端点（可通过 SSMS 或表格编辑器访问）允许查询 DMV（动态管理视图）以获取实时查询性能数据。 Power BI REST API 提供对自定义监控仪表板的容量指标的编程访问。

---

后续步骤

容量规划是一项持续的活动，而不是一次性的决定。从正确的层开始，使用容量指标应用程序积极监控，在扩展之前优化工作负载，并规划增长。从 Power BI Premium 获得最大价值的组织将容量管理视为性能工程学科。

ECOSIRE 的 Power BI 性能优化服务 包括容量评估、工作负载分析和规模调整建议。请联系我们审核您当前的容量利用率并确定提高性能的最具成本效益的途径。