Actualización completa para tablas de streaming

Una actualización completa de una tabla de streaming descarta todos los datos y metadatos existentes y reinicia la secuencia desde el principio. En concreto, trunca la tabla de streaming, quita todos los datos del punto de control y reinicia el proceso de streaming con nuevos puntos de control para cada flujo que escribe en la tabla. En esta página se describe cuándo podría ser necesario ejecutar una actualización completa y el impacto de ejecutar una actualización completa. También incluye procedimientos recomendados en torno a las actualizaciones completas.

Para obtener instrucciones sobre cómo desencadenar una actualización completa, consulte Ejecución de una actualización de canalización.

Impacto en los orígenes de datos

Una actualización completa quita todos los datos existentes de la tabla de streaming. Si el origen de datos tiene límites de retención (como temas de Kafka con períodos de retención cortos), algunos datos históricos pueden volverse irrecuperables después de una actualización completa.

Por ejemplo, si el origen es Kafka con retención de 24 horas y ejecuta una actualización completa después de esa ventana, los mensajes anteriores ya no están disponibles y no se pueden volver a procesar.

Nota:

Las actualizaciones completas no se recomiendan para cargas de trabajo de streaming de gran volumen o cuando la retención ascendente impide la reproducción de datos históricos.

Si la tabla de transmisión tiene tablas derivadas dependientes, se producirá un error en la canalización hasta que esas tablas también se actualicen completamente, a menos que la tabla de transmisión tenga skipChangeCommits habilitado. Las vistas materializadas descendentes también deben ser completamente actualizadas.

Cuándo ejecutar una actualización completa

Los refrescos completos de las canalizaciones declarativas de Lakeflow Spark deben ser desencadenados explícitamente. Puede ejecutar una actualización completa haciendo clic en Actualización completa en la interfaz de usuario de la canalización o habilitando la actualización completa automática en Lakeflow Connect.

Se recomienda una actualización completa cuando los cambios impiden que una consulta de streaming se reanude de forma segura desde su punto de control existente, o cuando los datos procesados previamente se vuelvan incoherentes con la lógica actualizada, el esquema o la configuración de origen. En las secciones siguientes se describen escenarios comunes.

Cambios en los esquemas

Los siguientes cambios de esquema en la tabla de destino no son compatibles con versiones anteriores y requieren una actualización completa:

  • Cambiar el nombre de las columnas sin el modo de asignación de columnas habilitado.
  • Cambiar las columnas de desduplicación.
  • Modificar tipos de datos de columna, entre los que se incluyen:
    • Restricción de tipos (por ejemplo, BIGINT → INT o DOUBLE → FLOAT).
    • Cambios de tipo incompatibles (por ejemplo, STRING → INT).
  • Eliminación definitiva de columnas del esquema de la tabla.

Para estos tipos de cambios de esquema, Databricks recomienda crear una nueva columna con el esquema o el nombre deseados y, a continuación, usar una vista sobre la tabla de streaming para unir los valores antiguos y nuevos.

Cambios en el diseño de datos físicos

Los siguientes cambios de diseño de datos físicos requieren una actualización completa:

  • Migración de particiones heredadas a un nuevo esquema de agrupación en clústeres.

Cambios en la fuente upstream

Los siguientes cambios de origen ascendentes requieren una actualización completa:

  • Modificar las tablas de origen leídas por la consulta de streaming.
  • Cambiar entre tipos de origen (por ejemplo, Kafka a Delta o Auto Loader a Kafka).
  • Cambio de ubicaciones de origen, como rutas de acceso de tabla o suscripciones de temas de Kafka.
  • Quitar y volver a crear una tabla delta de origen, incluso cuando el esquema permanece sin cambios.

Cambios en el procesamiento con estado

Los siguientes cambios de procesamiento stateful requieren una actualización completa:

  • Modificar las claves de agrupación o las funciones de agregación.
  • Agregar o remover agregados.
  • Cambiar las claves de combinación o los tipos de combinación.
  • Agregar o quitar uniones.
  • Modificar columnas de desduplicación o lógica de desduplicación.

Problemas de continuidad de datos

Es posible que se requiera una actualización completa cuando la continuidad de los datos esté en peligro:

  • Los registros CDC se han vuelto inaccesibles debido al vencimiento de la retención de datos.
  • Daños o eliminación del directorio del punto de control de transmisión.
  • Corrupción o pérdida de archivos de seguimiento de esquemas o de ubicación de esquemas.

Para obtener más información sobre cómo recuperar una canalización a partir de un error de punto de control, consulte Recuperación de una canalización a partir de un error de punto de control de streaming.

Limitaciones

Las siguientes limitaciones se aplican a las actualizaciones completas. Consulte Procedimientos recomendados para obtener información para ayudar a trabajar dentro de estas limitaciones.

  • Una actualización completa no vuelve a procesar los datos a menos que el origen conserve el conjunto de datos histórico completo.
  • Los conjuntos de datos grandes pueden hacer que las actualizaciones completas sean costosas y lentas.
  • Los consumidores finales que dependen de la tabla pueden fallar o devolver resultados incompletos hasta que se complete el refresco.

procedimientos recomendados

Situación procedimientos recomendados
Diseño para estabilidad Planee el esquema para evitar cambios que requieran una actualización completa. La adición de columnas suele ser segura, mientras que la modificación de las columnas existentes o esquemas de partición normalmente requiere volver a calcular la tabla.
Transmisión desde orígenes con períodos de retención cortos El streaming desde orígenes, como un tópico de Kafka, que no tienen largos períodos de retención, significa que una actualización completa pierde los datos ya no en el origen.
Para evitar la pérdida de datos históricos, transmita los datos sin procesar a una tabla de transmisión (también conocida como tabla bronce, en la arquitectura de medallón). Use tipos de columna flexibles (variante o cadena, por ejemplo), para evitar que esta tabla requiera una actualización completa si cambian los datos ascendentes. Esta tabla puede almacenar datos históricos y usarse en tablas de streaming de bajada (que pueden tener tipos más estrictos u otros cambios estructurales). Si las tablas de salida requieren una actualización completa, esta tabla tiene datos históricos; sin embargo, no requiere una actualización completa por sí misma.
Considerar alternativas antes de ejecutar una actualización completa De forma alternativa, puedes hacer lo siguiente:
  • Si cambia el origen de un flujo, considere la posibilidad de crear un nuevo flujo en lugar de actualizar el flujo existente de una tabla de streaming. Esto conserva los datos existentes en la tabla, pero puede escribir datos duplicados porque el nuevo flujo tiene un nuevo punto de control.
  • Como alternativa, puede restablecer el punto de control, pero esto puede provocar que se escriban datos duplicados en la tabla de destino.
  • Si ninguna opción es aceptable, considere la posibilidad de crear una nueva tabla de streaming y usar una vista para unir las tablas de streaming antiguas y nuevas.
Cuando se requiere una actualización completa Siga estos procedimientos recomendados cuando se requiera una actualización completa:
  • Pruebe la operación en un entorno de desarrollo o ensayo.
  • Documente las dependencias de bajada que se ven afectadas.
  • Programe la actualización durante una ventana de mantenimiento para minimizar el impacto en las cargas de trabajo de producción.
  • Asegúrese de que el sistema de origen conserva suficientes datos históricos para reproducir la secuencia.

Para rellenar los datos después de una actualización completa, puede crear un append onceflujo. Esto realiza un reposicionamiento único sin continuar ejecutándose después de la primera ejecución de reposicionamiento. El código permanece en el pipeline y, si alguna vez se actualiza completamente de nuevo, el backfill se ejecuta nuevamente.

  • Last updated on