SQL 仓库大小调整、缩放和队列行为
本文介绍 SQL 仓库的群集大小调整、排队和自动缩放行为。
尺寸概述
SQL 仓库在无服务器、专业和经典类型中可用，这些类型具有不同的性能功能和优化，这些特性和优化可能会影响仓库中的查询性能。 请参阅 SQL 仓库类型。 Databricks 建议在可用时使用无服务器 SQL 仓库。
对于任何类型的仓库，您需要选择其计算资源的群集大小 。 优化 Databricks SQL 仓库大小不仅仅是考虑数据量或用户计数。 查询复杂性和并发查询数也是性能的关键因素。
Databricks SQL 仓库使用动态并发来处理这些需求。 与静态容量仓库不同，Databricks SQL 实时调整计算资源，以管理并发负载并最大化吞吐量。 每个仓库大小类别每个单位都有固定的计算容量，但系统会缩放资源数量以满足不同的需求。
SQL 仓库的群集大小
本部分中的表将 SQL 仓库群集大小映射到 Azure Databricks 群集驱动程序大小和辅助角色计数。 驱动程序大小仅适用于专业和经典 SQL 仓库。
注意
对于无服务器 SQL 仓库，在某些情况下，群集大小可能会使用与专业和经典 SQL 仓库文档中列出的实例类型不同的实例类型，以用于等效群集大小。 总的来说，对于无服务器 SQL 仓库，其群集大小的性价比与专业和经典 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 仓库的群集上的查询数。 每个仓库群集的纵向扩展基于查询吞吐量、传入查询速率和队列大小。 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 个群集。
无服务器自动缩放和查询队列
智能工作负荷管理（IWM）是一组功能，可增强无服务器 SQL 仓库快速且经济高效地处理大量查询的能力。 它使用机器学习模型预测传入查询的资源需求并同时实时监视仓库的可用计算容量，从而动态地管理工作负载。 跟踪仓库中的这些信号和其他信号使 IWM 能够响应工作负载需求的变化。
此动态管理允许 IWM 执行以下操作：
- 快速纵向扩展计算，以保持低延迟。
- 更接近硬件限制的速率提供查询准入。
- 快速纵向缩减，以在需求较低时将成本降到最低。
当查询到达仓库时，IWM 将预测查询的成本。 同时，IWM 将会实时监视仓库的可用计算容量。 接下来，使用机器学习模型，IWM 可预测传入查询在现有计算上是否具有可用的必要计算。 如果没有所需的计算，则会将查询添加到队列中。 如果确实具有所需的计算，查询将立即开始运行。
IWM 实时监视队列。 如果队列的减少速度不够快，自动缩放会预配更多计算资源。 添加新容量后，将会准许排队的查询进入新计算资源。 使用无服务器 SQL 仓库可以快速添加新的计算。 所有 SQL 仓库类型的队列中的最大查询数为 1000。
调整无服务器 SQL 仓库的大小
对于无服务器 SQL 仓库，始终从超出预期需要的更大尺寸开始，并在测试时减小大小。 不要以较小的规模开始您的无服务器 SQL 仓库，然后逐渐增加。 一般情况下，请从单个无服务器 SQL 仓库开始，并依赖于 Azure Databricks 来正确调整无服务器群集的大小，从而确定工作负载和快速数据读取的优先级。 请参阅无服务器自动缩放和查询排队。
- 要减少给定无服务器 SQL 仓库的查询延迟，请执行以下操作，请执行以下操作：
- 如果查询溢出到磁盘，则增加 T 恤尺寸。
- 如果查询高度可并行，则增加 T 恤尺寸。
- 如果一次运行多个查询，请添加群集以实现自动缩放。
- 为了降低成本，请尝试在不溢出到磁盘或显著增加延迟的情况下缩小规模。
用于监视和评估性能的工具
若要帮助调整 SQL 仓库的大小，请使用以下工具：