Tecnologías Big Data

I. Introducción y objetivos

II. Las tres uves como marco de análisis

III. Volumen. Hadoop y Spark

IV. Velocidad. Spark streaming

V. Variedad. NoSQL

VI. Arquitectura de referencia

VII. Arquitecturas batch y streaming

VIII. Arquitecturas lambda y kappa

IX. Resumen
X. Caso práctico con solución

XI. Lecturas recomendadas

XII. Enlaces de interés

XIII. Glosario

XIV. Bibliografía
Lección 1 de 14

I. Introducción y objetivos

1.1. Introducción de la unidad

 En esta unidad, se hará un repaso a las tecnologías más características del mundo big data.
 1

En primer lugar, se establecerá un marco de análisis basado en los tres problemas principales que
las tecnologías big data ayudan a resolver:

Volumen

Velocidad 

Variedad
 2

A continuación, se analizarán las características principales de Hadoop y de Spark. Las dos son
opciones muy populares en la actualidad para abordar el problema relacionado con el
procesamiento de grandes cantidades de información.

 
 3

El segundo tipo de tecnología nos permite abordar el problema de la velocidad de procesamiento,

que se presenta cuando los datos llegan en un flujo continuo. Es necesario analizarlos a medida
que van llegando para tomar decisiones en tiempo real.
 4

Y, por último, se introducirán las tecnologías NoSQL, que nos permiten abordar el problema de la
variedad, que se da cuando es necesario tratar con información que puede presentar estructuras
cambiantes o diversas.
 5

El repaso que se hará aquí de todas estas tecnologías no pretende ser exhaustivo. Más adelante,
habrá ocasión de abordar con más detenimiento la mayoría de ellas. De lo que se trata ahora es
de afianzar un marco de análisis que permita contextualizar y más tarde profundizar en el estudio
de las diferentes tecnologías con un enfoque sistemático.
 6

Se verá también una arquitectura de referencia para una plataforma big data típica. Se distinguirá
entre arquitecturas para procesamiento por lotes (batch) y para flujos (streaming), y se
explicarán algunas variantes híbridas populares, como son las arquitecturas lambda y kappa.
El repaso que se hará aquí de todas estas tecnologías no pretende ser exhaustivo. Más adelante,
habrá ocasión de abordar con más detenimiento la mayoría de ellas. De lo que se trata ahora es
de afianzar un marco de análisis que permita contextualizar y más tarde profundizar en el estudio
de las diferentes tecnologías con un enfoque sistemático.

 
 C O NT I NU A R

1.2. Objetivos de la unidad

Al terminar esta unidad, el estudiante será capaz de:

1 Decidir qué tecnología es más adecuada en cada momento en función

de los requisitos y de los objetivos perseguidos.

2 Conocer los problemas que surgen a la hora de procesar una gran cantidad de información y
cómo se pueden solucionar con Hadoop o Spark.

3 Conocer los problemas que surgen a la hora de procesar flujos continuos de información y en
qué se basan soluciones como Spark Streaming para abordarlos.
4 Conocer los problemas que surgen cuando la información a procesar no tiene una estructura
fija y cómo las soluciones NoSQL nos permiten manejar esta variedad.

5 Diseñar una arquitectura de referencia a alto nivel para una plataforma big data típica.

6 Decidir qué arquitectura es la más adecuada, de lotes o de flujos, en función de las

necesidades y requisitos que se tengan.

7 Diseñar arquitecturas híbridas, como las lambda o kappa, que combinen lo mejor de las
arquitecturas para lotes y para flujos.
Lección 2 de 14

II. Las tres uves como marco de análisis

Cuando se aborda el análisis de las tecnologías big data disponibles en el mercado es fácil sentir
desorientación debido a la gran cantidad de propuestas existentes. Si no se tienen unos fundamentos
sólidos que guíen el análisis, la toma de una decisión respecto a qué tecnología o solución escoger puede
ser un proceso difícil y quizás condenado al fracaso.

En esta unidad se establecerán dichos fundamentos. La guía será un marco conceptual que se basa en el
tipo de problemas que resuelven las tecnologías big data. Estos tres problemas están relacionados con las
tres uves que ya mencionamos al principio del módulo para ayudarnos a definir el término big data.

A continuación, se verán cada uno de estos problemas:

1. volumen

2. velocidad

3. variedad

 Y qué tecnologías han surgido en el mundo big data para resolverlos

 C O NT I NU A R

El panorama de los datos y la inteligencia artificial en 2019

