Arquitecturas Big Data

© ADR Infor SL
 Indice
Competencias y Resultados de Aprendizaje desarrollados en esta unidad 3
Arquitecturas Big Data 4
Componentes de una arquitectura Big Data 4
Data Lake 4
Hadoop + Spark 5
Hadoop 6
Map Reduce 6
Ecosistema Hadoop 8
Almacenamiento distribuido: HDFS 11
Spark 13
Spark DAG 13
RDD's 14
Ecosistema Spark 16
Spark sobre Hadoop 17
Panorámica de herramientas 17
Hemos aprendido 18
Actividades prácticas 20
Recursos 21
Videos complementarios 21
Preguntas Frecuentes 21
Glosario. 22

2/23
 Arquitecturas Big Data

Competencias y Resultados de Aprendizaje

desarrollados en esta unidad
Competencia:
Conocer el ámbito de trabajo completo de data management
Resultados de Aprendizaje:

Comprender qué es un Data Lake, y su utilidad dentro de un ecosistema Big Data

Comprender qué es un Hadoop, y su utilidad dentro de un ecosistema Big Data
Comprender qué es un Spark, y su utilidad dentro de un ecosistema Big Data
Comprender la interrelación entre Hadoop y Spark, y su utilidad dentro de un ecosistema Big Data

3/23
 Arquitecturas Big Data

Arquitecturas Big Data

Al final de esta unidad, comprenderás en qué consiste una arquitectura Big Data, distinguir
sus distintas capas y la utilidad de cada una. Sabrás cómo se pueden almacenar enormes
cantidades de datos, y cómo procesarlas en estos almacenes con Hadoop; también
sabremos cómo se pueden procesar estos datos mucho más deprisa (incluso en tiempo
real) con Spark; y las herramientas más utilizadas para trabajar con todos los componentes
de una arquitectura Big Data.

Componentes de una arquitectura Big Data

En todo ecosistema Big Data, encontramos 2 partes claramente diferenciadas:

La ingesta y almacenamiento de datos,

y el procesamiento de dichos datos (y a menudo la visualización de resultados).

Como almacén de datos hablamos genéricamente de "Data Lake", es decir "lago de datos"; y el
procesamiento se lleva a cabo con Hadoop y/o Spark.

Vemos a continuación estos elementos.

Data Lake
El Data Lake o lago de datos es un concepto genérico, que significa "el conjunto total de datos que
tenemos almacenados"; es decir es el lugar de donde tomamos todos nuestros datos para procesarlos.

Los datos nunca se deben procesar directamente cuando están en sus sistemas de
origen: esto puede repercutir en problemas de rendimiento en dichos sistemas de
origen. Además, si son datos externos a nuestra organización, la empresa externa deberá
prepararlos para que puedan ser aprovechados (por ejemplo, los contenidos en las redes
sociales).

Si en el data lake están todos los datos que queremos procesar, entonces también tendremos imágenes
de las redes sociales, texto escrito por humanos, vídeos grabados por cámaras de seguridad o de
Youtube, etc... es decir dato no estructurado.

Por lo tanto, en el data lake se incluyen datos internos (procedentes de la organización) y externos a la
compañía (procedentes de redes sociales, bases de datos externas, etc.)

Se denomina precisamente "lago" de datos porque no es sólo una base de datos "al uso".
Una base de datos implica la idea de datos estructurados, es decir en forma de tablas con
filas y columnas.

4/23
 Arquitecturas Big Data

De modo que un data lake está compuesto por:

bases de datos relacionales (una, o muchas),

un datawarehouse si la empresa lo tiene (que deberá tenerlo, en caso de tener sistemas de Business
Intelligence),
bases de datos no relacionales (para los datos no estructurados),
y sistemas de ficheros.

Cualquier dato que queramos procesar, debe estar en el data lake. Por tanto, el trabajo de ingesta de datos
consiste en encontrar estos datos e introducirlos en el data lake.

Un banco español ha creado una empresa dentro de su grupo empresarial, que se dedica a
vender datos para que terceras empresas los incorporen a sus Data Lake; es decir
monetizan sus datos, abren una línea de negocio para comercializarlos.

