Shift schema drift left: policy-aware compile-time contracts for typed JVM and Spark pipelines

Este trabajo presenta un marco de trabajo en Scala 3 que cierra la brecha entre la verificación en tiempo de compilación y la ejecución en Spark, asegurando la compatibilidad estructural de esquemas mediante contratos tipificados y políticas explícitas que se validan tanto al compilar como en el momento de la escritura.

Lo esencial

Imagina que tu empresa es una gran fábrica de juguetes (los datos) que necesita enviar sus productos a una tienda muy estricta (el sistema de destino).

El problema que resuelve este artículo es el "desajuste de la caja".

El Problema: La Caja que no Cierra

A veces, en la fábrica, alguien cambia el nombre de un juguete, lo pone en un lugar diferente de la caja, o decide que ahora la caja puede ir vacía (nula) cuando antes siempre tenía algo. Si nadie se da cuenta de esto hasta que el camión llega a la tienda, la tienda rechaza todo el envío. ¡Desastre! Los datos se corrompen y el trabajo se detiene.

En el mundo de la programación (específicamente con herramientas como Spark y Scala), esto sucede todo el tiempo. Los programadores escriben código que parece correcto, pero cuando los datos reales llegan, el formato ha cambiado y el sistema falla.

La Solución: Un "Inspector de Doble Visto"

El autor, Vittal Mirji, propone una herramienta inteligente que actúa como un inspector de seguridad que trabaja en dos momentos clave:

1. El Inspector de Diseño (Tiempo de Compilación)

Imagina que antes de que la fábrica empiece a producir, un inspector muy estricto revisa los planos (el código).

• Lo que hace: Compara los planos de la caja de salida con los requisitos de la tienda.
• La magia: Si hay un error (por ejemplo, "el juguete 'Pelota' se llama ahora 'Bola'"), el inspector detiene la fábrica inmediatamente. No deja que el código se compile.
• La ventaja: Te ahorra tiempo porque te avisa antes de que construyas nada. Es como si el plano te dijera: "Oye, la puerta no encaja en el marco, corrígelo ahora".

2. El Inspector de Carga (Tiempo de Ejecución)

Pero, ¿qué pasa si alguien cambia el contenido del camión después de que los planos fueron aprobados? (Por ejemplo, si los datos vienen de un archivo CSV externo que no sigue las reglas).

• Lo que hace: Justo antes de que el camión salga de la fábrica hacia la tienda, un segundo inspector revisa la carga real en el camión.
• La magia: Si los datos reales no coinciden con lo que prometió el plano, el inspector bloquea la salida.
• La ventaja: Es tu última línea de defensa. Asegura que, aunque los planos fueran correctos, la realidad no te traicione.

¿Qué hace especial a esta herramienta? (Las Reglas del Juego)

La mayoría de las herramientas anteriores eran como un "sí o no" muy rígido. Esta nueva herramienta es más flexible y tiene reglas de compatibilidad (llamadas "políticas"):

• Regla Estricta: "Tiene que ser idéntico, ni más ni menos".
• Regla de Atrás (Backward): "Si la tienda acepta más cosas de las que pedimos, está bien. Pero si le falta algo importante, no pasa". (Como llevar un regalo extra a una fiesta, pero no puedes llegar sin el regalo principal).
• Regla de Adelante (Forward): "Si la tienda tiene más requisitos de los que tenemos, está bien. Pero no podemos enviar cosas que ella no espera".
• El Superpoder Oculto: Esta herramienta revisa algo que otros ignoran: la posibilidad de estar vacío dentro de listas y mapas. La mayoría de las herramientas solo revisan la caja principal. Esta una revisa un detalle específico profundo: si cada espacio en una lista o mapa anidada puede estar vacío o no. Por ejemplo, si el contrato dice "una caja de juguetes donde cada espacio debe estar lleno" pero el camión envía "una caja de juguetes donde algunos espacios están vacíos", este inspector lo detecta. Las herramientas anteriores a menudo pasaban por alto estos detalles de nulidad dentro de listas y mapas.

La Analogía Final: El Pasaporte y la Aduana