Todos los años se publica un resumen panorámico de las tecnologías más relevantes
relacionadas con el mundo del dato junto a todo tipo de soluciones y tendencias relacionadas
(Turck, 2019).

Puedes consultar el resumen del 2019 en este enlace.

Lo primero que salta a la vista al observar el panorama de cada año es la gran cantidad de
propuestas existentes. Para orientarse en este tipo de escenario, se hace necesario disponer
de algún tipo de marco conceptual como el que aquí proponemos.
Lección 3 de 14

III. Volumen. Hadoop y Spark

3.1. Hadoop
Ya hemos visto que Hadoop es un software que permite almacenar y procesar la información de manera
distribuida, es decir: repartir los datos y la carga de trabajo entre varios ordenadores que trabajan en paralelo
de forma coordinada.

Recuérdese que lo que permite Hadoop es, por un lado, guardar ficheros muy grandes y, por otro lado, repartir
las tareas de procesamiento de forma que el tiempo total disminuya de forma proporcional al número de
máquinas que trabajan en paralelo.

C O NT I NU A R

¿Qué es Hadoop?
Handoop es un software que se encarga de coordinar, de forma transparente para el desarrollador de
aplicaciones, el trabajo de un conjunto de ordenadores o nodos, de manera que se puedan almacenar y
procesar grandes camtidades de datos entre todos ellos.
 Figura 1. Hadoop se encarga de coordinar el almacenamiento y procesamiento de los datos
repartidos en el clúster. 
Fuente: © Concepción Labra 2020.

C O NT I NU A R

Para conseguir esto, Hadoop se basa en los siguientes dos componentes:

3.1.1. El sistema distribuido de archivos HDFS

El funcionamiento de HDFS se basa en lo siguiente:
 1

Dividir un archivo en bloques de tamaño adecuado para ser almacenados en el disco duro de
cada nodo.
 2

Distribuir los bloques entre los diferentes nodos.

 3

Replicar cada bloque varias veces, tres en la configuración por defecto, copiándolo en diferentes
nodos. Si un nodo falla, hay otros dos que contienen esa misma información. De esta manera,
evitamos que el fallo de un nodo produzca la corrupción del fichero.
 Resumen
Este último punto es muy importante ya que, en un sistema distribuido como Hadoop, al
aumentar el número de nodos del clúster aumenta la probabilidad de que uno de ellos falle.

C O NT I NU A R

Figura 2. Hadoop divide cada fichero en bloques y los distribuye entre los nodos del clúster. El
nivel de replicación por defecto de cada bloque es tres.
Fuente: © Concepción Labra 2020.
En la figura 2. se representa gráficamente el particionado de un fichero en bloques y cómo estos son
repartidos entre los diferentes nodos usando un nivel de replicación tres.

Es importante señalar que Hadoop adolece de latencias altas a la hora de responder. Una de las razones es
que el sistema de replicación de bloques hace que Hadoop sea muy seguro, pero también lento ya que es
necesario escribir cada bloque varias veces en el disco duro. Esto significa que HDFS no está pensado para
escenarios donde se requieren bajas latencias, es decir donde las respuestas deban ser del orden de
milisegundos o pocos segundos. En caso de que se necesiten este tipo de resultados rápidos, habrá que
utilizar otras opciones como, por ejemplo, Spark.

C O NT I NU A R

3.1.2. El marco de procesamiento distribuido MapReduce

Una vez que los bloques que componen un fichero están repartidos entre las diferentes máquinas, ya es
posible enviar a estas las diferentes tareas que hacen falta para llevar a cabo el trabajo de procesamiento.

para entender cómo

funciona Hadoop es el
concepto de MapReduce.
Dentro del paradigma de
El concepto fundamental
procesamiento en el que se
basa Hadoop, todas las
operaciones se tienen que
llevar a cabo en términos
 de Hadoop es la localidad
de los datos. Es decir, una
vez distribuidos los
bloques de un fichero
Una característica
entre los diferentes nodos,
estos ya no se mueven. A
diferencia de lo que sucede
en la computación

C O NT I NU A R

Tal y como se ilustra de manera simplificada en la figura 3, lo que ocurre dentro de un clúster Hadoop cuando
se está llevando a cabo un proceso MapReduce es, de manera muy simplificada, lo siguiente:

En la primera fase, denominada map o mapeo, se aplica una función a cada bloque de un fichero
En la segunda fase, llamada reduce, un nodo (a veces varios) recoge los resultados de cada fase map y
los agrega, con lo que se obtiene así el resultado final deseado

