ADQUISICIÓN DE DATOS

En esta ocasión nos vamos a centrar en los métodos para introducir los datos en nuestro sistema de análisis de Big Data.
Como sabemos, nuestros datos pueden provenir de fuentes muy diversas, desde sistemas de Internet, de herramientas tipo Twitter,
datos astrofísicos, o sea datos de naturalezas muy, muy diversas. Entonces, tenemos que hacer que todos estos datos tan diversos se
puedan integrar en nuestro sistema de almacenamiento, que es HDFS, es el sistema de almacenamiento básico de Hadoop, y tenemos
que utilizar distintas herramientas que, en función del origen de nuestros datos, nos permitan integrar estos datos, ya sea en modo
"batch", es decir procesamiento por lotes, o en modo "streaming", es decir, a medida que se van generando los datos en nuestro sistema
de almacenamiento para, posteriormente, poder ser procesados por nuestro sistema completo.
Vamos a presentar los principios básicos de la adquisición de datos para introducirlos en nuestro sistema de análisis de datos de Hadoop, análisis
de datos en Big Data.
Entonces, nosotros tenemos nuestro entorno que tiene un
hardware básico con un commodity hardware que está utilizando
y tenemos el sistema de archivos el gestor de recursos YARN y
el modelo de programación MapReduce para realizar el análisis
de estos datos.
Y nos van a ir llegando datos de distintas fuentes. Podemos tener
que analizar desde twitts, generados desde Twitter, podemos
estar analizando documentos de texto, podemos estar
analizando el contenido de páginas web, podemos estar
analizando contenido de video, es decir que tenemos muchos
tipos de información diferente que vamos a tener que gestionar.
Entonces tendremos que, esta información que estamos recibiendo, poder llegarla a introducir en nuestro sistema de ficheros. Ahí vamos a realizar
un primero paso que es lo que denominamos la adquisición de datos o en inglés el Data Ingestion, lo que es la ingestión y asimilación de datos
para ir recogiendo estos datos de forma apropiada. Y después realizar un proceso de transporte y colocación de estos datos, Data Collector, para
poder introducir finalmente nuestros datos en nuestro sistema de archivos HDFS, a partir de ahí ya empezar el proceso de anál isis propiamente
de estos datos una vez que los tengamos. colocados en nuestro sistema de ficheros.

Entonces, lo que hace referencia a lo que es esta adquisición de

datos podemos realizarla de dos modos fundamentales.

El modo clásico es el que se denominaba un proceso por lotes

o en modo batch, es decir que nos van llegando los datos y una
vez que tenemos todo un bloque de datos, se procesa ese bloque
de datos, ese lote y se va recibiendo el siguiente lote de datos,
se procesa y así sucesivamente. Es decir que se van analizando
grandes cantidades de datos que ya nos han ido llegando.

O la siguiente posibilidad que se nos ha aparecido más

recientemente es la posibilidad de ir realizando un análisis de los
datos en streaming, es decir, ir realizando en modo continuo en
tiempo real podríamos decir que va llegando un dato, se procesa,
llega otro dato, se procesa, llega otro dato, se procesa, y así
vamos procesando los datos en un tiempo real.

Digamos que el paradigma MapReduce se ajusta muy bien al

procesamiento por lotes. El procesamiento Batch, ya que
nosotros tenemos todo un conjunto de datos, grande amplio
conjunto de datos, entonces diseñamos nuestros procesos
Mappers.

Estos procesos Mappers se vieron en el paradigma MapReduce

y vamos a realizar una división, una partición de estos bloques,
de los lotes para ir realizando un procesamiento de cada uno de
estos bloques en cada uno de los procesos Mappers.
 De modo que así se pueden analizar los distintos bloques en
paralelo y cuando tengamos el siguiente lote, podremos procesar
el siguiente lote y así de forma continua vamos trabajando con
los distintos Batch con los distintos lotes de datos que nos vayan
apareciendo.
Pero como comentábamos recientemente se ha puesto muy de
moda el tratamiento de datos en streaming, como veremos más
adelante.

Entonces cuando nosotros vamos a realizar este procesamiento

de datos, podríamos hablar de que podemos trabajar a distintos
niveles, podemos procesar en lo que se denominan unos
grandes lotes Macro Batch, macro lotes, que podrían llevarnos
más de 15 minutos de procesamiento y de gestión de estos
datos.
También podríamos tener lo que se denominan micro lotes, Micro
Batch. En este modo de operación, nosotros estaríamos tratando
datos entre 2 y 15 minutos, o sea, sería un batch correspondiente
a un periodo más corto, pero significativamente largo, de todos
modos.

