具狀態查詢的非同步狀態檢查點

注意

可在 Databricks Runtime 10.4 LTS 和更新版本中使用。

非同步狀態檢查點會針對串流查詢維持一次的保證，但可能會降低某些結構化串流具狀態工作負載在狀態更新上發生瓶頸時的整體延遲。 這可藉由前一個微批次的計算完成後立即開始處理下一個微批次來完成，不需要等待狀態檢查點完成。 下表比較同步和非同步檢查點的權衡取捨：

特性	同步檢查點	非同步檢查點
延遲	每個微批次的延遲較高。	減少延遲，因為微批次可以重疊。
重新啟動	快速復原，因為只需要重新執行最後一個批次。	重新啟動延遲較高，因為可能需要重新執行多個微批次。

以下是可能受益於非同步狀態檢查點的串流工作特性：

• 工作有一或多個具狀態作業 (例如彙總、flatMapGroupsWithState、mapGroupsWithState、串流至串流聯結)
• 狀態檢查點延遲是整體批次執行延遲的主要歸因之一。 您可以在 StreamingQueryProgress 事件中找到此資訊。 這些事件也會在 Spark 驅動程式的 log4j 記錄中找到。 以下是串流查詢進度的範例，以及如何尋找狀態檢查點對整體批次執行延遲的影響。

  • {
       "id" : "2e3495a2-de2c-4a6a-9a8e-f6d4c4796f19",
       "runId" : "e36e9d7e-d2b1-4a43-b0b3-e875e767e1fe",
       "...",
       "batchId" : 0,
       "durationMs" : {
         "...",
         "triggerExecution" : 547730,
         "..."
       },
       "stateOperators" : [ {
         "...",
         "commitTimeMs" : 3186626,
         "numShufflePartitions" : 64,
         "..."
       }]
    }
    

  • 上述查詢進度事件的狀態檢查點延遲分析

    • 批次持續時間 (durationMs.triggerDuration) 約為 547 秒。
    • 狀態存放區提交延遲 (stateOperations[0].commitTimeMs) 約為 3,186 秒。 提交延遲會彙總到包含狀態存放區的工作。 在此情況下，有 64 個此類工作 (stateOperators[0].numShufflePartitions)。
    • 含有狀態運算子的每個檢查點工作平均花費 50 秒 (3,186/64)。 這是造成批次持續時間的額外延遲。 假設所有 64 個工作同時執行，檢查點步驟貢獻了約 9% 的批次持續時間 (50 秒/547 秒)。 最大並行工作小於 64 時，百分比會更高。

啟用非同步狀態檢查點

您必須使用 RocksDB 型狀態存放區進行非同步狀態檢查。 設定下列組態：

spark.conf.set(
  "spark.databricks.streaming.statefulOperator.asyncCheckpoint.enabled",
  "true"
)

spark.conf.set(
  "spark.sql.streaming.stateStore.providerClass",
  "com.databricks.sql.streaming.state.RocksDBStateStoreProvider"
)

非同步檢查點的限制和需求

注意

在縮小結構化串流工作負載的叢集大小時，計算自動調整有其限制。 Databricks 建議針對串流工作負載使用差異即時資料表與增強型自動調整。 請參閱 使用增強型自動調整來優化差異實時數據表管線的叢集使用率。

• 任何一或多個存放區的非同步檢查點中發生任何失敗，都會導致查詢失敗。 在同步檢查點模式中，檢查點會以工作的一部分執行，而 Spark 會在查詢失敗之前多次重試工作。 此機制不存在於非同步狀態檢查點。 Databricks 建議在工作失敗時使用連續工作來自動重試。 請參閱持續執行作業。
• 狀態存放區位置未在微批次執行之間變更時，非同步檢查點的運作效果最佳。 叢集調整大小與非同步狀態檢查點結合後可能無法正常運作，因為狀態存放區執行個體可能會隨著節點在叢集調整大小事件中新增或刪除而重新散發。
• 只有 RocksDB 狀態存放區提供者實作才支援非同步狀態檢查點。 預設記憶體內部狀態存放區實作並不支援。