Piensa en este sistema como un viaje internacional:

1. El Pasaporte (Código): El inspector de diseño verifica que tu pasaporte (tu código Scala) tenga la foto correcta, el nombre correcto y la fecha de validez antes de dejarte salir de casa. Si el pasaporte está mal, no sales.
2. La Aduana (Datos Reales): Justo antes de subir al avión, la aduana revisa tu maleta real. A veces, aunque tengas un pasaporte válido, te metes un objeto prohibido en la maleta sin darte cuenta. La aduana (el inspector de ejecución) lo detecta y te detiene antes de que el avión despegue.

En Resumen

Este artículo no promete resolver todos los problemas del mundo (como saber si un juguete es divertido o no), pero sí ofrece una forma muy inteligente y segura de asegurarse de que la forma de los datos (su estructura) coincida perfectamente entre quien los crea y quien los recibe.

Combina la seguridad de la planificación (antes de escribir el código) con la seguridad de la realidad (justo antes de enviar los datos), evitando que los errores de formato arruinen el día de los ingenieros de datos.

Resumen técnico

1. El Problema: La Deriva de Esquemas (Schema Drift)

En los sistemas de datos actuales, la deriva de esquemas (cambios no intencionados en la estructura de los datos, como renombrar campos, reordenar registros o cambiar la opcionalidad de colecciones anidadas) suele detectarse demasiado tarde: solo cuando un trabajo de procesamiento toca datos reales.

• Limitaciones de las soluciones existentes:
  • Capas de Dataset Tipado (ej. Frameless, Iskra): Cierran parte de la brecha pero requieren una adopción masiva ("wholesale adoption"), reemplazando todo el código de DataFrame crudo, lo que eleva el costo de adopción.
  • Enforcement a nivel de tabla (ej. Delta Lake, Iceberg): Operan en tiempo de escritura contra un esquema almacenado, no en tiempo de compilación contra un tipo Scala declarado. Por tanto, el fallo ocurre después de enviar el trabajo.
  • Comparadores de Spark en tiempo de ejecución: Detectan problemas después de que el programa ya se ha construido y ha cruzado límites externos.

El vacío: No existe actualmente una capa que proporcione prueba en tiempo de compilación de que un tipo de productor declarado es compatible con un tipo de contrato declarado bajo una política explícita, antes de que el trabajo se envíe.

---

2. Metodología y Diseño del Framework

El artículo presenta un framework pequeño en Scala 3 que ocupa la "costura" entre la compilación y el tiempo de ejecución, fusionando dos mecanismos complementarios:

A. Prueba en Tiempo de Compilación (Compile-Time Proof)

• Mecanismo: Utiliza macros de Scala 3 y reflexión citada (quoted reflection) para inspeccionar la estructura de las clases case (productor y contrato).
• Modelo Normalizado: Deriva una representación interna normalizada (TypeShape) que captura nombres de campos, anidación, forma de colecciones, opcionalidad y valores por defecto.
• Verificación: Un macro inline genera evidencia de tipo SchemaConforms[Out, Contract, P]. Si el productor no cumple el contrato bajo la política seleccionada, la compilación falla con un informe detallado de la deriva.
• Ventaja: Detecta errores en la declaración del código antes de que se compile el binario.

B. Anclaje en Tiempo de Ejecución (Runtime Pin)

• Necesidad: La prueba en compilación no puede ver los esquemas reales de datos externos (CSV, JSON, tablas) que pueden desviarse del código.
• Mecanismo: Antes de escribir en el sumidero (sink), el framework deriva un StructType de Spark desde el mismo tipo de contrato Scala y lo compara con el esquema real del DataFrame.
• Comparador Consciente de Políticas: Implementa un comparador personalizado que va más allá de las funciones nativas de Spark:
  • Verifica explícitamente la opcionalidad de colecciones anidadas (algo que Spark ignora por defecto).
  • Implementa semántica de subconjunto real para políticas de compatibilidad hacia atrás y hacia adelante.

C. Familia de Políticas (Policy Family)

El framework permite definir explícitamente qué cuenta como "compatible":

