Origen de los datos

Origen de los datos

1) Qué es lineage y por qué es necesario

Data Lineage es un registro formal «de dónde vinieron los datos, cómo se transformaron, dónde y por quién se utilizaron». El resultado es un gráfico de dependencias orientado con atributos (tiempo, versiones, propietarios, transformaciones, políticas de acceso, calidad) que hace que el sistema de datos sea explicable y auditable.

• Transparencia métrica (finanzas, producto, riesgo): "¿por qué el número X = 1 234? ».
• Análisis rápido de impacto de los cambios (esquema/job): «qué se romperá si»....
• Cumplimiento y auditoría (GDPR/ISO/SOC): trayectoria de campo probada.
• Aceleración del onboarding y reducción del toil (autoservicio del conocimiento).
• Mejora de la calidad: controles específicos donde el riesgo es mayor.

2) Áreas de recubrimiento y niveles de detalle

Nivel de flujo (pipeline/job): qué jobs/orquestadores dieron origen a los datasets.
Nivel de dataset (table/view/topic/file): entradas → salidas, versiones/snapshots.
Nivel de columna (column/feature-level): cómo se calcula cada campo, de qué fuente.
Capa de consumo: informes BI, API, modelos ML, dashboards y alertas.

Para entidades críticas (dinero, regulaciones) - los detalles de column-level son obligatorios.

3) Modelo de datos lineage: entidades clave

Dataset: `{urn, type, schema, owners, pii_class, retention, tags}`

Job/Task: `{urn, code_ref, version, runtime, schedule, owners}`

Run/Execution: `{run_id, job_urn, start/end, status, inputs[], outputs[], code_sha, infra}`

Campo: '{dataset _ urn, name, type, derivation}' (derivación - expresión/AST/operador).

Policy: `{dataset_urn/field, access_rules, masking, consent_scope}`

Quality Check: `{check_id, scope, rule, severity, result}`

4) Fuentes de lineage: conjunto pasivo activo vs

Active (event-based): instrumentamos orquestadores/motores (Spark/DBT/SQL engines/Kafka) para la emisión de eventos «job started/finished, inputs/outputs, column-mapping».

Pros: precisión, relevancia, minimización del post-parsing.
Pasivo (inference): parsim DAG 'y, consultas SQL/DDL/logs, registros de directorio/almacenamiento; construimos dependencias retroactivamente.

Ventajas: cobertura rápida del patrimonio; contras: por debajo de la precisión en column-level.

Normalmente se aplica un híbrido: eventos activos donde se puede y análisis pasivo como «red de seguridad».

5) Arquitectura de la solución (referencia)

Productores (orquestadores/motores) → Bus de eventos lineage → Normalizador → Almacén de gráficos → Índice/Búsqueda → UI/API/alertas → Exportación/Directorio.

Eventos: unificados (job/run/dataset/column-lineage), con identificadores URN y versiones semánticas.
Almacenamiento de grafos: gráfico de nivel de columna (por ejemplo, basado en un DB gráfico o relacional + índice invertido).
IU: visualización interactiva de los caminos más cortos, impacto/raíz-causa, «señales de calidad» en costillas y nodos.
Integraciones: directorio de datos, sistema de calidad (DQ), control de acceso (ABAC), auditoría (registros únicos de aplicaciones).

6) Identificadores y versificación

URN/ID Global para cada dataset/joba/campo: estable, humanizado, que incluye plataforma/no space/nombre/versión.
Versiones de esquemas (SchemaVersion) y versiones de código (code SHA, image digest).
Imágenes del gráfico de tiempo (time-travel lineage): reproducibilidad de las investigaciones.

7) Column-level lineage: cómo obtener fiablemente

SQL-parcing con la construcción de AST y normalización de alias/STE/piuh.
Anotaciones en código de transformación (pruebas DBT, comment primitive, UDF-metadata).
Eventos de motores: especifica las expresiones "target. col = f(src. a, src. b)».
Reglas semánticas: Las UDF/ops de agregación se marcan como «lossy» (con pérdida de granularidad) o «sensitive-preserving» (lleva etiquetas PII).

8) Conexión de lineage con privacidad y seguridad

