Catalyst frente a Great Expectations: ¿cuál deberías usar?

Un monitor gestionado basado en contratos frente a un framework de Python de código abierto — qué hace bien cada uno, cuándo es la elección equivocada y cómo hay equipos que usan los dos.

2026-09-10 · 11 min read

Usa Great Expectations si tu equipo escribe Python, si tus comprobaciones tienen su sitio dentro de pipelines que ya orquestas y si necesitas extender el framework con lógica que ningún lenguaje de reglas puede expresar. Usa Catalyst si quienes saben qué significa «datos buenos» no escriben Python, si quieres monitorización programada de las tablas del almacén sin operar un runner y si quieres las reglas guardadas como contratos ODCS portables en vez de como código en un repositorio. Great Expectations es un framework que ensamblas; Catalyst es un producto que conectas. La decisión tiene que ver sobre todo con quién escribe y posee las reglas, no con qué herramienta sabe expresar una comprobación de nulos.

Qué es Great Expectations

Great Expectations (habitualmente «GX») es un framework de Python de código abierto para validar datos. Lo instalas con pip, lo apuntas a una fuente de datos y escribes expectations —aserciones declarativas como expect_column_values_to_not_be_null o expect_column_values_to_be_between— agrupadas en Expectation Suites. Un Checkpoint ejecuta una suite contra un lote de datos y dispara acciones según el resultado. Los resultados se renderizan en Data Docs, un sitio HTML estático generado que describe qué se ejecutó y qué falló.

Tiene licencia Apache, es maduro y cuenta con diferencia con el catálogo de comprobaciones integradas más grande de esta categoría, además de una vía de primer nivel para escribir las tuyas en Python. La empresa que hay detrás vende también GX Cloud, una oferta gestionada que superpone una interfaz administrada, ejecuciones programadas y alertas sobre el motor de código abierto. A día de hoy, la API de Python ha cambiado de forma más de una vez entre versiones mayores —la API de la 1.x no es la de la 0.x— y esas migraciones han supuesto históricamente trabajo real, no un simple salto de versión.

Qué es Catalyst

Catalyst es un producto gestionado de calidad de datos. Conectas un usuario de base de datos en modo solo lectura, importa el esquema y construyes reglas en el navegador: not-null, unicidad, rangos, patrones, conjuntos de valores permitidos, frescura, integridad referencial y SQL personalizado para lo que sea a medida. Cada regla se guarda como un contrato del Open Data Contract Standard: el constructor visual y el YAML son dos vistas del mismo documento, y el YAML es la fuente de verdad, así que una regla añadida en la interfaz produce un diff de una línea que puedes revisar.

Las comprobaciones se ejecutan como SQL contra tu almacén según una programación. El dataset nunca sale de ahí: Catalyst guarda resultados, recuentos de violaciones y hasta cinco filas de ejemplo que fallan por comprobación, capturadas mientras la comprobación se ejecuta, nunca el dataset en sí. Conectores a día de hoy: PostgreSQL, MySQL, SQL Server, BigQuery, Redshift, Microsoft Fabric, más subida de ficheros CSV, JSON y Excel.

Cara a cara

Puesta en marcha: cómo es la primera hora

Con Great Expectations, la primera hora es ingeniería. Instalar la librería en un entorno, crear un Data Context, definir una fuente de datos y un data asset, construir una suite, definir un checkpoint, decidir dónde se guardan los resultados de validación y los Data Docs, y luego decidir qué lo ejecuta. Ninguno de esos pasos es difícil; son seis, viven todos en código y hay que mantenerlos todos. Si ya tienes un repositorio de Python con un orquestador dentro, la mayor parte de ese andamiaje ya existe y el coste marginal es pequeño. Si no, estás montando un pequeño servicio antes de haber validado una sola fila.

Con Catalyst, la primera hora es configuración. Creas un rol de solo lectura, pegas los datos de conexión y eliges una tabla. La importación del esquema lee information_schema y propone un contrato de base a partir de lo que encuentra —las columnas obligatorias se convierten en reglas not-null, las claves primarias en reglas de unicidad, las marcas de tiempo en candidatas a frescura— y a partir de ahí editas. La guía de PostgreSQL tiene las sentencias GRANT exactas, incluida la línea ALTER DEFAULT PRIVILEGES que todo el mundo olvida.