Después ya nos acercamos a lo que es el procesamiento en tiempo real y podríamos dividirlo en tres niveles diferentes.
Un primer nivel sería un Near Real-Time Decision Support, es decir un soporte a la decisión casi en tiempo real que ya estaríamos hablando en
una toma de decisiones que estaría rondando pues entre algunos segundos y 2 minutos, es decir, estamos dando una respuesta al sistema en
menos de 2 minutos.
Más rápido tendríamos lo que sería un procesamiento de eventos, un Near Real Time Event Processing, que ya estaríamos hablando de una
escala de tiempo entre 100 milisegundos y 2 segundos. Estamos procesando los eventos, muchos eventos en un tiempo muy corto para dar una
respuesta muy rápida.
Y por último ya tendríamos lo que sería el Real Time que podríamos decir que estamos trabajando en una escala inferior a los 100 milisegundos,
es decir, que estamos procesando bloques de datos a una velocidad muy alta y de esta manera, pues necesitamos darle una respuesta muy rápida
al usuario para que pueda actuar de la forma adecuada.

Entonces cuando tenemos todo este proceso de adquisición de

datos para su colocación en el sistema de archivos, deberemos
realizar toda una serie de consideraciones para que este proceso
sea correcto.

En primer lugar, podemos estar recolectando información que

procede de distintas fuentes y en distintos formatos, en distintos
tipos de datos y tendremos que realizar una extracción de los
datos propiamente de la información que vamos recibiendo.
Debemos filtrar esa información para encontrar los datos que son
relevantes para el usuario en ese momento. Y además debemos
realizar un proceso que nos permita validar esos datos, es decir,
ver la fiabilidad de esos datos, analizar si son datos correctos, si
su procesamiento va a ser de interés para el usuario, y en caso
contrario, descartarlos para no estar proporcionando resultados
erróneos. Y además tenemos que integrar todos los datos que
vamos recogiendo en nuestro sistema de archivos para su
posterior procesamiento y poder realizar el análisis apropiado de
estos datos.

Por tanto, tenemos que tener en cuenta que para realizar estas
operaciones vamos a tener que afrontar una serie de desafíos.

El primer desafío tenemos la enorme cantidad de fuentes de

datos de las que podemos disponer actualmente y además la
cantidad de estas fuentes de datos está en constante
crecimiento, cada día estamos disponiendo de más sensores, de
más herramientas que nos permiten recoger información que
proviene de más fuentes, es decir, que cada vez tenemos más
datos con los que tenemos que poder trabajar.

Y estos datos van a venir en distintos formatos, y se estarán generando cada día a mayor velocidad, con lo cual, tenemos que procesar todos
estos datos de la forma más adecuada y más rápida posible para poder introducirlos rápidamente en nuestro sistema de ficheros. Además, tenemos
que las propias fuentes están en constante evolución, es decir, cada día tenemos elementos más precisos que nos proporcionan mayor información
y, posiblemente, información en un formato diferente. Entonces los datos que se están generando hoy son distintos de los datos que se van a
generar mañana en algunos aspectos. Por ejemplo, en datos médicos, cada vez tenemos más sensores, más marcadores que permiten introducir
nuevos datos sobre la información que se está generando de cada paciente entonces, se tienen que ir adaptando los datos que se van manejando
de los distintos pacientes en este caso en función de la información que se puede proporcionar en cada momento, es decir que los datos
evolucionan dinámicamente.
Además también hay cambios en el mismo formato y en la semántica de los datos, se van introduciendo mayor exactitud, mayor precisión, distintos
modos de explicar las cosas, es decir que los datos en sí también cambian, y además debemos hacer que las aplicaciones hasta cierto punto sean
capaces de trabajar con todos estos datos cambiantes y todos estos formatos cambiantes para seguir siendo útiles, de modo que se tengan que
adaptar a la evolución de los datos y para seguir siendo útiles para los usuarios.

Entonces tendremos que para obtener un sistema que sea

