DataOps y administración de datos

1) Qué es DataOps y por qué lo necesita

DataOps es un conjunto de prácticas, procesos y herramientas que convierten el trabajo con datos en una canalización repetible y administrada: desde el ensamblaje y cambio de esquemas hasta la publicación de productos de datos y métricas. El objetivo es entregar datos de calidad a los consumidores de forma más rápida y segura (producto, análisis, riesgo, ML), manteniendo el cumplimiento y el costo óptimo.

• SLAs predecibles por datos (relevancia, integridad, precisión).
• Cambios rápidos y seguros (CI/CD/CT para datos).
• Transparencia de origen (línea de datos) y propiedad.
• Reducción de TCO (almacenamiento, computación, transferencia de datos).

2) Patrones arquitectónicos

Data Lake (almacenamiento de objetos, materias primas): barato, flexible, pero necesita DataOps riguroso.
Almacén (OLAP/SQL, modelado): vitrinas rápidas, circuito estricto.
Lakehouse (formatos de tabla + ACID: Delta/Iceberg/Hudi): unificación lake y warehouse, time-travel, upsert/merge.

• Bronze (crudo, inmutable) → Silver (pelado, armonizado) → Gold (unidades/vitrinas/fichas ML).
• Capas de servidor: DWH/OLAP (BigQuery/ClickHouse/Snowflake, etc.), API/grafo, feature store, caché.

Recomendación: almacenar exactamente una «fuente de verdad» por capa, y las transformaciones como código con versificación y pruebas.

3) Modelo de dominio y productos de fecha

Enfoque Data Mesh: propiedad de datos de comandos de dominio; data product owner es responsable de la calidad y SLO del producto de datos.
Contratos de datos: esquemas, semántica, SLA/SLO (por ejemplo, "la tabla de operaciones está disponible a las 08:00 UTC con una precisión de 99. 5% y un retraso de no más de 10 minutos en incrementos").
Interfaces: tablas SQL/pinzas, topics CDC, API/GraphQL. Una versificación clara y una política de depreciados.

4) Integración: fuentes y patrones de carga

ETL/ELT: tirar → doblar → transformar (en DWH/Lake). ELT es preferible con un OLAP potente.
CDC (Change Data Capture): cambios en streaming (Debezium, etc.) → baja latencia e incrementos precisos.
Batch vs Stream: híbrido - stream para eventos «calientes», batch para recuentos y backfill.
Semántica de entrega: en-least-once + mergues idempotentes; dedoup por clave/tiempo; exactly-once-like a través de formatos transaccionales.

5) Gestión de esquemas y evolución

Registro de Schema y pruebas de contrato: agregue campos de forma no destructiva, prohíba los cambios de breaking sin una nueva versión.
Versioning (V1→V2): publicación paralela, ventana de migración, alertas a los consumidores.
Políticas de tipos y unidades: monedas, zonas de tiempo, claves idempotency.

6) Calidad de datos (Calidad de datos, DQ)

Medidas clave: exhaustividad, precisión, consistencia, singularidad, validez, frescura/actualidad, falta de duplicados.

• Pruebas de calidad como código: llaves únicas, rangos, listas de referencia, reglas de negocio (por ejemplo, suma de subíndice = total).
• Pruebas de contraste/exposición en cada capa (Bronze/Silver/Gold) y en CI.
• Zonas de cuarentena: los datos que no han pasado las inspecciones no entran en Gold.
• Acuerdos de frescura: explicit freshness SLA y burn-rate-alerts por retraso.

7) Observabilidad de los datos (Observación de datos)

SLI según los datos: proporción de cadenas válidas, latencia de incrementos, proporción de omisiones, número de cambios de esquemas por período.
Lineage (rastreo de extremo a extremo): de qué fuente es el campo X, quién consume la tabla Y; visualización del gráfico de dependencias.
Monitoreo de anomalías: tendencias de volúmenes/distribuciones, ceros/picos repentinos, deriva de rasgos categóricos.
Alert Policy: ventana corta (desastres) + larga (degradación de arrastre), escalada en los propietarios de productos de datos.

