7.8 Calidad y observabilidad de datos

Presentación y motivación

La calidad de datos es la idoneidad para el uso: el grado en que los datos sirven a las decisiones, productos, e informes que dependen de ellos. Un conjunto de datos no es bueno o malo en abstracto. Es lo bastante bueno para un propósito, o no lo es. Una dirección de cliente que está bien para un conteo de marketing puede no ser apta para un aviso legal. Ese encuadre importa, porque mueve la conversación de «¿son perfectos nuestros datos?» (nunca) a «¿son aptos nuestros datos para lo que estamos a punto de hacer con ellos?» (respondible, y comprobable). Las dimensiones clásicas son la exactitud, la completitud, la consistencia, la oportunidad, la validez, y la unicidad, y la mayoría de los problemas reales se reducen a una de ellas.

Aquí está la verdad incómoda para los equipos grandes: los datos malos son peores que ningún dato. Cuando no tienes datos, lo sabes, y procedes con la cautela apropiada. Cuando tienes datos equivocados que se ven correctos, actúas sobre ellos con falsa confianza. Los datos malos corrompen silenciosamente. Fluyen hacia un tablero en el que un ejecutivo confía, hacia un modelo de aprendizaje automático que entrena con ellos y codifica sus errores, y hacia decisiones que nadie piensa en cuestionar porque el número estaba justo ahí en la pantalla. El daño es difuso y demorado, que es exactamente por qué es costoso. Para cuando alguien se da cuenta, el número equivocado ya se citó en una presentación para la junta, una declaración regulatoria, o una estadística pública.

La observabilidad de datos es la disciplina que atrapa esto antes de que lo hagan tus consumidores. Es el paralelo directo de la observabilidad y telemetría de software (capítulo 9.2): el mismo instinto que te dice que monitorees la latencia de solicitudes y las tasas de error te dice que monitorees la frescura, el volumen, el esquema, y la distribución de los datos. Este capítulo se construye sobre la estrategia y gobernanza de datos (capítulo 7.1) y la ingeniería de datos (capítulo 7.2), y alimenta el modelado de datos y la capa semántica (capítulo 7.7) y la IA responsable y confiable (capítulo 6.5). Para las empresas que reconcilian muchos sistemas fuente y para los gobiernos que publican estadísticas estatutarias, tratar la fiabilidad de datos como un problema de ingeniería con dueños y niveles de servicio es la diferencia entre la confianza y una corrección muy pública.

Principios fundamentales

La calidad de datos es idoneidad para el uso, no perfección; defínela contra el propósito.
Los datos malos son peores que ningún dato, porque corrompen las decisiones silenciosamente.
Prueba los datos como pruebas el código: afirmaciones, expectativas, y comprobaciones de esquema en el canal.
Los contratos entre productores y consumidores hacen las expectativas explícitas y aplicables.
Observa la frescura, el volumen, el esquema, y la distribución, de la misma forma en que observas los servicios.
El linaje convierte «algo está mal» en «esto es lo que se rompió y esto es lo que afecta».
Trata los incidentes de datos como incidentes de producción, con propiedad, severidad, y niveles de servicio.
Detecta los problemas donde entran, no tres capas después en un tablero.

Recomendaciones

Define la calidad por dimensión, y mídela

Las metas de calidad vagas producen resultados vagos. Divide la calidad en dimensiones medibles y adjunta comprobaciones concretas a cada una. La exactitud pregunta si los valores reflejan la realidad (¿este ingreso registrado coincide con el libro mayor fuente?). La completitud pregunta si los registros y campos esperados están presentes (¿faltan días, están nulas las columnas requeridas?). La consistencia pregunta si el mismo hecho concuerda a través de sistemas (¿el conteo de clientes en finanzas coincide con el conteo en el almacén?). La oportunidad pregunta si los datos llegan a tiempo para ser útiles (¿están listos los datos de ayer antes del informe matutino?). La validez pregunta si los valores se ajustan a reglas y formatos (¿son reales todos los códigos de moneda, están las fechas en rango?). La unicidad pregunta si las entidades aparecen una vez (¿hay pedidos duplicados inflando el total?). Elige las dimensiones que importan para cada conjunto de datos, fija umbrales, y rastréalas con el tiempo. La calidad que no mides es calidad que estás adivinando.