realmente eficiente tendremos que ser capaces de gestionar
nuevos tipos de datos con nuevas tecnologías y que cada vez
puedan ser gestionados con nuevas aplicaciones también, es
decir que tendremos que ir en nuestro proceso de adquisición de
datos generando los datos adecuados para gestionar esta
diversidad cambiante.
Además, tendremos que ser capaces de comprobar lo que
decíamos de la validez de los datos, la consistencia de los datos,
eliminar los errores y proporcionar unos datos que tengan un
valor real para el usuario de modo que tengamos que
asegurarnos de que el procesamiento va a ser adecuado y los
datos tienen un cierto sentido.
Asimismo como ya hemos visto es importante poderlos integrar todos estos datos de una forma rápida para que pasen rápidamente a nuestro
sistema de archivos a partir de ahí ya se pueda realizar todo el procesamiento necesario y además tenemos que permitir que la cantidad de datos
pueda escalar tanto como queramos, es decir que cada vez estamos procesando, produciendo más datos pues nuestro sistema de adquisición
debe tener que ser capaz de gestionar todo este volumen de datos y generarlo a veces, evento a evento, digamos, dato a dato, en datos agregados
en nuestro sistema de archivos para tener todos los datos que puedan ser procesados y filtrados.
Entonces como comentamos en algunas ocasiones para no tener que almacenar todos los datos concretos que se nos van generando, a veces lo
que se hace es que en el mismo proceso de adquisición realizar un proceso de agregación de datos, de modo que se reduzca el volumen de los
datos almacenados finalmente en el sistema de ficheros en función de las características de los datos que nos vayan llegando.

Entonces aparte de esto tendremos que tener en cuenta una

serie de consideraciones sobre lo que son las características del
sistema de adquisición de datos y que pueden imponer algunas
restricciones.
Por un lado, tendremos el ancho de banda de la red, lo que se
denomina el Bandwidth del Network, Network Bandwidth, que
nos va a limitar la capacidad de datos que podemos mover en la
red de forma simultánea, de forma que tenemos que ser
conscientes de que cuando vayamos a adquirir datos para
inyectarlos en nuestro sistema de archivos la red de
comunicación nos puede introducir unas ciertas limitaciones que
debemos tomar en consideración.
Después también tenemos que tener en cuenta que a menudo se pueden producir fallos en la red, puede haber algunos problemas de transmisión,
de modo que de algún modo tenemos que garantizar una cierta tolerancia a fallos y que el sistema de adquisición sea capaz de evitar o minimizar
el efecto de estos fallos que se produzcan, estos errores en la transmisión, etcétera. Además tenemos que tener en cuenta como siempre que
estamos trabajando con sistemas y tecnologías heterogéneas, con distintos procesadores, con distintos sistemas de cómputo, distintas interfaces
de red, con lo cual la adquisición tiene que tener en cuenta todos estos factores y también tenemos que nos aparecen datos con distintos formatos
que al final tendremos que intentar integrar en un mismo sistema de ficheros provocando el hecho de que en algún momento se tenga que realizar
alguna conversión del formato de los datos para poder integrarlos en un sistema de ficheros que después sean procesados todos del mismo modo
facilitando así el procesamiento de los propios datos.
Así pues, tenemos que para realizar la adquisición de datos tenemos que tener en cuenta todos estos parámetros y algunas herramientas que nos
van a permitir realizar esta adquisición e integración de datos en nuestro sistema de ficheros de Hadoop HDFS y a partir de las cuales pues ya se
podrá realizar el procesamiento de todos estos datos son las siguientes.

Vamos a explicar la herramienta Apache Flume. Nosotros ya

conocemos el ecosistema de Hadoop con los distintos niveles,
con los distintos "layers" y, también, hemos visto en ocasiones
anteriores el proceso de adquisición de datos para su integración
en el entorno de Hadoop.

Ahora nos vamos a centrar en una herramienta específica para

la adquisición de datos que es la herramienta Apache Flume.
Apache Flume es una herramienta que es robusta, simple,
estándar, configurable, flexible, distribuida, fiable, extensible y
tolerante a fallos para la adquisición de datos, lo que
denominamos también "Data Ingestion" y provenientes estos
datos de distintos productores y "webservers" y su integración en
el sistema de Hadoop. Como hemos comentado, es una
herramienta que está bien establecida, que es fiable y ofrece
muchas utilidades al usuario para la integración de datos en
Hadoop.
Tenemos un conjunto de aplicaciones que nos van a ir
produciendo una serie de eventos y una serie de ficheros de "log"
con distintos tipos de información como puede ser, por ejemplo,
Facebook, Twitter, servidores web, servidores en el "cloud",
etcétera, y vamos a ir tomando estos eventos y estos datos para
procesarlos mediante Flume y, así poder integrarlos en el
sistema de almacenamiento centralizado que estemos utilizando
en nuestro entorno Hadoop, ya sea HDFS o también integrarlos,
directamente, en una base de datos como HBase.