Privacidad por Diseño: etiquetas de campo 'pii _ class', 'consent _ scope', 'retention'. Al promover columnas, las etiquetas se transmiten según las reglas (por ejemplo, 'email → hash_email' permanece PII-derivado).
Tokenización PII: lineage almacena el hecho de tokenización/desintoxicación y los nodos de servicio de token; cualquier desintoxicación es un evento con auditoría.
Encriptación: para campos, el enlace AEAD/FPE captura el «estado cripto» y el área clave (tenant/scope) - sin revelar las claves.
Auditoría y WORM: los eventos de lineage y los cambios de directivas se almacenan en un registro sin cambios (append-only con hash chain).

9) Calidad de los datos y SLO basados en lineage

Cheques en las costillas: frescura (freshness), plenitud (completeness), singularidad/claves, deriva de distribuciones.
SLO/SLI: «El 95% del job que alimenta las métricas de finotchet se completan ≤ 06:00 UTC».
Root-cause: grafo + tiempos de ejecución dan una definición rápida del «primer nodo roto».

10) Análisis de impacto y gestión de cambios

Con un cambio planificado en el esquema/lógica: en el gráfico descendente (downstream), se muestra la lista de los informes/modelos/clientes de la API afectados.
Política «breaking changes»: notificación obligatoria a los propietarios de artefactos downstream, período grace, versiones paralelas ('v1 '/' v2') y bandera «sunset-date».
PR/tickets automáticos con lista de consumidores y lista de verificación de migración.

11) Integración con orquestadores y motores

Orchestrators: los eventos 'RunStarted/RunCompleted' con inputs/outputs se emiten antes/después de job.
SQL/ELT: conectores a motores (warehouse, lakehouse) para obtener el plan de ejecución real y el mapeo de columnas.
Stream-processing: lineage de mensajes (topic→topic, key/headers), esquemas Avro/Protobuf, evolución de circuitos a través del registro.
ML: lineaje de fichas/datasets, versiones del modelo, artefactos de entrenamiento, fuentes de características.

12) Simulación de reglas de propagación de etiquetas (contratos de datos)

Contrato de conjunto de datos: esquema + semántica de campos (claves, PII, agregabilidad, licencias/bases legales, retention).

• 'SELECT a, b FROM T' → transferir las etiquetas' a, b '.
• 'hash (email)' → la etiqueta 'PII-derived (pseudonymized)' con prohibición de desintoxicación.
• 'SUM (amount)' → pérdida de individualidad; no se permite la entrada en el campo de resultados.
• Los contratos se validan en CI (blocker en caso de incumplimiento) y las irregularidades son eventos en auditoría.

13) Rendimiento y escala

Ingestión incremental de eventos lineage; deduplicación por '(run_id, job_urn)'.
Almacenamiento del gráfico: división del índice caliente (últimos 30-90 días) y del archivo; Snapshots.
Almacenamiento en caché de rutas para consultas frecuentes (rutas cortas a métricas «doradas»).
Sharding en Nymspace/inquilinos; Protección contra «nodos monstruosos» (restricción de fan out).

14) Visualización y UX

• Path to metric: «de lo que se recoge la métrica».
• Impact from source: «a quién afectará el cambio».
• Línea de campo: «cómo se calcula el campo».
• Overlays: estados job, calidad, marcas PII, retenciones, propietarios.
• Acciones: abrir un contrato, crear un ticket de migración, suscribirse a las alertas de cambio.

15) Seguridad de acceso al gráfico

ABAC: la visibilidad de los nodos/costillas se limita a los inquilinos/roles.
Reducción: oculta los nombres de campos sensibles (o su seudonimización) en UI para roles no preparados.
mTLS/OIDC para API; los eventos de lineage están firmados por identidades de servicio.
WORM y control de lectura: también se registra la lectura de segmentos críticos del gráfico.

16) Operación: SLO, monitoreo, alertas

SLO gráfico: retraso en la aparición del evento <5 min; cobertura completa> 98% de pipelines críticos; El 100% de las «métricas de oro» tienen línea de column-level.
Alertas: ruptura de la cadena, run sin eventos de finalización, inconsistencia de esquemas, datasetas «huérfanas», crecimiento de fan out/ciclos.
Informes: semanal «state of lineage coverage», los 10 principales nodos de riesgo.

17) Privacidad y cumplimiento (ligamentos)

