Calidad de datos en el pipeline: validaciones, observabilidad y SLAs

Capítulo 24 · Parte III: Integración de datos y ETL/ELT · Guía práctica para diseñar y operar la arquitectura de datos de tu empresa

Capítulo 24 de la Guía práctica para diseñar y operar la arquitectura de datos de tu empresa. En el capítulo anterior aprendimos a mover datos casi en tiempo real con CDC y Debezium. Este capítulo aborda la consecuencia inevitable de esa velocidad: si los datos fluyen en segundos, los errores también. Toca hablar de calidad de datos en el pipeline.

El informe que nadie cuestionó, hasta que fue demasiado tarde

La escena se repite con pequeñas variaciones en empresas de todos los tamaños. Un lunes por la mañana, el comité de dirección revisa el cuadro de mando de ventas y algo no cuadra: la facturación del fin de semana aparece un 40% por debajo de lo esperado. Se convoca una reunión de urgencia, se especula con problemas de demanda, alguien menciona a la competencia. Horas después, un ingeniero de datos descubre la verdad: un cambio menor en el sistema origen —una columna que pasó a admitir nulos— hizo que el proceso de carga descartara silenciosamente miles de líneas de pedido. El pipeline no falló. No saltó ninguna alerta. Los datos llegaron a su destino puntualmente, con su esquema correcto y su carga completada en verde. Simplemente, estaban mal.

Este es el rasgo más traicionero de los problemas de calidad de datos: la mayoría no rompe nada visible. Un pipeline que revienta con un error es un incidente ruidoso que alguien atiende en minutos; un pipeline que entrega datos incorrectos con aspecto saludable es una fuga silenciosa que erosiona decisiones durante días o semanas, y que suele descubrir la persona equivocada en el peor momento posible: el usuario de negocio delante del informe. Cuando eso ocurre dos o tres veces, el daño ya no es el incidente concreto, sino algo mucho más caro de reparar: la confianza en la plataforma de datos. Y una plataforma en la que nadie confía es una plataforma que nadie usa, por brillante que sea su arquitectura.

El problema se ha agravado con la evolución que venimos describiendo en esta Parte III. Cuando los datos llegaban una vez al día en una carga batch, había una ventana natural para revisarlos; con las arquitecturas de CDC y streaming, los datos —y sus errores— se propagan en segundos a cuadros de mando, modelos de machine learning y procesos operativos. Y con la inteligencia artificial consumiendo datos corporativos, un dato erróneo ya no solo tuerce un gráfico: entrena un modelo, alimenta un agente o fundamenta una respuesta automática. La calidad de datos ha dejado de ser una tarea de limpieza ocasional para convertirse en una disciplina de ingeniería continua, con sus tests, su monitorización y sus acuerdos de servicio. Exactamente de eso va este capítulo.

Qué es la calidad de datos en el pipeline: del diagnóstico anual al control continuo

Definamos el concepto con precisión, porque arrastra décadas de connotaciones. La calidad de datos es el grado en que los datos son aptos para el uso que se les quiere dar; la calidad de datos en el pipeline es la práctica de medir y garantizar esa aptitud de forma automática, en cada ejecución, dentro del propio flujo de datos, en lugar de auditarla a posteriori sobre el almacén. Es la diferencia entre pasar la ITV una vez al año y llevar un coche moderno que monitoriza la presión de los neumáticos en cada trayecto.

La disciplina clásica de gestión de calidad de datos —la de los programas corporativos de limpieza, los data stewards y los comités— sigue siendo necesaria y la retomaremos en la Parte VI dedicada a la gobernanza. Lo que ha cambiado es dónde se libra la batalla técnica: en las plataformas modernas, la calidad se implementa como código, versionada junto al pipeline, ejecutada por el orquestador y monitorizada como se monitoriza la infraestructura. Los ingleses lo han bautizado con analogías de ingeniería de software que resultan muy exactas: los datos se testean como se testea el código, y se observan como se observan los sistemas en producción.

