e2e-fabric-cost-estimation

遥测 — 必须遵守。 每次调用 api.fabric.microsoft.com 都必须携带 x-ms-fabric-skill: e2e-fabric-cost-estimation（az rest：--headers "x-ms-fabric-skill=e2e-fabric-cost-estimation"）， 包括每次 LRO 轮询、fabric_lro 和重试。代码片段中省略了此项 — 仍须添加。

重要说明

1. 若要通过工作区名称查找工作区详细信息（包括其 ID）：列出所有工作区，然后使用 JMESPath 筛选
2. 若要通过工作区 ID、项类型和项名称查找项的详细信息（包括其 ID）：列出该工作区中此类型的所有项，然后使用 JMESPath 筛选
3. 定价因区域而异。 进行任何价格查询之前，务必先确定容量所在的 Azure 区域（通过 Fabric REST GET /v1/capacities，该接口会返回 region/sku/state，或通过 ARM），或者询问用户，并在每个报价中注明区域。

🔴 必须获取实时价格 — 只要回答中包含美元金额，就必须执行。 在提供任何美元金额、成本、盈亏平衡点、计费模式比较、RI 与 PAYG 分析、迁移成本或成本工作表之前，必须运行 shell 命令（bash/powershell），调用 Azure Retail Prices API：https://prices.azure.com/api/retail/prices。此要求无一例外，适用于所有涉及价格的回答 — Databricks/Synapse 迁移成本、Autoscale 与基础 SKU 的盈亏平衡点、RI 与 PAYG 的盈亏平衡点、成本工作表和计费模式策略。必须先获取实时的每 CU 小时 PAYG 费率（priceType eq 'Consumption'、* Capacity Usage CU 计量项）、预留期限总价，以及 autoscale for Spark Capacity Usage CU 费率，然后再进行计算。回答定价问题时，绝不能使用记忆或硬编码费率，也绝不能只根据公式推算盈亏平衡点。如果计量项查询未返回任何结果，必须告知用户 — 绝不能悄悄回退到硬编码费率（例如，不要假设 Autoscale 的费率为 $0.18/CU-hr；Autoscale 计量项是独立费率，必须单独获取）。 例外 — 纯容量估算： 如果问题的回答纯粹以容量单位表示，且不包含美元金额（例如，“哪个 SKU 适合 80 CUs？”或“P2 对应多少 CUs？”），则属于 CU 计算，而非定价，无需获取价格。一旦在容量估算回答中附上美元金额，就必须获取价格。

🟠 先澄清，再行动 — 不要假设默认值。 定价请求需要两个输入才能获取价格或进行计算：Azure 区域和工作负载概况（例如每天的 CU 小时数、节点/作业详细信息，或迁移所涉及的源集群大小）。如果缺少其中任一项，你的第一条回复必须询问用户缺少的输入，并停止 — 不要选择默认区域（绝不要假设 East US 或任何其他区域来“开始”），不要调用定价 API，也不要根据假设值生成估算。只有在用户提供缺失信息后，才能获取实时价格并进行计算。尽管强制获取价格的规则适用于最终的定价回答，但在此处先询问才是正确做法。

🔴 AUTOSCALE 费率是独立计量项 — 绝不能复用基础/PAYG 费率。 autoscale for Spark Capacity Usage CU 计量项的价格与基础 * Capacity Usage CU PAYG 费率不同。必须单独调用 API 获取该费率，并读取返回的 retailPrice。将基础/PAYG 费率（或 0.18 等记忆中的数值）赋给 autoscale 变量属于正确性错误 — 例如，禁止执行 autoscaleRate = paygRate 或 autoscaleRate = 0.18。如果 autoscale 计量项查询未返回任何结果，请列出该区域的所有 Fabric Spark 计量项并告知用户；绝不能用基础费率代替。

Fabric 成本估算

前置知识

• COMMON-CORE.md — Fabric 拓扑、容量概念、身份验证与令牌受众
• COMMON-CLI.md — 用于发现容量的 CLI 模式、身份验证方法（az login、令牌获取）

---

目录

主题	章节
Fabric 计费模式概览	§ 计费模式
容量单位（CU）参考	§ CU 参考
工作负载成本估算	§ 工作负载估算
存储定价	§ 存储
网络定价	§ 网络
计费模式策略	§ 计费策略
SKU 规模选择决策树	§ SKU 规模选择
迁移成本工作表	§ 工作表
定价 API 参考	pricing-api-reference.md
必须 / 建议 / 避免	§ 必须 / 建议 / 避免

---

Fabric 计费模式

Microsoft Fabric 使用统一容量模型，所有工作负载共享一个**容量单位（CU）**池。了解以下计费维度：

维度	说明	计费机制
计算（CU 秒）	查询、Spark 作业、管道消耗的处理能力	按容量 SKU 计量 CU 消耗
存储（GB/月）	Delta 表、文件、快捷方式的 OneLake 存储	按 GB 计收月费
网络出口（GB）	离开 Azure 区域的数据	按 GB 收取出口费用
容量预留	基础 SKU 承诺（F2–F8192）	按月或按年承诺

计费模式