GDPR/PbD: almacenar bases de procesamiento y retenciones como etiquetas; lineage proporciona una búsqueda rápida de rutas DSAR y un «derecho de eliminación» a través de la eliminación cripto en cascada de los segmentos correspondientes.
Gestión de secretos: las fuentes de acceso a las materias primas nunca caen en lineage como créditos abiertos; sólo se almacena una referencia de rol/política.
Auditorías/registros inmutables: todos los eventos de lineage están firmados y anclados en el repositorio append-only (consulte el artículo correspondiente).

18) Hojas de cheques

• Se han definido acuerdos URN para datasets/jobs/fields.
• Se incluye la emisión de eventos lineage de orquestadores y motores.
• El parser SQL/DDL y el normalizador de circuitos funcionan.
• Se aprobaron los contratos de datos y las reglas de propagación de PII/retencion.
• Se ha configurado el registro de eventos WORM y las copias de seguridad del gráfico.
• Los BI/ML están conectados como consumidores de lineage (informes, modelos, fichas).

• Cobertura de lineage por dominios críticos ≥ 98%, column-level por «dinero» = 100%.
• Alertas a las roturas, datasetas «huérfanas», se incluye la deriva de los esquemas.
• Auditoría trimestral de las marcas PII y contratos.
• Intercambio de cambios (breaking) y envío a los consumidores.

19) Mini recetas

json
{
"event": "RunCompleted",
"run": {
"id": "run_2025-10-31T14:20:00Z_42",
"job": "urn:job:etl:finance:close_books_v3",
"status": "SUCCESS",
"code_sha": "b3f9…",
"started_at": "2025-10-31T14:05:00Z",
"ended_at": "2025-10-31T14:19:52Z"
},
"inputs": [
"urn:dataset:lake:bank_txn_v2",
"urn:dataset:warehouse:fx_rates_d+1"
],
"outputs": [
"urn:dataset:warehouse:pnl_daily_v3"
],
"column_lineage": [
{
"output": "pnl_daily_v3. pnl_usd",
"expr": "SUM(txn. amount_local fx. rate)",
"inputs": ["bank_txn_v2. amount_local", "fx_rates_d+1. rate"],
"lossy": true
}
]
}

if input. field. pii in {email, phone, id} and transform in {hash, tokenize}:
output. field. pii = "pseudonymized"
elif transform in {aggregate, anonymize_k}:
output. field. pii = "anonymous"
else:
output. field. pii = input. field. pii

affected = downstream(urn:"urn:dataset:warehouse:users_v4", depth=4)
filter affected where kind in {"dashboard","model","api"} and owner not in {"team-exp"}

20) Errores frecuentes y cómo evitarlos

Lineage «por imagen» sin modelo formal. Se necesitan eventos/esquemas/URN, de lo contrario el gráfico no se escala.
No hay column-level donde está el «dinero». Sin el nivel de columna, no se pueden explicar los cálculos.
Eventos incompletos (sin esquemas code_sha/versii). No se puede reproducir.
Ignora la privacidad. Las marcas PII deben vivir y ser transportadas junto con los campos.
Una gran tarjeta gráfica sin charding. Divida por neymspace, guarde los snapshots.
La fe ciega de los parsers. En casos controvertidos, eventos activos de los motores.

21) Runbook’и

Incidente: la métrica «saltó».

1. Abrir «Path to metric» → comprobar los últimos nodos 'Run' en el camino.
2. Conciliar versiones de códigos/esquemas, estado DQ de los cheques en las costillas.
3. Si se encuentra un enlace roto, cree un ticket para el propietario, habilite la publicación temporal de métricas "hold'.
4. Después del fix, marca RCA y enlaza con los nodos del grafo.

Cambiar esquema de origen.

1. Solicitar el impacto downstream.
2. Enviar notificaciones a los propietarios, crear relaciones públicas de migración.
3. Elevar el paralelo 'v _ next', mantener ambas versiones hasta la fecha sunset.
4. Cerrar 'v _ prev', actualizar los contratos y el grafo lineage.

• «Privacy by Design (GDPR)»
• «Tokenización de datos PII»
• «Gestión de secretos»
• «Auditoría y registros inmutables»
• «Encriptación de Tránsito En/En»
• «Administración de claves y rotación»