Cómo validar checksums en ELT para detectar regresiones

João Barros 06 de October de 2026 6 min de lectura

Este tutorial muestra cómo implementar y validar checksums (hashes) en ELT para detectar regresiones y corrupciones en los datos durante las cargas. Validar checksums ayuda a garantizar integridad, facilita el reprocesado idempotente y reduce sorpresas en producción. Explicaré el porqué de cada paso y daré ejemplos concretos: por ejemplo, cómo gestionar un conjunto de 100k–1M de filas y qué métricas monitorizar (porcentaje de cambio, tiempo de procesamiento).

Pre-requisitos

Entorno con SQL (ej.: Azure Synapse, Databricks SQL, PostgreSQL) o Spark/Databricks.
Una tabla de origen con columnas simples (strings/números) o archivos Parquet/CSV. Idealmente comienza con una tabla pequeña (~10k filas) para validar el proceso antes de escalar a 100k–1M.
Permiso para crear tablas temporales y ejecutar funciones de hash (MD5/SHA1/SHA256). SHA256 es recomendado por ser resistente a colisiones (256 bits).
Conocimientos básicos de SQL o PySpark. Como mínimo saber ejecutar SELECT, JOIN y crear tablas simples.

Paso 1: Elegir la estrategia de checksum

Decidir si el checksum será por fila o por partición/archivo. Lo más común es generar un hash por fila basado en las columnas que representan la clave de negocio y los atributos a proteger. Para tablas con 100k–1M de filas, el cálculo por fila es fácil de almacenar (una columna adicional) y permite detectar qué registros han cambiado.

Evita incluir columnas con timestamps de ingestión si quieres idempotencia: si incluyes un campo como ingestion_time cada ejecución producirá checksums diferentes incluso sin cambios lógicos. Alternativa: generar dos checksums — row_checksum (atributos de negocio) e ingest_checksum (incluye metadata) — para diagnóstico.

Paso 2: Generar checksum por fila en SQL

Ejemplo en SQL usando SHA256 concatenando columnas en orden determinista. Incluye COALESCE para valores NULL y separador consistente. Nota: SHA256 produce 256 bits; la probabilidad de colisión es despreciable para volúmenes habituales (<10^9 filas).

-- Exemplo SQL (adaptar nome de tabela/colunas)
SELECT
  id,
  col1,
  col2,
  col3,
  LOWER(CONVERT(VARCHAR(64), HASHBYTES('SHA2_256',
      CONCAT(COALESCE(col1,''|'') , '||' , COALESCE(CAST(col2 AS VARCHAR),''), '||' , COALESCE(col3,''))
  ), 2)) AS row_checksum
FROM source_table;

En sistemas donde HASHBYTES no soporta strings grandes, serializa sólo los campos críticos (ej.: 5–10 columnas) o usa funciones nativas como sha2 en Databricks. Prueba con una muestra de 1k–10k filas para medir tiempo: en clústeres modestos generar 100k checksums SHA256 suele tardar entre 10–60s.

Paso 3: Generar checksum por fila en PySpark

Ejemplo en PySpark/Databricks usando SHA2. Mantén el orden de las columnas y trata NULLs explícitamente. PySpark escala bien: un clúster con 4 cores puede procesar 1M filas en 1–3 minutos dependiendo de la complejidad de las transformaciones.

# Exemplo PySpark
from pyspark.sql.functions import sha2, concat_ws, coalesce, lit, col

df = spark.table('source_table')
df_with_checksum = df.withColumn('row_checksum',
    sha2(concat_ws('||', coalesce(col('col1'), lit('')), coalesce(col('col2').cast('string'), lit('')), coalesce(col('col3'), lit(''))), 256)
)
df_with_checksum.createOrReplaceTempView('source_with_checksum')

Paso 4: Almacenar checksums y metadatos

Creas una tabla de auditoría que guarda clave, checksum, source_run_id y source_timestamp. Guarda también el número de filas y un hash global por partición/archivo para diagnosticar corrupciones de archivos grandes. Por ejemplo, para 1M de filas, una tabla audit_checksums con 1M de registros es trivial de almacenar en formato columnar (Parquet/Delta).

CREATE TABLE audit_checksums (
    id STRING,
    row_checksum STRING,
    source_run_id STRING,
    source_timestamp TIMESTAMP
);

INSERT INTO audit_checksums
SELECT id, row_checksum, 'run_20261006_01', CURRENT_TIMESTAMP FROM source_with_checksum;

Ejemplo de hash global por partición: agregas los row_checksums ordenados y calculas un hash final. Esto detecta diferencias a nivel de archivo incluso si el número de filas es igual.

Paso 5: Comparar checksums entre ejecuciones

Para detectar regresiones haces un JOIN entre la tabla actual y la tabla de auditoría anterior: checksum distinto => cambio; ausencia en la actual => eliminación; ausencia en la anterior => nueva fila. Analiza porcentajes: por ejemplo, si >0.1% de las filas aparecen como CHANGED en un proceso diario puede ser aceptable en algunos escenarios, pero si es >1% merece investigación.

-- Exemplo SQL de comparación
WITH prev AS (SELECT id, row_checksum AS prev_checksum FROM audit_checksums WHERE source_run_id = 'run_prev'),
     curr AS (SELECT id, row_checksum AS curr_checksum FROM source_with_checksum)
SELECT
  COALESCE(curr.id, prev.id) AS id,
  CASE
    WHEN prev.id IS NULL THEN 'NEW'
    WHEN curr.id IS NULL THEN 'DELETED'
    WHEN prev.prev_checksum != curr.curr_checksum THEN 'CHANGED'
    ELSE 'UNCHANGED'
  END AS status
FROM prev FULL OUTER JOIN curr ON prev.id = curr.id;

Paso 6: Manejar falsos positivos y normalización

Errores comunes: diferencias por orden de columnas, espacios en blanco, tipos diferentes o columnas irrelevantes. Normaliza strings (trim, lower), ordena colecciones antes de serializar y convierte tipos para evitar falsos positivos. Por ejemplo, usa LOWER(TRIM(col_name)) y convierte decimales a un formato con precisión fija antes de hash.

-- Normalização simples em SQL
LOWER(TRIM(col_name))
-- Em PySpark usa trim(lower(col('col')))

También define un umbral para alertas automáticas: por ejemplo, si NEW + DELETED + CHANGED > 0.5% de las filas diarias, crea una alerta y lanza un job de validación en profundidad.

Verificar el resultado

Valida ejecutando la comparación entre dos ejecuciones de ejemplo: introduce un cambio intencional en una fila y verifica si el estado aparece como CHANGED; elimina una fila y verifica DELETED; añade una fila y verifica NEW. Confirma también que filas con sólo el timestamp de ingestión distinto aparecen como UNCHANGED si ese campo no está incluido en el checksum. Registra métricas: tiempo de cálculo, número de cambios y porcentaje relativo para construir un histórico (p. ej. media diaria de 0.03% de cambios).

Conclusión

Implementar checksums en ELT es una técnica simple y poderosa para detectar regresiones, validar integridad y facilitar reprocesados idempotentes. Próximos pasos prácticos: automatizar la carga de los audit logs, crear alertas cuando el porcentaje de cambios exceda un umbral y generar checksums por partición para validar archivos grandes. Consejo: empieza por proteger un conjunto pequeño de tablas críticas (3–5 tablas) e itera conforme encuentres falsos positivos; en 2–4 semanas tendrás un mecanismo robusto que reduce investigaciones manuales y aumenta la confianza en las cargas.