模式	说明	最适用于
预留实例（RI）	承诺 1 年或 3 年；可享受大幅折扣（通过实时 API 获取计算结果）	稳定的基础负载
即用即付（PAYG）	按小时计费；无承诺；按完整标价收费	测试、不可预测的工作负载
Spark 自动缩放计费	可选的无服务器模式；Spark 作业从容量中卸载，按 Spark CU 小时计费。Spark 不启用突发和时长平滑；不消耗容量 CU	将可变的 Spark 支出与稳定的容量支出分开
Fabric 试用版	试用容量（大小因租户和资格而异 — 通常最高为 F64，试用期为 60 天）；使用前请核实当前试用条款；切勿据此确定生产环境规模	仅供评估

容量 SKU 层级 — 实时查询定价

请勿使用硬编码价格。 始终在运行时从 Azure Retail Prices API 获取当前定价。

第 1 步：检测客户区域

如果客户已有 Fabric 容量，请通过核心 Fabric REST API 获取其区域、SKU 和状态 — GET https://api.fabric.microsoft.com/v1/capacities 会为每个容量返回 region、sku 和 state。Azure Resource Manager（az resource list）可作为等效备用方案；只有 Fabric Admin API（/v1/admin/capacities）不包含区域信息。请参阅 resources/pricing-api-reference.md 中的模板。

如果尚无容量，请询问用户计划在哪个 Azure 区域部署。

步骤 2：获取实时 Fabric 定价

查询 Azure Retail Prices API（公开，无需身份验证）。对于每个涉及定价的问题——包括 Autoscale 与基础容量的盈亏平衡分析，以及计费模式（PAYG/RI/暂停-恢复）策略——你的第一步必须是在进行任何计算之前，先在 shell（bash/powershell）中实际运行此查询。 不要仅凭公式推断盈亏平衡点或计费权衡；先运行命令，然后根据返回的 retailPrice 行进行计算：

curl -s "https://prices.azure.com/api/retail/prices?api-version=2023-01-01-preview&\$filter=serviceName%20eq%20'Microsoft%20Fabric'%20and%20armRegionName%20eq%20'<region>'" | jq '.Items[] | {meterName, retailPrice, unitOfMeasure, type, reservationTerm}'

使用 resources/pricing-api-reference.md 中的参考模板对 NextPageLink 结果进行分页，然后筛选所选区域的 Fabric 容量计量项。Retail Prices API 不会为每个 F-SKU 返回一行数据——使用 ^F\d+ 匹配 skuName/armSkuName 将不会返回任何结果。现在，PAYG 每 CU 小时的费用按每个工作负载的 Consumption 计量项计费，其 meterName 以 Capacity Usage CU 结尾（priceType eq 'Consumption'，unitOfMeasure eq '1 Hour'）；取这些计量项中 retailPrice 的众数，作为基础计算费率（数值较小，单位为每 CU 小时——始终使用 API 返回的值；不要照搬此技能中的任何示例数值）。预留费用来自 meterName eq 'Fabric Capacity CU'（旧版统一计量项现在仅用于预留）。从这些行中读取每 CU 费率。

步骤 3：构建定价表

API 返回的是每 CU 费率，而非每个 SKU 的价格。通过将每 CU 费率乘以文档化 SKU→CU 映射中的各 SKU CU 数量，构建每 SKU 定价表（Fn = n CU，例如 F64 = 64、F128 = 128、F256 = 256、F512 = 512、F1024 = 1024、F2048 = 2048、F4096 = 4096、F8192 = 8192）。

将每个 reservationTerm 档位正确换算为月度金额（预留行是期限总价，而非小时费率）：

• PAYG 月费 = consumptionCuHourRate × skuCUs × 730（Consumption 行，priceType eq 'Consumption'，meterName 类似 * Capacity Usage CU）
• 1 年 RI 月费 = reservationRetailPrice × skuCUs ÷ 12（不要乘以 730）
• 3 年 RI 月费 = reservationRetailPrice × skuCUs ÷ 36

月度换算指南见 resources/pricing-api-reference.md。

步骤 4：向用户展示

展示定价表，并明确注明区域：

