Procesamiento Big Data con Apache Spark

febrero 21, 2025 · Baoss
Procesamiento Big Data con Apache Spark (Actualizado 2025)
BAOSS consultoría IT: procesamiento Big Data con Apache Spark en 2025

Apache Spark 3.5+ en 2025: Casos reales, métricas y arquitectura LLM-ready

En 2016 escribíamos que Spark se había «asentado como pilar tecnológico». En 2025, la frase se queda corta. Ahora Spark es el plano de control donde convergen data engineering, ML clásico e IA generativa. El reto ya no es «procesar big data». Ahora es servir features a un agente LangGraph en <50ms, indexar 50TB de PDFs para RAG sin reventar el presupuesto GPU y gobernar todo bajo Unity Catalog o OpenLineage. Además, desde BAOSS consultoría IT lo vemos en cada despliegue. El reto ya no es procesar datos, sino servirlos a agentes en producción.

Por ejemplo, en BAOSS hemos acompañado a tres clientes —retail europeo, banca tier-1, fabricante industrial— en esa transición. Aquí no hay teoría de conferencia. Hay arquitecturas desplegadas, métricas de producción y lecciones aprendidas (anonymizadas, con números reales).

El problema 2025-2026 que resuelve BAOSS consultoría IT: la pila data se ha fragmentado (y caro)

Ahora bien, las empresas llegan a nosotros con el mismo patrón:

  • Primero, Data lake «moderno» (Iceberg/Delta/Hudi): pero consultas SQL lentas por falta de Z-Order / liquid clustering.
  • Después, Pipelines batch en Airflow + Spark: que tardan 6h; el negocio pide frescura <15 min.
  • Además, Experimentos LLM en notebooks (LangChain, LlamaIndex, CrewAI) que no escalan a producción: OOM en driver, embeddings single-thread, sin versionado de prompts.
  • Asimismo, Coste cloud descontrolado: clústeres fijos 24/7, instancias GPU ociosas, shuffle spill a disco.
  • Por último, Governance rota: linaje roto entre tabla raw y feature store; PII en embeddings sin enmascarar.

Por lo tanto, la respuesta no es «comprar Databricks/Fabric/EMR Serverless y rezar». Es rediseñar la arquitectura sobre Spark 3.5+ aprovechando:

  • Primero, Spark Connect: clientes ligeros (VS Code, PySpark remoto, JDBC/ODBC) sin driver local.
  • Después, Structured Streaming + stateful processing: ventanas de sesión, deduplicación exact-once, join con tablas Delta «as-of».
  • Además, Pandas API on Spark / PySpark 3.5: migración 1:1 de código pandas legacy a distribuido.
  • Asimismo, English SDK / AI Functions: `df.select(ai(«resume esta queja en 3 bullets»))`. Así llama a GPT-4o / Claude 4 Sonnet vía batch inference nativo.
  • Por último, GPU scheduling nativo: (plugin NVIDIA RAPIDS + vLLM / Ollama en worker): inferencia embebida sin mover datos.

Caso 1 — Retail: Personalización tiempo real < 50 ms P99

Contexto: 120M eventos/día (clics, add-to-cart, compras) en Kafka. El stack combina modelo de ranking (LightGBM) + re-ranking con LLM (Llama 3.1 8B LoRA) para «razonar» ofertas. SLA: end-to-end < 50 ms desde evento a recomendación en app.

Arquitectura desplegada

  • Primero, Ingest: Kafka → Spark Structured Streaming (watermark 10 min, stateRocksDB off-heap).
  • Feature store online: Redis Cluster (TTL 7d) poblado por micro-batch cada 30s desde Delta Lake (CDF).
  • Inferencia híbrida:
    • LightGBM (CPU) → broadcast variable, scoring en mapPartitions (vectorizado Pandas UDF).
    • LLM re-ranking → vLLM en workers GPU (A10G 24GB) invocado vía gRPC desde mapPartitions; batch dinámico 32 reqs.
  • Serving: Spark Connect endpoint + gRPC gateway (Go) expuesto a Kubernetes (KServe).

Métricas duras (3 meses en prod)

KPI Antes (batch nightly + heurísticas) Después (streaming + LLM)
Latencia P99 evento→reco ~4 h (batch) 42 ms
CTR uplift baseline +18 %
Coste infra / mes €42k (EMR fijo + SageMaker endpoints) €25k (EMR Serverless spot + GPU autoscaling 0→12)
Tiempo despliegue nuevo modelo 2 semanas (CI/CD manual) 4 h (MLflow 2.14 + GitOps ArgoCD)

