• ENTRAR
  • No hay productos en el carrito.

Big Data. Pruebas y simulaciones. 1ª Parte

Entendiendo el Big Data...

Esta entrada, dividida en 2 partes, veremos lo siguiente:

  • Como se organiza arquitectonicamente un Big Data
  • Un supuesto de Big Data de una forma conceptual
  • Creación de un entorno simulado alternativo a Cloudera con mrjob
  • Un ejemplo sencillo del entorno anterior (no el de contar palabras)

En la UNED, donde actualmente estudio, como en cualquier otra universidad, en algunas asignaturas hay ciertas materias que te las dejan en el tintero y te recomiendan y/o proponen estudiarlas en forma de prácticas, ayudando con un porcentaje a la nota final de la asigantura, después de aprobar el examen o pasar un corte.

En este caso, la asignatura en cuestión ha correspondido a Sistemas de Bases de Datos y como no, una de las prácticas propuestas era optativa. Cuando el tiempo no juega a tu favor y te dan un enunciado de una práctica con 32 hojas, pues como que lo primero que a un presente se le pasa por la cabeza es dejar de lado esa práctica y conformarse con decir que tampoco cuenta tanto para la nota de la asignatura.

Ufffffff, lo que me hubiese perdido si como mínimo no hubiese leído el enunciado. Mi agradecimiento al Dr. Agustín C. Caminero Herráez y Dr. Luis Grau Fernández por proponernos al alumnado en el curso 2017/18 e ilustrarnos con esta maravilla de actividad que voy a intentar sintetizar para que también conozcan los estudiantes que por los motivos que fueran, no quisieron o pudieron hacer la práctica, a los amantes y apasionados de la informática, gurus que han cogido otros senderos, y cómo no a los primos, sobrinos y amiguetes que saben hacer de “to”, sarcasmo mode ON, 🙂 Por favor primos, sobrinos y amiguetes, no os molesteis sois bien recibidos, el sarcarmo es para vuestros tios y respectivos que no saben si son o no informáticos o sólo les gusta y los alaban como si del mismísimo Linus Torvalds se tratase. Pero bueno aún así no podemos privar a nadie de ese conocimiento, ver de una forma sencilla para cualquier persona del mundo mundial como pueden organizarse los Big Data.

Sí, esa serie de máquinas, apiladas unas sobre otras, encima de bidones o tiradas por todos los rincones de las habitaciones o yo que sé como demonios puedan acomodarlas. Fuera bromas, máquinas organizadas en clusters y que en conjunto tienen algunos discos duros, por no decir cientos, miles, millones o vaya usted a saber, sí tendrán que tener factorias de fabricación para ellos solos 🙂

El caso es que ese sistema funciona, funciona como si fuera una máquina de escribir electrónica cuando vuelca la memoría al papel, OMFG!!!!!! eso parecía magía, igual que cuando uno lanza una consulta a un buscador. Nos tarda nada apenas un segundo en devolvernos una respuesta tan sencilla y tan compleja como fuera nuestra consulta.

Bien, pues eso es un sistema distribuido, desde varias a miles de máquinas interconectadas, organizadas y sincronizadas, capaces de almacenar un gran volumen y devolvernos a gran velocidad y de gran variedad la información. Un ecosistema en el que una base de datos relacional no podría existir, ahí entran en juego los Big Data. Presentes en sistemas grandísimos y archiconocidos, pero también usados en entornos de investigación, económicos, médicos,… No hace falta ser Google para tener la necesidad de estos sistemas. Hacienda??? Los historiales médicos???? Espero que me sigais, y porque no nosotros mismos, quién no tiene unos gustos tan delicatesen como para mantener gigas y gigas almacenados si pudiesemos. Pero…. y si no queremos tener la información en las nubes por si acaso se caen todas las del mundo al mismo tiempo. Una plegaria para que esto no suceda.