Fabric Capacity Pricing — Region: [detected_region] (live as of [today's date])

| SKU | CUs | Monthly PAYG | 1-Year RI | 3-Year RI | RI Savings |
|-----|-----|-------------|-----------|-----------|------------|
| F4  | 4   | $[live]     | $[live]   | $[live]   | [calc]%    |
| ... | ... | ...         | ...       | ...       | ...        |

Source: Azure Retail Prices API (prices.azure.com)

重要：如果无法访问 API，请告知用户，并引导他们使用 Azure Pricing Calculator。切勿退回使用硬编码价格——这些价格会过时。

---

容量单元参考

各工作负载的 CU 消耗

工作负载	CU 消耗模型	关键指标
Spark（笔记本、SJD）	活跃 Spark 会话期间的 CU 秒数	vCore 数量 × 持续时间
SQL DW（仓库查询）	每次查询的 CU 秒数	查询复杂度 × 扫描的数据量
Power BI（语义模型、报表）	每次查询/刷新消耗的 CU 秒数	数据集大小、刷新频率、DAX 复杂度
Data Pipelines	每次活动执行消耗的 CU 秒数	活动类型、移动的数据量
Eventhouse / KQL	查询与引入数据消耗的 CU 秒数	引入速率、查询频率
Dataflows Gen2	每次刷新消耗的 CU 秒数	转换复杂度、数据量
OneLake	仅存储（静态存储不消耗 CU）	存储的 GB 数

Spark CU 映射（迁移时至关重要）

已记录的换算关系：1 Fabric CU = 2 个 Spark vCore（Fabric Spark 并发限制）。因此，节点的 CU 等效值为 vCores ÷ 2。以下 vCore 数量为池节点的默认值；在确定 SKU 规格前，务必先通过试点验证实际消耗量。

Spark 池节点大小	vCore	内存	每个节点的 CU 等效值（vCores ÷ 2）
小型	4 vCores	32 GB	2 CUs
中型	8 vCores	64 GB	4 CUs
大型	16 vCores	128 GB	8 CUs
特大型	32 vCores	256 GB	16 CUs
超特大型	64 vCores	512 GB	32 CUs

F64 容量的基础配置提供 128 个 Spark vCore；在标准（按容量计费）模式下，可通过 Spark 突发扩展至 3 倍（384 个 vCore）。

Spark 计费分为两种不同模式——请勿混为一谈：

1. 标准（按容量计费）Spark：Spark 作业从容量 SKU 消耗 CU。突发（最高 3 倍）和消耗平滑均适用。消耗的 CU 小时数 = 节点数 × 每节点 CU × 活跃秒数 / 3600，并计入容量费用。
2. Spark 自动缩放计费（选择加入，无服务器）：一种独立计费模式，Spark 作业会从容量中卸载，并按 Spark CU 小时数通过 autoscale for Spark Capacity Usage CU 计量项计费。在此模式下，Spark 作业不会消耗容量 CU，且 Spark 不支持突发和消耗平滑。你可以设置 Spark CU 上限；仅对会话活跃时间计费。使用此模式可将可变的 Spark 支出与稳定的容量支出分开——它不是在同一 SKU 上“突破基础容量”。

Databricks 到 Fabric Spark 的映射

⚠️ 未经验证的经验估算：这些映射仅为近似值，Microsoft 未正式记录。确定容量规格前，请通过试点工作负载进行验证。

Databricks 群集配置	Fabric 等效配置	CU 估算
2× Standard_D4ds_v5（每个 4 vCore）	2× 小型节点	峰值约 4 CUs
4× Standard_D8ds_v5（每个 8 vCore）	4× 中型节点	峰值约 16 CUs
8× Standard_D16s_v5（每个 16 vCore）	8× 大型节点	峰值约 64 CUs
自动缩放 2–10 个工作节点（D4s）	自动缩放 2–10 个小型节点	突发约 4–20 CUs

---

工作负载成本估算

步骤 0：检测当前支出（源平台）

估算 Fabric 成本前，使用 Azure Cost Management 获取客户当前的实际支出。请使用 resources/pricing-api-reference.md § Azure Cost Management API 中的查询模板和 CLI 模式：

• 上月按服务统计（按 ServiceName 分组，筛选 Databricks / Synapse / HDInsight / Power BI / Microsoft Fabric）：用于确定各产品的基准支出
• 每日趋势（粒度为 Daily，按 ServiceName 分组）：用于找出高峰日，以此估算 CU 峰值需求

解析响应并提取：

• 上月各服务的总支出（Databricks、Synapse、HDInsight、Power BI）
• 资源明细（计算、存储、网络）
• 每日成本的峰值与平均值模式

非 Azure 源平台（AWS、GCP、Databricks、Snowflake、Teradata）

如果源平台不在 Azure 上，请从该平台实时获取当前支出——切勿硬编码或猜测源平台的价格。优先使用客户的实际账单/用量；仅在存在公开牌价 API 时使用；否则请参考官方定价页面或发票，并注明来源和日期。有关经过验证的端点（AWS Price List、GCP Cloud Billing Catalog）以及 Databricks/Snowflake 的实际用量查询，请参阅 resources/pricing-api-reference.md § Source Platform Pricing (Multi-Cloud)。

Databricks 专用：获取集群利用率

参见 pricing-api-reference.md § Databricks Clusters API。按照 COMMON-CLI.md 获取令牌，并调用 GET /api/2.0/clusters/list。关键字段：cluster_name、node_type_id、num_workers、autoscale。

Synapse 专用：获取池配置

有关 az synapse sql pool 和 az synapse spark pool CLI 命令，请参见 pricing-api-reference.md § Synapse Pools。

步骤 1：分析现有工作负载

从源平台收集以下指标：

源平台	要收集的指标	查找位置
Databricks	每日集群小时数、DBU 消耗量、工作节点数量、节点类型	集群指标、计费控制台
Synapse Spark	池小时数、节点数量、节点大小	Synapse Studio → Monitor → Apache Spark pools
Synapse SQL	每日 DWU 小时数、查询数量、扫描的数据量	DMV、Azure Monitor
Azure SQL/SQLDB	DTU/vCore 小时数、查询模式	Performance Insights
Power BI Premium	P-SKU 大小、刷新频率、用户数量	Power BI 管理门户
HDInsight	VM 小时数、集群大小、HDFS 存储	Azure 计费
AWS Redshift / EMR	节点类型、节点数量、集群小时数、存储 GB	AWS Cost Explorer；通过 AWS CLI 获取集群配置
Google BigQuery / Dataproc	插槽数或按需扫描的 TB 数；Dataproc vCPU 小时数	Cloud Billing 导出；GCP 控制台
Snowflake	仓库大小、每日消耗的 credits、存储 TB 数	ACCOUNT_USAGE.METERING_DAILY_HISTORY
Teradata Vantage	节点/AMP 数量、TCore、存储；或 Marketplace 计量单位	客户发票 / 云 Marketplace 计量数据

步骤 2：映射为 Fabric CU 需求

Spark 工作负载（最常见的迁移场景）：

Daily CU demand = Σ (job_duration_hours × nodes × CU_per_node)
                  where CU_per_node = node_vCores ÷ 2

Example:
- 3 Spark jobs/day
- Job 1: 2 hours × 4 Medium nodes (4 CU each) = 2 × 4 × 4 = 32 CU-hours
- Job 2: 1 hour × 2 Small nodes (2 CU each) = 1 × 2 × 2 = 4 CU-hours
- Job 3: 0.5 hours × 8 Large nodes (8 CU each) = 0.5 × 8 × 8 = 32 CU-hours
- Total daily: 68 CU-hours
- Peak concurrent: 32 CUs (Job 1 or Job 3)

SQL 仓库工作负载（Synapse Dedicated SQL / DW）：

不要根据 DWU 到 CU 的公式进行估算——Microsoft 没有发布官方换算方式，因此任何 DWU ÷ 2 的数值都无法用于已承诺的 SKU。请改为根据客户的实际计费信号进行估算，并通过试点进行验证：

Workflow (measured, not heuristic):
1. Pull the customer's real DWU-hours/day from their Synapse invoice line
   or Azure Cost Management (Meter: "cDWU" / "Compute"), not from peak DWU.
2. Run a representative workload on the smallest candidate Fabric F-SKU and
   read measured CU-seconds from the Capacity Metrics app (see § Validation).
3. Scale that measured CU/DWU-hour ratio to the customer's total DWU-hours,
   then feed the resulting CU demand into the live-API SKU pricing lookup.
4. Present the number as pilot-validated, never as a formula output.

⚠️ 未经试点，不得承诺容量规模。 如果暂时无法进行试点，应将 DWU 小时数列为待测量的输入项，并标明估算受阻于缺少试点数据——不要将 DWU ÷ 2 得出的 CU 数值作为交付结果。

Power BI 工作负载：

CU demand ≈ P-SKU CU equivalent × utilization%

P1 = 64 CUs (F64), P2 = 128 CUs (F128), P3 = 256 CUs (F256), P4 = 512 CUs (F512), P5 = 1024 CUs (F1024)
EM1/A1 = 8 CUs (F8), EM2/A2 = 16 CUs (F16), EM3/A3 = 32 CUs (F32)

Example — single Power BI P-SKU, like-for-like migration:
- P2 at 70% avg utilization, 15 refreshes/day
- P2 direct equivalent = 128 CUs (F128)
- Effective sustained demand: 128 × 0.70 ≈ 90 CUs. Refresh bursts are short and
  absorbed by capacity smoothing, so the sustained concurrent demand stays ~90 CUs.
- Apply the 1.2× safety factor to the *demand* (NOT the source nameplate):
  90 × 1.2 = 108 CUs → round up to next tier → **F128**
- F128 is the direct P-SKU equivalent and already provides headroom over a
  sub-100% workload. Do NOT multiply the source P-SKU's *rated* nameplate
  (128) by the safety factor — the nameplate already exceeds the utilized
  demand, so 128 × 1.2 → F256 double-counts headroom and over-provisions.

步骤 3：汇总并确定容量规模

Sized CU = max over time of (Σ concurrent CU across all workloads in that window) + headroom
           (workloads share one capacity; size to the worst-case *concurrent sum*,
            NOT max(individual workload peaks) — peaks in different workloads can coincide)

Build a time-bucketed demand curve (e.g., hourly) summing Spark + SQL + PBI + Pipelines
CU in each bucket, then take the maximum bucket.

Recommended SKU = next SKU above (max_concurrent_CU × 1.2 safety factor)
  where max_concurrent_CU is the worst-case *effective/measured* concurrent CU
  DEMAND (already utilization-adjusted) — NOT a source SKU's rated nameplate.
  For a single Power BI P-SKU like-for-like migration, the recommendation is the
  direct CU-equivalent tier (P1→F64, P2→F128, P3→F256); do not inflate it further.

Two billing options for Spark:
  A) Standard (capacity-billed): include Spark CU in the concurrent sum above (one SKU).
  B) Autoscale Billing for Spark: size the base SKU for SQL + PBI + Pipelines only;
     Spark is offloaded and billed separately (does not consume capacity CUs).