Clave técnica: stateful streaming + broadcast model + vLLM colocalizado evita saltos de red. Además, el 40 % de reducción de coste vino de apagar clústeres fijos. La clave fue usar EMR Serverless + Spot Fleet (max 20 % on-demand). Además, aplicamos dynamic allocation agresivo (scale-down 60s idle).

Caso 2 — Banca: RAG corporativo a escala (50 TB, 12M docs)

Reto: Indexar histórico legal/contratos (PDF, scans OCR, emails) para asistentes internos (Claude 4 Opus + RAG). Sin embargo, el pipeline legacy (Python + LlamaIndex single-thread) tardaba 14 días en full re-index. Objetivo: <strong>< 8 h y gobernanza total (linaje, PII, versionado prompts).

Pipeline Spark-native

  • Ingest: Autoloader (cloudFiles) → Delta Lake bronze (binary + metadata).
  • Después, Parsing distribuido: pandas_udf con marker/pdfplumber (CPU) + Tesseract GPU para scans. Output: markdown limpio + bounding boxes.
  • Además, Chunking semántico: LangGraph agent (recursive splitter + LLM boundary detection) ejecutado como mapInPandas (batch 512 docs/worker).
  • Asimismo, Embeddings: vLLM + BGE-M3 (1024-d) en workers GPU; foreachPartition → upsert batch 1k a Milvus/Zilliz (HNSW, SQ8).
  • Por último, Governance:
    • Unity Catalog: tabla silver.chunks (linaje automático desde bronze).
    • OpenLineage + Marquez: trazabilidad prompt→chunk→embedding.
    • PII detection (Presidio) en silver; masking policy en Catálogo.

Resultados

  • Primero: full re-index 50 TB: 6.3 h (vs 14 días) — 53x speedup.
  • Después: coste indexado: €0.18 / GB (Spot GPU g5.2xlarge, 90 % utilización).
  • Además, freshness incremental vía CDC (Change Data Feed) → micro-batch 15 min. Así, los chunks nuevos entran en el vector DB < 3 min.
  • Por último, adopción: 1.2k usuarios activos/día. La latencia RAG P99 es 1.2 s (retrieval 300 ms + LLM 900 ms).

El salto no fue «usar Spark», sino modelar el pipeline RAG como ETL declarativo (Delta Live Tables / DLT). Añadimos expectations de calidad (chunk_size, embedding_norm, pii_free) que frenan el deployment si fallan. En definitiva, cuando esos pipelines alimentan agentes autónomos, el riesgo de los agentes de IA exige control desde el diseño.

Caso 3 — Industrial: Mantenimiento predictivo + GenAI reports (ROI 3.2x en 6 meses)

Planta: 4.5k sensores (vibración, temperatura, presión) @ 10 Hz → 3.8 TB/día. Objetivo: detectar anomalías y generar un informe técnico en lenguaje natural para el operario de turno.

Arquitectura «Lakehouse + AI» unificada

  • Primero, Edge → Kafka → Iceberg (MinIO on-prem): Spark Structured Streaming (exactly-once, checkpoint S3-compatible).
  • Después, Feature engineering: Además: ventanas temporales (1h, 24h), FFT y estadísticos rolling. Todo se escribe en Pandas API on Spark (migración directa de notebooks data science).
  • Después, ML clásico: Isolation Forest + XGBoost (Spark MLlib) entrenado en cluster CPU (r6gd.16xlarge). Model registry MLflow + Model Serving via Spark UDF (batch scoring nocturno).
  • Además, GenAI report: Alerta → LangGraph agent, que recupera contexto histórico y manuales PDF indexados en Caso 2. Después → GPT-4o mini (batch inference via ai() function). Así, el PDF/HTML se sirve en el portal interno.
  • Por último, Human-in-the-loop: Operario valida/corrige → feedback loop a Delta (tabla gold.operator_feedback) → re-entrenamiento semanal automatizado (DLT pipeline).
  • La gobernanza de esta capa automática sigue la lección del caso Hugging Face para tu empresa. Es decir: permisos explícitos, auditoría y reversibilidad.

Métricas de negocio (6 meses)

<!– wp

Artículos relacionados: Tendencias Data 2027: Agentic Operations, Modelos Razonamiento y ROI Masivo.