TIC, TAC, TEP: Aprender en el siglo XXI

IA, IoT y Tecnologías Información, Aprendizaje y Participación


3 comentarios

Cloudera, MapR, Hortonworks…¿Qué distribución Hadoop necesitas? (IV y fin)

En este último post de esta serie sobre Hadoop, hablaremos de las distribuciones comerciales líderes en el mercado y cómo elegir cuál es la que más nos interesa.


Aunque Hadoop no ha cumplido todavía su primera década en el mundo empresarial, sus expectativas para el futuro son de lo más prometedoras. Forrester, en su informe “The Forrester Wave™: Big Data Hadoop Distributions, Q1 2016” estima que, en los próximos dos años, el 100% de las grandes empresas adoptarán Hadoop y otras tecnologías relacionadas, como Spark, para sus analíticas Big Data.

Por tanto, la cuestión no va a ser tanto preguntarse:

¿Hadoop o no Hadoop? Sino: ¿Qué distribución de Hadoop me conviene más?

¿Por qué hay distintas distribuciones?

Al desarrollarse como proyectos independientes, es fácil encontrarse con problemas de compatibilidad entre versiones de distintos componentes. Siguiendo la senda abierta por RedHat en el caso de Linux, otras compañías han encontrado la forma de comercializar productos basados en desarrollo de software opensource, en este caso, con Hadoop.

Así, han “empaquetado” composiciones estables de estos componentes, creando sus propias distribuciones de Hadoop. Añaden a ésta otros componentes “de su cosecha” y servicios de soporte como “valor añadido” y ya tienen el pack completo. Ejemplos de estos componentes propietarios pueden ser, Impala propio de la distribución de Cloudera, y Tez de Hortonworks.

Los líderes en este mercado son ClouderaMapR TechnologiesIBM, y Hortonworks. Vamos a conocerlas un poco y después veremos qué tipo de criterios nos serán útiles para elegir entre una u otra. 

Cloudera

Cloudera fue la primera distribución Hadoop del mercado. Su chief architect es el propio Dough Cutting, uno de los creadores de Hadoop. Por ello su ritmo de innovación es vertiginoso. Su producto “Cloudera Enterprise” está formado por su propia distribución de Hadoop (CDH), un “Cloudera Manager” propietario y soporte de usuario para los componentes core de CDH. 

Logo Cloudera.
Figura 1: Logo Cloudera.

Cloudera fue la primera empresa que, ya en 2013, anunció su estrategia diferenciadora basada en crear componentes propietarios de valor añadido sobre el Hadoop opensource, como Impala, que junto con otras herramientas add-on como Cloudera Manager y Cloudera Navigator son muy valoradas por los clientes.También se caracteriza por acelerar la introducción del código opensource de nivel alfa o beta de las versiones más recientes de Hadoop y por su política de adquisiciones o colaboraciones con otras empresas que permitan cubrir las carencias en seguridad, gestión de datos y analíticas.Cloudera también ofrece un completo (aunque caro) programa de formación y certificación de profesionales.

https://www.cloudera.com/products/open-source/apache-hadoop.html
Figura 2: Ecosistema Hadoop Cloudera.(haz click para ampliar)

MapR Technologies

MapR pone el foco en ofrecer el máximo rendimiento y tolerancia a fallos, aprovechando el potencial de Hadoop para trabajar a gran escala, con el menor esfuerzo. Es el distribuidor de Hadoop que mayor esfuerzo ha hecho en hacer fiables y eficientes las mayores implementaciones de clusters Hadoop. Para ello ha desarrollado su propio sistema de ficheros nativo en Unix.

Por tanto, mientras Cloudera y Hortonworks distribuyen los metadatos y procesamiento en los DataNodes y NameNodes propios de HDFS, MapR tiene una arquitectura distinta, con un enfoque más distribuido que se traduce en mejores rendimientos. También se diferencia de sus competidores por sus características de alta disponibilidad (snapshots, mirroring, statefulfailover) e incluye el proyecto Apache Drill, basado en Google Dremel, para ofrecer procesamiento en tiempo real. 

 Logo MAPR.
Figura 3: Logo MAPR.
Figura 4: Ecosistema Hadoop MapR.