Para no discutir en abstracto, conviene fijar el vocabulario de las dimensiones de calidad, el marco que permite a negocio y tecnología hablar el mismo idioma. Las seis canónicas: la exactitud (¿el dato refleja la realidad? un DNI mal tecleado es un dato inexacto), la completitud (¿están todos los datos que deberían estar? líneas de pedido descartadas, campos vacíos), la consistencia (¿el mismo hecho coincide entre sistemas? el saldo del CRM contra el del ERP), la validez (¿cumple el formato y el dominio esperados? una fecha imposible, un código postal de siete dígitos), la unicidad (¿hay duplicados que no deberían existir?) y la puntualidad o frescura (¿el dato llega cuando se necesita?). No son una taxonomía académica: son la plantilla con la que se diseñan validaciones, se organizan las métricas de observabilidad y se redactan los SLAs. Cada control que veremos en este capítulo protege una o varias de estas dimensiones.

Y una idea con fuerza que ordena todo lo demás: el coste de un error crece con cada etapa que avanza. Corregir un registro inválido en la ingesta es una operación técnica rutinaria; corregirlo cuando ya ha pasado por las transformaciones, se ha agregado en las tablas de consumo, ha alimentado un informe regulatorio y ha entrenado un modelo exige reconciliar cada eslabón hacia atrás. De ahí el principio shift-left heredado del testing de software: desplazar los controles lo más cerca posible del origen. Las tres capas que siguen —validaciones, observabilidad y SLAs— son la materialización práctica de ese principio.

Primera capa: validaciones, los tests que viajan con el dato

La primera línea de defensa son las validaciones: afirmaciones explícitas y automatizadas sobre cómo deben ser los datos, evaluadas en puntos concretos del pipeline. Son el equivalente exacto de los tests en ingeniería de software, y como ellos, se escriben como código, se versionan en Git y se ejecutan en cada carga. Una validación dice cosas como "la columna importe nunca es negativa", "el identificador de cliente es único y no nulo", "cada pedido referencia a un cliente existente" o "el total de líneas cargadas hoy no difiere más de un 20% de la media de los últimos treinta días".

Conviene organizarlas mentalmente en tres niveles de sofisticación creciente. Las validaciones técnicas o de esquema comprueban la estructura: tipos de datos, nulabilidad, formatos, rangos elementales. Son baratas, rápidas y deberían ser universales; su lugar natural es la frontera de entrada, la capa Bronze de una arquitectura Medallion, antes de que el dato toque nada más. Las validaciones de integridad verifican las relaciones: unicidad de claves, integridad referencial entre tablas, conservación de volúmenes entre etapas (las filas que entran contra las que salen de una transformación, el control de cuadre más rentable que existe). Y las validaciones de negocio codifican el conocimiento del dominio: un descuento no supera el 100%, una fecha de alta hospitalaria no es anterior al ingreso, un pedido entregado tiene transportista asignado. Estas últimas son las más valiosas y las más difíciles de escribir, porque el conocimiento que codifican no está en el equipo de datos: está en negocio, y extraerlo exige conversación, no teclado.

El ecosistema de herramientas ha madurado notablemente. En el mundo de la transformación, los tests de dbt han popularizado la validación declarativa: cuatro tests genéricos de serie (unicidad, no nulidad, valores aceptados e integridad referencial) que se declaran en el YAML del modelo, más tests singulares en SQL y paquetes comunitarios que amplían el repertorio; su gran acierto es que el test vive pegado al modelo que valida. En el mundo Python, Great Expectations —cuyo motor GX Core mantiene licencia Apache 2.0— construyó todo un lenguaje de "expectativas" sobre los datos, con cientos de comprobaciones predefinidas y documentación autogenerada. Soda aporta un enfoque similar con su lenguaje declarativo de checks, y prácticamente todos los orquestadores y plataformas ETL comerciales incorporan ya nodos de validación. La herramienta importa menos que la disciplina: validaciones versionadas, ejecutadas en cada carga y con resultados visibles.