C O NT I NU A R

Figura 3. Los resultados de aplicar la fase map a cada bloque son enviados al nodo, que
finalmente aplica la fase reduce y genera los resultados. 
Fuente: © Concepción Labra 2020.
 C O NT I NU A R

La gran ventaja de este sistema es que el procesamiento se hará en paralelo entre muchos nodos. Cuantos
más nodos tenga el clúster, más rápido terminará el trabajo.

 Por otro lado, hay que decir que el marco MapReduce tiene sus limitaciones. No permite resolver cualquier
problema computacional, pero, para aquellos procesos que se pueden resolver a base de operaciones map y
reduce, el resultado es que podemos distribuir el procesamiento entre todos los nodos con las ventajas que
hemos señalado.

C O NT I NU A R

3.2. Spark
Como ya hemos comentado, uno de los inconvenientes de Hadoop es que no es la opción más indicada para
procesar datos de manera rápida. Cuando necesitamos latencias bajas, Spark es una alternativa más
adecuada.

 Spark hace un uso intensivo de la memoria en lugar del disco duro. De esta manera, es capaz de procesar
los datos de manera mucho más rápida, entre 10 y 100 veces más rápido que Hadoop, dependiendo de una
serie de factores. Esto hace que Spark pueda acercarse al procesamiento en tiempo real y dar resultados en
cuestión de milisegundos o pocos segundos.
 Figura 4. Spark core y las librerías complementarias. 
Fuente: spark.apache.org

Otra ventaja adicional de Spark es su generalidad. Como puede verse en la figura 4, incluye estas librerías
complementarias:

Spark SQL: permite realizar consultas en un lenguaje similar al SQL de las bases
de datos tradicionales.

Spark streaming: permite trabajar con flujos de datos que van llegando de forma
continua.

MLlib: permite trabajar con algoritmos de aprendizaje automático.

GraphX: permite trabajar con información estructurada en forma de grafo.

C O NT I NU A R
Estas librerías dotan a Spark de la capacidad de trabajar con muchos tipos de tareas, ya sean consultas tipo
SQL, flujos de datos, algoritmos de aprendizaje automático, grafos, etc.

 Por estas razones, rapidez y flexibilidad, Spark ha desplazado a Hadoop en muchos escenarios. Hadoop,
sin embargo, sigue siendo una opción que considerar cuando necesitamos un sistema distribuido de
archivos, como HDFS o alguna de las herramientas que forman parte del ecosistema Hadoop.
Lección 4 de 14

IV. Velocidad. Spark streaming

Hay escenarios donde los datos van llegando en un flujo continuo. Por ejemplo, en una aplicación del internet
de las cosas es necesario procesar los eventos de los sensores según van llegando y, quizás, tomar
decisiones en tiempo real.

Otro ámbito donde puede ser crucial tomar decisiones rápidas es el de la ciberseguridad, en donde unas
décimas de segundo pueden suponer la diferencia entre conseguir o no parar un ataque.

C O NT I NU A R

En la siguiente tabla se muestran algunas diferencias entre el procesamiento en streaming y el

procesamiento en lotes o batch.

Lotes (batch) Flujos (streaming)

Los datos están

Los datos van llegando y se
Procedencia de los datos almacenados (en una base
procesan en el momento
de datos, en Hadoop, etc.)

Puede ser de minutos u En tiempo casi real (menos

Tiempo de procesamiento
horas de un segundo)
 Aplicaciones Métricas agregadas, Sistemas de decisión en
informes tiempo real

Internet de las cosas,

Almacenes de datos (data
Escenarios ciberseguridad, vehículos
warehouses)
autónomos, etc.

Tecnología característica Hadoop Spark Streaming

Tabla 1. Diferencias entre el procesamiento de lotes y el de flujos.

Fuente: © Concepción Labra 2020.

C O NT I NU A R

Existen diferentes tecnologías en el mercado que permiten trabajar con flujos de datos y procesarlos en
tiempo casi real. Una de ellas es Spark Streaming.

Spark Streaming es una librería

que forma parte de Spark. La idea
inicial de Spark Streaming es que
un flujo continuo de datos puede
Spark Streaming
ser troceado en micro-batches, es
decir: en pequeños lotes de datos
que pueden ser procesados de la
misma manera que en un
Lección 5 de 14

V. Variedad. NoSQL

Respecto a las tecnologías del mundo big data que permiten trabajar con una amplia variedad de datos,
podemos destacar Hadoop HDFS y las soluciones NoSQL.