Hadoop + Spark
Con la llegada de Big Data, aparecen principalmente dos diseños tecnológicos para tratar la problemática
del procesamiento masivo de datos: Hadoop y Spark.

A grandes rasgos, Hadoop hace el tratamiento de datos en disco, mientras que Spark lo hace en memoria.
¿Qué quiere decir? Que Spark procesa datos en tiempo real mucho más rápido. Además, la facilidad de
uso de Spark es notablemente mayor que la de Hadoop.

Entonces, ¿Por qué Spark no sustituye a Hadoop? Porque como mejor funcionan es en
conjunto. El escenario perfecto es Hadoop y Spark trabajando conjuntamente.

Spark debería ser la elección óptima para cualquier entorno Big Data. Sin embargo, para empresas que
quieren tener bajo un mejor control sus inmensas cantidades de datos, Hadoop es la opción más adecuada.
A ésta se le puede añadir como un complemento excelente la velocidad de Spark, su agilidad y su facilidad
de uso.

5/23
 Arquitecturas Big Data

En definitiva, Hadoop y Spark tienen una relación de simbiosis. Hadoop ofrece elementos como sistemas
de archivos distribuidos, mientras que Spark ofrece procesamiento en memoria en tiempo real para los
datos que así lo requieran.

Componentes principales de un ecosistema Big Data

Componentes ecosistema Big Data

Hadoop
Apache Hadoop nació para cubrir la necesidad de procesar cantidades inmensas de datos con un alto
rendimiento y escalabilidad con Commodity Hardware, es decir, sin el gran desembolso económico en
infraestructura que supondría con las arquitecturas conocidas hasta el momento.

Hadoop es un proyecto de código abierto (open source), es decir, no hay que "pagar"
por utilizarlo, y de hecho cualquiera con conocimiento suficiente puede modificar el
código fuente para su propia conveniencia.

Hadoop se basa en dos pilares básicos:

Almacenamiento de datos en sistemas de archivos distribuidos, HDFS Hadoop.

Procesamiento distribuido de los datos usando la técnica del MapReduce.

Al margen de que Hadoop se puede usar sin Spark en una arquitectura Big Data, lo ideal es una arquitectura
Big Data en la que Spark se usa para procesos en tiempo real y Hadoop para procesos batch.

Map Reduce
MapReduce fue introducido por Google en 2004 y consiste en una técnica para procesamiento de grandes
cantidades de datos distribuidos. Sigue la filosofía: “¡Divide y vencerás!”.

