Great Expectations en 2026: Validación de Calidad de Datos y Preguntas de Entrevista

Great Expectations (GX) representa el framework open-source estándar para validación de calidad de datos en pipelines basados en Python. La versión 1.22, lanzada en agosto de 2026, consolida los cambios de API introducidos en GX 1.0 y añade soporte experimental para Python 3.14. Para los data engineers que construyen pipelines de producción, esta herramienta constituye un componente esencial de la infraestructura moderna.

Problemas que Great Expectations Resuelve en Pipelines de Datos

Los pipelines de datos fallan silenciosamente. Un cambio de esquema upstream, un valor nulo donde no debería existir ninguno, un formato de fecha que cambia de ISO a Unix timestamp: estos problemas frecuentemente llegan a dashboards o modelos de machine learning antes de que alguien los note. Great Expectations trata los datos como código, aplicando aserciones (llamadas Expectations) que se ejecutan automáticamente en puntos de control del pipeline.

El framework se integra con Apache Airflow, Databricks, Snowflake y servicios de almacenamiento en la nube como AWS S3 y Azure Blob Storage. Cada validación produce Data Docs, reportes HTML que las partes interesadas no técnicas pueden consultar.

Conceptos Fundamentales: Data Context, Data Sources y Expectations

GX 1.22 organiza la validación alrededor de cuatro componentes: el Data Context, los Data Sources, los Data Assets y las Expectation Suites.

El Data Context es el objeto de configuración central. Almacena metadatos para Data Sources, Expectation Suites, Checkpoints e historial de Validation Results. En la mayoría de los proyectos, un solo directorio gx/ contiene los archivos de configuración YAML y los Data Docs generados.

Un Data Source representa una conexión a una base de datos, data warehouse o sistema de archivos. Un Data Asset es una colección lógica de registros dentro de esa fuente, similar a una tabla o el conjunto de resultados de una consulta.

# gx_setup.py
import great_expectations as gx

# Initialize or load an existing Data Context
context = gx.get_context()

# Add a Pandas Data Source for local files
data_source = context.data_sources.add_pandas("local_files")

# Define a Data Asset pointing to a specific CSV pattern
data_asset = data_source.add_csv_asset(
    name="user_events",
    filepath_or_buffer="data/user_events_*.csv"  # Glob pattern
)

Esta configuración permite a GX validar cualquier CSV que coincida con user_events_*.csv en el directorio data/.

Construcción de una Expectation Suite para Validación de Columnas

Una Expectation Suite es una colección de aserciones contra un Data Asset. Cada Expectation declara una condición que debería ser verdadera para los datos, como "la columna user_id nunca debe ser nula" o "la columna age debe contener valores entre 0 y 120."

# build_suite.py
import great_expectations as gx

context = gx.get_context()

# Create or retrieve an Expectation Suite
suite = context.suites.add(
    gx.ExpectationSuite(name="user_events_suite")
)

# Add Expectations to the suite
suite.add_expectation(
    gx.expectations.ExpectColumnToExist(column="user_id")
)
suite.add_expectation(
    gx.expectations.ExpectColumnValuesToNotBeNull(column="user_id")
)
suite.add_expectation(
    gx.expectations.ExpectColumnValuesToBeBetween(
        column="age",
        min_value=0,
        max_value=120
    )
)
suite.add_expectation(
    gx.expectations.ExpectColumnValuesToMatchRegex(
        column="email",
        regex=r"^[\w.-]+@[\w.-]+\.\w+$"
    )
)

# Save the suite to the Data Context
context.suites.save(suite)

GX 1.0+ utiliza una API basada en clases para las Expectations. La sintaxis antigua basada en diccionarios (expect_column_to_exist) permanece disponible, pero el enfoque basado en clases proporciona mejor autocompletado en el IDE y seguridad de tipos.

Ejecución de Validaciones con Checkpoints

Un Checkpoint vincula un Data Asset, una Expectation Suite y Actions opcionales que se disparan cuando la validación pasa o falla. Los Checkpoints son el punto de entrada principal para validación automatizada en producción.