Entonces, Flume en este entorno gestiona la toma de datos y su

integración en el entorno Hadoop de una manera fiable y
acoplando las velocidades de los distintos entornos, es decir, los
productores van a ir produciendo datos a su propia velocidad y,
en cambio, estos datos se podrán integrar en el sistema de
almacenamiento a una cierta velocidad dependiendo del
rendimiento del sistema de almacenamiento.

Entonces, Flume aparece ahí en medio para garantizar un flujo

estable y que los datos que se vayan produciendo no se pierdan
y se puedan ir integrando en nuestro sistema de almacenamiento
de una forma segura y fiable.

Lo que aparece en Flume es que se definen un conjunto de

agentes que van a ir recogiendo los eventos procedentes de las
distintas aplicaciones y, después, tendremos un proceso
recolector, un "data collector" que va a ir tomando los datos que
van recogiendo los distintos agentes para transferirlos,
finalmente, a lo que es ya el sistema de almacenamiento
centralizado, ya sea HDFS o HBase.

Entonces, estos eventos, cada uno de estos eventos que van

generando la aplicación van a tener dos partes
fundamentalmente, primero, un encabezado o "header" y,
después, lo que sería ya propiamente la información
correspondiente al evento en sí, al dato integrado, al dato que se
quiera integrar en nuestro sistema de almacenamiento.

Si nos fijamos un poco en cómo es cada uno de estos agentes,

podremos ver que cada agente es un "daemon" independiente
escrito en Java y dispone de un primer proceso "source" que va
a ir recogiendo los eventos que le van llegando, después tiene
un "channel", o canal, que va a ir gestionando la llegada de estos
eventos provenientes de nuestro fichero de nuestra aplicación,
que han pasado por el "source" o fuente y, finalmente, un proceso
"sink", o podríamos traducirlo por "sumidero", que irá recogiendo
los datos que han pasado por el canal.
 Es posible que nosotros tengamos múltiples canales para
gestionar los datos, es decir, si van llegando muchos datos y
procesarlos es más lento, podemos utilizar más de un canal para
procesarlo. Y estos canales se pueden utilizar en dos modos
diferentes, un modo que sería lo que se denomina en un modo
de réplica, es de "replicación", es decir, que los datos que van
llegando se procesan simultáneamente por varios canales, se
replica el procesamiento de los distintos datos.
En cambio, hay otra opción que es lo que se denomina una
"multiplexación", es decir, que los datos que llegan a la fuente o
"source" se procesan por un canal o por otro, en función del
estado de la ocupación de los distintos canales.

Y, de esta manera, se pueden procesar los datos de una forma más rápida y así, garantizar el flujo estable que se quiere garantizar hacia nuestro
sistema de almacenamiento en función del procedimiento que se vaya utilizando.
Este proceso en el que nosotros tenemos varios canales que están procesando los datos del "source" o fuente, es lo que denominamos que se
produce un "fan-out", es decir, una distribución de los datos.

También es posible que tengamos distintas fuentes asociadas a

un único canal, en este caso, lo que se denomina es que tenemos
un "fan-in", es decir, distintas fuentes nos están sirviendo a un
único canal que, después, va a comunicarse con el sumidero, y
éste va a ser el que va a transferir los datos al sistema de
almacenamiento en el formato correcto.
Este es, esquemáticamente, el funcionamiento de Flume.

Como ya sabemos, tenemos nuestro entorno, el ecosistema de Hadoop, y necesitamos importar los datos, integrar datos dentro de lo que es el
sistema de almacenamiento.

Actualmente, tenemos muchos datos que están almacenados en

bases de datos relacionales clásicas, de las de toda la vida.
Estas bases de datos relacionales son gestionadas por lo que se
denomina un "DB RMS" que es un gestor de bases de datos
relacionales.
Todas estas bases de datos incluyen muchos datos que son muy
interesantes, pero que están en un formato que no es el formato
que necesita el sistema de almacenamiento de Hadoop y hay que
hacer algún proceso para integrar esta gran cantidad de datos en
los entornos "Big Data", como es el caso de Hadoop. Entonces,
se define una herramienta que se denomina Sqoop, que sería
algo así como "SQL to Hadoop" o "Hadoop to SQL", que nos va
a permitir llevar datos desde las bases de datos relacionales al
entorno de Hadoop y exportar datos que estén en Hadoop a
bases de datos relacionales.

Esto va a requerir un proceso de importación que nos va a llevar

