Big Data 2025: del «data lake» al data product listo para IA — casos reales y métricas de producción
En 2016 escribíamos que Big Data era «la cañería invisible». Nueve años después, la metáfora se queda corta. La cañería ya no basta: en 2025-2026, si tus datos no están listos para alimentar un agente autónomo que razona con RAG sobre tu catálogo de productos, detecta anomalías y ejecuta acciones, tu arquitectura es legacy.
El problema real ya no es «cómo almacenar petabytes». El problema real 2025-2026 es: cómo pasar de datos crudos a data products gobernados, versionados y consumibles por LLMs en producción, sin que el coste de inferencia devore el EBITDA.
De Hadoop a Lakehouse + Agentes: qué ha cambiado (y qué no)
La genealogía es clara: MapReduce (2004) → Hadoop (2006) → Spark in-memory (2014) → Delta Lake / Iceberg (2019) → Lakehouse + Agentes (2025).
Lo que no ha cambiado: la alineación gente-procesos-tecnología sigue siendo el cuello de botella #1.
Lo que sí ha cambiado radicalmente: el compute desacoplado de storage ya no es diferencial; es table stakes. Snowflake, Databricks, BigQuery, Fabric, MotherDuck — todos venden lo mismo: SQL elástico sobre Parquet/ORC en S3/ADLS/GCS.
- Formatos de tabla abiertos (Iceberg, Delta, Hudi) ganaron la guerra.
- En 2025, Apache Iceberg es el estándar de facto para nuevas arquitecturas: time travel, schema evolution, partition pruning nativo, y soporte multi-engine (Trino, Spark, DuckDB, Flink).
- La capa semántica (dbt, SQLMesh, Cube, AtScale) se ha vuelto obligatoria. Sin métricas versionadas y definiciones de negocio únicas, un agente IA alucina JOINs inexistentes.
- En producción 2025, RAG = hybrid search (vector + BM25 + knowledge graph) + reranking (Cohere Rerank, BGE-M3) + citation tracking + guardrails (NeMo Guardrails, LangSmith eval).
- Agentes autónomos (LangGraph, CrewAI, AutoGen, LlamaIndex Agents) ejecutan tool calling encadenado: SQL → Python → API → LLM → validación humana → deploy.
- El patrón MCP (Model Context Protocol) de Anthropic estandariza cómo el agente descubre y usa tus data products.
El stack 2025-2026 que vemos en producción en BAOSS
| Capa | Elección mayoritaria (clientes enterprise) | Alternativa open / self-hosted |
|---|---|---|
| Ingesta CDC | Fivetran, Airbyte Cloud, Striim | Airbyte OSS, Debezium + Kafka Connect |
| Storage / Table | Iceberg en S3/ADLS (Tabular / Snowflake / Databricks) | Iceberg + Nessie (catálogo) + MinIO |
| Compute | SQL Trino / StarRocks (federado), DuckDB (local) | Trino, Apache Doris, ClickHouse |
| Transformación | dbt Core + dbt Cloud (CI/CD, lineage, contracts) | SQLMesh, dbt Core self-hosted |
| Capa semántica | Cube, dbt Semantic Layer, AtScale | Cube OSS, MetricFlow |
| Orquestación | Airflow 2.9+ (Dynamic Task Mapping, Dataset scheduling), Dagster | Airflow, Dagster, Prefect |
| Observabilidad | Monte Carlo, Elementary, Datadog Data Observability | Elementary OSS, Great Expectations |
| IA / ML Platform | Databricks Mosaic AI, Vertex AI, Azure AI Foundry | vLLM + Ollama (local), Ray |
Caso 1: Migración lakehouse de 14 meses con tolerancia cero a discrepancias
Estrategia BAOSS (patrón Strangler Fig + dual-write + validación automática):
- Fase 0 (meses 1-2): Inventario automatizado (SQLGlot + dbt parser) → 2.100 jobs → 847 modelos lógicos únicos. Clasificación por criticidad (regulatorio / core / analítico).
- Fase 1 (meses 3-6): Iceberg + Trino en AWS (S3 + EMR Serverless). Dual-write CDC (Debezium) desde Teradata → Iceberg. Validación row-level + aggregate-level (Elementary + Great Expectations) en cada batch. Discrepancias < 0,001 %.
- Fase 2 (meses 7-10): Migración por dominios (riesgo → cliente → producto → cuenta). dbt contracts + data tests como gate de promoción.
Ventana de migración: 14 meses. Riesgo: cero tolerancia a discrepancias en saldos.
Equipo de 8 data engineers + 3 ML engineers.
Caso 2: Agente de atención al cliente que dejó de alucinar
Usaban Snowflake + dbt + Pinecone + GPT-4o para un agente de atención al cliente que respondía disponibilidad y precios.
Problema real: el agente fallaba en el 23 % de consultas de stock (alucinaba cantidades), 17 % en precios (usaba listas obsoletas) y 31 % en promociones (ignoraba la vigencia).
Causa raíz (auditoría BAOSS, 2 semanas): ausencia de capa semántica versionada: precios, stock y promociones vivían en 14 modelos dbt sin contracts ni tests. RAG naive: chunking fijo 512 tokens, sin hybrid search, sin reranker, sin knowledge graph de jerarquía producto-categoría-tienda. Sin MCP: el agente no descubría automáticamente qué data product consultar; hardcoded 47 function definitions frágiles. Sin guardrails ni citation tracking: imposible auditar por qué respondió X.
Solución implementada (8 semanas, 2 sprints): migración a Iceberg + Nessie en S3 (zero-copy clone para entornos dev/test). dbt Semantic Layer con metric contracts + data contracts (dbt 1.8+): 14 modelos → 7 data products versionados (v1.0-v1.3) con SLA de frescura. RAG híbrido: Elastic + Pinecone + knowledge graph. LangGraph + MCP: el agente descubre data products vía MCP server expuesto sobre Unity Catalog. Tool calling tipado con Pydantic v2. NeMo Guardrails + eval harness (LangSmith) con 1.200 golden questions.
Métricas post-producción (semana 10): Precisión stock: 23 % error → 2,1 % (target 2 %). Precisión precio: 17 % → 1,4 %. Precisión promo: 31 % → 3,8 %. Latencia P95: 4,2 s → 1,1 s.