HDFS
–
HDFS, el sistema distribuido de archivos de Hadoop, sirve para almacenar cualquier tipo de información,
sea estructurada o no. En HDFS, por ejemplo, puede almacenarse información tan variada como imágenes,
audio o ficheros en todo tipo de formatos, incluyendo texto plano no estructurado o bien formatos
semiestructurados como JSON, XML, CSV, etc.

NoSQL
–
En cuanto a las soluciones NoSQL, complementan a las tradicionales bases de datos, que se caracterizan
por contener información estructurada que es explotada mediante el lenguaje de consultas SQL. El término
NoSQL debe entenderse en el sentido de “no solo SQL”, ya que no se trata en absoluto de prescindir de las
bases de datos tradicionales, que en muchos casos pueden ser la opción más adecuada, sino de
complementar la oferta.
Del HDFS ya se ha hablado cuando se han introducido los fundamentos de Hadoop. En cuanto a las
soluciones NoSQL, se expondrá a continuación cuáles son sus características principales.

C O NT I NU A R

5.1. ¿Qué son las soluciones NoSQL?

Las bases de datos tradicionales son de tipo relacional. Esto quiere decir que la información debe
estructurarse desde un principio con arreglo a tablas que tendrán definidas una serie de columnas de
formato fijo. Es decir, para poder crear cada tabla se necesita conocer con antelación qué columnas o
campos tendrá, qué tipo de información contendrá cada campo, etc.

 Con toda esta información, se define el esquema de la tabla, un esquema que ya no

podrá ser modificado de manera sencilla en cuanto la tabla empiece a contener
datos. Debido a esta dificultad, no es de extrañar que en el mundo de las bases de
datos tradicionales se trabaje de forma muy rígida, definiendo a priori la estructura
de lo que se va a guardar y procurando hacer luego el menor número posible de
cambios.

Pero, en el mundo big data, la información con la que nos encontramos no tiene por qué ser siempre
estructurada, también puede ser semiestructurada o no estructurada.

 Las bases de datos NoSQL nos proporcionan un abanico que amplía las posibilidades de las bases de
datos tradicionales al permitir trabajar también con ese otro tipo de información no estructurada.

C O NT I NU A R
En la figura 5 pueden verse los principales tipos de soluciones NoSQL y algunas soluciones que se
corresponden con cada uno de los tipos existentes. Más adelante, se estudiarán con detenimiento estos
tipos y las tecnologías más características de cada tipo.

Figura 5. Principales tipos de soluciones NoSQL. 

Fuente: Jiuly Alexandra Rojas.

C O NT I NU A R
5.2. El teorema CA
El nombre del teorema CAP es un acrónimo que viene de consistencia (consistency), disponibilidad
(availability) y particionado (partition).

 Se trata de un teorema importante en el mundo big data porque proporciona un criterio para decidir si una
solución NoSQL es adecuada o no para un determinado escenario. Además de esta razón práctica, otra
razón para estudiarlo aquí es que plantea un dilema que es interesante, ya que todo sistema distribuido tiene
que afrontarlo en su diseño.

C O NT I NU A R

El teorema CAP dice que, en un sistema de cómputo, es imposible garantizar simultáneamente las
siguientes tres propiedades:

1 Consistencia: cada lectura o petición de datos debe recibir la escritura más reciente o un error.

2 Disponibilidad: cada lectura o petición de datos debe recibir una respuesta que no sea un error,
aunque sin la garantía de que esa respuesta corresponda a la escritura más reciente.

3 Tolerancia al particionado: el sistema debe continuar funcionando a pesar de la pérdida de

mensajes entre nodos (debido, por ejemplo, a un fallo de la red).

C O NT I NU A R
  El interés del teorema CAP es que permite acotar qué bases de datos NoSQL son más
adecuadas para nuestras necesidades.

Las soluciones del mundo big data están diseñadas, por definición, para ser tolerantes a un particionado de
la red. Es decir, en caso de que haya un fallo en la red, el sistema tiene que estar preparado para seguir
funcionando con unas ciertas garantías. Debe estar diseñado también para que, en cuanto se restaure la
comunicación entre los nodos, pueda recuperarse rápidamente del problema y volver a funcionar con
normalidad.

Las soluciones de procesamiento distribuido, por su naturaleza, deben ser tolerantes al particionado de red,
ya que este, probablemente, se acabe produciendo antes o después. Eso quiere decir que habrá que escoger
entre garantizar por diseño o bien la consistencia o bien la disponibilidad.

