Cómo probar la calidad de los datos en ELT: paso a paso

João Barros 05 de July de 2026 5 min de lectura

En un pipeline ELT, los datos se cargan primero en el data warehouse y solo se transforman después. Ese orden aporta velocidad, pero también un riesgo: los datos en bruto entran sin validación, por lo que un valor nulo o una fila duplicada pueden llegar hasta los informes sin que nadie se dé cuenta. Probar la calidad de los datos en ELT con consultas SQL simples resuelve esto: cada prueba se ejecuta después de la carga y falla en cuanto encuentra algo inesperado, antes de que los datos se consuman.

Requisitos previos

Acceso a un data warehouse SQL (Snowflake, BigQuery, PostgreSQL, SQL Server, entre otros).
Una tabla ya cargada por el proceso ELT — en este ejemplo, stg_encomendas.
Nociones básicas de SQL: SELECT, WHERE, GROUP BY y COUNT.

Paso 1: Definir las reglas de calidad

Antes de escribir código, decida qué significa "datos válidos" para su tabla. Escribir las reglas con palabras facilita revisarlas con el equipo de negocio. Para stg_encomendas usaremos cuatro reglas muy habituales:

No nulo: la columna id_encomenda nunca puede estar vacía.
Único: no pueden existir dos filas con el mismo id_encomenda.
Valores aceptados: la columna estado solo puede ser 'nova', 'paga' o 'cancelada'.
Frescura: debe existir al menos un pedido de las últimas 24 horas.

La idea central es siempre la misma: cada prueba es una consulta que devuelve las filas que incumplen la regla. Si la consulta devuelve cero filas, la prueba pasa; si devuelve filas, esas filas son exactamente los problemas que hay que corregir.

Paso 2: Probar valores nulos y duplicados

Empiece por las dos pruebas más frecuentes en un pipeline de datos. La primera cuenta cuántos id_encomenda son nulos; la segunda busca claves repetidas, un error clásico cuando la carga se ejecuta dos veces.

-- Prueba 1: id_encomenda no puede ser nulo
SELECT COUNT(*) AS falhas
FROM stg_encomendas
WHERE id_encomenda IS NULL;

-- Prueba 2: id_encomenda debe ser único
SELECT id_encomenda, COUNT(*) AS repeticoes
FROM stg_encomendas
GROUP BY id_encomenda
HAVING COUNT(*) > 1;

Si la Prueba 1 devuelve un número mayor que cero, o la Prueba 2 devuelve alguna fila, la carga tiene un problema que se debe investigar antes de continuar.

Paso 3: Validar valores aceptados e integridad

Ahora asegúrese de que la columna estado solo contiene valores previstos y de que cada pedido pertenece a un cliente que existe realmente en la tabla de clientes.

-- Prueba 3: estado solo puede contener valores de la lista
SELECT DISTINCT estado
FROM stg_encomendas
WHERE estado NOT IN ('nova', 'paga', 'cancelada');

-- Prueba 4: integridad referencial con la tabla de clientes
SELECT e.id_encomenda
FROM stg_encomendas AS e
LEFT JOIN stg_clientes AS c
  ON e.id_cliente = c.id_cliente
WHERE c.id_cliente IS NULL;

La Prueba 3 revela estados inválidos, como un error de escritura procedente del origen. La Prueba 4 muestra pedidos con un id_cliente que no corresponde a ningún cliente, una señal típica de datos desalineados entre tablas.

Paso 4: Probar la frescura de los datos

Un pipeline puede terminar sin errores y aun así traer solo datos antiguos. Esta prueba confirma que la última carga trajo registros recientes.

-- Prueba 5: debe haber pedidos de las últimas 24 horas
SELECT COUNT(*) AS encomendas_recentes
FROM stg_encomendas
WHERE data_encomenda >= CURRENT_TIMESTAMP - INTERVAL '24' HOUR;

Aquí la lógica se invierte: la prueba falla si el resultado es cero. La sintaxis de los intervalos de tiempo cambia entre warehouses, así que adapte INTERVAL '24' HOUR al suyo (por ejemplo, con DATEADD en SQL Server). Ajuste también la ventana a la frecuencia de su pipeline.

Paso 5: Unir todo en una sola prueba

Para automatizar, una las pruebas que devuelven "filas en fallo" en una sola consulta con UNION ALL. Cada fila del resultado se convierte en un fallo que investigar, y un resultado vacío significa que todo está bien.

SELECT 'nulo:id_encomenda' AS teste, CAST(id_encomenda AS VARCHAR) AS detalhe
FROM stg_encomendas
WHERE id_encomenda IS NULL

UNION ALL

SELECT 'estado_invalido' AS teste, estado AS detalhe
FROM stg_encomendas
WHERE estado NOT IN ('nova', 'paga', 'cancelada');

Guarde esta consulta como el paso final de su ELT — por ejemplo, en un modelo de dbt, una task de Airflow o un procedimiento programado. Si devuelve filas, haga que el pipeline se detenga o envíe una alerta al equipo, para que nadie construya informes sobre datos incorrectos.

Verificar el resultado

Para confirmar que las pruebas funcionan, inserte a propósito una fila inválida y vuelva a ejecutar las consultas:

INSERT INTO stg_encomendas (id_encomenda, id_cliente, valor, data_encomenda, estado)
VALUES (NULL, 10, 25.0, CURRENT_TIMESTAMP, 'expedida');

Tras esta inserción, la Prueba 1 debería devolver 1 y la Prueba 3 debería mostrar el estado 'expedida', que no está en la lista permitida. Si eso ocurre, las pruebas están detectando problemas como se esperaba. Elimine la fila de prueba al final para dejar la tabla como estaba.

Conclusión

Con solo cinco consultas simples ya valida nulos, duplicados, valores aceptados, integridad referencial y frescura cada vez que se ejecuta el ELT, detectando errores antes de que lleguen a los informes. El siguiente paso es convertir estas pruebas en parte automática del pipeline y guardar cada resultado en una tabla de histórico, para seguir la evolución de la calidad a lo largo del tiempo. ¿Cuál de estas reglas sería la más crítica en sus propios datos?