Contexto: En pipelines de producción que procesan millones de registros, inevitablemente algunos datos presentarán problemas de formato, encoding o validación. La forma en que manejes estos errores determina si tu pipeline es frágil o resiliente.
PREGUNTA
Estás ejecutando un pipeline de Apache Beam en Google Cloud Dataflow que procesa 10 millones de registros CSV diarios desde un bucket de GCS hacia BigQuery.
El pipeline valida que cada registro tenga un email válido y un timestamp en formato ISO.
Después de 3 horas de ejecución, descubres que 150 registros tienen timestamps mal formateados, lo que causa que el pipeline falle y se detenga completamente. Los stakeholders necesitan los datos procesados en 6 horas.
¿Cuál es la mejor solución arquitectónica para este escenario?
- A) Reiniciar el pipeline después de corregir manualmente los 150 registros problemáticos en el bucket de origen
- B) Implementar un dead-letter queue que capture registros con errores en una tabla separada de BigQuery y permita que el pipeline continúe procesando los registros válidos
- C) Agregar un bloque try-catch en el DoFn que silencie todas las excepciones y registre los errores en logs para revisión posterior
- D) Modificar la validación para aceptar cualquier formato de timestamp y realizar la limpieza posteriormente en BigQuery con SQL
RESPUESTA: B
EXPLICACIÓN
La implementación de un dead-letter queue (DLQ) es la solución correcta porque permite que el pipeline continúe procesando registros válidos mientras captura los 150 problemáticos para análisis posterior.
Apache Beam proporciona soporte nativo para este patrón mediante WithFailures.Result, que separa el flujo exitoso del flujo de errores sin detener la ejecución.
Esta arquitectura cumple con el SLA de 6 horas, proporciona visibilidad sobre qué registros fallaron y por qué, y evita el costo de reprocesar millones de registros válidos.
Las opciones incorrectas presentan problemas críticos:
- La opción A requeriría reiniciar el pipeline completo (otras 3+ horas), desperdiciando recursos y arriesgando el SLA.
- La opción C es peligrosa porque silencia excepciones sin capturar los datos problemáticos, resultando en pérdida silenciosa de información.
- La opción D compromete la calidad de datos al aceptar datos inválidos, propagando el problema downstream y violando el principio de “fail fast”
EJEMPLO REAL
En el proyecto de limpieza de Google Play Music Takeout, un pipeline de Apache Beam procesó 113GB de archivos CSV con múltiples problemas de encoding ASCII.
Al implementar dead-letter queues, los registros con caracteres mal codificados se enrutaron automáticamente a una tabla separada en MariaDB mientras el pipeline continuó procesando los 23,000+ archivos restantes.
Esto permitió identificar que el 3-5% de los registros tenían problemas de encoding que requerían normalización UTF-8, sin bloquear el procesamiento del 95% de datos válidos.
El análisis post-mortem de la dead-letter queue reveló patrones específicos de corrupción que guiaron la corrección sistemática.
CONSEJO CLAVE
En producción, diseña tus pipelines asumiendo que los datos están rotos por defecto. Implementa dead-letter queues desde el primer día, no como parche posterior a una crisis.
Configura alertas cuando el volumen del DLQ supere umbrales (ej: >1% de registros) para detectar problemas sistémicos temprano.
Recuerda: un pipeline que falla ruidosamente con visibilidad es infinitamente mejor que uno que falla silenciosamente perdiendo datos.