En esta página, se proporcionan orientación y recomendaciones para actualizar tus canalizaciones de transmisión. Por ejemplo, es posible que debas actualizar a una versión más reciente del SDK de Apache Beam o que desees actualizar el código de tu canalización. Se proporcionan diferentes opciones para adaptarse a distintas situaciones.
Mientras que las canalizaciones por lotes se detienen cuando el trabajo se completa, las canalizaciones de transmisión a menudo se ejecutan de forma continua para proporcionar un procesamiento sin interrupciones. Por lo tanto, cuando actualices las canalizaciones de transmisión, debes tener en cuenta las siguientes consideraciones:
- Es posible que debas minimizar o evitar interrupciones en la canalización. En algunos casos, es posible que puedas tolerar una interrupción temporal del procesamiento mientras se implementa una nueva versión de una canalización. En otros casos, es posible que tu aplicación no pueda tolerar ninguna interrupción.
- Los procesos de actualización de la canalización deben controlar los cambios de esquema de una manera que minimice la interrupción del procesamiento de mensajes y de otros sistemas adjuntos. Por ejemplo, si el esquema para los mensajes en una canalización de procesamiento de eventos cambia, los cambios en el esquema también pueden ser necesarios en los receptores de datos descendentes.
Puedes usar uno de los siguientes métodos para actualizar las canalizaciones de transmisión, según los requisitos de actualización y canalización:
- Realizar actualizaciones en tránsito
- Inicia un trabajo de reemplazo
- Ejecuta canalizaciones paralelas
Para obtener más información sobre los problemas que podrías encontrar durante una actualización y cómo evitarlos, consulta Valida un trabajo de reemplazo y Verifica la compatibilidad de trabajos.
Prácticas recomendadas
- Actualiza la versión del SDK de Apache Beam por separado de cualquier cambio en el código de canalización.
- Prueba tu canalización después de cada cambio antes de realizar actualizaciones adicionales.
- Actualiza con regularidad la versión del SDK de Apache Beam que usa tu canalización.
Realiza actualizaciones en tránsito
Puedes actualizar algunas canalizaciones de transmisión en curso sin detener el trabajo. Esta situación se conoce como actualización de trabajo en tránsito. Las actualizaciones de trabajos en tránsito solo están disponibles en circunstancias limitadas:
- El trabajo debe usar Streaming Engine.
- El trabajo debe estar en estado de ejecución.
- Solo estás cambiando la cantidad de trabajadores que usa el trabajo.
Para obtener más información, consulta Configura el rango de ajuste de escala automático en la página Ajuste de escala automático horizontal.
Para obtener instrucciones que expliquen cómo realizar una actualización de trabajo en tránsito, consulta Actualiza una canalización existente.
Inicia un trabajo de reemplazo
Si el trabajo actualizado es compatible con el trabajo existente, puedes actualizar la canalización mediante la opción update. Cuando reemplazas un trabajo existente, uno nuevo ejecuta el código de la canalización actualizada.
El servicio de Dataflow retiene el nombre del trabajo, pero ejecuta el trabajo de reemplazo con un ID de trabajo actualizado. Este proceso puede causar tiempo de inactividad mientras se detiene el trabajo existente, se ejecuta la verificación de compatibilidad y comienza el trabajo nuevo. Para obtener más detalles, consulta Los efectos de reemplazar un trabajo.
Dataflow realiza una verificación de compatibilidad para garantizar que el código de la canalización actualizada se pueda implementar de forma segura en la canalización en ejecución. Ciertos cambios en el código hacen que falle la verificación de compatibilidad, como cuando se agregan o quitan entradas complementarias desde un paso existente. Cuando falla la verificación de compatibilidad, no puedes realizar una actualización de trabajo local.
Para obtener instrucciones que expliquen cómo iniciar un trabajo de reemplazo, consulta Inicia un trabajo de reemplazo.
Si la actualización de la canalización no es compatible con el trabajo actual, debes detener y reemplazar la canalización. Si tu canalización no puede tolerar el tiempo de inactividad, ejecuta canalizaciones paralelas.
Detén y reemplaza las canalizaciones
Si puedes detener el procesamiento de forma temporal, puedes cancelar o desviar la canalización y, luego, reemplazarla por la canalización actualizada. Cancelar una canalización hace que Dataflow detenga de inmediato el procesamiento y apague los recursos lo más rápido posible, lo que puede causar una pérdida de los datos que se procesan, conocidos como datos en tránsito. Para evitar la pérdida de datos, en la mayoría de los casos, se prefiere el desvío. También puedes usar instantáneas de Dataflow para guardar el estado de una canalización de transmisión, lo que te permite iniciar una versión nueva de tu trabajo de Dataflow sin perder el estado. Para obtener más información, consulta Usa instantáneas de Dataflow.
Desviar una canalización cierra de inmediato cualquier ventana en proceso y activa todos los activadores. Aunque los datos en tránsito no se pierden, el desvío puede provocar que las ventanas tengan datos incompletos. Si esto sucede, las ventanas en proceso emiten resultados parciales o incompletos. Para obtener más información, consulta Efectos de la desviación de un trabajo. Una vez que se completa el trabajo existente, puedes iniciar un trabajo de transmisión nuevo que contenga el código de la canalización actualizada, lo que permite que se reanude el procesamiento.
Con este método, incurres en un tiempo de inactividad entre el momento en que se detiene el trabajo de transmisión existente y el momento en que la canalización de reemplazo está lista para reanudar el procesamiento de datos. Sin embargo, cancelar o desviar una canalización existente y, luego, iniciar un trabajo nuevo con la canalización actualizada es menos complicado que ejecutar canalizaciones paralelas.
Para obtener instrucciones más detalladas, consulta Desvía un trabajo de Dataflow. Después de desviar el trabajo actual, inicia uno nuevo con el mismo nombre.
Reprocesamiento de mensajes con Pub/Sub Snapshot y Seek
En algunas situaciones, después de que reemplazas o cancelas una canalización desviada, es posible que tengas que volver a procesar los mensajes de Pub/Sub enviados con anterioridad. Por ejemplo, es posible que debas usar la lógica empresarial actualizada para volver a procesar los datos. La Pub/Sub Seek es una función que te permite volver a reproducir mensajes de una instantánea de Pub/Sub. Puedes usar Pub/Sub Seek con Dataflow para volver a procesar los mensajes desde el momento en que se creó la instantánea de suscripción.
Durante el desarrollo y las pruebas, también puedes usar Pub/Sub Seek para volver a reproducir los mensajes conocidos de forma repetida para verificar el resultado de tu canalización. Cuando usas Pub/Sub Seek, no busques una instantánea de suscripción cuando una canalización consuma la suscripción. Si lo haces, Seek uede invalidar la lógica de marca de agua de Dataflow y podría afectar el procesamiento único de los mensajes de Pub/Sub.
El siguiente es un flujo de trabajo recomendado de gcloud CLI para usar Pub/Sub Seek con canalizaciones de Dataflow en una ventana de la terminal:
Para crear una instantánea de la suscripción, usa el comando
gcloud pubsub snapshots create:gcloud pubsub snapshots create SNAPSHOT_NAME --subscription=PIPELINE_SUBSCRIPTION_NAME
Para desviar o cancelar la canalización, usa el comando
gcloud dataflow jobs draino el comandogcloud dataflow jobs cancel:gcloud dataflow jobs drain JOB_ID
o
gcloud dataflow jobs cancel JOB_ID
Para buscar la instantánea, usa el comando
gcloud pubsub subscriptions seek:gcloud pubsub subscriptions seek SNAPSHOT_NAME
Implementa una canalización nueva que consuma la suscripción.
Ejecuta canalizaciones paralelas
Si necesitas evitar interrupciones en tu canalización de transmisión durante una actualización, ejecuta canalizaciones paralelas. Crea un trabajo de transmisión nuevo que tenga el código de la canalización actualizado y ejecuta la canalización nueva en paralelo con la canalización existente.
Cuando crees la canalización nueva, usa la misma estrategia de períodos que usaste para la canalización existente. Permite que la canalización existente se siga ejecutando hasta que su marca de agua supere la marca de tiempo del primer período completo que procesó la canalización actualizada. Luego, desvía o cancela la canalización existente. La canalización actualizada continúa ejecutándose en su lugar y, por lo tanto, controla el procesamiento por su cuenta.
El diagrama siguiente ilustra este proceso.
En el diagrama, Canalización B es el trabajo actualizado que toma el control de la Canalización A. El valor t es la marca de tiempo del primer período completo que procesó la canalización B. El valor w es la marca de agua de la canalización A. Por motivos de simplicidad, una marca de agua perfecta se da por sentada sin datos tardíos. El procesamiento y el tiempo se representan en el eje horizontal. Ambas canalizaciones usan ventanas fijas de cinco minutos (de saltos de tamaño constante). Los resultados se activan después de que la marca de agua pasa el final de cada período.
Debido a que el resultado simultáneo ocurre durante el período en el que se superponen las dos canalizaciones, configura las dos canalizaciones para escribir resultados en diferentes destinos. Luego, los sistemas descendentes pueden usar una abstracción sobre los dos receptores de destino, como una vista de base de datos, para consultar los resultados combinados. Estos sistemas también pueden usar la abstracción para anular los resultados duplicados del período superpuesto.
En el siguiente ejemplo, se describe el enfoque que consiste en usar una canalización que lee datos de entrada de Pub/Sub, realiza un procesamiento y escribe los resultados en BigQuery.
En el estado inicial, la canalización de transmisión existente (Canalización A) se ejecuta y lee mensajes de un tema de Pub/Sub (Tema) mediante una suscripción (Suscripción A). Los resultados se escriben en una tabla de BigQuery (Tabla A). Los resultados se procesan a través de una vista de BigQuery, que actúa como fachada para enmascarar los cambios subyacentes de la tabla. Este proceso es una aplicación de un método de diseño llamado patrón de fachada. En el siguiente diagrama, se muestra el estado inicial.
Crea una nueva suscripción (Suscripción B) para la canalización actualizada. Implementa la canalización actualizada (Canalización B), que lee del tema de Pub/Sub (Tema) con la Suscripción B y escribe en una tabla de BigQuery separada (Tabla B). En el diagrama siguiente, se ilustra este flujo:
En este punto, la canalización A y la canalización B se ejecutan en paralelo y escriben resultados en tablas separadas. Debes registrar el tiempo t como la marca de tiempo del primer período completo que procesa la canalización B.
Cuando la marca de agua de la Canalización A supere el tiempo t, desvía la Canalización A. Cuando desvías la canalización, se cierran las ventanas abiertas y se completa el procesamiento de los datos en tránsito. Si la canalización contiene ventanas y las ventanas completas son importantes (suponiendo que no hay datos tardíos), antes de desviar la Canalización A, permite que ambas canalizaciones se ejecuten hasta que tengas ventanas superpuestas completas. Detén el trabajo de transmisión de la Canalización A después de procesar todos los datos en tránsito y escribirlos en la tabla A. En el siguiente diagrama, se muestra esta etapa.
En este punto, solo se está ejecutando la Canalización B. Puedes realizar una consulta desde una vista de BigQuery (vista de fachada), que actúa como una fachada para la tabla A y la tabla B. En las filas que tienen la misma marca de tiempo en ambas tablas, configura la vista para que muestre las filas de la Tabla B o, si las filas no existen en la Tabla B, recurra a la Tabla A. En el siguiente diagrama, se muestra la lectura de la vista (vista de fachada) de la tabla A y la tabla B.
En este punto, puedes borrar la suscripción A.
Cuando se detectan problemas con una implementación de canalización nueva, tener canalizaciones paralelas puede simplificar la reversión. En este ejemplo, es posible que quieras mantener la Canalización A en ejecución mientras supervisas la Canalización B para lograr una operación correcta. Si se produce algún problema con la Canalización B, puedes recurrir a la Canalización A.
Limitaciones
Este enfoque tiene las siguientes limitaciones:
- Es probable que la ejecución de dos canalizaciones en la misma entrada genere datos duplicados en la salida. El sistema descendente debe estar al tanto de los datos duplicados y ser capaz de tolerarlos.
- Cuando se lee desde una fuente de Pub/Sub, no se recomienda usar la misma suscripción para varias canalizaciones y se pueden generar problemas de precisión. Sin embargo, en algunos casos de uso, como extraer, transformar y cargar (ETL) canalizaciones, el uso de la misma suscripción en dos canalizaciones puede reducir la duplicación. Es probable que en esta situación existan problemas con el ajuste de escala automático, pero se pueden mitigar a través del uso de la función de actualización de trabajo en tránsito. Si deseas obtener más información, consulta Optimiza el ajuste de escala automático para tus canalizaciones de transmisión de Pub/Sub.
- Cuando se lee desde una fuente de Pub/Sub, el uso de una segunda suscripción genera duplicados, pero no genera problemas con la precisión de los datos y el ajuste de escala automático.
Administra las mutaciones del esquema
Los sistemas de control de datos suelen necesitar adaptarse a las mutaciones del esquema a lo largo del tiempo, a veces debido a cambios en los requisitos del negocio y otras veces por razones técnicas. Por lo general, la aplicación de actualizaciones del esquema requiere una planificación y una ejecución cuidadas para evitar la interrupción de los sistemas de información de la empresa.
Considera una canalización que lee mensajes que contienen cargas útiles de JSON desde un tema de Pub/Sub. La canalización convierte cada mensaje en una instancia de TableRow y, luego, escribe las filas en una tabla de BigQuery. El esquema de la tabla de salida es similar a los mensajes que procesa la canalización.
En el siguiente diagrama, el esquema se conoce como Esquema A.
Con el tiempo, el esquema del mensaje puede mutar de maneras no triviales. Por ejemplo, se agregan, quitan o reemplazan campos. El Esquema A evoluciona a un esquema nuevo. En la discusión siguiente, se hace referencia al esquema nuevo como Esquema B. En este caso, la canalización A debe actualizarse, y el esquema de la tabla de salida debe ser compatible con el Esquema B.
Para la tabla de salida, puedes realizar algunas mutaciones del esquema sin el centro de noticias.
Por ejemplo, puedes agregar campos nuevos o disminuir la rigurosidad de los modos de columna, como cambiar REQUIRED a NULLABLE, sin tiempo de inactividad.
Por lo general, estas mutaciones no afectan las consultas existentes. Sin embargo, las mutaciones del esquema que modifican o quitan campos del esquema existentes interrumpen las consultas o generan otras interrupciones. El siguiente enfoque se adapta a los cambios sin requerir tiempo de inactividad.
Separa los datos que escribe la canalización en una tabla principal y en una o en más tablas de etapa de pruebas. En la tabla principal, se almacenan datos históricos que escribió la canalización. Las tablas de etapa de pruebas almacenan el resultado de la canalización más reciente. Puedes definir una vista de fachada de BigQuery en las tablas principal y de etapa de pruebas, lo que permite que los consumidores consulten los datos históricos y los actualizados.
En el siguiente diagrama, se revisa el flujo de canalización anterior para incluir una tabla de etapa de pruebas (Tabla de etapa de pruebas A), una tabla principal y una vista de fachada.
En el flujo revisado, la canalización A procesa mensajes que usan el Esquema A y escribe el resultado en la Tabla de etapa de pruebas A, que tiene un esquema compatible. La tabla principal contiene datos históricos que escribieron las versiones anteriores de la canalización, además de resultados que se combinan periódicamente de la tabla de etapa de pruebas. Los consumidores pueden consultar datos actualizados, incluidos los datos históricos y en tiempo real, con la vista de fachada.
Cuando el esquema de los mensajes cambia del Esquema A al Esquema B, puedes actualizar el código de la canalización para que sea compatible con los mensajes que usan el Esquema B. La canalización existente debe actualizarse con la implementación nueva. Si ejecutas canalizaciones paralelas, puedes garantizar que el procesamiento de datos de transmisión continúe sin interrupciones. Finalizar y reemplazar canalizaciones da como resultado una interrupción del procesamiento, ya que no se ejecuta ninguna canalización por un tiempo.
La canalización actualizada escribe en una tabla de etapa de pruebas adicional (tabla de etapa de pruebas B) que usa el esquema B. Puedes usar un flujo de trabajo organizado para crear la tabla de etapa de pruebas nueva antes de actualizar la canalización. Actualiza la vista de fachada para incluir los resultados de la nueva tabla de etapa de pruebas, que puede usar un paso de flujo de trabajo relacionado.
En el siguiente diagrama, aparece el flujo actualizado que muestra la tabla de etapa de pruebas B con el esquema B, y cómo se actualizó la vista de fachada para incluir el contenido de la tabla principal y de ambas tablas de etapa de pruebas.
Como un proceso separado de la actualización de la canalización, puedes combinar las tablas de etapa de pruebas en la tabla principal, ya sea de forma periódica o según sea necesario. En el siguiente diagrama, se muestra cómo la Tabla de etapa de pruebas A se fusiona en la tabla principal.
¿Qué sigue?
- Encuentra pasos detallados para actualizar una canalización existente.