El planteamiento honesto: el coste de puesta en marcha de GX te compra un framework de propósito general que puede validar cualquier cosa que un proceso de Python sea capaz de leer. El de Catalyst es menor porque su alcance es más estrecho: tablas en un almacén, comprobadas allí mismo.

Escribir las reglas

Esto es, a grandes rasgos, cómo se ve una suite en la API de Python actual de GX:

import great_expectations as gx

context = gx.get_context()
suite = context.suites.add(gx.ExpectationSuite(name="orders"))

suite.add_expectation(
    gx.expectations.ExpectColumnValuesToNotBeNull(column="order_id")
)
suite.add_expectation(
    gx.expectations.ExpectColumnValuesToBeInSet(
        column="status",
        value_set=["pending", "paid", "shipped", "refunded"],
    )
)

Y las mismas expectations como contrato ODCS:

apiVersion: v3.0.0
kind: DataContract
info:
  title: orders
  version: 1.0.0
  owner: data-platform
schema:
  - name: orders
    physicalType: table
    properties:
      - name: order_id
        logicalType: string
        quality:
          - rule: nullCount
            dimension: completeness
            severity: error
            mustBe: "0"
      - name: status
        logicalType: string
        quality:
          - rule: validValues
            dimension: conformity
            severity: error
            mustBe: "['pending', 'paid', 'shipped', 'refunded']"

Como texto, ninguno es obviamente mejor. La diferencia está en quién puede escribirlo y en qué pasa cuando la regla está mal. La versión en Python puede hacer cosas que el YAML no —llamar a un modelo, comparar contra un segundo sistema, calcular un estadístico sobre una ventana móvil— porque es un programa. La versión en YAML la puede leer y editar un analista, un data steward o un responsable de dominio que no abrirá jamás un terminal, y lleva una dimension, así que cien reglas se agregan en una vista de cobertura en lugar de en una lista.

La librería de expectations de GX es genuinamente extensa, y si necesitas expect_column_kl_divergence_to_be_less_than deberías usar GX, porque Catalyst no lo tiene y no va a fingir que sí. Catalyst cubre las comprobaciones que detectan la inmensa mayoría de los incidentes reales, y recurre al SQL personalizado para el resto.

Dónde viven las reglas

Esta es la parte que sobrevive a la elección de herramienta. Las expectation suites de GX están en el formato de GX: legible, pero escrito para un único runner y alojado en el repositorio de Python que sea dueño del pipeline. Eso está bien mientras GX sea la respuesta, y es una reescritura si deja de serlo.

Catalyst guarda los contratos en ODCS, una especificación abierta desarrollada dentro del proyecto Bitol de la Linux Foundation. El contrato describe la promesa del dataset con independencia de quién la haga cumplir, se exporta como fichero y se importa en cualquier otra cosa que hable el estándar. Si te vas de Catalyst, las reglas se van contigo, que es algo raro de anunciar por parte de un proveedor y la razón principal para confiar en el formato.

Elige Great Expectations si…

• Tu equipo escribe Python y ya tiene un orquestador en marcha. GX encaja en Airflow, Dagster o Prefect como una tarea más. Ese es su hábitat natural y ahí funciona muy bien.
• Necesitas lógica personalizada que ningún lenguaje declarativo de reglas expresa: deriva de distribuciones, pruebas estadísticas, conciliación entre sistemas, comprobaciones que llaman a un modelo. Las expectations personalizadas en Python no tienen techo.
• Validas dataframes, no solo tablas. GX comprueba datos a mitad del pipeline, en pandas o Spark, antes de que aterrice nada. Catalyst valida lo que ya está en el almacén y no ve un dataframe.
• La validación debe hacer fallar un build. Un checkpoint que termina con código distinto de cero bloquea un DAG o un job de CI. Eso es un trabajo distinto de la monitorización, y GX lo hace de forma nativa.
• Tu presupuesto es cero y tu tiempo de ingeniería no. Apache 2.0, sin licencias por usuario, sin proveedor.
• Usas un almacén que Catalyst aún no soporta. Snowflake y Databricks son los ejemplos obvios; vía SQLAlchemy, GX los maneja hoy.
• Vuestra política prohíbe que un servicio externo guarde metadatos del almacén. Catalyst está alojado en la UE y solo guarda resultados, recuentos de violaciones y hasta cinco filas de ejemplo que fallan por comprobación, pero autoalojado sigue siendo autoalojado.