¿Quién es el personaje que nos permite crear esta infraestructura? Pues bien, entre ellas Hadoop o Spark, esta entrada no va de como montar estos sistemas, ya que con seguir los manuales de los desarrolores se montan sin demasiada dificultad o algo más según la planificación o complejidad requerida. Y entonces ¿esto de que va? Os dije que de conocimiento de la arquitectura general y de un entorno manejable que simule todo esto sin necesidad de luchar contra uno de estos sistemas reales en tiempo de produccion. Y ¿porque simularlo? pues sencillo, porque una máquina virtual de Cloudera que lleva ya todo preparado y fácilmente ampliable, la podemos descargar de su web, son varios gigas, ahora bien, hacerla correr es otra historia, ya que es aconsejable trabajar con 4gb y aún así no va fina, cuando empece a desarrollar la práctica en un i3 con 4gb, le destine 2.7gb de ram y un 1 nucleo, tardo en arrancar y estabilizarse aproximadamente 20 minutos, con 2 nucleos funcionaba igual y el soporte a la maquina virtual tambien consume recursos, no lo olvideis. Ojo, Hadoop también se puede usar en Windows o en cualquier Linux, hay instaladores automáticos, son sencillos de usar y permiten añadir a nuestro “cluster” máquinas y/o almacenamiento de forma sencilla, pero dejáis un sistema operativo ya “ensuciado” para realizar otras labores y de momento estamos conociendo el sistema y probándolo, recordemos esto, mejor usar máquinas virtuales para las pruebas, si os llevais mal con ellas, lo siento, es cuestión de acostumbrarse.

Bueno, ahora ya si entraremos en materia a estudiar la arquitectura, que como preámbulo creo que me he colado, pero bueno el tema me parece interesante y creo que así lo parece.

El sistema distruido, el Big Data, estará formado por varias máquinas en forma de cluster en una red interconectada. En ningún momento sabemos en que máquina del cluster estará guardada la información que colguemos en el cluster, es el sistema quién decide a donde va la info (por simplificar las cosas es así). Además es escalable, es decir, podemos añadir más recursos aumentando proporcionalmente la capacidad con el número de máquinas. Pero es que resulta que el sistema también es tolerante a fallos, es decir, si una máquina falla, el sistema seguirá funcionando, gracias a la replicación de la información en otras máquinas del cluster.

En un caso hipotético de un cluster con 7 máquinas, cada nodo o máquina, puede almacenar uno o varios bloques de un fichero, por ejemplo, imaginemos que un fichero de 90mb, el sistema lo organizase en tres bloques, en tres partes de 30mb, vamos. Cada bloque podría ser repartido por ejemplo en tres nodos distintos, y además, en vez de guardarlo una vez, el Big Data lo que hará será guardar de nuevo cada bloque del fichero en otro nodo distinto, para la replicación necesaria para que el sistema sea torelante a fallos. Para que esto funcione una ( o varias máquinas, depende de la complejidad) debe funcionar como maestro, de tal forma que ese maestro debe saber en todo momento en que nodo esta cada bloque del fichero y en cuantos bloques se ha divido y además conoce también donde están las replicas que cada nodo guarda del bloque del fichero. Mirad la imagen, para verlo más claro.

 

COmunix

 

 

 

En el caso de Hadoop, nuestro Big Data, para que esta magía se haga realidad, es decir, para que sea distribuido, escalable y tolerante a fallos gracias a la replicación, necesitamos un sistema de ficheros que lo soporte y que se llama HDFS (Hadoop Distributed File System) y las operaciones MapReduce.

El sistema de ficheros HDFS, no entraremos en profundos detalles, pero se encargará de organizar y guardar la información y nos facilitará una capa de abstracción con las operaciones de manejo de ese sistema de ficheros. Estas operaciones son similares a los comandos usados en cualquier shell de Linux, los cuales aparecen en detalle en la página de Hadoop, https://hadoop.apache.org/ . Por ver algunas ordenes básicas lanzadas desde cualquier linea de comandos, tenemos por ejemplo las de listar ficheros, crear directorio, colgar fichero, descargar fichero, por mencionar algunas:

  • hadoop fs -ls [carpeta]
  • hadoop fs -mkdir [carpeta]
  • hadoop fs -put origen destino
  • hadoop fs -get origen destino

En cuanto a las operaciones MapReduce decir que son tres y que nos van a permitir paralelizar las ejecuciones en los nodos y recoger los resultados:

  • MAP : Opera sobre UN bloque de un fichero HDFS, ejecutandose en ese nodo que lo contiene
  • SHUFLE & SORT: Recoge y organiza los datos intermedios, se ejecuta solamente cuando todas las operaciones MAP han finalizado. Este operación podría omitirse
  • REDUCE: Toma los datos intermedios y produce la salida.