Ahora bien, escribir el test es la mitad del trabajo; la otra mitad es decidir qué ocurre cuando falla, y aquí es donde se separan las implementaciones maduras de las decorativas. La decisión clave es la severidad: un fallo puede ser bloqueante (el pipeline se detiene y el dato no avanza; reservado para errores que corromperían el destino, como duplicados de clave o violaciones de esquema) o de advertencia (el dato avanza, pero queda constancia y alguien lo revisa; adecuado para anomalías estadísticas o degradaciones tolerables). Junto a la severidad, el destino del dato rechazado: el patrón de cuarentena —desviar los registros inválidos a una zona de rechazados con el motivo anotado, dejando pasar los válidos— evita el dilema perverso de "o todo o nada" y convierte cada rechazo en material de diagnóstico. Quien haya leído el capítulo 22 reconocerá al primo hermano de las dead-letter queues de la ingesta. Y para los flujos críticos, el circuit breaker de datos: si el porcentaje de rechazos supera un umbral, no estamos ante registros sueltos defectuosos sino ante un problema sistémico aguas arriba, y lo responsable es cortar la publicación antes que entregar un dataset diezmado.

Queda un asunto que merece párrafo propio: los contratos de datos. Una validación protege al consumidor, pero no obliga al productor: el equipo del ERP puede cambiar una columna sin saber siquiera que veinte pipelines dependen de ella. El contrato de datos formaliza esa dependencia: un acuerdo explícito y versionado —esquema, semántica, garantías de calidad y frescura— entre quien produce un dataset y quienes lo consumen, idealmente verificado de forma automática en la integración continua del productor, de modo que un cambio incompatible falle antes de desplegarse. Es shift-left llevado a su conclusión lógica: el control no se ejecuta ya en el pipeline del consumidor, sino en el ciclo de desarrollo del productor. Su dificultad no es técnica sino organizativa —exige que los equipos de aplicaciones asuman responsabilidades sobre datos que hasta ahora "simplemente emitían"—, y por eso funciona cuando empieza pequeño: los tres o cuatro datasets más críticos, con productores dispuestos, y crecer desde el éxito.

Segunda capa: observabilidad de datos, detectar lo que nadie previó

Las validaciones tienen un límite epistemológico: solo detectan los problemas que alguien imaginó de antemano. Pero los incidentes más dañinos suelen ser precisamente los que nadie ha previsto: la fuente que deja de enviar datos sin error alguno, la distribución de un campo que se desplaza gradualmente, el volumen que cae un 30% porque un filtro anterior cambió de comportamiento. Para esa categoría de problemas nació la observabilidad de datos: la monitorización continua y en buena medida automática del comportamiento de los datos, para detectar anomalías sin necesidad de haber escrito una regla explícita para cada una.

La disciplina se ha consolidado alrededor de cinco pilares que funcionan como los signos vitales de un dataset. La frescura (¿cuándo se actualizó por última vez esta tabla, y es eso normal para ella?), el volumen (¿cuántas filas llegaron, comparadas con su patrón histórico?), el esquema (¿ha cambiado la estructura: columnas nuevas, eliminadas, tipos alterados?), la distribución (¿los valores se comportan como siempre: tasa de nulos, cardinalidad, medias, percentiles?) y el linaje (¿de dónde viene este dato y a qué afecta aguas abajo?). Los cuatro primeros se monitorizan con perfilado periódico y detección de anomalías —desde umbrales estáticos hasta modelos que aprenden la estacionalidad de cada métrica: que el volumen caiga en domingo puede ser normal; que caiga un martes, no—. El quinto, el linaje, es el que convierte una alerta en una respuesta: saber que la tabla afectada alimenta el informe regulatorio del jueves cambia la prioridad del incidente, y saber qué transformación introdujo la anomalía acorta el diagnóstico de horas a minutos. Es la conexión natural con el catálogo de datos que trataremos en el capítulo dedicado al lineage y la automatización del catálogo, y la razón por la que ambas disciplinas convergen: plataformas de catálogo como OpenMetadata incorporan perfilado y tests de calidad, y las herramientas de observabilidad construyen su propio linaje.

