La primera vez que vi un clúster de Hadoop procesando un día entero de transacciones de un retailer, me quedó claro que el problema ya no era guardar los datos: era hacerlos rendir. Llevo varios años acompañando a empresas en LATAM que acumularon terabytes de logs, ventas y eventos sin saber muy bien qué hacer con ellos. Y en estos meses de 2017 estoy viendo un cambio de fondo: las arquitecturas que diseñábamos alrededor de MapReduce están migrando hacia Spark, y eso reordena cómo pensamos el dato como activo. Permítame contarle lo que estamos aprendiendo en la práctica, sin humo.
En corto: Hadoop resolvió el almacenamiento distribuido y barato; MapReduce le dio un motor de procesamiento por lotes confiable pero lento. Spark llegó a procesar en memoria, hasta un orden de magnitud más rápido, y unificó batch, streaming y analítica en un mismo motor. Hoy la decisión correcta para la mayoría de empresas es Hadoop para almacenar y Spark para procesar.
Antes de Hadoop, escalar el procesamiento de datos significaba comprar servidores cada vez más grandes y caros. Hadoop invirtió la lógica: en lugar de una máquina enorme, muchas máquinas modestas trabajando en paralelo. Dos piezas lo hicieron posible.
El ecosistema creció rápido alrededor de ese núcleo: Hive para consultar con SQL, Pig para flujos de transformación, HBase para acceso aleatorio, YARN para gestionar recursos del clúster. Para una empresa, el atractivo era doble: hardware commodity y software de código abierto. Almacenar un activo que antes se descartaba por costo, de pronto, era viable.
MapReduce es robusto y predecible, pero tiene un talón de Aquiles: escribe en disco entre cada etapa. Un trabajo encadena fases map y reduce, y cada paso intermedio toca HDFS. Para un proceso por lotes nocturno está bien. Pero apareció una clase de cargas que sufre con ese diseño:
Además, escribir trabajos MapReduce a mano es verboso. Mucho código repetitivo para lógica que conceptualmente es simple. En proyectos reales, eso se traduce en equipos lentos y mantenimiento caro.
Spark, nacido en el AMPLab de Berkeley y hoy proyecto estrella de la Apache Software Foundation, atacó justo esos puntos. Su idea central es el RDD (Resilient Distributed Dataset): una colección distribuida que puede mantenerse en memoria a través de múltiples operaciones. Cuando un algoritmo itera, los datos ya están cargados; no hay viaje al disco en cada vuelta. De ahí los benchmarks que muestran a Spark hasta diez veces más rápido en disco y mucho más en memoria para cargas iterativas.
Pero la velocidad no es lo único, ni lo más importante para una empresa. Lo decisivo es la unificación. Spark trae bajo un mismo motor:
Esa integración importa porque reduce la cantidad de tecnologías que un equipo debe dominar y operar. Y como Spark corre sobre YARN y lee directamente de HDFS, no obliga a tirar la inversión en Hadoop: se monta encima. En nuestros proyectos de analítica, esa convivencia es la regla, no la excepción.
Esta es la pregunta que más confusión genera en los comités de tecnología. La respuesta honesta es que casi siempre necesita ambos, pero para cosas distintas.
Un error común es querer resolver todo con streaming porque suena moderno. El streaming es más exigente de operar y depurar; introducir esa complejidad donde el negocio tolera un reporte cada hora es desperdiciar esfuerzo. El criterio de consultor es simple: deje que la velocidad de la decisión defina la velocidad del procesamiento, no al revés.
Los patrones se repiten más de lo que uno esperaría. Algunos ejemplos concretos de lo que estas arquitecturas habilitan:
En todos, el salto de valor aparece cuando el dato deja de ser un costo de almacenamiento y empieza a alimentar decisiones repetibles. Ahí es donde la conversación se conecta con inteligencia artificial: sin una base de datos accesible y procesable, cualquier modelo es una promesa sin cimiento.
Quiero ser claro en algo que se nos olvida entre tanto framework. Hadoop y Spark son medios, no fines. Una empresa puede tener el mejor clúster y seguir tomando decisiones a ciegas si no ordena tres cosas:
Cuando estas tres piezas están alineadas, la inversión en infraestructura se paga sola. Cuando no, se convierte en el proyecto que nadie quiere auditar.
¿Spark reemplaza a Hadoop?
No. Spark reemplaza a MapReduce como motor de procesamiento, pero suele apoyarse en HDFS para almacenar y en YARN para gestionar recursos. Piense en Hadoop como la bodega y en Spark como la maquinaria que trabaja dentro de ella.
¿Necesito Spark si mis datos no son tan grandes?
Quizá no todavía. Si sus volúmenes caben con holgura en una base relacional bien dimensionada, esa puede ser la opción más sensata. Spark gana cuando el volumen, la velocidad o la variedad superan lo que una arquitectura tradicional maneja con comodidad. La regla es resolver el problema, no comprar tecnología por moda.
¿En qué lenguaje se programa Spark?
Principalmente Scala, que es su lenguaje nativo, pero ofrece APIs muy completas en Python (PySpark), Java y R. Eso le permite aprovechar el talento que ya tiene en casa en lugar de contratar perfiles escasos.
¿Cuánto tarda en verse valor?
Con un caso de uso acotado y datos disponibles, un piloto bien enfocado puede mostrar resultados en cuestión de semanas. Los proyectos que prometen transformación total en un solo gran despliegue son los que suelen fracasar.
Si su empresa ya acumula datos pero todavía no los convierte en decisiones, el camino no empieza comprando un clúster: empieza eligiendo bien el primer caso de uso y diseñando la arquitectura adecuada para él. En SUMāTO ayudamos a las organizaciones de la región a hacer exactamente eso, desde el diagnóstico hasta la puesta en producción, conectando analítica e inteligencia artificial con objetivos de negocio concretos. Lo invito a una conversación de diagnóstico, sin compromiso, para mirar juntos dónde está su dato y qué puede empezar a rendir este mismo año. Escríbanos en sumatogroup.com/contacto y demos el primer paso.