8) Seguridad y privacidad

Clasificación de datos: PII/financiero/sensible/público. Etiquetas en columnas y conjuntos.
Control de acceso: RBAC/ABAC, row-/column-level security, enmascaramiento, de identificación dinámica.
Criptografía: encriptación en el paso/en el paso; tokenización y pseudonimización para PII.
Líneas de almacenamiento: caliente/caliente/frío; políticas de retención y «derecho al olvido».
Auditoría e inmutabilidad: quién leyó/cambió; registro de firma de artefactos; exportar artefactos para los reguladores.

9) Orquestación, CI/CD/CT y gestión del cambio

Orquesta: Airflow/Argo/Kedro, etc.; DAG/hilos declarativos con dependencias y tareas idempotentes.
CI/CD/CT (Continuous Testing): SQL/Python linters, pruebas de transformación unit, pruebas de integración en samples aislados, pruebas de datos antes del merge.
Promoción de entornos: dev → stage → prod; los mismos manifiestos; control de banderas/directorios.
Backfills: operaciones «heavyweight» con limitación de recursos y ventana clara; control de idempotencia y deduplicación.

10) Gestión de costes (Data FinOps)

Modelos de costo: almacenamiento (volumen × clase), escáneres/consultas, egresos, backfills de larga duración.
Optimización: partición/clusterización, Z-ordering/cribado, pryuning en el tiempo, materialización de los piojos resultantes, compresión y formatos de columna.
Unit-economía de datos: $/1 millón de líneas en Oro, $/un informe, $/ficha para ML.
Frescura consciente de SLO: contar con la frecuencia que el producto requiere, no «cada 5 minutos según el hábito».

11) Master Data Management (MDM) y manuales

Discos de oro (golden records): eliminación de tomas de clientes/merchantes, jerarquía de cuentas.
Guías/referencias: monedas, países, listas BIN, listas de proveedores - con versiones y ventanas de acción.
Identificadores: claves estables, negociación de ID de sistema cruzado, mappings many-to-one.

12) ML-fiches y escaparates analíticos

Feature Store: versionar signos, tiempo-viaje, consistencia en línea/fuera de línea.
Contratos de datos con DS/ML: SLAs por frescura/deriva; esquemas y rangos permitidos.
Vitrinas BI: verificadas «versiones únicas» de métricas clave (DAU/GMV/ARPPU, etc.) con pruebas.

13) Procesos de incidentes y RCA para datos

Detección: caída de validez, retrasos en la carga, cambio de circuitos sin anuncio, anomalías en las distribuciones.
Escalamiento: propietario de un producto de datos → orquestador/plataforma → fuente/proveedor.
Acciones de mitigación: friso de publicaciones, reversión de la última transformación, publicación de la versión «buena» anterior, etiquetado en la página de estado de los datos.
RCA (enfoque de datos): raíces: roturas de esquemas/contratos, retrasos en la fuente, reglas de negocio incorrectas, deriva.
CAPA: controles de circuitos, nuevas pruebas, límites de escáneres, anotaciones de lanzamientos, capacitación.

14) Roles y Responsabilidades (RACI)

Data Product Owner: SLA/SLO, priorización, roadmap.
Data Engineer/Analytics Engineer: pipelines, simulaciones, pruebas, optimización.
Plataforma/Infra: orquestación, lake/warehouse, seguridad y accesos.
Governance/Steward: catálogo, calidad, clasificación, cumplimiento.
Sec/Compliance: privacidad, auditoría, informes regulatorios.
Propietarios comerciales de métricas: definir y controlar la «verdad» de los indicadores.

15) Catálogo y metadatos