Prueba los canales con afirmaciones y expectativas

Los datos merecen el mismo rigor de prueba que el código de aplicación. Usa la validación de datos en cada etapa: pruebas basadas en afirmaciones que fallan el canal cuando se viola un invariante, y pruebas basadas en expectativas que declaran cómo se ve «normal» para una tabla y señalan las desviaciones. Afirma que las claves primarias son únicas y no nulas, que las claves foráneas se resuelven, que las columnas categóricas contienen solo valores aceptados, que las columnas numéricas caen dentro de rangos plausibles, y que los conteos de filas aterrizan en una banda esperada. Añade comprobaciones de esquema que fallen ruidosamente cuando una columna se añade, elimina, renombra, o retipa aguas arriba. Ejecuta estas comprobaciones en integración continua para que una mala transformación se atrape antes de la fusión, y ejecútalas de nuevo en producción contra datos en vivo para que una mala fuente se atrape antes de que llegue a los consumidores. La meta es fallar temprano y ruidosamente, porque un canal roto es más seguro que uno silenciosamente equivocado.

Establece contratos de datos entre productores y consumidores

La mayoría de los incidentes de calidad de datos empiezan aguas arriba, cuando un equipo productor cambia un esquema, un significado semántico, o una convención de valor sin saber quién depende de ello. Un contrato de datos arregla esto haciendo explícita la interfaz: el esquema, la semántica de cada campo, los valores permitidos, las garantías de frescura, y el proceso para hacer un cambio. El productor se compromete con el contrato, el consumidor construye contra él, y un cambio disruptivo requiere versionado y aviso en lugar de una sorpresa silenciosa el lunes. Aplica los contratos mecánicamente donde puedas, validando los datos entrantes contra el contrato en la frontera y rechazando o poniendo en cuarentena las violaciones. Los contratos convierten una dependencia implícita y frágil en una explícita y negociada. También hacen visible la propiedad, que es la mitad de la batalla a escala.

Monitorea las cuatro señales de la observabilidad de datos

La observabilidad de datos vigila cuatro señales, en paralelo directo a cómo vigilas un servicio en ejecución (capítulo 9.2). Frescura: ¿son los datos tan recientes como deberían ser, o el canal se ha estancado? Volumen: ¿está el conteo de filas en el rango esperado, o llegó una tabla medio vacía o cargada doblemente? Esquema: ¿ha cambiado la estructura inesperadamente? Distribución: ¿han derivado los valores mismos, de modo que una columna que era 2 por ciento nula es repentinamente 40 por ciento nula, o un promedio se ha desplazado de una manera que señala un error aguas arriba? Instrumenta estas señales en tus tablas importantes, aprende sus patrones normales, y alerta ante incumplimientos. Así es como reemplazas «un ejecutivo notó que el tablero se veía mal» con «al equipo dueño se le avisó en el punto de fallo». El peor detector posible de un problema de datos es un humano posterior que confía en el número.

Añade detección de anomalías, pero ajústala contra la fatiga de alertas

Los umbrales estáticos atrapan los fallos obvios. Para la deriva más sutil, añade detección de anomalías que aprende el patrón estacional normal de cada métrica y señala desviaciones estadísticamente inusuales, así atrapas una fuga lenta antes de que se convierta en una inundación. Sé disciplinado sobre esto. Las alertas de anomalía ruidosas entrenan a la gente a ignorar las alertas, lo cual es peor que ninguna alerta. Empieza con tus tablas de mayor valor, alerta solo sobre cosas ante las que un humano debería actuar, enruta cada alerta a un dueño nombrado, y ajusta sin piedad. Una alerta ante la que nadie actúa es un error en tu monitoreo, no una función.

Rastrea el linaje para el análisis de impacto y la causa raíz