C O NT I NU A R

Si no se garantiza la consistencia, esto implica que los datos repartidos a lo largo de todos los nodos pueden
no estar sincronizados. Diferentes usuarios podrían llegar a ver diferentes versiones de un dato. 

Si no se garantiza la disponibilidad, esto significa que, en caso de particionado debido a un fallo en la red, el
sistema podría quedarse sin responder para evitar así dar una respuesta que no sea consistente.

C O NT I NU A R

En rigor lo que dice el teorema CAP es que no puede haber al mismo tiempo una disponibilidad y una
consistencia perfectas en aquellos raros momentos en donde hay un particionado del sistema. Obviamente,
una vez que ese fallo de red se solucione, el sistema debería recuperar la consistencia. 

La respuesta es que depende

del caso de uso. Si la
información es crítica, por
Por tanto, la pregunta es: ¿qué se
ejemplo, en el caso de un
debe priorizar: consistencia o
disponibilidad? banco, habría que priorizar la
consistencia. En el caso de
una red social, en cambio, la
consistencia de los datos no

1 of 2

En la figura 6 se puede ver

dónde se sitúan algunos de
La segunda pregunta es: ¿qué los productos NoSQL más
solución NoSQL se debe populares en función de que
escoger? se haya priorizado en su
diseño consistencia o
disponibilidad.

2 of 2
 C O NT I NU A R

Figura 6. Cada solución NoSQL prioriza consistencia o disponibilidad.

Fuente: Kaivalya Apte.

A la izquierda, en la zona etiquetada como CA, están las bases de datos tradicionales.
Están pensadas para garantizar consistencia y disponibilidad, pero no tolerancia al
particionado, ya que no están diseñadas para trabajar de forma distribuida. 

Abajo, con la etiqueta AP, están las bases de datos NoSQL, que se deberán escoger cuando
se priorice la disponibilidad. En este caso, Cassandra, CouchDB, DynamoDB o Riak serían
buenas opciones. 

Y, por último, a la derecha, en el lado CP, están las bases de datos que hay que escoger
cuando se prioriza la consistencia. Aquí se sitúan soluciones como HBase, Redis o
MongoDB.
Así pues, el teorema CAP ayuda a decidir qué grupo de soluciones NoSQL son más convenientes para cubrir
las necesidades de un determinado escenario o de una determinada aplicación.
Lección 6 de 14

VI. Arquitectura de referencia

Al hablar de las características diferenciales del lago de datos, se comentó acerca de la autonomía que
proporciona al analista de datos. Se comentó también que el papel del departamento de IT cambia
sustancialmente como consecuencia de ello.

Algunas de las funciones de IT que pasan a tener mucho peso en este nuevo escenario son
aquellas que tiene que ver con diseñar, construir y mantener el lago de datos que servirá como
plataforma alrededor de la cual se articulará una buena parte de la actividad de la empresa.

Es, por tanto, esencial que la organización cuente con una buena arquitectura de referencia
que permita no solo dar soporte a las iniciativas analíticas, sino también tener un vocabulario
común en el cual basarse a la hora de discutir y desarrollar proyectos, aplicaciones, casos, etc.

Las arquitecturas de referencia se pueden definir utilizando diferentes niveles de abstracción.

Pueden estar definidas al nivel de las tecnologías concretas o bien a un nivel mucho más
abstracto.  A continuación, se partirá de una arquitectura de referencia abstracta a nivel
funcional. Luego se verá cómo esta podría implementarse con algunas tecnologías
específicas como las que se estudiarán en los diferentes módulos.

C O NT I NU A R

Pero, más allá de esta imagen, ¿cómo es realmente un lago de datos? Teniendo en cuenta
las funciones que tiene que soportar la arquitectura, se podría empezar con el diseño
preliminar que se muestra en la figura 8., que está compuesto por los siguientes bloques:

El hardware físico formado por los nodos que componen el clúster.

Sobre esta capa de hardware, está el software Hadoop, que se encarga de la

coordinación del trabajo de los diferentes nodos.

Y, por encima, tenemos aquellas capas que deben encargarse de llevar a cabo las
diferentes funciones.

Figura 7. La metáfora del lago de datos: las diferentes fuentes como afluentes que vierten
información al lago y los analistas como pescadores que sacan información.
Fuente: EMC.
 Figura 8. Un primer esquema de partida para el diseño de la arquitectura de una