注意：容量平滑会重新分配短时突发负载（交互式负载约 5–64 分钟，后台负载最长 24 小时），但不会降低稳态并发总量——应根据持续并发需求确定容量规模。

---

存储定价

实时查询：OneLake 存储费率

通过 Azure Retail Prices API 获取客户所在区域的 OneLake 存储费率。OneLake 存储采用分层定价——没有单一的 OneLake Storage 计量项（该筛选条件不会返回任何行）。请使用分层计量项名称，并选择与数据访问模式相符的层级：OneLake Storage Hot Data Stored、OneLake Storage Cool Data Stored、OneLake Storage Cold Data Stored，以及适用于镜像副本的 Storage Mirroring Data Stored（筛选条件：serviceName eq 'Microsoft Fabric' and armRegionName eq '<region>'，忽略带有 reservationTerm 的行）。如果筛选结果为空，请列出该区域的所有 Fabric 存储计量项，并展示给用户——绝不要默默使用硬编码费率。可运行模板请参见 resources/pricing-api-reference.md。

存储类型和定价模式

存储类型	定价查询筛选条件	备注
OneLake（托管 Delta/Parquet）	meterName eq 'OneLake Storage Hot Data Stored'（或 Cool/Cold）	主要的 Fabric 存储；按访问模式分层
OneLake 快捷方式（不复制）	$0（仅快捷方式元数据）	仍需支付源存储费用
ADLS Gen2（源，通过快捷方式访问）	serviceName eq 'Storage' and skuName eq 'Hot LRS'	现有存储；不会产生重复数据
镜像存储	meterName eq 'Storage Mirroring Data Stored'	OneLake 中的 Delta 副本