Cuando algo se rompe, dos preguntas importan de inmediato: qué lo causó, y qué afecta. El linaje de datos responde a ambas mapeando cómo fluyen los datos desde la fuente a través de cada transformación hasta cada tabla, tablero, y modelo posterior. Para la causa raíz, rastreas una cifra equivocada de vuelta aguas arriba hasta la transformación o fuente que la introdujo. Para el análisis de impacto, rastreas hacia adelante para ver cada consumidor tocado por una mala carga, así puedes notificarlos y poner en cuarentena el daño antes de que se propague. Captura el linaje automáticamente desde tus herramientas de transformación y orquestación en lugar de mantener un diagrama a mano, porque un diagrama dibujado a mano está equivocado al día siguiente de dibujarlo. En empresas con muchas fuentes, publica el linaje en un catálogo de datos para que cualquier consumidor pueda ver de dónde vino un campo y confiar en él en consecuencia.

Trata los incidentes de datos como incidentes de producción

Las prácticas que mantienen confiables a los servicios se aplican directamente a los datos. Da a cada conjunto de datos importante un dueño. Define niveles de severidad para el «tiempo de inactividad de datos», los períodos en que los datos faltan, están equivocados, o llegan tarde. Fija niveles de servicio: objetivos de frescura, un presupuesto de error aceptable, y un tiempo objetivo para detectar y resolver. Pon rotaciones de guardia de datos detrás de los canales más críticos, escribe runbooks, y ejecuta postmortems sin culpa después de los incidentes para que el mismo fallo no recurra. Cuando una tabla de pagos llega tarde o una métrica pública está equivocada, eso es un incidente, y merece la misma seriedad que una interrupción. Este es el cambio cultural que hace que rindan frutos todas las herramientas.

Perfila y reconcilia continuamente

Perfilar significa examinar rutinariamente la forma de tus datos: distribuciones de valores, tasas de nulos, cardinalidad, mínimo y máximo, y patrones de formato. Expone problemas que no pensaste en afirmar, y te dice cómo se ve «normal» para que puedas fijar buenas expectativas. La reconciliación significa comprobar que las fuentes independientes concuerdan: ¿coincide el total del almacén con el sistema fuente de registro?, ¿la suma de las partes es igual al todo? Automatiza la reconciliación entre sistemas críticos y alerta ante la divergencia, porque una ruptura de reconciliación a menudo es la señal más temprana y clara de que algo salió mal aguas arriba.

Ventajas y desventajas

Enfoque	Ventajas	Desventajas	Mejor ajuste
Pruebas de afirmación (fallo duro)	Detiene en seco los datos malos, invariantes claros	Puede bloquear canales por problemas menores	Claves críticas, integridad referencial
Pruebas de expectativa (señal suave)	Atrapa la deriva, menos frágil	Necesita ajuste, puede ignorarse	Distribuciones, bandas de volumen
Contratos de datos	Previene sorpresas aguas arriba, propiedad clara	Sobrecarga de coordinación y gobernanza	Fronteras de productor o consumidor entre equipos
Detección de anomalías	Atrapa la deriva sutil e imprevista	Fatiga de alertas, falsos positivos	Tablas de alto valor, métricas estacionales
Comprobaciones manuales puntuales	Barato para empezar, sin herramientas	No escala, se pierde errores silenciosos	Solo en etapa muy temprana
Plataforma de observabilidad completa	Cobertura amplia, linaje, alertas	Costo, configuración, otro sistema que operar	Muchas fuentes, reporte regulado

La tensión central es cobertura frente a ruido. No instrumentar nada y los problemas llegan primero a tus consumidores, lo cual destruye la confianza. Instrumentar todo con alertas de gatillo fácil y ahogas a tu equipo en falsos positivos hasta que silencian el canal, lo cual también deja que los problemas lleguen a los consumidores. Resuelve esto clasificando tus datos por radio de impacto. Las tablas que alimentan las métricas de la junta, los productos de cara al cliente, los informes regulatorios, y los modelos de aprendizaje automático reciben el tratamiento completo: contratos, afirmaciones duras, observabilidad, y propiedad de guardia. La larga cola de tablas exploratorias recibe perfilado ligero. Gasta tu presupuesto de fiabilidad donde los datos equivocados dolerían más, y sé deliberadamente escaso en todas partes más.

