Tema: data-quality
-
Los pipelines que rechazan en la ingesta los cambios inesperados del esquema de origen detectan antes los cambios en la fuente, pero fallan más a menudo que los que fuerzan la coerción
Hipótesis: un pipeline que hace fallar una tarea de ingesta cuando el esquema de origen difiere del declarado (de la misma forma en que la resolución de esquemas de Avro señala un error cuando un campo del lector no tiene valor por defecto y el escritor carece de él) detecta los cambios en la fuente dentro de una sola ejecución, pero también falla ante cambios inofensivos, mientras que un pipeline que fuerza la coerción sigue funcionando y deja que algunos cambios lleguen a quienes consumen los datos sin ser advertidos; se propone una comparación sobre las mismas fuentes, sin afirmar ningún resultado.
-
Las comprobaciones de frescura y de número de filas en las tablas de origen en bruto detectan la mayoría de los incidentes de un pipeline antes que las pruebas a nivel de columna aguas abajo
Hipótesis: en un almacén de datos con modelos por capas, la mayoría de los incidentes que terminan siendo visibles para quienes consumen los informes se manifiestan primero como una carga de origen en bruto obsoleta o de tamaño insuficiente, de modo que las comprobaciones de frescura y de volumen en la capa de origen los detectan antes que las pruebas de no nulo, unicidad y valores aceptados sobre los modelos aguas abajo; se propone una comparación sobre incidentes registrados.
-
Comprobaciones de calidad de datos: actualidad, volumen, nulos y unicidad como conjunto mínimo de pruebas
Cuatro comprobaciones económicas detectan la mayoría de las cargas rotas: la fuente se actualizó con suficiente frecuencia (actualidad), el intervalo entregó un número plausible de filas (volumen), las claves y las medidas obligatorias no son nulas, y la granularidad declarada es única. Expresar cada una como una consulta que devuelve las filas que fallan, ejecutarla después de cargar y antes de publicar, y separar las advertencias de los errores bloqueantes.
-
Indicar las unidades junto a cada medición
Hacer interpretables los registros de medición manteniendo la unidad, la estadística de agregación y la población junto a cada valor.
-
Convertir las marcas de tiempo a UTC en el límite
Rechazar las marcas de tiempo ambiguas, convertir los instantes con información de zona horaria a UTC, y conservar la zona horaria original cuando importe la semántica de programación local.
-
Comprobaciones de calidad de datos: actualidad, volumen, nulos y unicidad como conjunto mínimo
Cuatro comprobaciones baratas detectan la mayoría de las cargas defectuosas: ¿la fuente es lo bastante reciente?, ¿llegó un número plausible de filas?, ¿están rellenas las claves y las métricas?, ¿es única la granularidad declarada? Cada comprobación se formula como una consulta que devuelve las filas erróneas, se ejecuta tras la carga y antes de publicar, y distingue entre aviso y bloqueo.
-
Confident Learning: auditoría de la calidad de las etiquetas mediante revisión dirigida
Usa probabilidades de clase fuera de muestra para ordenar las sospechas de errores de etiquetado, revísalas según las reglas de anotación y mantén la distinción entre desacuerdo del modelo y error verificado.
-
Canonicalizar URL sin alterar su significado
Usa una clave de comparación definida por la aplicación y conserva la URL exacta de la petición cuando la normalización pueda alterar el enrutamiento o las firmas.
-
Estrategias de deduplicación de registros: filas exactas, conservar el último por clave y ventanas acotadas
Primero hay que decidir qué cuenta como duplicado: filas idénticas, varias versiones de una misma clave o mensajes reentregados dentro de una ventana. Las filas exactas se resuelven con DISTINCT; las versiones requieren una regla de conservar el último con un orden explícito; las reentregas se deduplican por clave de idempotencia dentro de una ventana de tiempo o de estado acotada, como hacen las colas de mensajes y los motores de streaming.
Legible por máquina: JSON