Figura 4: Ecosistema Hadoop MapR.

HortonWorks

La filosofía de HortonWorks esta más cercana al modelo de innovación opensource. Toda la tecnología de la distribución HortonWorks es Apache open source 100%. Está tan comprometida con este modelo, que incluso cuando adquiere alguna empresa para rellenar algún “gap” no cubierto por el core de Hadoop, aporta el código al proyecto Apache en beneficio de la comunidad, como hizo cuando adquirió XA secure, que pasó a convertirse en Apache Ranger.

Fue el primer vendor en usar la funcionalidad HCatalog para los servicios de metadatos y logró optimizar el proyecto Hive, el estándar de facto para las queries SQL interactivas, con la iniciativa Stinger.

Logo Hortonworks.
Figura 5: Logo Hortonworks.

Hortonworks ofrece una práctica herramienta de gestión y administración del cluster, Apache Ambari cuya funcionalidad es similar al Cloudera Manager, pero tiene ventaja de ser un software no propietario.

Otra de las ventajas de esta distribución es una sencilla y práctica “sand-box”, para aprender a manejar el entorno, así como numerosos y tutoriales online.

Pero la mayor diferencia entre Hortonworks y sus competidores fue el desarrollo de importantes mejoras en el core trunk de Hadoop que permiten que se ejecute de forma nativa en plataformas Windows, tanto en servidores onpremise, como en la nube (Windows Azure), mientras que sus competidores trabajan únicamente sobre Linux.

hFigura 6: Ecosistema Hadoop HortonWorks
Figura 6: Ecosistema Hadoop HortonWorks

 Todas estas distribuciones pueden usarse de forma independiente, o en combinación con una Big Data Suite. Las distribuciones Hadoop te ofrecen un práctico “empaquetado” , herramientas y soporte. Pero aún así pueden requerir un gran esfuerzo en codificación de jobs en MapReduce o integración de las diferentes fuentes de datos en Hadoop.

Aquí es donde entran las “Big Data Suites”, aportando ventajas en modelado, generación de código, programación de jobs e integración de distintas fuentes de datos.

Las Big Data Suites pueden ser de código abierto, como Talend o Pentaho, o propietarias. La mayoría de los grandes fabricantes de software, como IBM, Oracle o Microsoft, integran suites de Big Data en su portfolio de software. Es importante asegurarse de la compatibilidad entre la Big Data Suite y la distribución con la que estamos trabajando. Algunas distribuciones son más “flexibles” que otras en cuanto a compatibilidad.

¿Qué preguntas tenemos que hacernos a la hora de elegir?

A la hora de elegir qué distribución instalar, conviene hacerse una serie de preguntas.

  • ¿Qué problema de negocio quieres resolver?.
  • ¿Qué tipo de datos tienes que analizar?.
  • ¿Componentes opensource o software propietario?.
  • La infraestructura Hadoop que estás considerando, es lo suficientemente flexible para tus distintos casos de uso?.
  • ¿Qué herramientas ya existentes quieres integrar con Hadoop?.
  • ¿Necesitan tus administradores herramientas de gestión? (la distribución core de Hadoop no las incluye).
  • ¿Necesitas recursos de formación? ¿Cómo de compleja es la instalación?.
  • ¿Necesitas soporte?.
  • ¿Puedes tener problemas de vendor lock-in? (como código no transferible a otras distribuciones o formatos de datos propietarios).

Lo mejor, para poder comparar, es crear una tabla que reúna las especificaciones concretas de las distribuciones que estás considerando, priorizando las que son más importantes para tu negocio.Por ejemplo, si tienes instalaciones mixtas, con sistemas operativos UNIX y Microsoft, la opción a elegir será Hortonworks. Si necesitas un cluster muy optimizado para funcionar en tiempo real, investiga MapR. Si necesitas un potente motor de consultas SQL, puede interesante Cloudera, por la potencia de Impala… 

Sólo hemos visto las distribuciones más importantes, pero no las únicas. Lo principal es hacerse una idea del tipo de cuestiones que debemos valorar a la hora de elegir.

Con este post cerramos la serie sobre Hadoop. Puedes consultar los post anteriores aquí.