Preguntas para discutir con tu equipo

Cuando los datos malos llegan a producción, ¿quién se entera primero, y cómo? Esta es la pregunta más reveladora sobre tu fiabilidad de datos, porque la respuesta honesta usualmente es «un consumidor, por accidente». Si un analista, un ejecutivo, o un cliente es tu sistema de detección, tu tiempo medio de detección se mide en días y tu credibilidad recibe el golpe cada vez. La alternativa es la instrumentación que avisa al equipo dueño en el punto de fallo, antes de que el número equivocado se propague. Trae números reales: cuántos de tus últimos diez incidentes de datos fueron atrapados por el monitoreo frente a reportados por un humano posterior, y cuánto tiempo permaneció cada uno sin detectar. La respuesta te dice si tienes observabilidad o solo esperanza, y debería impulsar directamente dónde inviertes primero en comprobaciones de frescura, volumen, esquema, y distribución.
¿Cuáles conjuntos de datos tienen un dueño, un contrato, y un nivel de servicio, y cuáles son huérfanos? A escala, la mayoría de los fallos de calidad de datos se remontan a una interfaz sin dueño: un equipo productor cambió algo sin idea de quién dependía de ello, porque ningún contrato lo decía. La propiedad es el fundamento que hace posibles los contratos, las rutas de alerta, y la respuesta a incidentes, y los conjuntos de datos huérfanos son donde vive la corrupción silenciosa. Recorre tus tablas más importantes y pregunta, para cada una, quién es responsable, con qué se ha comprometido el productor, y qué frescura y exactitud se les prometen a los consumidores. Trae tu linaje: las tablas con el radio de impacto posterior más grande son las que más necesitan esto y a menudo son las que carecen de ello. La brecha entre «importante» y «con dueño» es tu lista de prioridades para el próximo trimestre.
¿Cuál es el costo real de un incidente de calidad de datos para nosotros, y lo tratamos en consecuencia? Los equipos subinvierten en calidad de datos porque el costo de los datos malos es difuso y demorado, así que nunca aparece como una línea de partida, mientras que el costo de construir herramientas de calidad es concreto e inmediato. Reencuadra esto poniendo precio a un incidente real de extremo a extremo: la decisión equivocada, el retrabajo, las horas de ingeniero gastadas rastreando la causa raíz sin linaje, la confianza erosionada que hace que la gente reconstruya silenciosamente sus propios conjuntos de datos en la sombra, y, en entornos regulados o de cara al público, el aviso de corrección y su daño reputacional. Trae un ejemplo específico del último año y súmalo honestamente. Si un único fallo silencioso en un canal de pagos o de estadísticas públicas pudiera costar más que un año de herramientas de observabilidad, el caso de negocio se hace solo, y la conversación cambia de si invertir a dónde.
¿Hemos clasificado nuestros conjuntos de datos por radio de impacto, y nuestra inversión en monitoreo realmente sigue esa clasificación? El modo de fallo central a escala es gastar el esfuerzo de fiabilidad uniformemente, así que la tabla exploratoria en la que nadie confía recibe la misma atención que la que alimenta las métricas de la junta, mientras una alerta de gatillo fácil en una tabla de bajo valor entrena a la gente a silenciar el canal que también lleva el aviso crítico. No puedes instrumentar todo sin ahogarte en ruido, y no puedes instrumentar nada sin dejar que los problemas lleguen primero a los consumidores, así que la decisión real es dónde va el tratamiento completo (contratos, afirmaciones duras, observabilidad, y propiedad de guardia) y dónde basta el perfilado ligero. Trae un inventario de tus tablas etiquetadas por lo que depende de ellas: métricas de la junta, productos de cara al cliente, informes regulatorios, y modelos de aprendizaje automático, luego compara esa clasificación contra dónde realmente están tus comprobaciones y alertas hoy. Para una empresa que reconcilia muchas fuentes o un gobierno que publica cifras estatutarias, las tablas con exposición legal o pública pertenecen a la cima de la lista, y cualquier brecha entre «dañaría más si estuviera mal» y «se monitorea más» es un error de priorización que corregir ahora.
¿Qué modelos de aprendizaje automático y analítica están decidiendo sobre datos que nunca validamos, y qué errores podrían estar codificando silenciosamente? Un tablero muestra un número equivocado a un humano que podría cuestionarlo, pero un modelo entrena con características equivocadas y codifica esos errores en cada predicción que hace, a una escala y opacidad que hace el daño mucho más difícil de detectar o deshacer. La presión en competencia es la velocidad: los equipos de ciencia de datos quieren moverse rápido en nuevas características, y añadir validación, contratos, y garantías de frescura a cada alimentación se siente como fricción hasta que un modelo se degrada silenciosamente porque una columna aguas arriba derivó. Trae un inventario de tus modelos de producción y analítica, los conjuntos de datos que cada uno consume, y una marca honesta de cuáles de esas alimentaciones tienen pruebas, contratos, y observabilidad frente a cuáles están desprotegidas. En un entorno empresarial o gubernamental donde un modelo influye en decisiones de crédito, beneficios, o cumplimiento, los datos de entrenamiento no validados se convierten en un pasivo de auditoría y equidad además de un riesgo de calidad, así que la pregunta de qué alimentaciones bloquean el lanzamiento de un modelo debería tener un dueño y una respuesta documentada (capítulo 6.5).
Cuando un error de calidad aparece semanas después, ¿realmente podemos reprocesar y reconciliar, o ya descartamos lo que necesitaríamos? Muchos fallos de calidad son invisibles en el momento de la carga y solo se vuelven claros después, cuando una ruptura de reconciliación o una tendencia sospechosa impulsa a alguien a mirar, y para entonces la capacidad de arreglarlo limpiamente depende de elecciones que hiciste mucho antes: si conservaste registros crudos inmutables, si las fuentes independientes pueden reconciliarse, y si el linaje te permite rastrear la cifra equivocada hasta su origen. La tensión es el costo y la simplicidad frente a la reproducibilidad, porque retener datos crudos y ejecutar reconciliación continua entre sistemas no es gratis, y es tentador borrar las entradas crudas una vez que las tablas transformadas se ven bien. Trae tu política de retención e inmutabilidad para los datos crudos, la lista de pares de sistemas críticos que reconcilias automáticamente, y un ejemplo real de un error que pudiste o no pudiste resolver reprocesando. Para una agencia gubernamental bajo una obligación estatutaria de rastrear cualquier número publicado hasta los registros fuente, o una empresa enfrentando una reformulación regulatoria, los datos crudos inmutables y la reconciliación automatizada no son higiene opcional sino el mecanismo que hace defendible una corrección.