plataforma big data. 
Fuente: ©Concepción Labra 2020.

Antes de desarrollar esta arquitectura, es necesario añadir varias capas para llevar a cabo
las siguientes funciones:

Ingesta de las fuentes de datos externas.

Almacenamiento en bruto de los datos ingeridos.

Procesamiento de los datos.

Gestión de flujos de trabajo.

Acceso o explotación de la información.  

C O NT I NU A R
Si se asigna un bloque para cada una de las funciones, se tendría una arquitectura funcional como la que se
muestra en la figura 9.

Figura 9. Arquitectura funcional de una plataforma big data. 

Fuente: elaboración propia.

C O NT I NU A R
 Figura 10. Arquitectura, al nivel de la tecnología, de una plataforma big data basada en el
ecosistema Hadoop que proporciona la distribución de Cloudera. 
Fuente: ©Concepción Labra 2020.

C O NT I NU A R

En esta figura, se ve una posible arquitectura basada en un ecosistema Hadoop, donde se han incorporado
las siguientes tecnologías:
Ingesta

Para la capa de ingesta, se utiliza Sqoop, un software que permite extraer información de bases de datos
estructuradas e incorporarlas al ecosistema Hadoop.

Procesamiento

Para la capa de procesamiento, se pueden utilizar tecnologías como Hive, que permite realizar consultas
en lenguaje SQL; Pig, que permite escribir rápidamente programas que trabajen con flujos de datos; y
Spark, que permite llevar a cabo procesamiento de datos de manera muy rápida.

Explotación

Esta capa debe incluir una gama de servicios que cubra las necesidades de explotación de la
empresa y proporcione acceso a la información a los diferentes usuarios, herramientas y
aplicaciones, a través de protocolos ODBC y JDBC, APIs, etc.

En el diseño de la figura 3.11. se utiliza HBase, una base de datos NoSQL que suele formar parte de
los entornos Hadoop. Si se utilizan algunas distribuciones, como la de Cloudera, por ejemplo,
también estará disponible Impala, que permitirá hacer consultas SQL interactivas.  
 Coordinación

Para la capa de coordinación de flujos el diseño mostrado en la figura 10. se puede usar el planificador
Oozie. Un planificador actúa como una especie de director de orquesta que determina cuándo se van a
lanzar los diferentes trabajos de procesamiento de datos que se van a llevar a cabo en la plataforma.

C O NT I NU A R

Las tecnologías mencionadas suelen ir incluidas en distribuciones como la de Cloudera, que empaquetan
los componentes básicos de Hadoop junto a muchas otras tecnologías que funcionan sobre ellos, como, por
ejemplo, Sqoop, Hive, Pig o HBase.

No se trata ahora de entender en detalle lo que hace cada una de estas tecnologías (esto es algo que se
abordará más adelante), sino de comprender cómo se debe pensar a la hora de plantear el diseño de una
arquitectura big data de referencia.

 Una vez que se hayan completado todos los módulos, el alumno debería ser capaz
de analizar cómo debe ser una solución completa capaz de dar respuesta a
diferentes necesidades que puedan plantearse.
Lección 7 de 14

VII. Arquitecturas batch y streaming

La arquitectura que se ha planteado en el apartado anterior se corresponde con una arquitectura para
procesamiento de tipo batch o por lotes, pero no siempre es así. A la hora de plantear una arquitectura, una
de las primeras cosas que hay que decidir es si la solución que se busca es para un escenario de
procesamiento de lotes o de flujos.

En la tabla 2 se resumen las características que permiten discernir entre uno y otro escenario:

  Lotes (batch) Flujos (streaming)

Datos Los cálculos se hacen con todos los Los cálculos se hacen con los datos
datos. de una ventana pequeña de tiempo. 

Ventajas Alcance completo. Resultados fiables.  Permite tomar decisiones en tiempo

real.

Desventajas Puede tardar minutos u horas, no sirve No se pueden tener en cuenta todos
para respuestas online. los datos, es más importante
responder rápido.

Aplicaciones Almacén de datos, informes, cuadros Ciberseguridad, IdC, vehículos

de mando. autónomos.

Tecnología Hadoop, Sqoop, Hive, Impala.  Spark, NoSQL, Flume. 

 Tabla 2. Características distintivas de las arquitecturas de lotes y flujos. 

Fuente: © Concepción Labra 2020.
 C O NT I NU A R

La arquitectura de referencia que se ha propuesto, basada en un ecosistema Hadoop, es adecuada