Si tienes interés en conocer un poco la arquitectura de Hadoop, cómo funciona su sistema de ficheros y la filosofía MapReduce, no te pierdas los siguientes post de esa mini-serie:


Post original publicado en ThinkBig Empresas.

Anuncio publicitario


3 comentarios

El Ecosistema Hadoop (III) : Una gran diversidad “biológica”

Ya estamos llegando al final del camino. En esta miniserie nos planteamos desentrañar la compleja madeja de Hadoop. Explicar de forma clara y legible en qué consiste, para qué sirve, y por qué, si hablamos de Big Data, tendremos que acabar hablando también de Hadoop. En el post de hoy trataremos el Ecosistema Hadoop. Es un entorno “vivo” en el que van surgiendo nuevos proyectos, o mejorándose los anteriores, para ir cubriendo las nuevas necesidades que se nos plantean cada día al trabajar con Big Data.

Hadoop no es un proyecto Opensource independiente. Es más bien un complejo ecosistema de proyectos muy diversos que trabajan a la par. Su objetivo es crear un conjunto común de servicios capaces de transformar lo que llamamos “commodity hardware” (hardware de bajo coste, sin capacidad de redundancia), en un servicio coherente que permita almacenar de forma redundante petabytes de datos, y procesarlos eficientemente.

Aunque comenzó como proyecto individual, poco a poco se fueron sumando distintos proyectos abarcando áreas de:

  • plataforma de almacenaje y procesamiento de datos
  • lenguajes de scripting
  • bases de datos
  • herramientas analíticas
  • lenguaje query
  • gestión de workflow
  • y mucho más…

Muchos de estos componentes de la pila Hadoop son proyectos Open Source de la Fundación Apache que permiten trabajar tanto con procesos en batch, como con procesos en stream, gráficos o procesamiento en tiempo real. Otros han sido creados de forma propietaria por empresas que han comercializado diferentes versiones “empaquetadas” de Hadoop (como Cloudera, MapR, Hortonworks etc). En el último post de esta serie, analizaremos más en detalle dichas distribuciones. Veamos algunos de los proyectos más conocidos del ecosistema Hadoop.

Proyectos del Ecosistema Hadoop.
Figura 1: Proyectos del Ecosistema Hadoop.

Algunos componentes de la pila Hadoop

  • Pig: es un lenguaje de alto nivel que traduce a “MapReduce”. Convierte una descripción de alto nivel de cómo deben ser procesados los datos en Jobs de MapReduce, sin necesidad de tener que escribir largas cadenas de jobs cada vez, mejorando notablemente la productividad de los desarrolladores.
  • Hive: Convierte una transformación en lenguaje SQL en Pig o directamente MapReduce. En Facebook se usa hasta en un 90% de las operaciones.
  • HBase: HDFS es ideal para trabajar en procesos batch. Sin embargo no funciona bien para las analíticas en tiempo real, uno de los requerimientos más demandados en la industria IT hoy en día. HBase se creó para cubrir esa necesidad. HBase tiene un motor de procesamiento en memoria que le agiliza enormemente las operaciones de lectura-escritura sobre Hadoop, permitiendo así trabajar con datos en streaming. También permite trabajar con bases de datos noSQL. Se puede acceder a HBase desde Hive, Pig y MapReduce y usa HDFS para almacenar la información, por tanto es completamente tolerante a fallos. Se usa por ejemplo en los mensajes de Facebook. El mensaje que le envías a un amigo es un objeto en una tabla Hbase. Almecena parte de sus metadatos en Zookeeper.
  • Zookeeper: es otro proyecto de Apache que almacena y facilita servicios de coordinación para distintos servidores.
  • HCatalog: es un proyecto que sacó los metadados de Hive para que también se pudiera acceder a ellos Pig y MapReduce. Es un servidor de metadatos con algunas mejoras. HCatalog puede acceder a los datos en el estándar HDFS o bien en HBase.