# run_checkpoint.py
import great_expectations as gx

context = gx.get_context()

# Create a Checkpoint
checkpoint = context.checkpoints.add(
    gx.Checkpoint(
        name="user_events_checkpoint",
        validation_definitions=[
            gx.ValidationDefinition(
                name="validate_user_events",
                data=context.data_sources.get("local_files")
                    .get_asset("user_events")
                    .build_batch_request(),
                suite=context.suites.get("user_events_suite")
            )
        ],
        actions=[
            gx.checkpoint.UpdateDataDocsAction(name="update_docs"),
        ]
    )
)

# Run the Checkpoint
result = checkpoint.run()

# Check overall success
if result.success:
    print("All validations passed")
else:
    print("Validation failures detected")
    for validation_result in result.run_results.values():
        for expectation_result in validation_result.results:
            if not expectation_result.success:
                print(f"  Failed: {expectation_result.expectation_config}")

Cuando el Checkpoint se ejecuta, GX carga el batch, aplica cada Expectation y actualiza los Data Docs. Las validaciones fallidas pueden disparar notificaciones de Slack, alertas de PagerDuty o terminación del pipeline dependiendo de las Actions configuradas.

Integración de GX con DAGs de Apache Airflow

La mayoría de los pipelines de datos en producción utilizan un orquestador como Apache Airflow. GX proporciona una integración oficial con Airflow que encapsula la ejecución de Checkpoints en un operador.

# dags/user_events_pipeline.py
from airflow import DAG
from airflow.operators.python import PythonOperator
from datetime import datetime
import great_expectations as gx

def validate_user_events():
    """Run GX Checkpoint for user events data."""
    context = gx.get_context(context_root_dir="/opt/airflow/gx")
    checkpoint = context.checkpoints.get("user_events_checkpoint")
    result = checkpoint.run()
    
    if not result.success:
        # Raise exception to fail the Airflow task
        raise ValueError("Data validation failed. Check Data Docs for details.")

with DAG(
    dag_id="user_events_pipeline",
    start_date=datetime(2026, 1, 1),
    schedule_interval="@daily",
    catchup=False
) as dag:
    
    validate_task = PythonOperator(
        task_id="validate_user_events",
        python_callable=validate_user_events
    )
    
    # Downstream tasks depend on validation passing
    # transform_task >> load_task

Colocar la validación antes de las tareas de transformación evita que los datos incorrectos se propaguen downstream. Este patrón, a veces llamado "shift-left testing", detecta problemas en la ingestión en lugar de después de que se completen jobs de cómputo costosos.

Preguntas de Entrevista Comunes sobre Great Expectations

Las entrevistas de data engineering en 2026 frecuentemente incluyen preguntas sobre herramientas de calidad de datos. A continuación se presentan preguntas que aparecen en entrevistas técnicas, junto con las respuestas que distinguen a candidatos experimentados de juniors.

"¿Cómo implementarías controles de calidad de datos en un pipeline de producción?"

Las respuestas sólidas mencionan integrar la validación como una etapa del pipeline, no como un dashboard separado. Específicamente:

• La validación de esquema en la ingestión detecta problemas estructurales inmediatamente, por ejemplo un string apareciendo donde se esperaba un entero
• La validación de lógica de negocio verifica restricciones de dominio como precios positivos y rangos de fechas
• Las alertas automatizadas notifican a los ingenieros de guardia cuando falla la validación, previniendo corrupción silenciosa de datos
• Las pruebas de dbt manejan verificaciones de la capa de transformación mientras GX maneja validación de ingestión y salida

"¿Cuál es la diferencia entre una Expectation Suite y un Checkpoint?"

Una Expectation Suite contiene las aserciones mismas: qué columnas deben existir, qué rangos de valores son aceptables, qué patrones regex deben coincidir. Define qué verificar.

Un Checkpoint define cuándo y cómo ejecutar esas verificaciones. Conecta un Data Asset específico (los datos a validar), una Expectation Suite (las reglas a aplicar) y Actions (qué sucede después de la validación).

"¿Cómo se manejan Expectations que varían según el ambiente?"