solamente para arquitecturas de lotes. Si se necesita una arquitectura de flujos que responda en tiempo real,
se necesitará buscar otra alternativa, basada, por ejemplo, en Spark Streaming.

 Spark está diseñado para hacer procesamiento rápido del orden de segundos o fracciones de segundo,
mientras que, por el contrario, Hadoop es lento: presenta latencias altas a la hora de responder, por lo que no
es aconsejable cuando es necesario dar respuestas en tiempo casi real.
Lección 8 de 14

VIII. Arquitecturas lambda y kappa

Como se ha visto, las arquitecturas de lotes tienen sus ventajas, y las de flujos, las suyas. La arquitectura
lambda es una arquitectura híbrida que trata de combinar lo mejor de ambos mundos. Busca, por un lado, la
rapidez de una arquitectura de flujos y, por el otro, la completitud que tenemos en el trabajo con lotes al poder
procesar todos los datos y no solo los que van llegando en una breve ventana de tiempo como sucede en las
soluciones de flujos.

En la figura 11 se muestra una arquitectura lambda que responde a este esquema híbrido. Se explican, a
continuación sus componentes y las funciones que estos realizan. 

1. Todos los datos ingeridos se envían tanto a la capa de batch como a la llamada

capa de tiempo real.

2. La capa de batch gestiona el conjunto de datos completo, calcula las vistas de

batch que contienen métricas calculadas sobre todos los datos y actualiza la
capa servidora periódicamente.

3. La capa servidora (serving layer) indexa las vistas batch para que puedan ser
consultadas con baja latencia por los usuarios.

4. La capa de tiempo real (speed layer) trata los últimos datos que van llegando,
calcula las vistas de tiempo real y completa la información que falta en la capa
servidora.  

5. Para responder a una consulta de un usuario, se mezcla la información de las

vistas batch de la capa servidora y la de las vistas de tiempo real.
 Figura 11. Componentes de una arquitectura lambda. 
Fuente: Marz y Warren, 2015.
 

C O NT I NU A R

El libro de Nathan Marz sobre arquitecturas lambda

A pesar de que su título no lo anuncie, el libro que se indica en la figura 12 está dedicado a analizar los
conceptos básicos de una arquitectura lambda y a explicar en detalle cómo crear una.  
Figura 12. Portada del libro Big data: principles and best practices of scalable realtime data
systems, donde se explica en detalle cómo diseñar una arquitectura lambda. 
Fuente: Marz y Warren, 2015.
 C O NT I NU A R

La arquitectura lambda trata de ofrecer lo mejor de una arquitectura batch y de una streaming, pero también
ha recibido una serie de críticas. Entre ellas, se señala que hay que mantener dos conjuntos de código, uno
para el procesamiento en batch y otro para el procesamiento en streaming, con la consiguiente dificultad de
que ambos estén siempre sincronizados y produzcan los mismos resultados. La complejidad derivada de
esta duplicación y las posibles inconsistencias que puedan surgir son dos inconvenientes a tener en
cuenta. 

A raíz de estas críticas, posteriormente surgieron otras propuestas alternativas como la arquitectura kappa
de Jay Kreps, que propone utilizar solo procesamiento en streaming, ya que, dice, el procesamiento en batch
se puede considerar una variante del procesamiento en streaming, donde simplemente se está utilizando
una ventana de datos más grande.
Lección 9 de 14

IX. Resumen

Repasa los conocimientos adquiridos en la unidad

En esta unidad, se ha profundizado en cómo las tecnologías big data permiten resolver los problemas
asociados a las tres uves.
Se ha visto que el problema del volumen, es decir de cómo procesar cantidades de información que
exceden con mucho la capacidad de una sola máquina, puede abordarse con una tecnología como
Hadoop, que pone a múltiples máquinas a trabajar en paralelo. Para ello, utiliza dos componentes
fundamentales, como son: HDFS para poder distribuir los ficheros de datos y MapReduce para poder
llevar el procesamiento de las tareas map y reduce allí donde están los datos.

Spark, que surgió para corregir parte de las carencias de Hadoop, resuelve, al igual que este, el problema
del procesamiento distribuido. Su éxito se debe a que lo hace además aportando numerosas ventajas
frente a Hadoop, entre las que destacan la rapidez y la versatilidad.