根据现有平台估算存储量

源	指标	Fabric 对应项
Databricks DBFS / 托管表	Delta 表总大小（GB）	OneLake Tables/ 中的大小相同
Synapse Spark 托管表	ADLS Gen2 synfs 容器大小	迁移或使用快捷方式；大小相同
Synapse SQL DW 存储	DBCC PDW_SHOWSPACEUSED	大致相同（Delta 格式）
Power BI 数据集	模型大小（压缩后，内存中）	数据集导入 = 未压缩 Delta 大小的 2–4 倍
HDInsight HDFS	HDFS du 输出	转换为 Delta；与原始数据相比，通常可压缩 30–60%

---

网络出口定价

实时查询：出口费率

使用筛选条件 serviceName eq 'Bandwidth' and armRegionName eq '<region>' and meterName eq 'Standard Data Transfer Out'，获取客户所在区域的带宽/出口费率（忽略带有 reservationTerm 的行）。请参阅 resources/pricing-api-reference.md 中可运行的模板。

出口成本模型

Azure 出口费用按阶梯计价，数据源不同，适用的计费项也不同。切勿直接套用单一的每 GB 固定费率——应先确定阶梯和数据源，再查询实时费率。

场景	定价来源	缓解措施
同一区域（区域内）	免费	让容量和存储位于同一区域
互联网出口的第一档	带宽 API：每月前 100 GB 免费（meterName eq 'Standard Data Transfer Out'），之后按阶梯计费	将小批量传输合并，控制在免费额度内
互联网出口（超出免费额度）	带宽 API：按月流量分阶梯计费，GB 数越高，费率越低	尽量减少公开下载；分别计算每个阶梯区间的费用
跨区域（区域间）	带宽 API：meterName eq 'Inter Region Data Transfer Out'	使用 OneLake 区域快捷方式
跨云数据源（AWS/GCP → Fabric）	源云的出口计费项（AWS Data Transfer Out / GCP Network Egress），而非 Azure	通过同一云中的快捷方式暂存；出口费用由源云收取
Private Link / Private Endpoint	标准出口费用加上 PE 每小时费用以及按 GB 收取的 PE 数据处理费用	用于满足合规要求；将以上三项费用都纳入预算

迁移出口费用估算：对于一次性迁移，按适用的阶梯区间（免费 → 第 1 档 → 第 2 档……）拆分迁移量，并按各档实时费率计算费用；从 AWS/GCP 迁移时，还要加上源云的出口费用。Azure 内同一区域的数据传输：$0。

---

计费模式策略

决策框架

┌─────────────────────────────────────────────────────────────┐
│ Is the workload Spark-heavy (>50% of CU demand)?            │
│                                                             │
│ YES → Consider Autoscale Billing for Spark (offloads Spark  │
│       from capacity, billed separately) + Reserved Instance │
│       sized for the non-Spark base (SQL + PBI + Pipelines). │
│       Alternative: one capacity-billed SKU sized for the    │
│       full concurrent sum if you prefer a single bill.      │
│                                                             │
│ NO → Is demand predictable and steady?                     │
│      YES → Reserved Instance (1-year or 3-year)            │
│      NO  → Pay-As-You-Go (for evaluation period)          │
│            then reassess after 30 days of metrics          │
│                                                             │
│ Intermittent (dev/test, scheduled batch windows)?          │
│   → Pause/resume the capacity (billing stops while paused) │
│     instead of, or combined with, PAYG.                    │
└─────────────────────────────────────────────────────────────┘

Spark 密集型工作负载：Spark 自动缩放计费与标准容量

Spark 有 两种不同的计费模式——请选择其中一种；它们不会在同一个 Spark 作业上叠加：

• 标准模式（按容量计费）：Spark 从容量 SKU 消耗 CU（支持 3× 突增和用量平滑）。调整一个 SKU 的大小，使其能够覆盖一段时间内所有工作负载（SQL + PBI + Pipelines + Spark）的并发 CU 总量。
• Spark 自动缩放计费（选择启用的无服务器模式）：Spark 作业从容量中卸载，并按 Spark CU 小时单独计费，费率对应 autoscale for Spark Capacity Usage CU 计量项。Spark 的突增和用量平滑已禁用，这些作业也不会消耗容量 CU。这样，你可以根据非 Spark 稳态负载（SQL DW + Power BI + Pipelines）调整基础容量，并通过 Spark CU 上限单独支付 Spark 费用。