Veamos un ejemplo muy simple y cotidiano para hacernos una idea: hacer un bocadillo. Mejor dicho,
pensemos en hacer miles de bocadillos en el menor tiempo posible (esto es un problema de "gran volumen
de datos").

6/23
 Arquitecturas Big Data

Pues bien, hacer el "Map" es separar y preparar los ingredientes para poder llevar a cabo el proceso más
rápidamente: romperlos en elementos más pequeños que hagan que, más tarde, será más fácil combinarlos.

Hacer "Reduce" es combinar estos ingredientes o elementos, para obtener el resultado final. Puesto que
con el Map dejamos la entrada muy bien dividida, podrían hacerse muchos bocadillos al mismo tiempo
(tantos como personas trabajando.... o procesadores trabajando en el sistema de información), llegando a
un ritmo de producción de bocadillos muy alto, potencialmente muchos miles a la vez.

7/23
 Arquitecturas Big Data

Por tanto, el algoritmo cuenta con dos pasos:

1. Map: Un nodo maestro toma la entrada, la divide en pequeños sub-problemas, y
los distribuye a los nodos. Un nodo puede, a su vez, dividir de nuevo el
problema, de modo que se construye una estructura de árbol multi-nivel. El nodo
final u "hoja" procesa el problema más pequeño.
2. Reduce: Cada nodo maestro a continuación recoge las respuestas a todos los
sub-problemas y las combina de alguna manera para formar una salida; las salidas
se siguen combinando para obtener la respuesta al problema que fue originalmente
planteado.

Ecosistema Hadoop
Para montar una solución Hadoop, son necesarios varios componentes divididos en diferentes niveles:

Ingesta de datos

Herramienta para la ingesta de datos masivos de diversas fuentes hacia los diferentes repositorios BIG
DATA.

Ejemplos son Sqoop, Flume, Kafka…

8/23
 Arquitecturas Big Data

Almacenamiento distribuido

Capa de almacenamiento distribuido que proporciona acceso de alto rendimiento a los datos de la
aplicación.
Se utiliza HDFS.

Capa de Gestión

Herramientas que gestionan aspectos como el direccionamiento, las tareas, la planificación de tareas y
las comunicaciones.

Ejemplos son Zookeeper, Oozie, Yarn…

Capa de procesado de datos

Herramientas para procesar datos y obtener resultados.

Ejemplos son MapReduce, Spark, Apex, y Pig.

9/23
 Arquitecturas Big Data

Capa de visualización

Herramientas para la visualización de datos; se denominan "Notebooks".

Ejemplos son Zeppelin, Jupyter, R, D3…

Capa Analítica
Herramientas para el procesado analítico, con las que hacer Machine Learning / Deep Learning.

Ejemplos son Mahout, Sparkling water, SystemML…

SQL sobre Hadoop

Herramientas que permiten tartar la información distribuida como si de una base de datos tradicional se
tratase.

Ejemplos son Hive, Impala, HCatalog…

10/23
 Arquitecturas Big Data

Como puede verse con los ejemplos, el "universo" de herramientas existentes es

amplísimo... en la siguiente imagen puede apreciarse la cantidad de herramientas y
tecnologías que pueden utilizarse.

Por este motivo, no puede ser un objetivo que una persona conozca todo el ecosistema
tecnológico; el cual, además, no deja de crecer y cambiar a un ritmo elevadísimo. Lo
importante es conocer la arquitectura general, las posibilidades existentes y el tipo de
problemas que se pueden resolver con Big Data.

Almacenamiento distribuido: HDFS

Fichero de gran tamaño

Imaginemos que tenemos un fichero relativamente grande, por ejemplo, de 160 Mb.

Cuando lo introducimos en HDFS, lo que ocurre es que se particiona en varios bloques.

11/23
 Arquitecturas Big Data

Partición en bloques

Cada uno de estos bloques tendrá por defecto un tamaño de 64 Mb (el último bloque será más
pequeño, hasta completar los 160Mb):

Como vemos en nuestro ejemplo, va a crear dos bloques de 64 Mb y un tercer bloque con el resto de
información hasta completar los 160Mb. Una vez que se ha particionado, lo que hace HDFS es llevar
cada uno de estos bloques a la arquitectura Hadoop, es decir, va a copiar cada uno de estos bloques en
un clúster de Hadoop.

Replicación DataNodes

Para garantizar la integridad de los datos, HDFS lo hace mediante replicación: replicar cada bloque de
nuestro fichero 3 veces, por tanto, va a ser copiado cada bloque en tres clústeres distintos. La
información relativa a cada clúster es gestionada por una pieza de software llamada DataNode.

Al mismo tiempo, HDFS dispone de un clúster especial denominado NameNode que gestiona la
información de toda la arquitectura HDFS. Este nodo NameNode es quien determina a qué clúster hay
que ir para recoger todas las piezas que componen nuestro fichero.

12/23
 Arquitecturas Big Data

NameNodes

Al igual que con las piezas que componen nuestro fichero, el NameNode es replicado, es decir, que
encontramos dentro de la arquitectura HDFS un NameNode que está en reposo, NameNode secundario,
a la espera de que ocurra algún tipo de fallo en nuestro NameNode activo. En ese caso, activaríamos
este otro NameNode y garantizaríamos de nuevo la integridad completa de nuestra arquitectura.

Hadoop

Spark
Spark es un sistema de procesamiento de alta velocidad para Big Data.

Su diferencia principal con Hadoop es que el procesamiento lo hace en memoria, lo cual

implica que el proceso sea hasta 100 veces más rápido ya que no tiene que escribir en
disco, a la vez que mantiene la escalabilidad lineal y la tolerancia a fallos de Hadoop.

Soporta varios lenguajes de programación, pero el más usado actualmente es Scala. Como apunte, Spark
es muy popular entre los profesionales dedicados al aprendizaje automático (Machine Learning).

Spark DAG
DAG es el acrónimo de “Directed Acyclic Graph” (Grafo Acíclico Dirigido). Este tipo de grafos se
caracterizan porque para cada nodo no hay un camino directo que empiece y acabe en él. La regla básica
es que un nodo se conecta a otro, pero nunca a sí mismo.

13/23
 Arquitecturas Big Data

Es el equivalente a MapReduce en Hadoop. Cada ejecución en Spark crea un DAG con un número
determinado de etapas, aunque no es un número fijo, sino que se define en función del caso, para que se
ejecuten en un clúster.

Aquí encontramos la razón por la que Spark es muchísimo más rápido que Hadoop. La
explicación se encuentra en que en Spark los resultados obtenidos en etapas intermedias
no se escriben en disco, mientras que en MapReduce los resultados obtenidos entre las
etapas de Map y Reduce deben ser escritos en disco.

Los datos de Spark están almacenados en memoria, por lo que su acceso y modificación
son sensiblemente más rápidos.

RDD's

14/23
 Arquitecturas Big Data

Un RDD es una estructura de datos inmutable. Es una colección de elementos que se puede particionar y
distribuirse entre los nodos del clúster, de forma que cada partición se pueda procesar en paralelo.

Se denominan así por:

R: "Resilient", es decir resistente o elástico; si los datos en memoria se pierden, pueden ser
reconstruidos.
D: "Distributed", es decir distribuido; están almacenados en la memoria del clúster.
D: "Dataset", es decir conjunto de datos; los datos iniciales pueden provenir de cualquier tipo de
fuente.

La programación en Spark se basa en hacer operaciones sobre RDDs. Los dos tipos de operaciones que
se pueden realizar son:

Acciones

Consisten en aplicar una operación sobre un RDD para obtener un valor.

Transformaciones

Al realizar una transformación obtenemos un nuevo y modificado RDD basado en el original.

15/23
 Arquitecturas Big Data

Un programa típico se organiza de la siguiente manera:

Se crea un objeto RDD leyendo datos de fichero, bases de datos o cualquier otra
fuente de información.
Una vez creado el RDD inicial se realizan transformaciones para crear más objetos
RDD a partir del primero. Dichas transformaciones se expresan en términos de
programación funcional y no eliminan el RDD original, sino que crean uno nuevo.
Tras realizar las acciones y transformaciones necesarias sobre los datos, los
objetos RDD deben converger para crear el RDD final. Este RDD puede ser
almacenado.

Ecosistema Spark
En la mayoría de las implementaciones el ecosistema Hadoop y Spark es compartido, e instalaremos Spark
como un módulo sobre el cual se apoyarán el resto de aplicaciones y herramientas. Normalmente cuando
se monta una solución Spark se instalan por defecto varios componentes:

Spark SQL

Representa los RDDs como un modelo Entidad-Relación para poder trabajar con datos estructurados.

Spark Streaming

Extensión del sistema Spark para el procesado de grandes volúmenes de datos que se van creando en
tiempo real.

Los datos de entrada se transforman en mini-lotes, que a su vez se convierten en RDDs (estrategia de
micro-batch). Los datos de entrada se replican para que haya tolerancia a fallos.

MLlib

Biblioteca implementada en el sistema Spark que contiene varios algoritmos iterativos de Aprendizaje
Automático (Clasificación, regresión, …).

GraphX

Otra biblioteca de Spark que implementa algoritmos sobre grafos para ser ejecutados en el clúster.

16/23
 Arquitecturas Big Data

Características propias de Hadoop y Spark

Spark

Spark sobre Hadoop

Ahora que ya hemos visto un poco más en profundidad qué es Hadoop y qué es Spark, retomamos el
punto inicial donde decíamos que actualmente se considera que la mejor arquitectura Big Data es aquella
en la que ambas tecnologías viven en simbiosis.

De forma gráfica se indica cómo debería ser dicha arquitectura:

Panorámica de herramientas
Para hacerse una idea, aunque crece cada día, este landscape es bastante completo para tener una visión de
la magnitud de herramientas existentes....

Es decir, a lo largo del módulo hemos nombrado muchas herramientas disponibles... ¡¡que
no suponen ni el 5% de todas las disponibles!! No debe ser un objetivo conocer todas
estas herramientas; cada día surgen otras nuevas, de hecho es uno de los problemas
actuales con Big Data: el ritmo de innovación tecnológica es tan alto, que no hay personas
con la formación completa en este sentido.

17/23
 Arquitecturas Big Data

>

Se trata de un campo en plena expansión, en el que el reciclaje continuo es una necesidad,

si queremos estar al día en su aspecto tecnológico. Sin embargo, su sentido de negocio y
propósito general se mantienen (ingesta, procesamiento y visualización de cantidades
ingentes de datos desde múltiples fuentes).

Herramientas para Big Data

Hemos aprendido

18/23
 Arquitecturas Big Data

Toda arquitectura de Big Data contempla, por un lado, el almacenamiento de

datos (estructurados y no estructurados), y por otro la plataforma de
procesamiento.
Entendemos por Data Lake al conjunto completo de los datos que una
arquitectura de Big Data almacena para su procesamiento.
Hadoop y Spark son las plataformas de procesamiento utilizadas en ecosistemas
Big Data.
Hadoop es capaz de procesar grandes cantidades de datos mediante la técnica de
Map-Reduce.
Hadoop persiste los pasos intermedios de procesamiento, es decir, los almacena
en disco; de esa forma, pueden recuperarse más tarde o en caso de fallo. HDFS
es el sistema empleado por Hadoop para ese almacenamiento.
Spark, a diferencia de Hadoop, no persiste en disco los resultados intermedios,
por lo tanto puede llegar a ser 100 veces más rápido.
Spark planifica primero los trabajos de procesamiento en DAGs (grafos acíclicos
dirigidos) y descompone los datos en RDD; posteriormente, ejecuta todo el
trabajo en memoria hasta que devuelve el resultado.
Es muy habitual que Hadoop y Spark trabajen juntos en un ecosistema Big Data.
La panorámica de herramientas es amplísima, y además no para de crecer a un
ritmo tal que una sola persona no puede dominar todas ellas.

19/23
 Arquitecturas Big Data

Actividades prácticas
Herramientas y soluciones de arquitectura Big Data

Vamos a indagar por el "universo" de las herramientas disponibles en ecosistemas Big Data, y qué impresión te
causa este ecosistema.

1. Ya sea para ingesta, almacenamiento, procesamiento o visualización de datos, y las hayamos

nombrado o no en el contenido del tema, ¿qué herramientas pertenecientes a un ecosistema
big data - o que consideres como tal - puedes nombrar?

2. Cuando se habla de procesar datos en tiempo real... independientemente de la definición que

demos en el curso, ¿qué idea asocias a esa expresión de "tiempo real"?

¿Crees que se puede conseguir esa respuesta en tiempo real de forma práctica, o crees que
no es posible? ¿Por qué?

20/23
 Arquitecturas Big Data

Recursos

Videos complementarios
https://youtu.be/yJslTGEmWm8: Vídeo explicativo sobre Hadoop

Preguntas Frecuentes

1. Si el ritmo de creación y evolución de las herramientas es tan rápido que "una persona no
tiene tiempo para aprender a dominarlas", ¿entonces no es una pérdida de tiempo estudiar
Big Data?

Efectivamente herramientas hay muchísimas, basta con observar el "landscape" actual que se
muestra en la unidad.

Existan muchas más herramientas de las que podemos dominar, porque muchas empresas se
desarrollan sus propias herramientas, y después las liberan a todo el mundo en modo "Open
Source". Algunas de estas herramientas acaban teniendo éxito porque pueden aplicarse a muchas
situaciones distintas. Son estas herramientas de más éxito las que es recomendable saber utilizar.

Por otro lado, para cada finalidad hay muchas herramientas equivalentes: para ingesta de datos,
gestión del almacenamiento, para lanzar consultas pesadas, gestión del procesamiento,
visualización... una vez conocido cada parte del ecosistema, es mucho más sencillo elegir entre
distintas alternativas.

Como en cualquier otro sector menos tecnológico, herramientas y "marcas" hay muchas, pero no
es necesario tener ni dominar todas ellas para llevar a cabo proyectos de dato con éxito.

21/23
 Arquitecturas Big Data

2. ¿Cuál es la diferencia entre un DataWarehouse y un Data Lake?

El DataWarehouse es el conjunto de bases de datos que se preparan para hacer Business

Intelligence. Incluye la base de datos de Stage, el ODS y el DDS. Todas ellas son bases de datos
estructuradas.

Pero el Data Lake no sólo incluye los datos estructurados. Hoy en día, una organización puede
querer saber qué dicen de ella en Twitter, en vídeos de Youtube, o en Facebook donde los
usuarios incluyen fotografías.

Entonces, la organización debe ingestar y almacenar también esta información no estructurada.

Además, seguir alimentando sus sistemas de BI tradicionales, es decir el DataWarehouse.

Pues a todo este conjunto de información se le denomina Data Lake.

3. ¿Cuál es el "kit" básico o mínimo de herramientas o tecnologías para construir un sistema

Big Data?

No hay respuesta a esa pregunta. No hay que asociar la idea de "solución Big Data" a una
arquitectura siempre completa que incluye ingesta de datos, almacenamiento, procesamiento, y
visualización.

Si bien ésa es una arquitectura "completa", no existe la arquitectura "correcta". En cada empresa
hay problemas distintos y necesidades distintas. Un pequeño data lake puede ser suficiente para
algunos, mientras que para otros el data lake es muy complejo.

Una empresa puede requerir el procesamiento (y por tanto, almacenamiento) de vídeo -dato no
estructurado complejo- mientras que otra puede sólo necesitar dato estructurado, aunque sea de
forma masiva (p.ej. para tomar decisiones de compra en bolsa).

Una empresa puede requerir tiempo real (para lo cual Spark es mejor solución) mientras que otra
no (entonces, Hadoop es una buena opción).

Glosario.

Clúster: Es un subconjunto de procesadores dentro de una "granja" o grupo aún mayor de

procesadores, destinados a ejecutar algún trabajo de computación. La comunicación de datos
entre los nodos de un clúster es más rápida que entre nodos de distintos clústeres.

22/23
 Arquitecturas Big Data

Commodity Hardware: Es hardware de bajo precio, como por ejemplo los PCs de trabajo
habituales que utilizamos en una oficina, o un ordenador portátil medio.

Datawarehouse: Conjunto de bases de datos que almacenan los datos estructurados de una
compañía; incluye Stage, ODS y DDS.

En disco: Significa que los datos se escriben en un sistema de ficheros, es decir se "persisten", de
modo que si se desconecta el sistema, estos datos no se pierden y permanecen donde estén
almacenados.

En memoria: Significa que los datos no están persistidos, sino en una memoria "RAM" de un
ordenador; si se desconecta (apaga), estos datos se pierden. Por contra, la ventaja es que la
memoria RAM es mucho más rápida que los ficheros (o "discos duros").

HDFS: Las siglas provienen de Hadoop Distributed File System, es decir, Sistema de Ficheros
Distribuidos de Hadoop.

Ingesta: Denominamos "ingesta" a todo el proceso y trabajo relacionado con la localización y

extracción de los datos, desde sus sistemas de origen hacia nuestro sistema de información.

Modelo Entidad-Relación: Es una representación esquemática de modelos de datos relacionales,

es decir datos estructurados, que están en forma normal.

Procesos batch: Son procesos que no requieren respuesta en tiempo real, es decir, pueden ser
lanzados para que se ejecuten, y obtener su respuesta cierto tiempo después (segundos, minutos,
horas...).

23/23