Otros proyectos

  • Mahout, es una librería de Machine Learning que permite escribir aplicaciones MapReduce
  • Ambari, Ganglia, Nagios ofrecen una interfaz de acceso al cluster
  • Sqoop, que permite ejecutar aplicaciones MapReduce que introducen o extraen información de bases de datos SQL (por tanto, estructuradas)
  • Flume sirve para introducir datos en streaming en Hadoop. Si tenemos servidores que generan datos de forma continua, se puede usar Flume para almacenarlos en HDFS (pueden ser datos semiestructurados o no estructurados).
  • Oozie es un gestor de workflow. Te permite definir cuándo quieres que tus jobs MapReduce se ejecuten, de forma programada o cuando haya disponibles nuevos datos.
  • Fuse-DFS permite acceder a HDFS usando herramientas LinuxComo Hadoop es un sistema distribuido en el que distintos componentes tienen que hablar unos con otros, también se da soporte a librerías de serialización como  (Protobuf (creado por Google) y Avro y Thrift (de Apache)

En el cuarto (¡y último!) post de esta miniserie, hablaremos de las distribuciones comerciales líderes en el mercado y cómo elegir las más adecuada a nuestras necesidades.

Si tienes interés en conocer un poco la arquitectura de Hadoop, cómo funciona su sistema de ficheros y la filosofía MapReduce, no te pierdas los siguientes post de esa mini-serie:


Post original publicado en ThinkBig Empresas


3 comentarios

Hadoop por dentro (II): HDFS y MapReduce

En nuestro primer post sobre Hadoop hablamos de su origen y sus características principales. Ahora vamos a conocer un poco la arquitectura que da soporte a la fiabilidad, escalabilidad y gran potencia que hacen de él un entorno ideal para las aplicaciones Big Data.  La idea que subyace en la filosofía Hadoop es distribuir algo muy grande, estamos tratando con Big Data, entre muchos nodos diferentes. Y tenemos dos cosas que repartir. Por un lado, la gestión y almacenamiento de la información. Y por otro, el procesamiento de los datos. Por tanto, Hadoop se basa en dos componentes principales: 

  • El Sistema de Ficheros distribuido Hadoop (HDFS), para la parte de almacenamiento
  • El Servidor MapReduce, para la gestión distribuida del procesamiento.
Figura 1: Ejemplo de cluster Hadoop con dos nodos.(Fuente)
Figura 1: Ejemplo de cluster Hadoop con dos nodos.(Fuente)

 

HDFS (Hadoop Distributed File System)

 Es el sistema de ficheros que almacena los datos en Hadoop. Para hacer frente al desafío que supone el gran tamaño de ficheros en Big Data, HDFS “rompe” estos ficheros enbloques (de tamaño configurable, aunque suelenser de 128MB o 256 MB), y luego los distribuye entre los distintos Data Nodes que conforman el cluster HDFS

Figura 2: Lectura y Escritura en HDFS.
Figura 2: Lectura y Escritura en HDFS.

Además de distribuir los bloques entre distintos nodos de datos, también los replica (al menos en 3 nodos diferentes, 2 en el mismo rack y 1 en otro) para evitar pérdidas de información si alguno de los nodos falla. El servidor HDFS en un cluster se llama Name Node. El NameNode almacena los metadatos, como el árbol de directorios del sistema de ficheros (Espacio de Nombres), y sabe en qué nodo del cluster está cada bloque de información (Mapa de Bloques). Por su gran importancia, este nodo se suele replicar en un Secundary Name Node.

Cuando una aplicación cliente necesita leer o modificar un bloque de datos, el Name Node le indica en qué nodo se localiza esa información. También se asegura de que los nodos no estén caídos y  que la información esté replicada, para asegurar su disponibilidad aun en estos casos.(Ver Figura 2). 

Por todo esto, HDFS le proporciona a Hadoop una gran escalabilidad. Según aumenta el volumen de datos a tratar, se pueden ir agregando nodos al cluster de forma dinámica. Los mayores clusters de Hadoop pueden llegar a tener tamaños de decenas de petabytes de datos , distribuidos entre miles de nodos.

En la wiki de Apache Hadoop podemos encontrar un listado de empresas e instituciones que trabajan con Hadoop, con detalles sobre el tamaño de sus clusters y el tipo de hardware que utilizan. Por ejemplo, Facebook tiene dos clusters principales: 

  • Un cluster de 1100 máquinas, con 8800 nodos y cerca de 12 PB de almacenamiento.
  • Un segundo cluster de 300 máquinas con 2400 nodos y cerca de 3PB de de almacenamiento.

Mapreduce

 Es el componente de procesamiento de Hadoop. Consiste en un framework de programación (librerías y entorno de ejecución) que trabaja sobre HDFS y se basa en el uso de dos tipos de funciones:

  • Map – “Divide y vencerás”: divide la tarea de entrada en subtareas y las ejecuta entre distintos nodos.
  • Reduce – “Combina y reduce la cardinalidad”: la función “Reduce” recoge las repuestas a las sub-tareas en cada subnodo y las combina y agrupa para obtener la respuesta final.
Figura 3: Filosofía MapReduce.

 Un ejemplo típico de uso

 Uno de los típicos ejemplos de aplicación de MapReduce consiste en contar el número de veces que se repite una palabra en un texto. Se divide en texto original en bloques o “tokens” (en este caso, grupos de 3 palabras). Cada token se pasa a una instancia de mapper que los organiza en parejas (clave=nombre fruta, valor=1 si está). En el proceso de Sort and Shuffle se organizan todos los resultados parciales obtenidos por los mappers en cada instancia o nodo y se reducen al agrupar y sumar todas las ocurrencias de una palabra en concreto. En el ejemplo de la Figura 4 “Apple” aparece 4 veces, “Grapes” 1 vez, etc… Así se obtiene el resultado final con la suma de las ocurrencias de cada palabra en el texto.  

Figura 4: Ejemplo de aplicación de MapReduce para contar palabras de un texto.
Figura 4: Ejemplo de aplicación de MapReduce para contar palabras de un texto.

“Llevar la ejecución a los datos”

Antes de que existiera el framework MapReduce la única forma de distribuir el procesamiento era, o bien compartiendo el mismo almacenamiento, o desplazando los datos de los nodos esclavos, al nodo de computación. Cuando los volúmenes de datos se hicieron enormes, surgieron problemas:

  • aumentaron los costes y los tiempos de respuesta (peores rendimientos de red).
  • aumentaba el riesgo de corrupción e inconsistencia de los datos.
  • aumentaba el riego de saturar el nodo maestro etc…
Figura 5: Comparativa modelos de procesamiento distribuido (Tradicional versus MapReduce)
Figura 5: Comparativa modelos de procesamiento distribuido (Tradicional versus MapReduce)

Estos problemas se solucionaron llevando el procesamiento allá donde se encontraban los datos, mejorando notablemente los tiempos de respuesta y cumpliendo así uno de los mantras del Big Data: “move the computation to the data”.

¿Cómo funciona MapReduce? ¿Cómo distribuye el procesamiento?

Cada máquina de un cluster Hadoop tiene un servidor MapReduce que se llama TaskTracker. A su vez, hay un gestor de Jobs por cada cluster, el JobTracker, que se encarga de dividir cada proceso a realizar en subprocesos, y distribuir la computación de estos subprocesos entre distintas máquinas del cluster, enviándo a los TaskTrackers de cada una de ellas el job que le corresponde realizar.

El Job Tracker también es responsable de comprobar que no haya desaparecido algún Task Tracker por fallo de hardware o sofware. En caso de detectar que un Task Tracker ha desaparecido, asigna automáticamente esa tarea a otro Task Tracker del cluster.

Figura 6: Cluster Hadoop de 3 nodos.
Figura 6: Cluster Hadoop de 3 nodos.

Versiones de Hadoop

Para terminar, vamos a hablar sobre las versiones de Hadoop. En la versión 1, si se caía el Job Tracker o se saturaba, el cluster dejaba de funcionar. También, en esta versión, el motor MapReduce estaba integrado en el Core de Hadoop y era la única API que podía interactuar con NTFS. Esta situación cambió en 2011 con el lanzamiento de la versión 2. MR2 incorporaba YARN (Yet Another Resource Navigator ), un gestor de cluster mejorado que separaba la tareas que realizaba el Job Tracker en la versión anterior en dos daemons: 

  • Un Gestor de recursos global: Global ResourceManager.
  • Un programador/Monitor de aplicaciones (por aplicación): ApplicationMaster (AM).
Figura 7: Comparativa de versiones de Hadoop.
Figura 7: Comparativa de versiones de Hadoop.

En la versión 2 se desarrolló una nueva versión de MapReduce, muy diferente de la anterior, ya que dejó de estar integrada en el Core (se ejecuta como una aplicación independiente). Gracias a esto, ahora es posible el acceso al sistema de ficheros de Hadoop desde otros entornos de programación y ejecución.

Esto es importante porque, aunque MapReduce es el framework ideal para muchas de las aplicaciones Big Data, no lo es para todas. Por ejemplo, Facebook no usa MapReduce sino Apache Giraph para analizar los grafos sociales generados entre sus usuarios y Contactos.  

Figura 8: La pila YARN
Figura 8: La pila YARN

No te pierdas el tercer post de esta mini-serie sobre Hadoop, donde hablaremos de las aplicaciones que conforman su ecosistema.    


Post original publicado en ThinkBig Empresas


3 comentarios

Big Data y Hadoop: Episodio (I)

Cuando leemos sobre Big Data, uno de las “buzzwords” con la que más nos encontramos es “Hadoop”. Aunque Hadoop lleva dando vueltas por el mundo tecnológico desde 2006 y ya existe mucha literatura técnica sobre el tema, en este post vamos a intentar explicar de forma sencilla qué es Hadoop y por qué es tan importante para el mundo del Big Data.

¿Qué es Hadoop?

Hadoop es un proyecto opensource de la Apache Foundation, introducido en 2006, y desarrollado en Java cuyo objetivo es ofrecer un entorno de trabajo acorde con las necesidades del Big Data (las 4 “V”). Hadoop, por tanto,  está diseñado para trabajar con volúmenes de datos masivos (Volumen), estructurados o no (Variedad), y procesarlos de forma segura y eficiente (Veracidad/Velocidad) , tanto en costes como en tiempo.

Al principio, según aumentaba el volumen de datos de trabajo, la solución tradicional consistía en invertir en equipos más potentes, con mayores capacidades de almacenamiento-procesamiento, y, por supuesto,  más caros. Pero pronto se vio que había que plantearse otra forma de hacer las cosas. Ese camino no era viable.

La clave estaba en distribuir, tanto el almacenamiento de la información, como su procesamiento, entre muchos equipos trabajando de forma coordinada en “clusters”, con uno o varios nodos maestros encargados de gestionar, por una parte el sistema de ficheros distribuido donde los datos se almacenan en diferentes bloques redundados; y por otra, la coordinación y ejecución de los distintos jobs o tareas entre los miembros del cluster. Al trabajar de forma distribuida los retos principales eran: poder acceder a los datos, procesarlos a gran velocidad y evitar la pérdida de información si alguno de los nodos fallaba.  

Figura 1: Ejemplo de un cluster Hadoop compuesto por tres nodos
Figura 1: Ejemplo de un cluster Hadoop compuesto por tres nodos

Hadoop dio respuesta a estos problemas, ofreciendo:

• Fiabilidad. Distribuye los datos y las tareas entre distintos nodos. En caso de fallo de un nodo, la tarea se reasigna automáticamente a otro y los datos no se pierden porque están replicados en otros nodos del cluster.
• Escalado horizontal: el mismo programa se puede probar en una máquina, y después escalarse a 1000, o a 4000 máquinas
• APIS muy sencillas, tanto para procesamiento como para acceso a los datos
• Potencia, al dividir el procesamiento entre distintas máquinas, se pueden procesar enormes volúmenes de datos en tiempos eficientes.


Sus capacidades para distribuir la capacidad de almacenamiento y el procesamiento de los datos entre un gran número de máquinas, y ofrecer redundancia basada en software, se traducen en otra de las mayores ventajas de trabajar con Hadoop: 

 No hace falta comprar hardware especial, ni costosos sistemas RAID. 

Puede ejecutarse sobre “commodity hardware”, lo cual supone una gran  flexibilidad y un importante ahorro.

Otra de las ventajas de Hadoop es su escalabilidad. Especialmente cuando se despliega en plataformas de nube pública como Microsoft AzureAmazon AWS y Google Compute Cloud, que permiten ir añadiendo-reduciendo recursos según varíen las necesidades del negocio.  En estos casos se suelen usar los sistemas de almacenamiento propios de estas plataformas para desacoplar la computación del almacenamiento. Así, la computación se dedica a ejecutar procesar y analizar los datos en lugar de a mantener el sistema de archivos que los sustenta

Un poco de historia para situarnos

En realidad, los creadores de Hadoop, Doug Cutting y Mike Cafarella simplemente querían diseñar un motor de búsqueda open source, al que llamaron Nutch (en 2002). Pronto se tropezaron con las dificultades propias de trabajar con grandes volúmenes de datos. Vieron que su buscador era lento,  que necesitaban equipos muy potentes y que tenían que estar monitorizando continuamente que no fallaran los procesos.

Cuando poco después, Google publicó dos trabajos sobre su sistema de ficheros y la filosofía MapReduce (Google File System paper en Octubre 2003 y MapReduce paper en Diciembre de 2004) Cutting y Cafarella vieron la solución a sus problemas, ya que este nuevo enfoque les permitía automatizar muchas de los pasos que estaban realizando de forma manual. Se pusieron manos a la obra y en unos pocos meses, diseñaron (en Java) el sistema de ficheros y el entorno de procesamiento que permitía distribuir, tanto el procesamiento como el almacenamiento entre distintas máquinas.

Poco después, Cutting empezó a trabajar en Yahoo, donde había un gran interés en desarrollar tecnologías open source basadas en Map Reduce y el sistema de ficheros Google. Tomaron de Nutch la parte de almacenamiento y procesamiento y así, en 2006, nació Hadoop, como un nuevo proyecto open source de la Apache Software Foundation. El  nombre y la imagen,  lo tomaron del elefantito de peluche del hijo de Cutting.  El buscador Nutch quedó entonces como proyecto independiente. 

Figura 2: Dough Cutting con el elefante de juguete que dio nombre a Hadoop
Figura 2: Dough Cutting con el elefante de juguete que dio nombre a Hadoop

Como el origen de Hadoop fue un poco circunstancial, y lo que se buscaba era dar soporte al buscador Nutch, cuando se empezó a usar con una perspectiva más amplia aparecieron una serie de carencias. Para cubrir estas carencias, surgieron diferentes proyectos open source que iban complementado Hadoop, creando un auténtico ecosistema.

Así, el pequeño elefante amarillo fue el primer animalito de un auténtico “zoológico”, al que luego se fueron sumando otros más: cerditos, impalas, orcas, abejas con cabeza de elefante… hasta un “cuidador del zoo”, añadiendo un toque de humor a toda esta complejidad tecnológica.

En un próximo post, hablaremos con más detalle del entorno Hadoop y las herramientas que lo conforman, pero como aperitivo, os dejamos algunos de sus coloridos logos en la siguiente imagen. Hay unos cuantos más… 

Figura 3: Algunos componentes del ecosistema Hadoop
Figura 3: Algunos componentes del ecosistema Hadoop

Al igual que ocurre con otros proyectos Open Source, algunos fabricantes ofrecen distribuciones estables, que aderezan con herramientas propias y, sobre todo, soporte. Las más habituales son Cloudera HadoopHortonWorksMapR,Microsoft HD InsightIBM InfoShere BigInsightsAWSEMR (Elastic MapReduce),  etc. En particular, nosotros en  LUCA elegimos HortonWorks para ofrecer Big Data as a service en España.

Si tienes interés en conocer un poco la arquitectura de Hadoop, cómo funciona su sistema de ficheros y la filosofía MapReduce, no te pierdas los siguientes post de esa mini-serie:


Post original publicado en ThinkBig Empresas


3 comentarios

Modelos Pedagógicos Asociados al mLearning

Os dejo aquí un nuevo vídeo de otra Master Class del Programa de Televisión Educativa de Bureau Veritas Formación: «Modelos Pedagógicos Asociados al mLearning«. En este caso, trata sobre las ventajas e inconvenientes que aporta el uso de dispositivos móviles en la formación online, así como los distintos modelos pedagógicos que se pueden considerar, según el grado de utilización de este tipo de dispositivos en los procesos de enseñanza-aprendizaje.

Os dejo también, para descargar, la presentación. Espero que os guste.

Master Class ModelosPedagogicos_mLearning

(pulsar sobre la imagen, para ver el vídeo)