实时获取自动缩放 Spark 费率（$/CU-hour）——不要重复使用基础费率或 PAYG 费率，也绝不要硬编码数值。 对任何自动缩放或盈亏平衡问题，首先必须在 shell 中运行此获取命令，并读取 API 返回的 retailPrice：

curl -s "https://prices.azure.com/api/retail/prices?api-version=2023-01-01-preview&\$filter=serviceName%20eq%20'Microsoft%20Fabric'%20and%20armRegionName%20eq%20'<region>'%20and%20meterName%20eq%20'autoscale%20for%20Spark%20Capacity%20Usage%20CU'" | jq '.Items[] | select(.reservationTerm == null) | {meterName, retailPrice, unitOfMeasure, armRegionName}'

使用返回行中的 retailPrice 值作为自动缩放费率。如果该区域没有返回任何行，请列出该区域的所有 Fabric Spark 计量项并展示出来——不要假设、复制或重复使用基础费率。请参阅 resources/pricing-api-reference.md 中可运行的模板。

估算公式（自动缩放计费模式，使用实时费率）：

Example (fill in live prices from API):
- SQL DW peak: 16 CUs
- Power BI peak: 8 CUs  
- Spark peak: 64 CUs (but only 4 hours/day)
- Pipelines: 4 CUs

Base capacity (standard, capacity-billed): sized for SQL + PBI + Pipelines = 16 + 8 + 4 = 28 CUs raw
  → apply 1.2× safety: 28 × 1.2 = 33.6 CUs → round up to next tier → **F64**
  Monthly cost: [look up F64 1-Year RI rate from API, amortized ÷ 12]
  
Spark (Autoscale Billing, offloaded from capacity):
  64 CU × 4 hours/day × 30 days = 7,680 CU-hours/month
  Cost: 7,680 × [live 'autoscale for Spark Capacity Usage CU' rate from API]

Total: [base RI ÷ 12] + [Spark autoscale] + [storage] + [egress]
Compare vs. current spend from Cost Management API above.

预留实例与 PAYG 的盈亏平衡点

不要依赖固定的利用率阈值。请根据实时定价，针对具体 SKU 和区域计算盈亏平衡点：

monthlyAmortizedReservationCost = skuCUs × reservationRetailPrice ÷ (12 for 1-yr | 36 for 3-yr)
paygMonthlyAtFullUse            = skuCUs × paygCuHourRate × 730
breakEvenHoursPerMonth          = monthlyAmortizedReservationCost ÷ (skuCUs × paygCuHourRate)

→ If expected billed hours/month > breakEvenHoursPerMonth, the RI wins.
→ Express RI savings as (paygMonthlyAtFullUse − monthlyAmortizedReservationCost) ÷ paygMonthlyAtFullUse.

reservationRetailPrice（期限总价）和 paygCuHourRate（priceType eq 'Consumption'，来自 * Capacity Usage CU 计量项）均来自 Retail Prices API。对于需求高度可变或具有季节性的场景，可将较小规模的 RI 基础容量与 PAYG 或 Spark 自动缩放计费结合，用于可变部分。

---

SKU 大小选择决策树

输入变量

向用户收集：

1. 所有工作负载的峰值并发 CU 需求
2. 每日平均消耗的 CU 小时数
3. 工作负载构成（Spark、SQL、PBI 和其他工作负载所占比例）
4. 增长预测（12 个月预测）
5. 合规要求（Private Link、专用容量）
6. 预算限制（每月上限）

大小选择算法

1. Build a time-bucketed concurrent-demand curve; concurrent_CU = Σ workload CU per bucket
2. peak_CU = max concurrent_CU over the curve (NOT max of individual workload peaks)
3. Pick the CU basis by billing mode (Spark is the only workload that can be offloaded):
     If using Autoscale Billing for Spark:
       basis_CU = max concurrent (SQL + PBI + Pipelines)   # Spark offloaded, billed separately
     Else (standard, capacity-billed):
       basis_CU = peak_CU                                  # Spark included in the concurrent sum
4. Apply the growth forecast to the CU DEMAND, before sizing (never to a chosen SKU —
   multiplying a SKU by a growth factor can invent a tier that does not exist):
     projected_CU = basis_CU × (1 + growth_rate)
5. Apply the 1.2x safety factor to the projected demand (BOTH billing modes, incl. the
   Autoscale base):
     sized_CU = projected_CU × 1.2
6. Round UP to the next real SKU tier. The ONLY valid Fabric capacity tiers are
   **F2, F4, F8, F16, F32, F64, F128, F256, F512, F1024, F2048, F4096, F8192**
   (CUs double at each step). There are NO in-between sizes: never name an
   interpolated tier such as F48, F96, F192, or F1500 — always snap to an
   existing tier from that list, even in comparisons, ranges, or asides.
7. Validate: chosen-SKU monthly cost ≤ budget constraint
8. If budget exceeded: recommend workload optimization or phased migration