• Exacto: Coincidencia exacta de nombres y orden (con o sin sensibilidad a mayúsculas/minúsculas).
• Por Posición: Ignora nombres, solo compara posición.
• Backward (Hacia atrás): El productor puede tener campos extra; faltan campos del contrato solo si son opcionales o tienen valor por defecto.
• Forward (Hacia adelante): El productor debe tener todos los campos del contrato; el contrato puede tener campos extra.
• Full: Acepta todas las combinaciones (desactiva la verificación).

D. Ensamblaje (Typed Builder Fuse)

Utiliza un constructor tipado (addSink[R, P]) que exige la evidencia de compilación como requisito de tipo. Si la compilación pasa, el pipeline ejecuta la verificación en tiempo de ejecución antes de escribir. Esto crea un "disciplina de tipo" (typestate) que asegura que ambas capas estén conectadas.

---

3. Contribuciones Clave

1. Derivación Macro de Scala 3: Una implementación que genera pruebas de compatibilidad estructural en tiempo de compilación bajo una familia de políticas probada, con diagnósticos de deriva ricos en rutas de error.
2. Diseño de Sumidero Híbrido: Fusiona la prueba en compilación con un comparador en tiempo de ejecución consciente de políticas, incluyendo la verificación de opcionalidad de colecciones anidadas y semántica de subconjunto (Backward/Forward) que Spark no ofrece nativamente.
3. Artifact Reproducible: Un repositorio de referencia pequeño que demuestra que esta combinación tiene un costo de compilación bajo y un costo en tiempo de ejecución medible (microsegundos por comparación de esquema), sin requerir una reescritura masiva del código del pipeline.

---

4. Resultados y Evaluación

La evaluación se centra en la viabilidad del mecanismo y la reproducibilidad, no en métricas industriales a gran escala:

• Cobertura de Pruebas:
  • Compilación: Se validó la aceptación y rechazo de casos estructurales (reordenamiento, campos faltantes, opcionalidad anidada) bajo diferentes políticas.
  • Ejecución: Se demostró que la capa en tiempo de ejecución detecta deriva que los tipos declarados no pueden descartar (ej. esquemas reales de CSV que violan la opcionalidad anidada).
  • End-to-End: Las pruebas del constructor tipado confirmaron que la evidencia de compilación y la verificación en tiempo de ejecución están correctamente enlazadas en el límite del sumidero.
• Rendimiento (Benchmarks):
  • Tiempo de Compilación: El overhead es bajo y reproducible. En entornos locales y GitHub, el tiempo adicional para generar pruebas de 10 a 50 pares de esquemas varió entre 0.27s y 1.88s (aprox. 11-16% de overhead).
  • Tiempo de Ejecución: El comparador personalizado es más lento que los comparadores nativos de Spark (aprox. 17-25 veces más lento en coincidencia exacta desordenada), pero sigue operando en el rango de microsegundos (ej. ~4700 ns vs ~278 ns para Spark). Dado que la verificación ocurre una vez por escritura de sumidero y no por fila, el costo se considera aceptable.

---

5. Significado y Limitaciones

• Significado: El trabajo demuestra que es posible mover la detección de deriva estructural desde el fallo en tiempo de ejecución hacia la prueba en tiempo de compilación y la CI, manteniendo una guardia en tiempo de ejecución para los límites de datos externos. Ofrece una alternativa de menor costo de adopción que las capas de Dataset tipado completo.
• Limitaciones Declaradas:
  • Alcance Estructural: Solo verifica la forma de los datos (nombres, tipos, anidación), no reglas de negocio, invariantes temporales o restricciones semánticas.
  • Ecosistema: No incluye integración con registros de esquemas externos ni estudios de usabilidad a gran escala.
  • Evidencia de Valor: El artículo es honesto al admitir que no mide la mejora de productividad o fiabilidad en producción, dejando eso para trabajo futuro.

Conclusión: El artículo presenta un mecanismo "narrow and honest" (estrecho y honesto) que demuestra la viabilidad técnica de combinar contratos estructurales en tiempo de compilación con verificación en el límite de ejecución para pipelines de datos en JVM y Spark.