Por Andrew Tan
La desviación de esquemas y los cambios disruptivos en los sistemas de origen son la principal causa de fallos silenciosos de datos, pero la mayoría del contenido sobre pipelines se centra en la infraestructura, no en el comportamiento del sistema de origen
Relacionado: Este artículo cubre el Patrón 1 de nuestro análisis de 50 postmortems de data pipelines de Uber, Netflix, Stripe, y otros. La desviación de esquemas representó el 38% de los incidentes, siendo la causa raíz más común que encontramos.
El campo que cambió de tipo un martes
Un equipo que conozco realiza la reconciliación de pagos para una empresa de comercio electrónico de tamaño medio. Su pipeline extrae datos de transacciones de un procesador de pagos de terceros, los transforma y los carga en su almacén de datos. Ha estado funcionando sin incidentes durante dos años y medio.
Una tarde de martes en noviembre, el procesador de pagos actualizó silenciosamente su API. Un campo — transaction_amount — cambió de una cadena (porque algunos sistemas heredados representan dinero como "47.50") a un flotante nativo (47.50). Sin versionado. Sin aviso de deprecación. Sin correo electrónico. La documentación se actualizó en algún momento de la semana siguiente.
El pipeline no se estrelló. Siguió funcionando. Siguió procesando transacciones. Siguió reportando éxito.
Lo que dejó de hacer fue convertir correctamente. La transformación posterior asumía entrada de cadena y aplicaba una expresión regular para eliminar símbolos de moneda antes de convertir. Con un flotante entrante, la expresión regular no coincidía con nada, la conversión producía nulo, y cada transacción durante las siguientes seis horas tenía un monto de cero.
Seis horas de transacciones de cero dólares, todas mostrando como procesadas. Nadie se dio cuenta hasta que el informe de reconciliación diaria salió a la mañana siguiente y los números parecían como si un error de redondeo se hubiera tragado el negocio.
Estoy contando esta historia porque ilustra algo que la mayoría de los escritos sobre arquitectura de pipelines pasan por alto: los fallos más aterradores no provienen de tu infraestructura. Provienen de sistemas que no controlas.
Tres tipos de cambios en el sistema de origen
No todos los cambios en el sistema de origen son iguales. He visto a equipos quemarse con cada uno de ellos, y requieren diferentes defensas.
Los cambios aditivos son los que los proveedores anuncian como "compatibles hacia atrás". Aparecen nuevos campos en la respuesta. Los campos existentes permanecen igual. En teoría, tu pipeline debería estar bien — no estás usando los nuevos campos. En la práctica, los cambios aditivos rompen pipelines cuando alcanzan suposiciones implícitas de tamaño (una respuesta JSON ahora excede un límite de búfer), cuando capturas de esquema con comodines comienzan a recoger campos que no esperabas, o cuando ese nuevo campo se llama de una manera que colisiona con un campo que ya tienes en tu tabla de destino.
Los cambios disruptivos son al menos los honestos. El campo se renombra. El tipo cambia. Un endpoint se deprecia. Estos deberían ser anunciados — y usualmente lo son, para proveedores reputables. Pero "anunciado" no significa "actuado". El anuncio se sienta en un resumen de correo electrónico que nadie lee porque el equipo que lo recibe no es el equipo que posee el pipeline, y para cuando llega la fecha de deprecación, el ingeniero original se ha mudado a una empresa diferente.
Los cambios silenciosos son la situación del procesador de pagos. El tipo de cambio que nadie te cuenta porque, desde la perspectiva del proveedor, nada cambió. La semántica es la misma. Los datos son los mismos. Solo cambió el tipo. O la codificación. O el comportamiento de manejo de nulos. Los cambios silenciosos son los que se convierten en eventos de corrupción de datos de seis horas antes de que alguien se dé cuenta.
La proporción de cada tipo varía según la madurez del proveedor. Las APIs financieras establecidas son principalmente cambios disruptivos con largos períodos de deprecación. Los productos SaaS con ciclos de lanzamiento rápidos son principalmente silenciosos y aditivos. Los feeds de datos proporcionados por socios — el tipo poco glamuroso y crítico que ejecuta integraciones B2B — son genuinamente impredecibles.
Por qué la mayoría de los pipelines fallan en la capa incorrecta
Aquí está el asunto sobre la validación de esquemas: casi todas las herramientas modernas de pipelines la soportan. Puedes definir esquemas. Puedes validar en la ingestión. Puedes rechazar registros malformados.
La mayoría de los equipos no lo hacen, por razones comprensibles.
En los primeros días de un pipeline, el esquema cambia constantemente. El sistema de origen todavía está en desarrollo. La validación estricta fallaría en el pipeline cada vez que se agrega o renombra un campo durante la iteración normal. Así que la validación se apaga, o se afloja a "mejor esfuerzo", y para cuando el pipeline llega a producción, nadie recuerda ajustarla de nuevo.
También hay una división filosófica en cómo los equipos piensan sobre la aplicación de esquemas. La validación estricta de esquemas se siente defensiva. Se siente como si estuvieras construyendo un muro que romperá el pipeline cada vez que el sistema de origen respire. El manejo permisivo se siente pragmático. Maneja lo que puedas, pasa lo que no puedas, deja que el destino lo resuelva.
El problema con el manejo permisivo es que desplaza la superficie de fallo hacia abajo y la hace invisible. Tu pipeline no falla. Tus análisis o aplicaciones posteriores procesan silenciosamente datos incorrectos. Y para cuando te das cuenta — días después, cuando un informe parece incorrecto, o un usuario reporta una discrepancia — los registros corruptos se han mezclado con los legítimos, se han agravado por transformaciones posteriores, y posiblemente se han actuado.
La validación de esquemas en la capa del pipeline no se trata de ser estricto por el bien de serlo. Se trata de hacer que los fallos sean ruidosos y tempranos en lugar de silenciosos y tardíos.
Las tres clases de defensa
Después de observar suficientes de estos incidentes, he encontrado que los equipos que manejan los cambios en el sistema de origen con gracia hacen tres cosas de manera consistente.
Validación de forma, no solo de tipos. La validación de tipos detecta la situación del procesador de pagos. Pero la validación de forma detecta los casos más sutiles: un campo requerido que se vuelve opcional (y por lo tanto a veces ausente), un arreglo que solía tener siempre un elemento ahora a veces teniendo cero, un objeto que solía ser plano ahora anidando un nivel más profundo.
La distinción importa porque los errores de tipo producen fallos ruidosos. Las discrepancias de forma producen fallos silenciosos. Un campo que está presente el 99.9% del tiempo y ausente el 0.1% del tiempo producirá un error de manejo de nulos que tardará semanas en salir a la superficie porque solo se activa en tipos de transacciones raras, o regiones geográficas específicas, o métodos de pago de casos extremos.
Monitoreo de desviación de esquemas, no solo estado del trabajo. El estado del trabajo te dice si el pipeline se ejecutó. El monitoreo de desviación de esquemas te dice si lo que el pipeline procesó hoy tiene la misma forma que lo que procesó ayer.
Esto no requiere una plataforma de observabilidad sofisticada. La versión más simple es una verificación diaria que calcula un hash del esquema inferido de una muestra de registros de cada fuente y alerta si el hash cambia. Es crudo pero efectivo. La mayoría de los eventos de desviación de esquemas son detectables por este método dentro de 24 horas.
Las versiones más sofisticadas rastrean estadísticas a nivel de campo: tasas de nulos por campo, cardinalidad por campo, distribución de tipos por campo. Cuando la tasa de nulos para transaction_amount pasa de 0.0% a 0.1%, algo cambió en el sistema de origen. Tal vez sea intencional. Tal vez sea un error. De cualquier manera, quieres saberlo antes de que se convierta en un problema.
Separar la ingestión del procesamiento. Este es el patrón arquitectónico que compra más tiempo cuando ocurren cambios en el sistema de origen. Si tu pipeline ingiere datos sin procesar en una zona de aterrizaje antes de procesarlos, tienes la opción de reproducir contra datos históricos sin procesar después de corregir un problema de esquema. Si la ingestión y el procesamiento están acoplados, pierdes esa opción.
La zona de aterrizaje sin procesar no tiene que ser costosa o compleja. Para muchos casos de uso, un almacén de objetos de solo anexión (S3, GCS, Azure Blob) con JSON sin procesar particionado es suficiente. La capa de transformación lee desde la zona de aterrizaje, no directamente desde la fuente. Cuando algo sale mal en el sistema de origen, corriges la transformación y reproduces. Los datos todavía están allí.
Pruebas de contrato en la capa del pipeline: ¿vale la pena?
Escucharás sobre las pruebas de contrato impulsadas por el consumidor como la solución "correcta" a este problema. La idea es que tu pipeline publica un contrato — estos son los campos de los que dependo, estos son los tipos que espero, esto es lo que considero un cambio disruptivo — y se espera que el sistema de origen valide contra ese contrato antes de implementar cambios.
Esto funciona bien cuando controlas ambos lados de la integración. Si estás integrando microservicios internos, o trabajando con un proveedor que toma en serio la estabilidad de la integración, las pruebas de contrato son genuinamente valiosas. Herramientas como Pact lo hacen manejable.
Para la mayoría de las integraciones que veo en la práctica — SaaS de terceros, APIs de socios, feeds de datos de sistemas sobre los que no tienes control — las pruebas de contrato son una teoría agradable. No puedes obligar a un procesador de pagos a ejecutar tus pruebas de Pact antes de que implementen. No puedes negociar derechos de publicación de contratos con un proveedor cuyo equipo legal nunca ha oído hablar de contratos impulsados por el consumidor.
El marco más práctico es: ¿qué puedes hacer en tu lado del límite para detectar cambios y recuperarte de ellos rápidamente?
Lo que me lleva de nuevo al monitoreo de esquemas, las zonas de aterrizaje y la validación a nivel de pipeline. No es glamuroso. No es la solución técnicamente interesante. Pero es la que realmente funciona en todo el rango de escenarios de sistemas de origen que encontrarás.
La pregunta que hacer en cada inicio de integración
He comenzado a hacer una pregunta en cada revisión de diseño de integración: ¿Cuál es el proceso cuando esto cambia sin previo aviso?
No si. Cuándo.
Suena pesimista. El equipo de integración de socios a veces se lo toma personalmente. Pero la pregunta fuerza una conversación que casi siempre saca a la luz suposiciones que nadie había hecho explícitas: la suposición de que el equipo del sistema de origen comunicará cambios disruptivos, la suposición de que alguien en el equipo de integración leerá el registro de cambios, la suposición de que el pipeline puede tolerar X días de datos incorrectos antes de que alguien se dé cuenta.
Esas suposiciones suelen ser incorrectas. Hacerlas explícitas te da la oportunidad de diseñar alrededor de ellas.
La respuesta a "¿qué pasa cuando esto cambia sin previo aviso?" debería involucrar al menos: dónde se dispara la alerta, quién la recibe, qué tan rápido el equipo puede identificar qué campo cambió, y qué tan rápido pueden reproducir los datos afectados desde la zona de aterrizaje sin procesar. Si la respuesta es "tendríamos que investigar y probablemente llamar al proveedor", el pipeline no está listo para producción.
Dónde encaja layline.io en esto
La evolución de esquemas es una de las cosas en las que pensamos mucho en cómo layline.io maneja el procesamiento de datos. Cuando estás lidiando con pipelines tanto por lotes como en streaming — y la realidad es que la mayoría de los equipos ejecutan ambos indefinidamente — el problema de cambios en el sistema de origen se complica. Un cambio de esquema en una fuente de streaming te golpea en tiempo real. El mismo cambio en una fuente por lotes podría no aparecer durante 24 horas.
El modelo de procesamiento de layline.io te apoya con la evolución de esquemas a través del enrutamiento de versiones explícito: cuando se introduce una nueva versión de esquema, puedes aplicar lógica y validación separadas o dirigir esos registros a un flujo separado para validación y manejo por completo, en lugar de dejarlos contaminar tu ruta de procesamiento principal.
No es magia. Todavía tienes que diseñar tu integración con la suposición de que las cosas en el sistema de origen cambiarán. Pero significa que cuando cambian, la superficie de fallo es más pequeña y el camino de recuperación es más rápido.
Los equipos que manejan los cambios en el sistema de origen con gracia no son los que tienen la infraestructura más sofisticada. Son los que dejaron de asumir que el sistema de origen nunca los sorprendería.
Si tu equipo está lidiando con desviación de esquemas o confiabilidad en la integración de sistemas de origen, el motor de procesamiento de layline.io maneja la evolución de esquemas y la resiliencia del pipeline tanto para cargas de trabajo por lotes como en tiempo real. La Community Edition es gratuita para explorar.
Andrew Tan es un emprendedor en serie y fundador de layline.io, construyendo infraestructura de procesamiento de datos empresarial que maneja cargas de trabajo tanto por lotes como en tiempo real a escala.