El mercado ofrece dos caminos que no son excluyentes. El de las plataformas comerciales de observabilidad de datos —Monte Carlo popularizó la categoría y el término data downtime, y compite con actores como Acceldata, Sifflet o las capacidades crecientes de las propias plataformas cloud— que se conectan al warehouse y a los pipelines, aprenden el comportamiento normal de miles de tablas y alertan sobre desviaciones con poco esfuerzo de configuración inicial. Y el camino open source y componible: perfilado programado con las herramientas de validación ya citadas, métricas exportadas a la plataforma de monitorización general (Prometheus, Grafana y compañía), paquetes como Elementary para el ecosistema dbt, y el módulo de calidad del propio catálogo. En nuestra valoración, la elección depende menos del presupuesto que de la escala del problema: con decenas de tablas críticas, el enfoque componible bien ejecutado cubre las necesidades; con miles de tablas y docenas de equipos consumidores, el aprendizaje automático de las plataformas dedicadas empieza a justificar su coste, porque escribir y mantener manualmente la monitorización de todo el patrimonio es, sencillamente, inviable.

Un aviso de experiencia acumulada del sector: la observabilidad mal calibrada muere de éxito. Un despliegue entusiasta que activa detección de anomalías sobre todo el almacén genera decenas de alertas diarias, el canal de avisos se convierte en ruido de fondo, y a las tres semanas nadie lee nada: es la fatiga de alertas, el mismo fenómeno que la observabilidad de infraestructura aprendió a sufrir hace una década. La medicina es idéntica: priorizar los datasets por criticidad (el linaje ayuda a saber cuáles importan), empezar monitorizando pocos activos con buenas alertas accionables, definir a quién llega cada aviso y con qué expectativa de respuesta, y medir la tasa de falsos positivos como una métrica de salud del propio sistema de observabilidad.

Tercera capa: SLAs de calidad, convertir la promesa en compromiso medible

Las dos capas anteriores son tecnología; la tercera es un acuerdo. Sin ella, la calidad de datos queda atrapada en una ambigüedad corrosiva: negocio asume que los datos son perfectos (hasta que descubre que no), y el equipo de datos persigue una perfección indefinida e inalcanzable (porque nadie ha dicho cuánta calidad es suficiente). Los SLAs de calidad de datos rompen esa ambigüedad trasladando al mundo del dato la disciplina que la ingeniería de fiabilidad (SRE) aplicó a los servicios, y que ya introdujimos a nivel de proyectos en el capítulo de roadmap y gobernanza: definir qué se promete, medirlo y responder cuando no se cumple.

El andamiaje conceptual tiene tres piezas que conviene distinguir con rigor. El SLI (Service Level Indicator) es la métrica: el porcentaje de registros que superan las validaciones, las horas desde la última actualización, la tasa de duplicados. El SLO (Service Level Objective) es el objetivo interno sobre esa métrica: "el 99,5% de los registros de la tabla de ventas supera las validaciones" o "el dato está disponible antes de las 7:00 el 99% de los días hábiles". Y el SLA (Service Level Agreement) es el compromiso formal con el consumidor, con sus consecuencias pactadas cuando se incumple —que en un contexto interno no son penalizaciones económicas, sino protocolos: comunicación proactiva del incidente, prioridad de resolución, revisión postmortem—. La jerga importa menos que la lógica: métrica, objetivo, compromiso.

El diseño de buenos SLOs de calidad es un ejercicio de negociación más que de ingeniería, y ahí van los matices que la práctica de consultoría enseña.
Primero: los SLOs se definen con el consumidor, no para el consumidor; el objetivo de frescura del dato de ventas lo fija quien decide con él a qué hora se sienta a mirarlo, no la capacidad técnica del pipeline.
Segundo: no todos los datasets merecen SLA; el esfuerzo de medir y sostener compromisos se reserva para los productos de datos críticos —el informe regulatorio, el dataset que alimenta el modelo en producción, el cuadro de mando de dirección—, y pretender SLAs universales es la forma más rápida de no tener ninguno creíble.
Tercero: el concepto de presupuesto de error (error budget) traduce el objetivo en gestión cotidiana: un SLO del 99,5% de registros válidos concede un 0,5% de margen; mientras el margen no se consume, el equipo invierte en evolución; cuando se agota, la prioridad pasa a ser estabilizar. Es el mecanismo que evita tanto la negligencia como el perfeccionismo paralizante. Y cuarto: el indicador agregado que mejor entiende la dirección es el data downtime —el tiempo durante el cual los datos están indisponibles, incompletos o erróneos—, porque se parece sospechosamente al indicador de caída de servicio que ya conocen, y porque su reducción trimestre a trimestre es la mejor evidencia de que la inversión en calidad rinde.

