Punto de comprobación del estado asincrónico para consultas con estado

Nota:

Disponible en Databricks Runtime 10.4 LTS y versiones posteriores.

La creación de puntos de comprobación de estado asincrónico mantiene garantías exactamente una vez para las consultas de streaming, pero puede reducir la latencia general de algunas cargas de trabajo con estado de Structured Streaming que tengan cuellos de botella en las actualizaciones de estado. Esto se logra empezando a procesar el siguiente microlote tan pronto como se haya completado el cálculo del microlote anterior, sin esperar a que se complete el punto de comprobación de estado. En la tabla siguiente se comparan los inconvenientes de los puntos de comprobación sincrónicos y asincrónicos:

Característica	Creación de puntos de comprobación sincrónicos	Creación de puntos de control asincrónicos
Latencia	Mayor latencia para cada microlote.	Latencia reducida, ya que los microlotes se pueden superponer.
Restart (Reiniciar)	Recuperación rápida, ya que solo el último lote debe volver a ejecutarse.	Mayor retraso de reinicio, ya que es posible que sea necesario volver a ejecutar más de un microlote.

A continuación, se muestran las características del trabajo de streaming que pueden beneficiarse de los puntos de comprobación de estado asincrónicos:

• El trabajo contiene una o varias operaciones con estado (por ejemplo, agregación, flatMapGroupsWithState, mapGroupsWithState, combinaciones flujo-flujo)
• La latencia de punto de comprobación de estado es uno de los principales colaboradores de la latencia general de ejecución por lotes. Esta información se puede encontrar en los eventos StreamingQueryProgress. Estos eventos también se encuentran en los registros log4j del controlador de Spark. Este es un ejemplo del progreso de la consulta de streaming y de cómo encontrar el impacto del punto de comprobación de estado en la latencia general de ejecución de lotes.

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

  • Análisis de latencia del punto de comprobación de estado del evento de progreso de la consulta anterior

    • La duración del lote (durationMs.triggerDuration) es de aproximadamente 547 segundos.
    • La latencia de confirmación del almacén de estado (stateOperations[0].commitTimeMs) es de aproximadamente 3186 segundos. La latencia de confirmación se agrega entre las tareas que contienen un almacén de estado. En este caso, hay 64 tareas de este tipo (stateOperators[0].numShufflePartitions).
    • Cada tarea que contiene el operador de estado tardó un promedio de 50 segundos (3186/64) en el punto de comprobación. Se trata de una latencia adicional que contribuye a la duración del lote. Suponiendo que las 64 tareas se ejecutan simultáneamente, el paso de punto de comprobación ha contribuido en torno al 9 % (50 s/547 s) de la duración del lote. El porcentaje es incluso mayor cuando el número máximo de tareas simultáneas es menor que 64.

Habilitación de un punto de comprobación de estado asincrónico

Debe usar el almacén de estado basado en RocksDB para la creación de puntos de comprobación de estado asincrónicos. Establezca las siguientes configuraciones:

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

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

Limitaciones y requisitos de los puntos de comprobación asincrónicos

Nota:

El escalado automático de proceso tiene limitaciones al reducir verticalmente el tamaño del clúster para cargas de trabajo de Structured Streaming. Databricks recomienda usar tablas Delta Live con escalado automático mejorado para cargas de trabajo de streaming. Consulte Optimización del uso del clúster de canalizaciones de Delta Live Tables con escalado automático mejorado.

• Cualquier error de un punto de comprobación asincrónico en uno o varios almacenes genera un error en la consulta. En el modo de punto de comprobación sincrónico, el punto de comprobación se ejecuta como parte de la tarea y Spark reintenta la tarea varias veces antes de generar un error en la consulta. Este mecanismo no está presente con los puntos de comprobación de estado asincrónicos. Databricks recomienda usar trabajos continuos para reintentos automáticos en caso de error de trabajo. Consulte Ejecución de trabajos continuamente.
• Los puntos de comprobación asincrónicos funcionan mejor cuando las ubicaciones de almacenamiento de estado no cambian entre las ejecuciones de microlotes. Es posible que el cambio de tamaño del clúster, en combinación con los puntos de comprobación de estado asincrónicos, no funcione bien porque la instancia de los almacenes de estado podría volver a distribuirse a medida que se agregan o eliminan nodos como parte del evento de cambio de tamaño del clúster.
• Los puntos de comprobación de estado asincrónicos solo se admiten en la implementación del proveedor de almacén de estado de RocksDB. La implementación predeterminada del almacén de estado en memoria no los admite.