Elige Catalyst si…

• Quienes conocen las reglas de negocio no escriben Python. Este es, con diferencia, el motivo más común por el que los equipos acaban aquí. Las reglas escritas por quien entiende los datos ganan a las reglas escritas por quien entiende el framework.
• Quieres monitorización, no solo aserciones. Las ejecuciones programadas, el histórico pass/warn/fail y las líneas de tendencia vienen configuradas en lugar de ensambladas.
• Quieres un formato de reglas abierto. Los contratos ODCS se revisan en pull requests y son portables entre herramientas.
• Nadie quiere hacerse cargo de un servicio de validación. Sin entorno que parchear, sin bucket de Data Docs, sin actualizaciones de dependencias, sin migración cuando la API cambia de forma.
• Necesitas roles, SSO y una traza de auditoría. El RBAC y el registro de auditoría están en el producto, no son un proyecto.
• Tus datos viven en sitios heterogéneos, entre ellos BigQuery, un Postgres primario y alguna que otra hoja de cálculo, y quieres una sola vista sobre todo ello.

Usar ambos

No son mutuamente excluyentes, y un buen número de equipos usa los dos a propósito. El reparto que funciona: GX dentro del pipeline, como puerta —comprobaciones que deben bloquear un build antes de que aterricen datos malos, más las expectations estadísticas exóticas—. Catalyst por encima del pipeline, como monitor: las promesas duraderas y revisables sobre las tablas de las que dependen los consumidores, ejecutándose según una programación con independencia de qué job las escribió hoy, con el histórico que un log de fallo de CI no te da.

Si ya tienes suites de GX, la migración no es automática —a día de hoy no hay importador—, pero la traducción es mecánica para las expectations comunes, e importar primero el esquema hace que la mayor parte del contrato se genere sola. Para la visión completa de qué comprobar y por qué, empieza por la guía para validar datos.

Preguntas frecuentes

¿Great Expectations es gratuito?

La librería de Python de Great Expectations es de código abierto bajo licencia Apache 2.0 y de uso gratuito, también comercialmente. GX Cloud, el producto gestionado de la misma empresa, es una oferta comercial con sus propios precios; consulta su web para ver las condiciones vigentes. «Gratis» en el sentido del código abierto sigue significando que pagas el cómputo sobre el que se ejecuta y el tiempo de ingeniería para operarlo.

¿Catalyst requiere Python?

No. Catalyst se conecta a tu base de datos con un usuario de solo lectura y las reglas se construyen en el navegador o se escriben como YAML de ODCS. No hay nada que instalar ni código que ejecutar. El SQL es opcional, y solo para reglas personalizadas que los tipos integrados no cubren.

¿Puedo usar Great Expectations y Catalyst juntos?

Sí, y es una arquitectura razonable. Usa Great Expectations como puerta del pipeline —aserciones que hacen fallar un build antes de que aterricen datos malos— y Catalyst como capa de monitorización y de contratos sobre las tablas que ya aterrizaron, con ejecuciones programadas e histórico pass/warn/fail. Leen los mismos datos y responden a preguntas distintas.

¿Puede Catalyst validar dataframes de pandas o Spark?

No. Catalyst valida datos en reposo: tablas y vistas de un almacén conectado, más ficheros CSV, JSON y Excel subidos. Los dataframes en memoria dentro de un proceso de Python en ejecución son exactamente el caso para el que existe Great Expectations.

¿Cuál es mejor para un equipo de datos pequeño?

Si el equipo son uno o dos ingenieros que viven en Python y ya tienen un orquestador en marcha, Great Expectations no cuesta nada y encaja en el flujo de trabajo existente. Si el equipo incluye analistas o responsables de dominio que deberían estar escribiendo las reglas, o si nadie quiere mantener otro servicio, una herramienta gestionada gana en tiempo total invertido. El plan Starter de Catalyst es gratuito para una conexión y un dataset (PostgreSQL y MySQL), suficiente para poner a prueba la premisa antes de comprometerte.