Cuatro sectores, cuatro lecciones de calidad

Como en cada capítulo, la teoría se asienta mejor con las cicatrices ajenas, contadas en tercera persona y con sus matices.

Banca: el coste de cuadrar a mano. Una entidad financiera europea dedicaba cada cierre de mes un equipo completo a reconciliar manualmente las cifras de riesgo entre el sistema origen y el datamart regulatorio, porque las discrepancias eran habituales y el informe al supervisor no admite errores. El rediseño no empezó por herramientas sino por cartografía: identificar los veinte controles de cuadre que el equipo ejecutaba a mano y codificarlos como validaciones automáticas de conservación de volúmenes e importes entre cada etapa del pipeline. El resultado no fue solo el ahorro de esfuerzo: fue que las discrepancias pasaron a detectarse el día que se producían, con el linaje señalando la transformación culpable, en lugar de aflorar en la semana de cierre con toda la presión regulatoria encima. La lección: las validaciones más rentables ya existen, escondidas en los procedimientos manuales de reconciliación; el primer proyecto de calidad suele ser traducirlos a código.

E-commerce: la anomalía que era una campaña. Un retailer online desplegó detección de anomalías sobre sus tablas de pedidos y sufrió el bautizo clásico: la primera gran alerta de volumen —un pico del triple de pedidos en dos horas— no era un error, era el arranque de una campaña de marketing que el equipo de datos desconocía. Tras el rubor inicial, la organización extrajo la conclusión correcta: el problema no era la herramienta sino el aislamiento; se estableció un canal por el que marketing anticipa las campañas al equipo de plataforma, y las ventanas de campaña se anotan en el sistema de observabilidad para ajustar la sensibilidad. Con el tiempo, la misma monitorización que dio la falsa alarma detectó un caso real: una caída del 25% en pedidos desde la app que resultó ser un error de la pasarela de pago tras una actualización, detectado por los datos antes que por la monitorización técnica de la propia app. La lección: la observabilidad de datos acaba siendo un sensor del negocio entero, y sus falsos positivos iniciales son el precio de calibrarla.

Sanidad: validar sin bloquear la asistencia. Un proyecto de plataforma analítica en el ámbito hospitalario se enfrentó a un dilema específico del sector: los datos clínicos de los sistemas asistenciales llegan con incidencias de calidad inevitables —codificaciones incompletas en episodios urgentes, registros administrativos corregidos a posteriori—, pero descartar registros sin criterio en un contexto sanitario puede sesgar los indicadores asistenciales. La solución adoptada distinguió severidades con criterio clínico: las validaciones estructurales bloquean (un identificador de paciente malformado no puede avanzar, por seguridad y por cumplimiento), mientras que las incidencias de completitud se marcan y se acompañan de un indicador de calidad visible junto al propio dato en los cuadros de mando: el usuario ve que el indicador de codificación de diagnósticos está al 87% de completitud ese mes, y decide con esa información. La lección viaja bien a cualquier sector: a veces la respuesta correcta no es bloquear ni dejar pasar, sino exponer la calidad como metadato y dejar que el consumidor informado decida.

Logística: el SLA que ordenó las prioridades. Un operador logístico con docenas de pipelines y un backlog eterno de peticiones vivía en la tiranía del último grito: cada incidencia de datos era "urgentísima" para alguien. La introducción de SLAs de calidad, dataset a dataset y negociados con cada área consumidora, tuvo un efecto lateral que nadie había previsto: obligó a las áreas a explicitar cuánto les importaba realmente cada dato. El dato de seguimiento de envíos para clientes obtuvo frescura de quince minutos con SLA formal; el informe interno de productividad semanal aceptó veinticuatro horas sin drama. Con los compromisos publicados, las alertas se enrutaron por criticidad y el equipo dejó de tratar todos los fuegos como iguales. La lección: el mayor valor del SLA no es el número, es la conversación que obliga a mantener.

Riesgos frecuentes y anti-patrones: la colección completa

El repertorio de errores en iniciativas de calidad de datos es notablemente estable de una organización a otra. Recorrerlo despacio es la vacuna más barata.