los datos de las bases de datos hasta nuestros entornos de
almacenamiento, ya sea "HDFS" o "HBASE" y ofrecer, también,
un proceso de exportación para los datos que tengamos en
nuestros entornos Hadoop, poderlos devolver a entornos de
bases de datos relacionales para su proceso mediante otras
herramientas. Aquí podemos estar pensando en bases de datos
tipo Mysql, Oracle, etcétera, las bases de datos habituales que
están siendo utilizadas en sistemas normales, tradicionales. Ahí
vamos a tener dos procesos, un proceso para importar, en el cual
nosotros tenemos nuestra base de datos relacional

y vamos a tener que Sqoop va a hacer una petición para pedirle

a esa base de datos relacional que le dé la información referente
al formato de los datos, y le vamos a pedir los metadatos en el
que nos diga cómo están almacenados los datos dentro de esas
bases de datos y cómo es cada una de las filas, de las tablas que
están formando esas bases de datos relacionales. Una vez que
Sqoop obtiene esta información de la base de datos relacional,
va a hacer una petición para empezar a hacer el proceso de
transferencia de esa base de datos relacional al sistema de
almacenamiento de Hadoop. En concreto, se va a hacer una
aplicación de un "Map-Only Job", es decir, se va a pedir unas
operaciones de "Map".

Recordemos el paradigma "MapReduce" que es el paradigma básico de Big Data de Hadoop, pues en este caso se va a hacer unas tareas sólo
de "Map-Only", es decir, que se van a ir tomando las filas de las distintas tablas, por los distintos procesos Map que se van a ir generando y cada
una de esas filas de las tablas van a ser transformadas en ficheros de nuestro sistema de almacenamiento HDFS, por ejemplo, de Hadoop. De
esta manera, se van procesando cada una de las tablas de la base de datos, fila a fila, de una manera paralela, de modo que l a transferencia
desde una base de datos relacional a Hadoop va a ser relativamente rápida. Este proceso lo realizan los distintos procesos Map, los "Map Jobs"
en este caso, y vamos a generar los ficheros para su posterior procesamiento con las herramientas de análisis que dispongamos en nuestro
sistema.
En el sentido contrario, también podemos tener el caso en que
tengamos unos ficheros en nuestro sistema Hadoop y deseemos
devolver estos ficheros hacia lo que es el sistema de bases de
datos relacional. En este caso, tendremos que realizar la
operación de una forma muy parecida, vamos a tener que, en
primer lugar, Sqoop va a tener que pedir a la base de datos
relacional, toda la información referente a los metadatos y al
formato de las distintas tablas que estén almacenadas en esta
base de datos y, una vez que ya ha obtenido la información
referente a los datos que van a almacenarse en esa base de
datos, vamos a generar los procesos Map que van a ir tomando
los distintos ficheros que se encuentren en nuestro sistema de
almacenamiento de Big Data, y van a realizar el proceso para
transformar estos ficheros en filas de las tablas de la base de
datos, de modo que se van a ir integrando en la base de datos
estas filas obtenidas a partir de los ficheros que tenemos en
nuestro sistema de almacenamiento en Hadoop, en Big Data, ya
sea HDFS o HBASE, etcétera.
Esto es, fundamentalmente, el modo de operación de la herramienta Sqoop. En otra ocasión posterior, analizaremos su funcionamiento sobre
unos ejemplos y veremos cómo funciona concretamente la transformación de los datos.

En este caso se trata de la herramienta "Apache Kafka". Esta es

una herramienta que originalmente fue desarrollada en Linkedin,
pero después se integró, ya como un proyecto dentro del
proyecto Apache. En concreto, se denomina "Apache Kafka" y es
una herramienta para realizar un sistema de mensajes, es lo que
se llama un "messaging system".
Nosotros tenemos que, cuando hablamos de mensajes,
generalmente tendremos un emisor, un "sender", y un receptor o
"receiver".

Entonces, normalmente, entre un emisor y un receptor se

