En el episodio de hoy de Un podcast ninja sobre Big Data hablamos del ecosistema Hadoop y de los orígenes del Big Data ¡Abrochense los cinturones que nos subimos al Delorean para viajar al pasado 🚙!
Esta historia comienza en 2003.
Pero vamos a remontarnos un poco más en el tiempo. En concreto a marzo del año 2000 cuando Google no era más que una start-up intentando indexar todo Internet.
Aunque por aquel entonces pues Internet también era bastante más pequeño de lo que es ahora.
Porque Internet es como el universo, no deja de expandirse.
Hasta marzo del 2000 Google había estado funcionando con el código que sus fundadores habían escrito en la universidad y que estaba ejecutándose en unos cuantos ordenadores, que habían conectado unos con otros.
Lo que pasa es que en vez de comprar todo el ordenador con las unidades de lectura de disco, el chasis y todo eso, que en realidad no lo querían para nada porque solo les interesaba ser capaces de ejecutar el código que indexaba internet pues compraban las placas base y las amontonaban unas con otras en torretas en un edificio de Santa Clara.
En total 1500 dispositivos de los cuales conseguían que funcionasen unos 1200 a la vez.
Empezaban a tener problemas gordos para gestionar el volumen de datos que implicaba indexar Internet a una velocidad razonable.
Volumen de datos y velocidad de procesamiento. Esto huele ya a Big Data.
Google tenía principalmente dos problemas:
Tened en cuenta que de todas esos ordenadores siempre había alguno que estaba caído.
Así que entre 2003 y 2006 Google publicó tres artículos de investigación con todo el trabajo que había hecho internamente con su infraestructura de datos.
En esos artículos explicaban sus soluciones pero no cómo implementarlas.
Mientras tanto, sus vecinos en Yahoo y más concretamente Doug Cutting, también estaban trabajando en los mismos problemas. Al fin y al cabo necesitaban igualmente rastrear Internet.
Así que al leer los documentos de Google sobre su sistema de archivos y MapReduce, Doug se dio cuenta de que estaba planteando mal su solución y se inspiró en la arquitectura de Google para crear en 2005 Hadoop, que nombró así en honor al juguete de su hijo, que era un elefante amarillo, como el logo de Hadoop.
El proyecto comenzó con dos componentes clave:
Lo que pasa es que Yahoo decidió liberar el proyecto para que formara parte de la fundación Apache y así invitar a más empresas tecnológicas a usar y contribuir al proyecto.
En seguida otra empresas que tenían el mismo tipo de problemas con sus volúmenes de datos empezaron a contribuir.
En 2007, una empresa joven que estaba creciendo muy rápido dirigida por un tal Mark Zuckerberg, de 23 años, y que tal vez os suene, Facebook se llamaba, abrió dos nuevos proyectos bajo la licencia de Apache.
Mientras tanto, una empresa menos conocida llamada Powerset, que estaba trabajando en un motor de búsqueda, se inspiró en el tercer artículo de Google para desarrollar Apache HBase, otro sistema de almacenamiento columnar que depende de HDFS para el almacenamiento.
Poco después Microsoft adquirió Powerset para iniciar un nuevo proyecto que tal vez os suene también Bing.
Y ojo con Bing, porque parece el buscador que no usa nadie pero os recuerdo que Microsoft ha apostado muy fuerte por OpenAI, los creadores de ChatGPT… la IA destinada presuntamente a sustituir a Google para buscar en Internet.
Si habéis estado estos meses en una cueva y no sabéis qué es ChatGPT, os dejo el enlace al episodio aquí.
Por último, pero no menos importante, hubo otra compañía más con un papel decisivo en la rápida adopción de Hadoop: Amazon.
Amazon Web Services comenzaba a funcionar y ofrecía soporte para MapReduce.
Esto permitía que las startups almacenaran fácilmente sus datos en S3, el sistema de archivos distribuidos de Amazon y pudieran procesarlos usando MapReduce, sin la molestia de administrar un clúster de Hadoop.
Vamos viendo un poco que es un poco todo lo mismo pero que cada empresa lo llama de una manera diferente.
Para almacenar los datos de forma distribuida Google se inventa el sistema de ficheros de Google, en Hadoop esto mismo se llama HDFS y Amazon lo llama S3.
De la misma manera Google llama a sus sistema de almacenamiento columnar Bigtable y éste tiene un homólogo en Hadoop que se llama HBase.
Y así un poco con todo.
Así que ya estamos en 2008 y Hadoop va cogiendo fuerza.
Estaba bastante guay para que las empresas que manejaban Big Data pudieran almacenar y procesar cantidades masivas de datos.
Peeero era un poco rollo ponerlo a funcionar, monitorizarlo y mantener el cluster.
Así que enseguida comenzaron a aparecer suministradores que se encargaban de empaquetar soluciones Hadoop y hacer más amigable su configuración y monitorización, como Cloudera entre otras.
Ya tenemos un sistema de ficheros distribuido, un sistema de procesamiento distribuido, un sistema de almacenamiento columnar también distribuido y suministradores que se encargan de hacer más amigable su configuración y monitorización.
Incluso acordaos de Hive, que permitía transformar consultas a bases de datos mediante SQL a tareas MapReduce para poder hacerlas también distribuidas.
Pero bueno, Hive era un poco lento…
En 2010, una vez más, Google tuvo indirectamente una enorme influencia en el mundo de Big Data, al publicar un cuarto trabajo de investigación, llamado "Dremel: análisis interactivo de conjuntos de datos a escala web".
Este artículo introdujo dos innovaciones principales:
Por aquellos años, 2012 más o menos, apareció otro proyecto de código abierto que supondría una pequeña revolución en el mundo Big Data.
Estoy hablando de Apache Spark.
Apache Spark supuso una evolución en el procesamiento distribuido de los datos ya que era más sencillo y bastante más rápido en muchas ocasiones que MapReduce.
Además interoperaba con Hive y soportaba el uso de Machine Learning.
De los creadores de Apache Spark surgió la empresa Databricks en 2013 pero en lugar de vender despliegues de Spark en datacenters como hacía Cloudera con Hadoop (y después también con Spark), Databricks se especializó sólo en el despliegue de Spark en la nube, concretamente en AWS.
A partir de ahí siguieron surgiendo más y más proyectos de código abierto impulsados por grandes empresas según sus necesidades de trabajar con sus grandes volúmenes de datos.
Spotify, Netflix, Airbnb…
Esos cientos de proyectos además se fueron interconectando unos con otros haciendo bastante complicado seguir todas las tecnologías que iban surgiendo en el ecosistema Big Data.
Sin embargo, en los últimos años, el aumento en popularidad del Machine Learning ha impactado en la evolución de Hadoop.
No ha sido fácil integrar soluciones de Machine Learning en Hadoop.
Resumiendo un poco la historia de la relación entre el Machine Learning y Hadoop…
Los científicos de datos necesitaban dos cosas que Hadoop no podía ofrecer al principio:
Hoy en día, las implementaciones de Hadoop en la nube han sido reemplazadas principalmente por Apache Spark o Apache Beam aunque por supuesto, aún hay empresas que prefieren despliegues de Hadoop en sus propias instalaciones y de hecho siguen usándolo junto con Spark.
Sin embargo, la proporción de datos que se mueven a la nube sigue aumentando cada año.
Y bueno, espero que hayáis disfrutado este viaje al pasado para repasar un poco los orígenes del ecosistema Hadoop, al menos de una parte.
A mí me gustan especialmente estas historias porque al ver de dónde vienen un poco las cosas pues ayuda a entender la situación actual y a navegar un poco por la cantidad de herramientas que forman el ecosistema de Hadoop en particular y de Big Data en general.
A veces vemos tantas herramientas que es fácil perderse 😅
Espero que os guste el episodio.
Si es así, no olvidéis dejar un «Me gusta» y algún comentario al episodio en Ivoox o una valoración de 5 estrellas del podcast en Apple podcasts, en Spotify, en Google podcasts o donde quiera que escuchéis el podcast.
Recordad que si tenéis cualquier duda o pregunta podéis contactar conmigo a través del formulario de contacto o podemos seguir la conversación en Twitter.
Muchas gracias por estar ahí y os espero en el próximo episodio de Un Podcast Ninja sobre Big Data.