SKU 快速参考选择器

将计算后大小的 CU输入此表——即先运行大小选择算法的步骤 1–5，计算 sized_CU = peak_CU × (1 + growth_rate) × 1.2，再将该值（而非原始峰值需求）映射到相应层级。安全系数和增长率已计入左侧列，因此不要再次应用。

大小调整后的 CU（增长率 + 1.2× 安全系数）	推荐的基础 SKU	备注
≤ 2 CUs	F2	试用／非常小型的开发环境
3–4 CUs	F4	开发／测试、小型团队
5–8 CUs	F8	小型生产环境
9–16 CUs	F16	中型生产环境
17–32 CUs	F32	标准生产环境
33–64 CUs	F64	大型生产环境、多个团队
65–128 CUs	F128	企业级
129–256 CUs	F256	大型企业
257–512 CUs	F512	超大型企业
513–1024 CUs	F1024	多团队企业平台
1025–2048 CUs	F2048	超大型部署
2049–4096 CUs	F4096	超大规模部署
4097–8192 CUs	F8192	最大的单容量层级
> 8192 CUs	多个容量	讨论多容量架构／工作区分区

---

迁移成本工作表

模板：呈现给用户

估算迁移成本时，请使用上述 API 的实时数据。生成一份工作表，涵盖以下关键部分：

• 页眉 — 客户/项目名称、区域、定价日期、数据来源
• 当前支出 — 来自 Cost Management API 的各平台实时月度成本（Databricks、Synapse SQL/Spark、Power BI Premium、存储）
• 源工作负载概况 — 每日 Spark 作业数、每日 SQL DWU 小时数、Power BI SKU 利用率、管道运行次数、存储 TB
• Fabric CU 需求 — 各工作负载类型的峰值和平均 CU 估算值，以及总计
• 推荐配置 — 基础 SKU（F 层）、Spark 计费模式、RI 期限
• 月度成本明细 — 来自实时 API 价格的容量、Spark 自动缩放、存储和网络出口费用
• 与当前支出相比的节省额 — 差额和百分比变化

完整的可打印模板请参阅 resources/cost-estimation-worksheet.md。

---

必须 / 优先 / 避免

必须做到

• 始终获取双方的实时定价。 目标平台（Fabric）价格来自 Azure Retail Prices API（prices.azure.com）；源平台价格来自该平台的实时计费/定价 API 或客户的实际账单。任何一方的金额都不得硬编码。
• 切勿仅凭启发式换算最终确定 SKU 或承诺成本。 将所有跨平台的 vCore→CU 和 DWU→CU 映射仅视为试点验证输入（Fabric 内部的 1 CU = 2 个 Spark vCore 比例已有文档记录，但源引擎与 Fabric 之间的等效关系尚未确定）。将基于启发式方法得出的数值标注为初步估算，并要求先运行试点工作负载（通过 Capacity Metrics 应用测量 CU 消耗），再确定承诺容量或购买 RI。
• 从客户现有的 Fabric 容量中识别其区域，或明确询问 — 定价因区域而异
• 客户拥有 Azure 订阅访问权限时，通过 Azure Cost Management API 获取当前支出 — 为比较建立基准
• 估算前务必询问源工作负载概况 — 切勿假设工作负载规模
• 纳入所有成本维度 — 计算（CU）、存储、网络出口以及任何高级功能（Private Link、BCDR）
• 明确说明数据来源 — 区域、货币、API 查询日期，以及用于验证的 Azure 定价计算器链接
• 当 Spark 占 CU 需求的比例超过 50% 时，单独核算 Spark 的自动缩放计费 — 在此模式下，Spark 会从容量中卸载并单独计费；不要将其计入基础容量
• 在选择 SKU 前，将峰值 CU 需求乘以 1.2 的安全系数
• 纳入预留实例分析 — 展示推荐 SKU 的按需付费、1 年期和 3 年期方案对比
• 提供成本工作表模板，并使用实时数据填写所有明细项

优先考虑

• 对于 Spark 密集型工作负载，优先采用 Spark 自动缩放计费 — 将 Spark 从容量中卸载并单独计费，避免为突发 Spark 作业过度预配基础 SKU（此模式下，Spark 的突发与平滑功能会禁用）
• 对于 Spark 密集型混合工作负载，默认推荐基础容量使用预留实例 + Spark 自动缩放计费
• 对于现有 ADLS Gen2 数据，优先使用 OneLake 快捷方式而非复制数据 — 避免重复存储成本
• 将容量和存储部署在同一 Azure 区域 — 消除跨区域网络出口费用
• 存在预算限制时采用分阶段迁移 — 从 F8/F16 开始，再逐步扩容
• 迁移后每月监控利用率 — 建议在获取 30 天以上的实际使用数据后再购买 RI
• 在估算中考虑工作负载平滑 — Fabric 会将交互式突发负载平滑至约 5–64 分钟，并将后台作业平滑至最长 24 小时；使用自动缩放计费时，Spark 的平滑功能会禁用。平滑会重新分配突发负载，但不会降低稳态并发需求。

避免

