SQL 仓库大小调整、缩放和队列行为
本文介绍 SQL 仓库的群集大小调整、排队和自动缩放行为。
调整无服务器 SQL 仓库的大小
对于无服务器 SQL 仓库，始终从超出预期需要的更大的 T 恤尺寸开始，并在测试时减小大小。 不要从较小的无服务器 SQL 仓库 T 恤尺寸开始，然后再增加大小。 一般情况下，请从单个无服务器 SQL 仓库开始，并依赖于 Azure Databricks 来正确调整无服务器群集的大小，从而确定工作负载和快速数据读取的优先级。 请参阅无服务器自动缩放和查询排队。
- 要减少给定无服务器 SQL 仓库的查询延迟，请执行以下操作，请执行以下操作：
- 如果查询溢出到磁盘，则增加 T 恤尺寸。
- 如果查询高度可并行，则增加 T 恤尺寸。
- 如果一次运行多个查询，请添加群集以实现自动缩放。
- 为了降低成本，请尝试在不会溢出到磁盘或显著增加延迟的情况下逐步减小 T 恤尺寸。
- 要帮助正确调整无服务器 SQL 仓库的大小，请使用以下工具：
注意
在某些情况下，无服务器 SQL 仓库的群集大小使用的实例类型可能与专业和经典 SQL 仓库文档中针对同等群集大小列出的实例类型不同。 总的来说，对于无服务器 SQL 仓库，其群集大小的性价比与专业和经典 SQL 仓库的相似。
无服务器自动缩放和查询队列
智能工作负载管理 (IWM) 是一组功能，可以增强无服务器 SQL 仓库快速且经济高效地处理大量查询的能力。 它使用机器学习模型预测传入查询的资源需求并同时实时监视仓库的可用计算容量，从而动态地管理工作负载。 跟踪仓库中的这些信号和其他信号使 IWM 能够响应工作负载需求的变化。
此动态管理允许 IWM 执行以下操作：
- 快速纵向扩展计算，以保持低延迟。
- 更接近硬件限制的速率提供查询准入。
- 快速纵向缩减，以在需求较低时将成本降到最低。
当查询到达仓库时，IWM 将预测查询的成本。 同时，IWM 将会实时监视仓库的可用计算容量。 接下来，使用机器学习模型，IWM 可预测传入查询在现有计算上是否具有可用的必要计算。 如果没有所需的计算，则会将查询添加到队列中。 如果确实具有所需的计算，查询将立即开始运行。
IWM 大约每 10 秒监视一次队列。 如果队列速度不够快，自动缩放将开始快速采购更多计算。 添加新容量后，将会准许排队的查询进入新计算资源。 使用无服务器 SQL 仓库可以快速添加新的计算。 所有 SQL 仓库类型的队列中的最大查询数为 1000。
专业和经典 SQL 仓库的群集大小
本部分中的表将 SQL 仓库群集大小映射到 Azure Databricks 群集驱动程序大小和辅助角色计数。 驱动程序大小仅适用于专业和经典 SQL 仓库。
| 群集大小 | 驱动程序的实例类型（仅适用于专业和经典 SQL 仓库） | 辅助角色计数 |
|---|---|---|
| 2X-小 | Standard_E8ds_v4 | 1 x Standard_E8ds_v4 |
| X-小 | Standard_E8ds_v4 | 2 x Standard_E8ds_v4 |
| 小 | Standard_E16ds_v4 | 4 x Standard_E8ds_v4 |
| 中 | Standard_E32ds_v4 | 8 x Standard_E8ds_v4 |
| 大 | Standard_E32ds_v4 | 16 x Standard_E8ds_v4 |
| X-大 | Standard_E64ds_v4 | 32 x Standard_E8ds_v4 |
| 2X-大 | Standard_E64ds_v4 | 64 x Standard_E8ds_v4 |
| 3X-大 | Standard_E64ds_v4 | 128 x Standard_E8ds_v4 |
| 4X-大 | Standard_E64ds_v4 | 256 x Standard_E8ds_v4 |
所有辅助角色的实例大小都是 Standard_E8ds_v4。
每个驱动程序和辅助角色均附加了 8 个 128 GB 标准 LRS 托管磁盘。 附加的磁盘按小时收费。
经典和专业 SQL 仓库所需的 Azure vCPU 配额
若要启动经典或专业 SQL 仓库，你的 Azure 帐户中必须为 Standard_E8ds_v4 实例提供足够的 Azure vCPU 配额。 使用以下准则来确定所需的 vCPU 配额：
- 如果只有一个或两个 SQL 仓库，请确保为群集中的每个核心提供 8 个 Azure vCPU。 这样可确保拥有足够多的 Azure vCPU 来处理大约每 24 小时发生一次的仓库重新预配。 如果 SQL 仓库使用自动缩放或多群集负载均衡，则可能需要增加倍数。
- 随着 SQL 仓库数量的增加，群集的每个核心可以拥有 4 到 8 个 Azure vCPU。 Databricks 建议从较大的数字开始并监视稳定性。
- SQL 仓库使用的 Azure vCPU 是对 Azure vCPU（供“数据科学与工程”使用的群集或非 Databricks 工作负载使用）的补充。
若要请求额外的 Azure vCPU 配额，请参阅 Azure 文档中的标准配额：按 VM 序列提高上限。
注意
此表中的信息可能因产品或区域可用性和工作区类型而异。
专业和经典 SQL 仓库的排队和自动缩放
Azure Databricks 根据计算结果的成本限制分配给 SQL 仓库的群集上的查询数。 每个仓库的群集纵向扩展取决于查询吞吐量、传入查询的速率和队列大小。 Azure Databricks 建议为每 10 个并发查询使用一个群集。 所有 SQL 仓库类型的队列中的最大查询数为 1000。
Azure Databricks 根据处理所有当前正在运行的查询、所有排队的查询以及在接下来的两分钟内预计传入的查询所需的时间，来添加群集。
- 如果少于 2 分钟，请勿增大规模。
- 如果为 2 到 6 分钟，请添加 1 个群集。
- 如果为 6 到 12 分钟，请添加 2 个群集。
- 如果为 12 到 22 分钟，请添加 3 个集群。
其他情况下，Azure Databricks 将添加 3 个群集，并每增加 15 分钟的预期查询负载就添加 1 个群集。
此外，如果查询在队列中等待 5 分钟，则始终会纵向扩展仓库。
如果处于低负载达到 15 分钟，则 Azure Databricks 将纵向缩减 SQL 仓库。 Azure Databricks 会保留足够的群集来处理最后 15 分钟的峰值负载。 例如，如果峰值负载为 25 个并发查询，Azure Databricks 会保留 3 个群集。
专业和经典 SQL 仓库的查询队列
当分配给仓库的所有群集都以满负荷状态执行查询或仓库处于 STARTING 状态时，Azure Databricks 会让查询排队。 所有 SQL 仓库类型的队列中的最大查询数为 1000。
元数据查询（例如 DESCRIBE <table>）和状态修改查询（例如 SET）永远不会排队，除非仓库处于 STARTING 状态。