establece una vía de comunicación a través de lo que es una
cola, un sistema de colas y se ofrece una cola de mensajes, de
manera que los mensajes van pasando por una cola, hasta que
van llegando al receptor. Así, el "sender", el emisor, emite un
mensaje, este mensaje se inserta en una cola y el receptor va
tomando los mensajes de esta cola, a medida que van estando
disponibles y a medida que va pudiendo procesarlos. De esta
manera, tenemos una comunicación entre emisor y receptor,
punto a punto. Pero también es, en muchos casos, más que una
comunicación, un sistema de mensajes punto a punto, se utilizan
sistemas que se denominan "pub-sub", que es de Publish-
Subscribe, que sería un sistema en el que no se basa tanto en
una comunicación punto a punto, sino que alguien publica un
mensaje y todos aquellos receptores que estén suscritos pueden
ver ese mensaje y pueden tomarlo.
En este caso, tenemos también el mismo caso que antes, un emisor, una cola y un receptor donde podríamos mandar mensajes, pero en general,
lo que tenemos es, no sólo un receptor, sino que disponemos de varios receptores que se han suscrito para ir recibiendo los mensajes que vaya
enviando este emisor. De modo que el emisor envía un mensaje inicial a la cola y después los mensajes que estén en esta cola pueden ser
recogidos por los distintos receptores que se hayan suscrito a este sistema, es decir, que tenemos un sistema que va de un em isor a múltiples
receptores.
En este caso concreto, tenemos que Kafka es una herramienta
para gestionar este tipo de sistemas de comunicación "pub-sub"
de Publish-Subscribe. Entonces tenemos que, tenemos distintos
productores que van a ir generando información relacionada con
distintos temas y se van a ir recogiendo los distintos mensajes,
en función de los temas que traten o al tipo de información que
contengan y se van a organizar por un concepto, que es el
concepto de tópicos. Es decir, vamos a tener un conjunto de
mensajes relacionados con un tópico en concreto. Entonces, los
distintos productores van a ir produciendo mensajes de distintos
tópicos, pero, en particular, producen de uno de estos tópicos y
estos mensajes de un mismo tópico, se particionan en lo que se
denomina "partitions", particiones y se van a ir guardando en
distintas particiones.
Ahí tenemos organizados los mensajes que han ido llegando por orden temporal, en las distintas particiones referentes a este tópico. A
continuación, tenemos unos procesos que denominaremos "brokers", que cada uno de estos brokers va a tomar los mensajes que han ido llegando
a cada una de las particiones y tendremos generalmente un broker asociado a cada una de estas particiones, que va a tomar los datos que van
llegando a esa partición y los van a ir procesando, como veremos a continuación. Muy posiblemente, se gestione que cada uno de los brokers
gestione una réplica para tener un "backup" de la partición, para que en caso de que se produzca algún problema, se puedan re cuperar los
mensajes y no se pierdan aquellos mensajes que ya han sido recogidos. Entonces, estos mensajes referentes a una partición en concreto, llegan
al broker correspondiente, que el broker lo que va a hacer va a ser, va a ver qué consumidores están registrados y les va a mandar los mensajes
correspondientes, que le han ido llegando. De modo que así, el broker gestiona una parte de los mensajes referentes a este tópico y los distintos
brokers irán llegando e irán mandando los mensajes de las distintas particiones al consumidor que esté registrado. En el caso habitual, tendremos
un broker por cada una de las particiones. Si tenemos más brokers que particiones, va a haber brokers que no van a recibir da tos de ninguna
partición. Y si tenemos más particiones que brokers, eso suele dar problemas, ya que entonces un broker tiene que gestionar más de una partición
y eso va a propiciar que se genere un cierto desbalanceo, con lo cual el procesamiento de los mensajes puede ser menos eficiente. El caso más
habitual, es que tengamos un broker para cada una de las particiones y se vayan procesando, de una manera balanceada los distintos mensajes
que van llegando a cada una de las particiones.

En otro caso, podemos tener también que no sea un único el

consumidor que está suscrito, sino que tenemos varios
consumidores suscritos a un mismo tópico. Entonces, cuando
tenemos varios consumidores suscritos a un mismo tópico, lo que
vamos a hacer va a ser que, los distintos brokers van a ir
mandando los mensajes de forma directa, cada "broker" a un
consumidor diferente. De este modo, los consumidores forman lo
que se llama un "consumer group", es decir, un grupo de
consumidores que en conjunto van a procesar o van a recibir
todos los mensajes referentes a ese tópico de las distintas
particiones, pero no todos los consumidores van a recibir todos
los mensajes, sino que cada uno de los consumidores va a recibir
los mensajes correspondientes a una partición.

De modo que, en general están todos, pero se pueden procesar de una forma más rápida y más eficiente que cuando tenemos un ún ico
consumidor. Esta es fundamentalmente la idea de Kafka, como sistema para gestionar los mensajes y enviarlos a los consumidores. Y en una
ocasión posterior veremos cómo procesamos, algún ejemplo, cómo se realiza la operación con Kafka para gestionar estos mensajes provenientes
de distintas aplicaciones.