Los datos de producción frecuentemente tienen características diferentes a los datos de staging. Dos enfoques:

1. Expectations Parametrizadas: Usar variables de ambiente o parámetros de runtime para ajustar umbrales. Por ejemplo, min_value=int(os.getenv("AGE_MIN", 0)).

2. Múltiples Suites: Mantener suites separadas para staging y producción. Staging podría permitir nulls en campos opcionales para probar flujos de datos incompletos.

"¿Qué sucede cuando un Checkpoint falla en un pipeline programado?"

El Checkpoint retorna un CheckpointResult con success=False. El comportamiento del pipeline depende de cómo el orquestador maneja la falla:

• En Airflow, lanzar una excepción marca la tarea como fallida, bloqueando tareas downstream
• En Databricks, el notebook puede salir con un estado de error
• Las Actions adjuntas al Checkpoint pueden enviar mensajes de Slack, crear tickets de Jira o disparar procedimientos de rollback

Expectations Personalizadas para Validación Específica del Dominio

GX incluye más de 300 Expectations incorporadas, pero las reglas específicas del dominio frecuentemente requieren implementaciones personalizadas. Una Expectation personalizada extiende la clase base e implementa la lógica de validación.

# custom_expectations/expect_valid_iso_country_code.py
from great_expectations.expectations import Expectation
from great_expectations.core import ExpectationConfiguration
import pycountry

class ExpectValidIsoCountryCode(Expectation):
    """Expect column values to be valid ISO 3166-1 alpha-2 country codes."""
    
    column: str
    
    @classmethod
    def _prescriptive_template(cls) -> str:
        return "Column {column} values must be valid ISO country codes"
    
    def _validate(self, metrics, runtime_configuration=None, execution_engine=None):
        column_values = metrics.get("column_values")
        valid_codes = {c.alpha_2 for c in pycountry.countries}
        
        invalid_values = [
            v for v in column_values 
            if v is not None and v not in valid_codes
        ]
        
        return {
            "success": len(invalid_values) == 0,
            "result": {
                "observed_value": len(invalid_values),
                "unexpected_list": invalid_values[:10]  # Sample
            }
        }

Las Expectations personalizadas se registran colocándolas en el directorio great_expectations/plugins/ o agregando el módulo al plugins_directory en great_expectations.yml.

Data Docs: Comunicando Calidad a las Partes Interesadas

Los Data Docs son sitios HTML estáticos generados a partir de resultados de validación. Cada ejecución produce una página mostrando qué Expectations pasaron o fallaron, con detalles sobre valores inesperados.

# Generate and open Data Docs
context = gx.get_context()
context.build_data_docs()
context.open_data_docs()  # Opens browser

Para sistemas de producción, los Data Docs pueden alojarse en S3, GCS o Azure Blob Storage con controles de acceso apropiados. La plataforma GX Cloud ofrece Data Docs alojados con características de colaboración en equipo.

Migración GX 1.0: Cambios Importantes desde 0.x

Los equipos que actualizan desde GX 0.x enfrentan cambios de API. Las principales diferencias:

La guía de migración oficial cubre cada cambio. Para bases de código grandes, la migración incremental usando shims de compatibilidad reduce el riesgo.

Puntos Clave para Calidad de Datos con GX 1.22

• Great Expectations 1.22 (agosto 2026) soporta Python 3.10 a 3.13, con soporte experimental de 3.14 a través de la variable de ambiente GX_PYTHON_EXPERIMENTAL
• Las Expectation Suites definen qué validar, los Checkpoints definen cuándo y cómo
• Integrar Checkpoints como etapas de pipeline en DAGs de Airflow o notebooks de Databricks para detectar datos incorrectos en la ingestión
• Las Expectations personalizadas manejan reglas específicas del dominio que las Expectations incorporadas no pueden cubrir
• Los Data Docs proporcionan reportes HTML legibles para las partes interesadas; alojarlos en almacenamiento en la nube para acceso en producción
• Las respuestas de entrevista deben enfatizar la calidad de datos como una etapa de pipeline integrada, no como un dashboard agregado posteriormente