El teatro de la calidad. Existe una versión decorativa de todo lo descrito en este capítulo: validaciones que se ejecutan pero cuyas alertas no lee nadie, cuadros de mando de calidad que se presentan en el comité y no cambian ninguna decisión, severidades todas en "advertencia" porque nadie se atrevió a bloquear nada. El síntoma inequívoco: los tests fallan de forma recurrente y los datos siguen publicándose igual. Un control que no tiene consecuencias no es un control, es atrezzo; mejor tener diez validaciones con respuesta garantizada que doscientas ignoradas.

Validar solo a la entrada (o solo a la salida). Hay quien concentra todos los controles en la ingesta y da por buena toda la cadena posterior, olvidando que las transformaciones propias son una fuente de errores tan fértil como los orígenes: un join que multiplica filas, un filtro mal puesto, una agregación con la granularidad equivocada. Y hay quien solo valida el producto final, descubriendo el error donde es más caro diagnosticarlo. La geometría correcta es de puertas sucesivas: controles ligeros y estructurales en la entrada, controles de integridad y cuadre tras cada transformación relevante, y controles de negocio sobre la capa de consumo.

Perseguir el 100%. La calidad perfecta no existe y perseguirla tiene coste marginal creciente: cada nueve adicional en el objetivo multiplica el esfuerzo. Peor aún, el perfeccionismo suele traducirse en bloqueos agresivos que sacrifican la puntualidad —una dimensión de calidad— en el altar de la exactitud —otra dimensión—, cuando el consumidor quizá prefería el dato a las 7:00 con un 99% de completitud que a las 12:00 con el 99,9%. Las dimensiones de calidad se equilibran entre sí, y el punto de equilibrio lo fija el uso, no la ingeniería.

Limpiar en silencio. El pipeline que corrige, imputa o descarta datos sin dejar rastro es un anti-patrón particularmente insidioso: cada corrección silenciosa es una discrepancia futura entre el origen y el destino que alguien investigará durante días, y una decisión de negocio tomada por un ingeniero sin que negocio lo sepa. Toda corrección automática debe quedar registrada (qué se cambió, cuánto, por qué regla) y las reglas de limpieza deben ser tan visibles y gobernadas como las validaciones.

Confundir la herramienta con el programa. Comprar una plataforma de observabilidad y declararse "organización data quality driven" es el equivalente a comprarse una báscula y declararse en forma. Sin propietarios de datos que respondan por cada dataset crítico, sin proceso de triaje de incidencias y sin la conversación de SLAs con los consumidores, la mejor herramienta produce alertas huérfanas. La tecnología de este capítulo amplifica una disciplina organizativa; no la sustituye. Es la conexión con la gobernanza de datos que desarrollaremos en la Parte VI.

Olvidar los datos en movimiento. Con la adopción de CDC y streaming, aparece la tentación de aplicar los controles solo en el reposo final. Pero un flujo de eventos defectuoso puede haber alimentado consumidores operativos mucho antes de aterrizar en el warehouse. Los pipelines de streaming exigen sus propias validaciones en vuelo —esquema contra el registry, reglas por evento, cuarentena vía dead-letter— y su propia observabilidad de lag y volumen por topic.

Cómo elegir software de calidad y observabilidad de datos

El mercado de herramientas de calidad vive un momento de convergencia que conviene entender antes de comprar. Confluyen cuatro tradiciones: las suites clásicas de data quality ligadas a las plataformas de integración (Informatica, Talend/Qlik, SAP, IBM), fuertes en perfilado, estandarización y deduplicación masiva; las herramientas de testing nacidas del stack moderno (tests de dbt, Great Expectations, Soda), ligeras, declarativas y pensadas para vivir en Git y CI/CD; las plataformas de observabilidad de datos (Monte Carlo, Acceldata, Sifflet y un ecosistema creciente), centradas en detección automática de anomalías y linaje; y los catálogos con calidad integrada (OpenMetadata y equivalentes comerciales), que apuestan por unificar metadatos, linaje y controles en un solo plano. Las fronteras se difuminan cada trimestre: los catálogos añaden perfilado, las plataformas de observabilidad añaden validaciones declarativas, y las suites clásicas se modernizan.