Perspectiva sectorial

Startup. La velocidad y la confianza importan más que la cobertura. Pon un puñado de pruebas ligeras en tu herramienta de transformación (unicidad y no nulo en las claves, valores aceptados en las columnas que llevan significado, una banda de conteo de filas por fuente), y añade monitoreo de frescura y volumen solo en las pocas tablas que alimentan las métricas de tu empresa. Enruta cada alerta a un único canal del que un ingeniero sea dueño, y resiste comprar una plataforma de observabilidad antes de tener las tablas o el equipo que lo justifiquen. La meta es notar un campo mal etiquetado antes de que infle un número que los fundadores citan, no instrumentar todo.

Pequeña empresa. Sin un ingeniero de datos y con un presupuesto ajustado, apóyate en las funciones de calidad ya incorporadas en el almacén, la herramienta de BI, o las plataformas SaaS por las que pagas en lugar de levantar una pila separada. Enfoca tu esfuerzo en el puñado de números que realmente impulsan las decisiones (ingresos, canal de ventas, inventario), verifícalos de cordura contra una fuente independiente en una cadencia regular, y trata las alertas de frescura y esquema de un proveedor como suficientemente buenas cuando existen. Comprar calidad incorporada en herramientas que ya operas supera a construir un canal que no tienes a nadie que mantenga.