• 不要硬编码价格——始终使用实时数据源（Fabric 使用 Azure Retail Prices API；查询当前支出时使用源平台的价格 API 或实际账单）；硬编码的值会过时
• 不要虚构没有公开价格 API 的平台（Databricks DBU、Snowflake credits、Teradata）的价格——使用客户的实际用量／账单或官方定价页面，并注明来源
• 不要引用价格却不注明来源和日期——始终注明“截至 [date]，数据来自 Azure Retail Prices API”
• 在稳定运行状态尚未确定时，不要建议购买 3 年期 RI——等待工作负载模式得到验证（至少 3 个月）
• 不要只根据 Spark 峰值来确定容量大小——应将 Spark 纳入并发 CU 总量（标准做法），或通过 Autoscale Billing for Spark 将其卸载；基础 SKU 应覆盖非 Spark 的稳定运行状态
• 不要忽略 Power BI 的 CU 消耗——语义模型刷新和交互式查询会消耗大量 CU
• 对于多区域或混合架构，不要遗漏网络出口流量费用
• 不要混淆 CU 和 vCore——CU 是 Fabric 统一的计费单位；vCore 是 Spark 执行资源。在 Fabric Spark 中，vCore→CU 的比例有文档说明（1 CU = 2 Spark vCore，参见 Spark CU Mapping 部分），因此 Fabric 池节点→CU 的换算是确定的。跨平台等效关系则属于经验估算——即将源引擎的 vCore（Databricks/Synapse/EMR）映射为 Fabric CU——在确定 SKU 大小之前，必须通过试点验证
• 不要跳过 Cost Management API 检查——如果用户有 Azure 访问权限，务必以编程方式确认其当前基准支出

---

示例

示例 1：Databricks 迁移成本估算

用户提示词：“我每天运行 5 个 Databricks Spark 作业，每个作业在 4×D8s_v5 集群上运行约 3 小时，此外还有一个 Power BI P1 和 2TB Delta 表。在 Fabric 上需要多少费用？”

Agent 工作流：

1. 确定区域（询问用户或通过 GET /v1/capacities 或 ARM 检查现有容量——参见 § Fabric 容量发现）
2. 通过 Cost Management API 获取当前 Databricks 支出
3. 使用 Retail Prices 分页模式获取实时 Fabric 定价
4. 计算 CU 需求并提供计算表

CU 计算逻辑：

Spark: 5 jobs × 3h × 4 nodes × 4 CU/node (D8s_v5 = 8 vCores = Medium = 4 CU) = 240 CU-hours/day
Peak concurrent (2 jobs overlap): 2 × 4 × 4 = 32 CUs → candidate for Autoscale Billing for Spark
PBI: P1 = 64 CUs (F64 equivalent) — steady-state base
Storage: 2 TB × OneLake tiered rate (from API)

Recommended config (Autoscale Billing for Spark option):
  Base: F64 (1-Year RI) — covers Power BI P1 steady-state
  Spark: Autoscale Billing — 240 CU-hours/day × 30 days × live 'autoscale for Spark Capacity Usage CU' rate
  Storage: 2 TB × 1024 GB × live OneLake Hot rate
  Total = (Base RI ÷ 12) + Spark Autoscale + Storage

价格查询：使用 armSkuName eq 'Fabric_Capacity_CU_Hour' + armRegionName eq '<region>' + meterName eq 'Fabric Capacity CU' 筛选 Retail Prices API。reservationTerm 是可筛选的 OData 字段，因此可以通过 reservationTerm eq '1 Year' 直接获取 1 年期的行（也可以从每个返回行中读取该字段）——将该期限的总费用 ÷ 12 × 64 CUs。Spark 费率使用 meterName eq 'autoscale for Spark Capacity Usage CU'，存储费用使用 meterName eq 'OneLake Storage Hot Data Stored'。完整的分页和筛选模式请参见 pricing-api-reference.md。

示例 2：Synapse SQL DW 迁移

用户提示词：“我们每天运行 Synapse DW1000c 18 小时，并有 5TB 的仓库数据。”

Agent 工作流：

1. 通过 Cost Management API 获取当前 Synapse 支出（筛选条件："Azure Synapse Analytics"）
2. 使用 Retail Prices 分页模式获取客户所在区域的实时 Fabric 定价
3. 计算 CU 需求并推荐 SKU

CU 计算逻辑：

Sizing input: the customer's measured DWU-hours/day from their Synapse invoice
(DW1000c × 18h ≈ 18,000 DWU-hours/day) — NOT a DWU ÷ 2 CU formula.
Pilot the workload on a candidate F-SKU, read CU-seconds from Capacity Metrics,
and scale the measured CU/DWU-hour ratio to total DWU-hours.
Do NOT apply an assumed engine-efficiency discount; size from the pilot's measured CU,
not from a guessed "% less CU" factor.
Pilot-start SKU: F512 as a conservative starting tier to run the pilot on.

Pricing (from API):
  F512 PAYG monthly: paygCuHourRate × 512 CUs × 730   (priceType eq 'Consumption', '* Capacity Usage CU' meter)
  F512 1-yr RI monthly: reservationRetailPrice × 512 CUs ÷ 12   (reservation row is a TERM TOTAL, not ×730)
  Storage: 5 TB × 1024 × OneLake Hot rate

Recommendation: Start F512 PAYG → monitor 30 days → right-size down (e.g., to F256 RI) if measured CU is lower