Los criterios de selección, en el orden en que deberían pesar. Primero, la cobertura de tu stack real: que hable con tu warehouse, tu lakehouse, tu orquestador y tus pipelines de streaming concretos, no con una lista genérica de logotipos; la prueba de concepto sobre tus tres datasets más problemáticos es innegociable. Segundo, el modelo de definición de controles: como código versionable (imprescindible si tu equipo trabaja con CI/CD) o mediante interfaz visual (relevante si quieres que perfiles menos técnicos, incluidos los data stewards, mantengan reglas de negocio). Tercero, la integración con el flujo de trabajo de incidentes: enrutado de alertas, propiedad por dataset, y sobre todo linaje que acelere el diagnóstico; una alerta sin contexto de impacto es media alerta. Cuarto, la escalabilidad económica: los modelos de precio por volumen escaneado o por tabla monitorizada pueden crecer de forma incómoda con el patrimonio de datos; hay que modelar el coste al doble del tamaño actual. Y quinto, la distinción de licenciamiento que mantenemos en toda la guía: open source real (los tests de dbt sobre dbt Core, GX Core, Soda Core u OpenMetadata, todos bajo Apache 2.0), open core con capacidades premium en la versión comercial, y propietario puro; ninguna opción es intrínsecamente mejor, pero conviene saber qué se firma y qué pasa con los controles escritos si algún día se cambia de plataforma.

El consejo de arquitectura que resume la sección: en el estado actual del mercado, la combinación más sensata para la mayoría de organizaciones es validaciones como código en la capa de transformación (la herramienta que ya usa el equipo: tests de dbt o equivalente), observabilidad proporcional a la escala (componible al principio, plataforma dedicada cuando el patrimonio la justifique) y el catálogo como punto de encuentro donde calidad, linaje y propiedad se ven juntos. Comprarlo todo el primer año rara vez acaba bien; la madurez se construye por capas, como el propio pipeline.

Checklist operativo: calidad de datos lista para producción

La lista de verificación antes de dar por implantada la calidad en un pipeline crítico:

• Datasets críticos identificados y priorizados, con propietario asignado que responde por su calidad, y criticidad justificada por el uso (regulatorio, operativo, dirección).
• Validaciones en las tres capas: técnicas en la entrada, de integridad y cuadre tras cada transformación relevante, de negocio en la capa de consumo; todas versionadas en Git y ejecutadas por el orquestador en cada carga.
• Severidades y consecuencias definidas por validación: qué bloquea, qué advierte, y quién responde a cada tipo de fallo con qué plazo.
• Cuarentena operativa: zona de registros rechazados con motivo anotado, proceso de revisión periódica y métrica de tasa de rechazo vigilada (con circuit breaker en los flujos donde un rechazo masivo deba frenar la publicación).
• Observabilidad de los signos vitales en los datasets priorizados: frescura, volumen, esquema y distribución con detección de anomalías, y linaje disponible para evaluar impacto aguas abajo.
• Alertas gobernadas: enrutadas por criticidad y propiedad, con tasa de falsos positivos medida y revisada; ninguna alerta sin destinatario responsable.
• SLIs, SLOs y SLAs definidos con los consumidores para los productos de datos críticos, publicados donde el consumidor los vea, con presupuesto de error y protocolo de incumplimiento.
• Registro de correcciones automáticas: ninguna limpieza silenciosa; toda transformación correctiva documentada, medida y visible.
• Calidad en streaming cubierta: validación de esquema contra el registry, dead-letter queues y monitorización de lag en los flujos de eventos, no solo en el reposo.
• Postmortems de incidentes de datos: cada incidente relevante produce al menos una validación o monitor nuevo que lo habría detectado antes; el sistema de calidad crece con cada cicatriz.

Formación recomendada

Para profundizar con práctica guiada, estos cursos están directamente relacionados con el capítulo y disponibles en español:

• Introducción a la calidad de datos (DataCamp): las dimensiones de calidad, los roles y responsabilidades y el proceso completo de gestión, incluida una introducción a la detección de anomalías; la base conceptual de este capítulo en formato interactivo de 2 horas.

• Introducción a la calidad de datos con Great Expectations (DataCamp): la implementación práctica de validaciones con la biblioteca GX Core en Python: expectativas, suites, checkpoints y su despliegue en pipelines de producción.

