Ejecutando Great Expectations a escala en AWS Glue

Ejecutar Great Expectations 1.9+ en un entorno de producción de AWS Glue requiere resolver tres problemas no obvios: inicialización del contexto sin un sistema de archivos, gestión de suites de expectativas a escala, y rendimiento bajo altos volúmenes de datos. Esta guía cubre los tres, basada en despliegues en producción que procesan 2.4 mil millones de eventos por día. La decisión arquitectónica central es si usar un Ephemeral Data Context (sin estado persistente) o un File Data Context (lee desde una ruta montada). En Glue, el sistema de archivos es de solo lectura excepto /tmp, y los workers de Glue no comparten estado entre ejecuciones. La elección correcta es casi siempre un contexto Ephemeral con expectativas cargadas desde S3 al inicio del job.

Organizar suites de expectativas a escala requiere una convención de nombres que mapee a tu arquitectura de datos. Usamos una jerarquía de tres niveles: {capa}.{dataset}.{versión}. Una suite Bronze para el dataset de órdenes en la versión 3 es bronze.orders.v3. Esto hace que la gestión de suites sea scriptable, permite expectativas versionadas junto con el código del pipeline, y permite la selección automática de suites basada en argumentos del job de Glue. Cargar suites desde S3 al inicio agrega 2-4 segundos de latencia por dataset. A escala con 25+ datasets, esto importa. El patrón es cargar todas las suites relevantes durante la fase de inicialización del job de Glue, antes de que se construya el DAG de Spark, para que la carga de suites se paralelice con el inicio del contexto de Spark.

La arquitectura Medallion introduce requisitos de validación específicos por capa que mapean directamente al diseño de conjuntos de expectativas GX. Las validaciones de la capa Bronze se centran en la integridad estructural: conformidad de schema, restricciones de null en claves primarias, validación de formato en campos críticos. El umbral de éxito es 50%. Las validaciones Silver agregan expectativas de reglas de negocio: integridad referencial, restricciones de rango, consistencia entre columnas. El umbral sube al 75%. Las validaciones Gold agregan expectativas estadísticas: límites de distribución, límites de outliers, requisitos de completitud para analítica. Umbral: 90%.

La orquestación con Step Functions cambia el patrón de manejo de fallos. Con un job de Glue directo, manejas los fallos en el job mismo. Con Step Functions, obtienes compensación distribuida: un fallo Gold dispara una Lambda que verifica si Bronze y Silver están saludables, determina el blast radius y enruta la alerta apropiada. Esta separación de la lógica de validación de la lógica de orquestación es la ventaja arquitectónica clave a escala. La optimización del rendimiento a escala viene de tres palancas: validación por lotes, expectativas nativas de Spark (usa el BatchRequest de Spark de GX en lugar de convertir a Pandas), y perfilado selectivo (ejecutar las expectativas de perfilado costosas solo en particiones cambiadas, no en escaneos completos del dataset).

Lista de verificación de despliegue práctico: fija GX a una versión exacta en requirements.txt (las versiones menores introducen cambios disruptivos en los formatos de suites), usa S3 para el almacenamiento de resultados de validación con un esquema de partición que permita consultas eficientes de rango de tiempo, y configura la emisión de métricas de CloudWatch desde cada ejecución de validación para que tu dashboard de confiabilidad tenga señal en tiempo real.