Pero… ¿Como sucede esto? sencillo, cada vez que se solicita una operación MapReduce, se envian a los nodos involucrados el software que realiza la operación MAP. Ya!!!, mmmmm vale!!! pero que es realmente el MAP, pues por ejemplo, un script en Python, un programita en Java o en otro lenguaje que pueda ser ejecutado en una máquina Linux o para la plataforma operativa que usemos, en resumen, un fichero ejecutable que trabajará sobre un bloque como si se tratase del fichero completo, pero solo para ese bloque del fichero. Y el resultado se procesará con el REDUCE que es otro script o programita recopilando esos datos y produciendo una salida con las operaciones de cada nodo que realizo el MAP. Pero… ¿Cómo sabemos donde están los datos y donde se ejecuta cada programita? Y que nos importa!!!!!!!!!!!! es un sistema distribuido, que se encargue Hadoop de hacerlo. Para nosotros la visión que tenemos es de sólo una computadora.

Si os parece vamos a ver en un ejemplo conceptual y teorico, y dejo el ejemplo práctico con código para la segunda parte de la entrada al blog para que podais digerirlo mejor.

Imaginemos que somos los P_TOS AMOS de Facebook, Uisssss!!!!! me he colao!!!!! me he venido arriba!!!!! lo siento :(, bueno seamos más humildes :), estamos haciendo una red social para un instituto o la universidad, ¿porque no? Entonces necesitaremos varias máquinas para tener la información organizada, replicada y poder ser tolerante a fallos, por si falla alguna de ellas. Necesitamos atender muchas conexiones para los chat, almacenar las fotos, videos, contenido multimedia en general de los miembros de la red social. Además necesitaremos posiblemente añadir nuevas funcionalidades, videoconferencias entre los miembros, permisos de visibilidad entre ellos, registros de accesos,…lo que se nos ocurra. Toda esta información debe ir organizada de alguna manera, una Base de Datos (BBDD a partir de ahora).

Bien, la BBDD adquiere en poco tiempo un tamaño grande, de tal forma que la BBDD se va diviendo en bloques, los cuales, se van dispersando en distintos nodos para mantener la replicación y lo mismo sucede con cada fichero, foto o lo que sea que cuelga cada miembro de nuestra red social. Y claro poneos en la situacion: un miembro de la red social entra en ella, y claro necesitara ver el muro de publiciones, su perfil, sus eventos, sus ficheros,…. Entonces como se comporta el sistema, pues bien, se solicita que una operación MapReduce se ejecute a la máquina maestro, la operación MAP se cuelga (si no lo esta ya) en los nodos que contienen los bloques que nos corresponden a toda la información y que esta dispersa en todos ellos, la operacion SHUFFLE&SORT (si existe) intenta reorganizar esos datos para enviarlos al REDUCE que organizara y presentará lo que necesitamos.

¿Se ha entendido? Creo que si, ahora implementarlo es más complicado, ese es otro cantar. Pero la cuestión que nos atañe es la siguiente: La Red Social ha sido un auténtico éxito, es la repanocha, vamos nos falta un pelo para ser Dios, pero nos estamos quedando sin recursos a causa de ese gran éxito, la BBDD crece y crece, las fotos, los videos,…… nos quedamos sin espcio, pero todavia tenemos algo de pasta o nos ofrecen inversiones. ¿Qué nos impide con la organización que tenemos ampliar en capacidad de almacenamiento y poder aumentar el número de máquinas? Absolutamente nada, creeis que el software utilizado seguirá funcionando en 10, 100, 1000 o 10000 máquinas más????? La leche!!!!!!!!!! necesitamos expandir nuestra red social a la comarca, y en breve a la región, nos importaría expandirla a nivel nacional????? Sr. Zuckeberg pongase a temblar…

No te pierdas la segunda parte en breve.

Si te gustó, búscame en Telegram como @nomed1, próximamente también en www.tallerdeandroides.com, hasta la próxima.

 

Buenaventura Salcedo | @nomed1

www.tallerdeandroides.com


Tú escuela de Hacking Ético.

Suscríbete a nuestro Boletin

  Suscribirse ahora
Copyright © 2018 - Todos los derechos reservados.
X