Empresa. El problema es la fiabilidad a través de muchos equipos y miles de tablas, así que estandariza la interfaz: contratos de datos en cada frontera de productor, una plataforma de observabilidad vigilando la frescura, el volumen, el esquema, y la distribución, y linaje publicado en un catálogo para el análisis de impacto. Clasifica los conjuntos de datos por radio de impacto, pon detección de anomalías y propiedad de guardia en los de alto valor, y haz correr los incidentes de datos por el mismo proceso de severidad y postmortem que las interrupciones de servicio. Los niveles de servicio en los canales que alimentan informes regulatorios y tableros ejecutivos convierten la fiabilidad de datos de una aspiración en un compromiso medido y gobernado.

Gobierno. La exactitud estatutaria y la rendición de cuentas pública fijan el estándar: aterriza registros crudos inmutables de encuestas y administrativos, transfórmalos en etapas estratificadas y probadas, y reconcilia contra los totales fuente en cada paso. Mantén linaje completo para que cualquier cifra publicada pueda rastrearse hasta los registros fuente para la auditoría, y bloquea cada lanzamiento detrás de la validación de validez, completitud, y consistencia contra períodos anteriores. La contratación de herramientas debería exigir transparencia y portabilidad de datos, y una estadística pública equivocada debe manejarse como un incidente serio, con la misma gravedad que exige la confianza pública en las cifras oficiales.

Ejemplos

Startup. Una empresa de veinte personas opera su estrategia de mercado sobre un almacén alimentado por eventos de producto y un proveedor de pagos. Al principio, un campo de moneda mal etiquetado infló silenciosamente los ingresos reportados durante dos semanas antes de que alguien lo notara, lo cual sacudió la confianza del equipo en cada tablero. Respondieron con un conjunto ligero de pruebas en su herramienta de transformación: unicidad y no nulo en las claves, comprobaciones de valor aceptado en las columnas de moneda y estado, y una banda de conteo de filas por fuente. Añadieron monitoreo básico de frescura y volumen en el puñado de tablas que alimentan las métricas de la empresa, enrutado a un único canal de Slack del que un ingeniero es dueño. Es modesto, pero atrapa los fallos que importan, y los fundadores confían de nuevo en los números.

Empresa. Un banco multinacional reconcilia datos de clientes y transacciones a través de docenas de sistemas fuente en un almacén gobernado que alimenta informes regulatorios, modelos de riesgo, y tableros ejecutivos. Ejecuta contratos de datos en cada frontera de productor, así que un cambio de esquema aguas arriba se versiona y negocia en lugar de sorprender a los consumidores. Una plataforma de observabilidad monitorea la frescura, el volumen, el esquema, y la distribución a través de miles de tablas, con detección de anomalías en las de alto valor y linaje publicado en un catálogo de datos para el análisis de impacto. Los incidentes de datos siguen el mismo proceso de severidad y guardia que las interrupciones de servicio, con niveles de servicio en los canales que alimentan las presentaciones regulatorias. Cuando un sistema fuente deriva, al equipo dueño se le avisa y los informes posteriores afectados se conocen en minutos, no los descubre un regulador.

Gobierno. Una agencia nacional de estadísticas publica indicadores económicos que los mercados, los responsables de política, y el público tratan como autoritativos, así que la exactitud es una obligación estatutaria y cada cifra publicada debe ser auditable. Sus canales aterrizan registros crudos inmutables de encuestas y administrativos, luego los transforman en etapas estratificadas y probadas con reconciliación contra los totales fuente en cada paso. El linaje completo permite a los analistas rastrear cualquier número publicado hasta los registros fuente, lo cual es tanto una herramienta de calidad como un requisito legal. Antes del lanzamiento, las cifras pasan puertas de validación de validez, completitud, y consistencia contra períodos anteriores, y cualquier anomalía se investiga y documenta en lugar de publicarse. Una estadística pública equivocada es un incidente serio, así que la agencia trata el tiempo de inactividad de datos con la gravedad que exige la confianza pública.

