1. Data Governance

Gestión de disponibilidad, usabilidad, integridad y seguridad de datos empresariales.

1.1 🎯 Data Governance

Qué: Framework de políticas, procesos y controles para gestionar datos como activo estratégico.

Por qué: Datos son el nuevo petróleo. Sin governance = caos, riesgos legales, decisiones incorrectas.

Quién: Chief Data Officer, Data Stewards, compliance, engineering.

Cuándo: Desde día 1 manejando datos sensibles o a escala.

Esfuerzo: Inversión inicial alta, previene multas millonarias (GDPR hasta €20M).

1.2 📊 Pilares de Data Governance

1.3 📋 Data Quality Framework

1.3.1 Dimensiones de Calidad

1.3.2 Data Contracts

Qué: Acuerdo explícito entre producer y consumer sobre schema y calidad de datos.

Ejemplo:

# user_events.contract.yml
dataset: user_events
owner: analytics-team
schema:
  - name: user_id
    type: string
    required: true
    format: uuid
  - name: event_type
    type: enum
    values: [signup, login, purchase]
  - name: timestamp
    type: datetime
    required: true
sla:
  freshness: 5 minutes
  completeness: 99%

Enforcement: Pipeline rechaza datos que violan contrato.

Herramientas: Great Expectations, Soda, Monte Carlo

1.4 🔍 Data Lineage

Qué: Mapa visual de origen, transformaciones y destino de datos.

Por qué: Debugging, impact analysis, compliance.

Cuándo: Sistemas complejos con múltiples transformaciones.

Ejemplo de Lineage:

graph TD
    A[Users DB] --> B[ETL Job]
    B --> C[Data Warehouse]
    C --> D[BI Dashboard]
    B --> E[ML Feature Store]
    E --> F[Recommendation Model]

Preguntas que responde:

• ¿De dónde vienen estos datos?
• ¿Qué sistemas usan esta tabla?
• Si cambio schema aquí, ¿qué se rompe?
• ¿Por qué este reporte muestra X?

Niveles:

• Column-level: Trazabilidad campo por campo
• Table-level: Dependencias entre tablas
• System-level: Flujo entre sistemas

Herramientas: Apache Atlas, Amundsen, DataHub

1.5 ⚙️ Implementación Operacional

1.5.1 Enforcing Data Contracts

Cómo implementar contratos estrictos en el pipeline:

1. Definición: Contratos en repositorio Git central (schemas/). Formato JSON Schema, Protobuf o YAML.
2. CI Check: En el PR de un cambio de schema, validar backward compatibility.
3. Producer Check (Runtime): Librería en el productor valida datos antes de emitir (Blocking).
4. Consumer Check (Runtime): Validar en ingestión. Si falla → Dead Letter Queue (DLQ).

Pipeline Ejemplo:

flowchart LR
    A[App Producer] -->|Valida Schema| B{Pass?}
    B -- No --> C[Log Error & Drop]
    B -- Yes --> D[Kafka Topic]
    D --> E[ETL Consumer]
    E -->|Valida Contrato| F{Pass?}
    F -- No --> G[Dead Letter Queue]
    F -- Yes --> H[Data Warehouse]

1.5.2 Automatización de Lineage

Cómo lograr lineage a nivel de columna sin intervención manual:

1. SQL Parsing: Herramientas analizan logs de queries para inferir dependencias (SELECT a FROM table_b).
2. Integración con Orquestadores: Airflow/Dagster envían eventos de OpenLineage en cada run.
3. Metadata Injection: Dbt genera lineage automáticamente (ref()).

Captura con OpenLineage:

{
  "eventType": "COMPLETE",
  "run": { "runId": "uuid..." },
  "job": { "name": "daily_etl_users" },
  "inputs": [{ "name": "raw_users", "namespace": "postgres" }],
  "outputs": [{ "name": "dim_users", "namespace": "snowflake" }]
}

1.6 📚 Data Catalog

Qué: Inventario searchable de todos los datasets de la organización.

Por qué: Descubrimiento, evitar duplicados, democratizar acceso.

Cuándo: >50 datasets o múltiples fuentes.

Metadata incluida:

Ejemplo Entry:

Dataset: customer_transactions
Description: Todas las transacciones de clientes desde 2020
Owner: finance-team
Schema: 
  - transaction_id (UUID, PK)
  - user_id (UUID, FK → users)
  - amount (DECIMAL)
  - timestamp (DATETIME)
Freshness: Real-time (< 1 min)
Access: Restricted (PII)
Tags: #financial #pii #production
Related: customer_profiles, product_catalog

Herramientas: Alation, Collibra, Atlan

1.7 🔐 Data Security & Privacy

1.7.1 Access Control

1.7.2 Privacy by Design

Principios:

1. Data Minimization: Solo recopilar lo necesario
2. Purpose Limitation: Usar solo para fin declarado
3. Consent Management: Opt-in explícito
4. Right to Access: Usuario puede ver sus datos
5. Right to Delete: Usuario puede borrar sus datos
6. Pseudonymization: Reemplazar identificadores directos
7. Encryption: En tránsito y reposo

1.7.3 PII (Personally Identifiable Information)

Tipos:

Techniques:

1.8 🗄️ Master Data Management (MDM)

Qué: Proceso para crear "golden record" único y autoritativo de entidades críticas.

Por qué: Sin MDM = 10 sistemas con 10 versiones de "Cliente A".

Cuándo: Múltiples sistemas con datos duplicados/conflictivos.

Entidades típicas:

• Clientes: Deduplicar, consolidar info de CRM, Support, Sales
• Productos: SKU único, jerarquía consistente
• Empleados: HR system como source of truth
• Proveedores: Vendor master data

Proceso:

Fuente 1: Cliente "John Smith", email: john@email.com
Fuente 2: Cliente "J. Smith", phone: 51234
Fuente 3: Cliente "Smith, John", address: 123 Main St

↓ [MDM Process: Match, Merge, Survive]

Golden Record:
  Name: John Smith
  Email: john@email.com
  Phone: 51234
  Address: 123 Main St
  Master_ID: CUST-0001

Herramientas: Informatica MDM, Talend MDM, Profisee

1.9 📊 Data Quality Monitoring

1.9.1 Observability para Datos

Métricas:

1.9.2 Anomaly Detection

# Ejemplo: Detectar anomalías en volumen diario
import pandas as pd

daily_counts = df.groupby('date').size()
mean = daily_counts.mean()
std = daily_counts.std()

# Alert si >3 std deviations
threshold = mean + 3 * std
anomalies = daily_counts[daily_counts > threshold]

Herramientas: Monte Carlo Data, Bigeye, Datafold

1.10 🔄 Data Lifecycle Management

Retention Policy Ejemplo:

Transaction Records:
  - Active: 2 años (hot storage)
  - Archive: 5 años (cold storage)
  - Delete: Después 7 años
  - Exception: Legal hold suspende deletion

1.11 📋 Data Governance Roles

1.12 🚫 Anti-patrones

1.13 📚 Recursos

• DAMA-DMBOK - Data Management Body of Knowledge
• GDPR Compliance Guide
• Data Governance Institute
• Great Expectations Documentation