Spark permite, además, abordar también el problema de la velocidad o procesamiento online de flujos de
datos gracias a la librería Spark Streaming. Esta librería divide los datos entrantes en microlotes y, sobre
ellos, aplica las operaciones estándar de Spark. Aunque existen otras opciones para procesamiento en
tiempo casi real, la más popular es, probablemente, esta librería de Spark.
Para resolver el problema de la variedad de los datos, es decir, de la necesidad de trabajar con
información de formato y estructura muy variados, existe el amplio abanico de las soluciones NoSQL. Se
ha visto que hay múltiples opciones en el mercado y que, para escoger una, se deben resolver dos
cuestiones. Una hace referencia al tipo de información que se quiere almacenar (clave-valor, columnar,
documento o grafo). La otra tiene que ver con si necesitamos priorizar la consistencia de la información
o, por el contrario, la disponibilidad del sistema. Por el teorema CAP se sabe que, necesariamente, habrá
que escoger priorizar una u otra.

También se ha hablado de la arquitectura de las plataformas big data y se han hecho propuestas a nivel
funcional y tecnológico. Por último, se han introducido dos populares modalidades de arquitecturas
híbridas: la lambda, que trata de reunir lo mejor del mundo batch y del streaming; y la kappa, que surge
como alternativa para superar las carencias de la primera.
Lección 10 de 14

X. Caso práctico con solución

Aplica los conocimientos adquiridos en esta unidad

ENUNCIADO

Dados los siguientes casos, indicar cuál de estas arquitecturas sería la más adecuada:

1. Lotes

2. Flujos
 3. Lambda

DATOS

1. Una empresa desea ingerir los datos procedentes de sus sistemas operacionales, filtrarlos en
tiempo real para detectar ciertas acciones por parte del usuario y ofrecerle una recomendación
online.

2. Una empresa desea empezar a ingerir los datos procedentes de todos sus sistemas
informacionales en su nuevo lago de datos, con objeto de generar, de manera más rápida, los
informes diarios que se le presentan a dirección.

3. Una empresa desea ingerir los datos procedentes de la temperatura de un sensor y filtrarlos en
tiempo real para ver si se lanza una alarma cuando la temperatura sobrepase cierto umbral.

VER SOLUCIÓN
SOLUCIÓN

1. Lambda

2. Lotes

3. Flujos
Lección 11 de 14

XI. Lecturas recomendadas

Se recomienda la lectura del artículo donde Jay Kreps cuestiona la arquitectura lambda y hace una
propuesta alternativa, a la que llama arquitectura kappa:

Schmarzo, B. Big data: understanding how data powers big business. John Wiley & Sons; 2013.
Lección 12 de 14

XII. Enlaces de interés

Kreps, J. Questioning the lambda architecture. Online article, July, 205; 2014.

ABRIR ENLACE
Lección 13 de 14

XIII. Glosario

El glosario contiene términos destacados para la

comprensión de la unidad

Batch
–
Ver la definición en este glosario del término “lotes”. 

Nodo
–
Cada una de las máquinas que componen un clúster.

Clúster
–
Conjunto de ordenadores, o nodos, que trabajan de manera coordinada. Por lo general, llevan a cabo tareas
en paralelo, de manera que el tiempo de procesamiento final se reduce de manera proporcional al número
de nodos. 

Lotes (Batch)
–
Se denomina procesamiento por lotes (o procesamiento batch) a la ejecución de un programa que se lanza
de manera planificada, sin la supervisión directa de los usuarios. Otra característica del procesamiento por
lotes es que el programa accede a una serie de datos que han sido previamente almacenados, por ejemplo,
en una base de datos, por contraposición al procesamiento online, donde los datos se van procesando a
medida que llegan, o el procesamiento en streaming, donde los datos van llegando en un flujo continuo
ininterrumpido. Los tiempos habituales en el procesamiento por lotes son minutos o, incluso, horas;
mientras que en el procesamiento en streaming, son segundos o milisegundos.
Lección 14 de 14

XIV. Bibliografía

De Mauro, A.; Greco, M.; Grimaldi, M. A formal definition of big data based on its essential
features. Library Review; 2016.

Dean, J.; Ghemawat, S. MapReduce: simplified data processing on large clusters; 2004.

Kreps, J. “Questioning the lambda architecture”. Online article, July, 205; 2014. 

Marz, N.; Warren, J. Big data: principles and best practices of scalable realtime data systems.
Manning Publications Co.; 2015.

Schmarzo, B. Big data: understanding how data powers big business. John Wiley & Sons; 2013.

Turck, M. A turbulent year: the 2019 data & AI landscape; 2019. [En línea] Disponible en este
enlace.