Caso de negocio: motivaciones, ROI y TCO

El retorno de la calidad y observabilidad de datos viene de la confianza preservada, los incidentes acortados, y las malas decisiones evitadas. Los datos confiables son el fundamento que hace que cada inversión posterior en analítica, inteligencia de negocio, e IA realmente rinda frutos, porque un modelo o tablero es tan bueno como los datos debajo de él. Cuando las comprobaciones de calidad atrapan una mala carga en la frontera, evitas el costo mucho mayor de que un número equivocado llegue a una decisión, un cliente, o una declaración. El linaje colapsa la investigación de causa raíz de días de rastreo manual a minutos, lo cual es tiempo de ingeniería recuperado puro. La observabilidad reduce el tiempo medio de detección de «cuando un consumidor se queja» a «cuando el canal falla», que es donde se evita la mayor parte del daño a la confianza.

El costo total de propiedad incluye herramientas para pruebas, observabilidad, y catalogación, más el tiempo de ingeniería para instrumentar los canales y el trabajo organizacional de asignar dueños y escribir contratos. Esto es real, pero pésalo contra el costo de no hacerlo: corrupción silenciosa descubierta por ejecutivos, modelos de aprendizaje automático entrenados con características malas que codifican errores a escala, analistas reconstruyendo silenciosamente conjuntos de datos en la sombra porque ya no confían en los oficiales, y, en entornos regulados o públicos, avisos de corrección que dañan la credibilidad durante años. Al liderazgo, enmarca la calidad de datos como un seguro sobre cada decisión impulsada por datos que toma la organización. La prima es modesta y predecible. La pérdida sin seguro, un único número equivocado de alto perfil, no lo es.

Antipatrones y trampas

Tratar la calidad de datos como un proyecto de limpieza único en lugar de una práctica de ingeniería continua.
Descubrir los fallos por los consumidores posteriores en lugar del monitoreo en el punto de fallo.
Sin propiedad de conjuntos de datos, así que nadie es responsable cuando algo se rompe y a nadie se le avisa.
Productores cambiando esquemas o semántica sin contrato, rompiendo silenciosamente a cada consumidor.
Alertas de anomalía tan ruidosas que el equipo silencia el canal y se pierde el incidente real.
Alimentar datos no validados directamente a los modelos de aprendizaje automático, codificando errores a escala (capítulo 6.5).
Mantener el linaje como un diagrama dibujado a mano que está equivocado al día siguiente de dibujarlo.
Perseguir datos perfectos en todas partes en lugar de calidad apta para el uso en las tablas que importan.
Borrar los datos crudos, así no puedes reprocesar ni reconciliar cuando aparece un error de calidad después.

Modelo de madurez