Catálogo de datos: descripción de tablas/campos, propietarios, etiquetas (PII/finanzas), consultas de ejemplo, niveles de calidad.
Metadata activa: lineaje de llenado automático, consulta popular, recomendaciones de uso.
Glossary (diccionario de negocios): definiciones de indicadores y reglas de cálculo, versión y propietario.

16) Dashboards DataOps (conjunto mínimo)

Salud de las pipelines: tareas de éxito/error, latencia DAG, tiempo de ejecución promedio, colas.
Calidad y frescura: validez por pruebas, retardo de capas Bronze/Silver/Gold, fracción de cuarentena.
Lineage-view: el impacto de la caída de la tabla X en los consumidores Y.
Finanzas: $ por almacenamiento y escáneres, consultas/modelos «caros», ahorros en la materialización.
Cambios: lanzamientos de transformaciones, cambios de esquemas, alertas de contratos.

17) Lista de verificación «Preparación del producto de datos»

• Entradas/salidas descritas, propietario y SLA/SLO (frescura/plenitud/precisión).
• Esquemas y contratos en el repositorio, se incluyen las pruebas de calidad (umbral de validez).
• Configurado lineage y directorio; etiquetas PII/clasificación aplicada.
• Accesos RBAC/ABAC, enmascaramiento y políticas de retención.
• Orquestación y alertas: ventanas cortas y largas, canales de escalada.
• Las backfills son idempotentes; hay un plan de retroceso y cuarentena.
• Optimización del valor: lotes/agrupamiento/materialización.
• Documentación de métricas y consultas de ejemplo.

18) Anti-patrones

«Data swamp»: lake sin diagramas/catálogo/propietarios → datos no utilizados y caros.
El desguace del diagrama de fuente «apretado» → incidentes en cascada.
Pruebas sólo en prod → detección posterior, correcciones costosas.
Un «martillo de plata» de transformación común para todos los dominios.
Falta de cuarentena: el matrimonio cae en Oro y BI.
Escáneres sin límite/Joynes «para la suerte» → una explosión de valor.
PII en logs/samples, sin retoque y sin enmascaramiento.

19) Mini plantillas

Plantilla de SLA para el producto de datos

Frescura: 99% de incrementos a más tardar T + 10 min; el recuento completo es a las 08:00 UTC D + 1.
Plenitud: ≥ 99. 7% de los registros vs fuentes; los umbrales de las llaves.
Precisión: discrepancia con la métrica de control ≤ 0. 3%.
Disponibilidad: SQL-Endpoints/Whuches disponibles ≥ 99. 9% (28 días).
Canal de escalamiento, propietario, ventana de soporte.

Directiva de versionamiento de esquemas

Menor: agregar campos opcionales, back-compatible.
Mayor: eliminar/cambiar el nombre; publicación paralela V1/V2 ≥ N semanas; marcas de deprechate.

Plan de fondo

Fuente, rango de fechas, estimación de costo/tiempo, idempotencia, ventana de inicio, criterios de éxito, retroceso.

20) Hoja de ruta para la implementación de DataOps (ejemplo 8-12 semanas)

1. Ned. 1-2: inventario de fuentes, mapa de dominios, selección de Lakehouse/OLAP, catálogo.
2. Ned. 3-4: normas de circuitos/contratos, esqueleto CI/CD/CT, pruebas DQ básicas.
3. Ned. 5-6: lineage y alertas de frescura, cuarentena, los primeros productos de fecha SLA.
4. Ned. 7-8: Optimización de FinOps (lotes/materialización), backfils por patrón.
5. Ned. 9-12: MDM/referencias, RBAC/enmascaramiento, práctica de RCA para incidentes de datos, KPI de madurez.

21) Resultado

DataOps es un sistema operativo de datos: responsabilidad de dominio, contratos y pruebas, automatización de cambios, observabilidad y seguridad, economía y procesos de incidentes. Con este enfoque, los datos se convierten en un producto fiable: se pueden versionar, medir, escalar y utilizar con confianza en la toma de decisiones, informes y ML.