Share via

SQL 倉儲大小調整、縮放和佇列行為

  • 發行項

本文說明 SQL 倉儲的叢集大小調整、佇列和自動調整行為。

調整無伺服器 SQL 倉儲的大小

一律從無伺服器 SQL 倉儲的 T 恤大小開始，而不是您在測試時需要和縮小大小。 請勿從無伺服器 SQL 倉儲的小型 T 恤大小開始，並繼續進行。 一般而言，從單一無伺服器 SQL 倉儲開始，並依賴 Azure Databricks 以無伺服器叢集、將工作負載優先順序設定為適當大小，以及快速讀取數據。 請參閱 無伺服器自動調整和查詢佇列。

  • 若要減少給定無伺服器 SQL 倉儲的查詢延遲：
    • 如果查詢溢出到磁碟，請增加 T 恤大小。
    • 如果查詢可高度平行處理，請增加 T 恤大小。
    • 如果您一次執行多個查詢，請新增更多叢集以進行自動調整。
  • 若要降低成本，請嘗試在不溢出到磁碟或大幅增加延遲的情況下，以 T 恤尺寸下調。
  • 若要協助調整無伺服器 SQL 倉儲的大小，請使用下列工具：
    • 監視頁面：查看尖峰查詢計數。 如果尖峰佇列通常高於其中一個，請新增叢集。 所有 SQL 倉儲類型佇列中的查詢數目上限為 1000。 請參閱 監視 SQL 倉儲。
    • 查詢歷程記錄。 請參閱 查詢歷程記錄。
    • 查詢配置檔（尋找 溢出至 磁碟超過1的位元組）。 請參閱 查詢配置檔。

注意

對於無伺服器 SQL 倉儲，在某些情況下，叢集大小可能會使用與 Pro 和傳統 SQL 倉儲檔中所列的實例類型不同的實例類型，以取得對等的叢集大小。 一般而言，無伺服器 SQL 倉儲的叢集大小價格/效能比率與 Pro 和傳統 SQL 倉儲的價格/效能比率類似。

無伺服器自動調整和查詢佇列

智慧型手機工作負載管理 （IWM） 是一組功能，可增強無伺服器 SQL 倉儲快速且符合成本效益地處理大量查詢的能力。 IWM 使用 AI 支援的預測功能來分析傳入的查詢，並判斷最快且更有效率的 （預測 IO），可確保工作負載能快速擁有正確的資源量。 主要差異在於 Databricks SQL 中的 AI 功能，以動態回應工作負載需求，而不是使用靜態閾值。

此回應性可確保：

  • 快速上調，以在需要時取得更多計算，以維持低延遲。
  • 更接近硬體限制的查詢承認。
  • 快速縮減，以在需求不足時將成本降到最低，並提供一致的效能與優化的成本和資源。

當查詢到達倉儲時，IWM 會預測查詢的成本。 同時，IWM 會即時監視倉儲的可用計算容量。 接下來，使用機器學習模型，IWM 會預測傳入查詢是否有現有計算上可用的必要計算。 如果沒有所需的計算，則會將查詢新增至佇列。 如果確實需要計算，查詢就會立即開始執行。

IWM 會監視佇列大約每 10 秒。 如果佇列速度不夠快，自動調整就會開始快速採購更多計算。 新增容量之後，佇列查詢就會被接納到新的叢集。 使用無伺服器 SQL 倉儲時，可以快速新增新的叢集，而且一次可以建立多個叢集。 所有 SQL 倉儲類型佇列中的查詢數目上限為 1000。

專業和傳統 SQL 倉儲的叢集大小

本節中的表格會將 SQL 倉儲叢集大小對應至 Azure Databricks 叢集驅動程式大小和背景工作角色計數。 驅動程式大小僅適用於 Pro和傳統 SQL 倉儲。

叢集大小 驅動程式的實體類型（僅適用於 Pro 和傳統 SQL 倉儲） 背景工作計數
2X-Small Standard_E8ds_v4 1 x Standard_E8ds_v4
X-Small Standard_E8ds_v4 2 x Standard_E8ds_v4
Small 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-Large Standard_E64ds_v4 32 x Standard_E8ds_v4
2X-Large Standard_E64ds_v4 64 x Standard_E8ds_v4
3X-Large Standard_E64ds_v4 128 x Standard_E8ds_v4
4X-Large Standard_E64ds_v4 256 x Standard_E8ds_v4

所有背景工作角色的實例大小都會Standard_E8ds_v4。

每個驅動程式和背景工作角色都有 8 個 128 GB 的標準 LRS 受控磁碟連結。 連結的磁碟會每小時收費。

傳統和 Pro SQL 倉儲所需的 Azure vCPU 配額

若要啟動傳統或 pro SQL 倉儲，您必須有足夠的 Azure vCPU 配額，才能在 Azure 帳戶中Standard_E8ds_v4實例。 使用下列指導方針來判斷所需的 vCPU 配額：

  • 如果您只有一或兩個 SQL 倉儲，請確定您有 8 個 Azure vCPU 可供叢集中的每個核心使用。 這可確保您有足夠的 Azure vCPU 來考慮重新布建大約每 24 小時發生的倉儲。 如果您的 SQL 倉儲使用自動調整或多重叢集負載平衡，您可能需要增加乘數。
  • 隨著 SQL 倉儲數目的增加，允許叢集中每個核心的 4 到 8 個 Azure vCPU。 Databricks 建議從較大的數目開始，並監視穩定性。
  • SQL 倉儲所使用的 Azure vCPU 除了 資料科學 和工程或非 Databricks 工作負載所使用的叢集所使用的 Azure vCPU 之外。

若要要求額外的 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 會每隔 15 分鐘新增 3 個叢集加上 1 個叢集，以達到預期的查詢負載。

此外，如果查詢在佇列中等候 5 分鐘，則一律會向上調整倉儲。

如果負載不足 15 分鐘，Azure Databricks 會縮減 SQL 倉儲。 它會保留足夠的叢集來處理過去 15 分鐘的尖峰負載。 例如，如果尖峰負載是 25 個並行查詢，Azure Databricks 會保留 3 個叢集。

專業和傳統 SQL 倉儲的查詢佇列

當指派給倉儲的所有叢集都以完整容量或處於 STARTING 狀態時執行查詢時，Azure Databricks 會排入查詢佇列。 所有 SQL 倉儲類型佇列中的查詢數目上限為 1000。

除非倉儲處於STARTING狀態，否則元數據查詢（例如DESCRIBE <table>）和狀態修改查詢（例如SET）永遠不會排入佇列。