• dbt intermedio (DataCamp): técnicas avanzadas de testing en dbt —tests genéricos, singulares y personalizados con Jinja, tests sobre fuentes y seeds— para llevar la validación como código a flujos de transformación listos para producción.

Preguntas frecuentes sobre calidad de datos en el pipeline

¿Qué es la calidad de datos en el pipeline?

Es la práctica de medir y garantizar la aptitud de los datos de forma automática y continua dentro del propio flujo de datos, mediante validaciones ejecutadas en cada carga, monitorización del comportamiento de los datos (observabilidad) y compromisos medibles de calidad (SLAs), en lugar de auditar la calidad a posteriori sobre el almacén.

¿Cuáles son las dimensiones de la calidad de datos?

Las seis dimensiones canónicas son exactitud (el dato refleja la realidad), completitud (no falta información), consistencia (el mismo hecho coincide entre sistemas), validez (cumple formato y dominio), unicidad (sin duplicados indebidos) y puntualidad o frescura (llega cuando se necesita). Sirven como vocabulario común entre negocio y tecnología para diseñar controles y acordar objetivos.

¿Qué diferencia hay entre validación de datos y observabilidad de datos?

Las validaciones son reglas explícitas escritas de antemano ("el importe no es negativo") que se evalúan en cada ejecución y pueden bloquear datos que las incumplen: detectan los problemas previstos. La observabilidad monitoriza de forma continua los signos vitales de los datos (frescura, volumen, esquema, distribución) y detecta anomalías sin reglas previas: cubre los problemas que nadie imaginó. Una estrategia madura combina ambas.

¿Qué es un SLA de calidad de datos?

Es un compromiso formal y medible sobre la calidad de un dataset acordado con sus consumidores: por ejemplo, "disponible antes de las 7:00 con al menos el 99,5% de registros válidos el 99% de los días hábiles". Se apoya en SLIs (las métricas) y SLOs (los objetivos internos), y define qué ocurre cuando se incumple: comunicación proactiva, prioridad de resolución y análisis postmortem.

¿Qué es el data downtime?

Es el tiempo durante el cual los datos están indisponibles, incompletos o son erróneos, es decir, el periodo en que los consumidores no pueden confiar en ellos. Funciona como indicador agregado de la salud de la plataforma de datos, equivalente al tiempo de caída de un servicio, y su reducción sostenida es la evidencia más comprensible para la dirección del retorno de la inversión en calidad.

¿Qué herramientas open source existen para la calidad de datos?

Las más consolidadas son los tests de dbt (integrados en dbt Core), Great Expectations (cuyo motor GX Core mantiene licencia Apache 2.0), Soda Core y las capacidades de perfilado y tests de calidad de catálogos como OpenMetadata, también bajo Apache 2.0. Cubren validación declarativa, perfilado y documentación de resultados; para la detección automática de anomalías a gran escala, el mercado ofrece además plataformas comerciales de observabilidad de datos.

En resumen

La calidad de datos ha dejado de ser una auditoría ocasional para convertirse en una disciplina de ingeniería continua con tres capas que se refuerzan: validaciones que codifican lo que sabemos que puede fallar, observabilidad que vigila lo que no supimos prever, y SLAs que convierten la calidad en un compromiso negociado con quien consume el dato. La regla que ordena la inversión es el shift-left —detectar pronto es exponencialmente más barato—, la métrica que la justifica ante dirección es el data downtime, y el error que la arruina es el teatro: controles sin consecuencias. Porque el objetivo final no es técnico, es humano: que la organización pueda confiar en sus datos sin necesidad de verificarlos cada vez.

En el próximo capítulo subiremos un nivel de abstracción para hablar de quién dirige toda esta orquesta: orquestación, dependencias y observabilidad de pipelines — DAGs, políticas de retry y alerting.

Siguiente en la Parte III: capítulo 25, Orquestación de pipelines: DAGs, retry policies, alerting. · Volver al índice de la guía

Los ejemplos de este capítulo son ilustrativos y no corresponden a implantaciones concretas.

Contenido elaborado con asistencia de inteligencia artificial — Equipo Editorial Dataprix. Verifica la información antes de tomar decisiones. Última actualización: agosto de 2026.