Nivel 1, Iniciar: La calidad no es trabajo de nadie. Los problemas los encuentran los consumidores, usualmente después de que un número equivocado llega a un informe. Sin pruebas, sin monitoreo, sin propiedad. Los arreglos son apagar incendios manualmente, y los mismos fallos recurren.
Nivel 2, Desarrollar: Algunos equipos añaden pruebas básicas en sus tablas críticas (claves, nulos, valores aceptados) y un poco de monitoreo de frescura y volumen en los conjuntos de datos que más les importan. Las prácticas funcionan donde existen, pero la cobertura y el rigor varían equipo por equipo, nada está estandarizado, y los incidentes todavía se manejan de forma reactiva.
Nivel 3, Estandarizar: Las dimensiones de calidad se definen con umbrales, y las mismas expectativas se aplican a través de los equipos en lugar de depender de quién construyó un canal. Los contratos de datos gobiernan las fronteras clave de productor, la observabilidad cubre la frescura, el volumen, el esquema, y la distribución en las tablas importantes, y el linaje apoya el análisis de impacto. Cada conjunto de datos importante tiene un dueño nombrado, y los incidentes de datos siguen un proceso documentado de severidad y respuesta en toda la organización.
Nivel 4, Gestionar: La calidad y la fiabilidad se miden y controlan contra líneas base. El tiempo de inactividad de datos se rastrea con métricas reales: tiempo medio de detección, tiempo medio de resolución, frescura y exactitud contra niveles de servicio acordados, y presupuestos de error que un conjunto de datos puede gastar antes de disparar una acción. Las tasas de ruptura de reconciliación, las tasas de aprobación de pruebas, y las tasas de falsos positivos de anomalía se rastrean con tendencias en el tiempo, las alertas se ajustan contra esos números en lugar de por conjetura, y las decisiones de continuar o no con un lanzamiento de datos se toman con base en la calidad medida contra la línea base en lugar de esperanza.
Nivel 5, Orquestar: La calidad y la observabilidad son omnipresentes, automatizadas, y adaptativas. La detección de anomalías atrapa la deriva sutil, los contratos se aplican mecánicamente, y el linaje se captura automáticamente y se publica en un catálogo. Los datos tienen niveles de servicio y propiedad de guardia como los servicios de producción, la reconciliación se ejecuta continuamente, y los postmortems sin culpa alimentan una reducción constante del tiempo de inactividad de datos. La calidad está integrada con la gobernanza de datos, el aprendizaje automático, y la planificación de negocio, y la organización continuamente reajusta el alcance de los umbrales, la cobertura, y la propiedad a medida que cambia el panorama de datos.

Ideas para el debate

¿Cuáles de tus tablas causarían más daño si estuvieran silenciosamente equivocadas durante una semana, y son esas las que más monitoreas?
¿Dónde habría prevenido un contrato de datos tu último incidente causado aguas arriba, y por qué no había uno?
¿Cuánto tiempo de ingeniería toma hoy una investigación típica de causa raíz, y cuánto ahorraría el linaje automatizado?
¿Alguno de tus modelos de aprendizaje automático entrena con datos que no validas, y qué errores podrían estar codificando?
¿Está tu sistema de alertas lo bastante ajustado para que la gente actúe ante cada alerta, o alguien ha silenciado el canal?
¿Qué niveles de servicio de frescura y exactitud realmente aceptarían tus consumidores más importantes, y podrías cumplirlos hoy?

Puntos clave

La calidad de datos es idoneidad para el uso a través de la exactitud, la completitud, la consistencia, la oportunidad, la validez, y la unicidad.
Los datos malos son peores que ningún dato, porque corrompen silenciosamente las decisiones y los modelos.
Prueba los datos como código: pruebas de afirmación y expectativa más comprobaciones de esquema, en CI y en producción.
Usa contratos de datos para hacer explícitas y aplicables las expectativas de productores y consumidores.
Observa la frescura, el volumen, el esquema, y la distribución, en paralelo a la observabilidad de software (capítulo 9.2).
Captura el linaje para la causa raíz rápida y el análisis de impacto, y publícalo para los consumidores.
Trata los incidentes de datos como incidentes de producción, con propiedad, severidad, y niveles de servicio.
Instrumenta donde los datos equivocados duelen más; apunta a la calidad apta para el uso, no a la perfección en todas partes.

Referencias y lecturas adicionales

Barr Moses, Lior Gavish, y Molly Vorwerck, «Data Quality Fundamentals».
Jacek Majchrzak, Sven Balnojan, y Marian Siwiak, «Data Contracts».
Danette McGilvray, «Executing Data Quality Projects».
Thomas C. Redman, «Data Driven: Profiting from Your Most Important Business Asset».
Laura Sebastian-Coleman, «Measuring Data Quality for Ongoing Improvement».
Joe Reis y Matt Housley, «Fundamentals of Data Engineering».
DAMA International, «DAMA-DMBOK: Data Management Body of Knowledge».
ISO/IEC 25012, «Modelo de calidad de datos».