Sei sulla pagina 1di 11

Stream Processing Frameworks

Apache Flume

GRUPO 7
Integrantes:
● Nestor Calcina Huaranga
● Weimar Ccapatinta Huamaní
● Angel Flores Leon

1. Descripción del Framework

Flume es un servicio distribuido, confiable y disponible para recolectar, agregar y mover de


manera eficiente grandes cantidades de datos de registro incluyendo datos generados por
las redes sociales, tráfico de red, mensajes de correo electrónico y casi cualquier fuente de
datos configurable.

Tiene una arquitectura simple y flexible basada en flujos de datos de transmisión. Es


robusto y tolerante a fallas con mecanismos de confiabilidad ajustables y muchos
mecanismos de recuperación y recuperación de fallas. Utiliza un modelo de datos extensible
simple que permite la aplicación analítica en línea.

Flume es lo suficientemente flexible como para escribir en otros sistemas, como HBase o
Solr.
2. Principales características
● Perfectamente integrado en el ecosistema Hadoop, ejemplo de ello es la

integración de Sink HDFS o HBase en Keberos.

● Especializado en datos de logs.

● Permite la recolección y agregación de logs de forma sencilla.

● Pensado para eventos simples, no para eventos complejos.

● Robusto y tolerante a fallos, con mecanismos de fiabilidad configurables y de

conmutación por error y recuperación.

● Permite la lectura y escritura de multitud de fuentes de datos.

● Simplifica el filtrado y transformación de datos gracias a los interceptores.

● Dificultad de escalado horizontal, el añadir consumidores implica cambiar la

topología del pipeline e añadir un nuevo destino.

● Soporta canales efímeros basados en memoria y canales duraderos basados en

ficheros, por lo que no trabaja eficientemente para mensajes de larga duración

puesto que los tiene que recuperar del agente.

● Los canales basados en ficheros no replican datos, por lo que están sujetos a

errores de disco, para solventarlo se suelen replicar con RAIZ o SAN.

3. Arquitectura
A continuación resumimos las conceptos de Flume.

● Evento: una carga de bytes, con encabezados opcionales, que representan la


unidad de datos que Flume puede transportar desde el origen hasta el destino.
● Flujo de datos: es el movimiento de eventos desde el origen al destino.
● Cliente: es la implementación de una interfaz que recoge los eventos y se los
entrega a un agente de Flume. Suele operar en el espacio de proceso de la
aplicación de la que se están consumiendo los datos.
● Agente: es un proceso independiente que aloja otros componentes como sources,
sinks o channels. Se encarga de recibir, guardar y enviar eventos.
○ Source: es la implementación de una interfaz que puede consumir eventos
que le son envíados con un mecanismo específico. Por ejemplo la interfaz de
Avro es un implementación que permite recibir eventos Avro desde clientes u
otros agentes y ponerlos en un canal.
○ Channel: es un almacén transitorio de eventos, estos eventos son
entregados al canal a través de las fuentes que operan en el agente.
○ Sink: es la implementación de una interfaz que permite eliminar eventos de
un canal y transmitirlos al siguiente agente en el flow o a su destino final.
Estos últimos son conocidos como terminal sink. Por ejemplo, HDFS.

4. Flujo de trabajo

Para usar Flume, necesitamos ejecutar un agente Flume, que es un demonio Java que
ejecuta fuentes y receptores (sink) conectados por canales. Una fuente en Flume genera
eventos y los entrega al canal, que almacena los eventos hasta que se envían al receptor.
Se puede pensar en la combinación fuente-canal-receptor como un componente básico de
Flume.

Una instalación Flume está formada por una colección de agentes conectados que se
ejecutan en una topología distribuida. Los agentes en los límites del sistema (ubicados en
servidores web, por ejemplo) recopilan datos y los envían a los agentes que son
responsables de agregar y luego almacenar los datos en su destino final. Los agentes están
configurados para ejecutar una colección de fuentes y receptores particulares, por lo que
utilizar Flume es principalmente un ejercicio de configuración para encajar las piezas.

5. Integración con otras herramientas

Además de poder transmitir datos desde múltiples fuentes a múltiples destinos, Flume
puede integrarse con una amplia gama de herramientas y productos. Puede extraer datos
de casi cualquier tipo de fuente, incluidos archivos de registro del servidor web, archivos
CSV generados a partir de una base de datos RDBMS y eventos. Del mismo modo, Flume
puede enviar datos a destinos como HDFS, HBase y Hive.

Flume incluso puede integrarse con otras herramientas de transmisión de datos como Kafka
y Spark.

Los siguientes ejemplos ilustran las capacidades de integración de Flume.

Transmisión de datos de registro a HDFS desde Twitter- Como se mencionó


anteriormente, Flume puede transmitir datos desde una fuente web como Twitter a un
directorio que reside en HDFS. Este es un requisito típico de un escenario en tiempo real.
Para que esto suceda, Flume debe configurarse para recoger datos del origen (tipo de
origen) y hundir los datos en el destino (tipo de destino). El tipo de fuente aquí es Twitter, y
el tipo de sumidero es HDFS-SINK. Una vez que se realiza el sumidero, las aplicaciones
como Spark pueden realizar análisis en HDFS.
Transmisión de datos de registro de Kafka a HDFS con Flume - Kafka es un agente de
mensajes, que puede transmitir datos en vivo y mensajes generados en páginas web a un
destino como una base de datos. Si necesita transmitir estos mensajes a una ubicación en
HDFS, Flume puede usar Kafka Source para extraer los datos y luego sincronizarlos con
HDFS usando HDFS Sink.

Transmisión de datos de registro a Elasticsearch- Flume se puede usar para transmitir


datos de registro a Elasticsearch, una herramienta popular de código abierto que se puede
usar para realizar rápidamente operaciones complejas de búsqueda de texto en grandes
volúmenes de datos JSON en un entorno distribuido de manera escalable. Está construido
sobre Lucene y aprovecha las capacidades de Lucene para realizar búsquedas basadas en
índices en JSON.
Flume puede transmitir documentos JSON desde un servidor web a Elasticsearch, para que
las aplicaciones puedan acceder a los datos de Elasticsearch. Los documentos JSON
pueden transmitirse directamente a Elasticsearch de forma rápida y confiable en un entorno
distribuido. Flume reconoce un destino ELK con su capacidad ElasticsearchSink.
Elasticsearch debe instalarse con un complemento FlumeSink para que reconozca a Flume
como una fuente desde la cual aceptar flujos de datos. Flume transmite datos en forma de
archivos de índice al destino Elasticsearch. Por defecto, un archivo de índice se transmite
por día con un formato de nombre predeterminado "flume-aaaa-MM-dd", que se puede
cambiar en el archivo de configuración de Flume.

6. Ventajas y Desventajas

Ventajas:

● Flume es escalable, confiable, tolerante a fallas y personalizable para diferentes


fuentes y sumideros.
● Apache Flume puede almacenar datos en tiendas centralizadas (es decir, los datos
se suministran desde una sola tienda) como HBase y HDFS.
● El canal es horizontalmente escalable.
● Si la velocidad de lectura excede la velocidad de escritura, Flume proporciona un
flujo constante de datos entre las operaciones de lectura y escritura.
● Flume proporciona una entrega confiable de mensajes. Las transacciones en Flume
se basan en canales donde se mantienen dos transacciones (un remitente y un
receptor) para cada mensaje.
● Con Flume, podemos ingerir datos de múltiples servidores en Hadoop.
● Nos brinda una solución confiable y distribuida y nos ayuda a recopilar, agregar y
mover gran cantidad de conjuntos de datos como Facebook, Twitter y sitios web de
comercio electrónico.
● Nos ayuda a ingerir datos de transmisión en línea de varias fuentes como tráfico de
red, redes sociales, mensajes de correo electrónico, archivos de registro, etc. en
HDFS.
● Es compatible con un gran conjunto de fuentes y tipos de destinos.

Desventajas:

● Apache Flume tiene algunas limitaciones. Para empezar, su arquitectura puede


volverse compleja y difícil de administrar y mantener cuando se transmiten datos
desde múltiples fuentes a múltiples destinos.
● Además, la transmisión de datos de Flume no es 100% en tiempo real. Se pueden
usar alternativas como Kafka si se necesita más transmisión de datos en tiempo
real.
● Si bien Flume puede transmitir datos duplicados al destino, puede ser difícil
identificar datos duplicados. Este desafío variará según el tipo de destino al que se
transmiten los datos.

Ejemplo de Caso de estudio


Explicar cómo lo utiliza y con qué herramientas lo integra.

Caso de Estudio

Flume está diseñado para la ingestión de grandes volúmenes de datos basados en eventos
en Hadoop. El ejemplo clásico es usar Flume para recopilar logs de un banco de servidores
web, y luego mover los eventos del log de esos archivos a nuevos archivos agregados a
una Data Lake en HDFS para su procesamiento. El destino habitual (o sink en el lenguaje
de Flume) es HDFS. Sin embargo, Flume es lo suficientemente flexible como para escribir
en otros sistemas, como HBase o Solr.

Para usar Flume, necesitamos ejecutar un agente Flume, que es un demonio Java que
ejecuta fuentes y receptores (sink) conectados por canales. Una fuente en Flume genera
eventos y los entrega al canal, que almacena los eventos hasta que se envían al receptor.
Se puede pensar en la combinación fuente-canal-receptor como un componente básico de
Flume.

Una instalación Flume está formada por una colección de agentes conectados que se
ejecutan en una topología distribuida. Los agentes en los límites del sistema (ubicados en
servidores web, por ejemplo) recopilan datos y los envían a los agentes que son
responsables de agregar y luego almacenar los datos en su destino final. Los agentes están
configurados para ejecutar una colección de fuentes y receptores particulares, por lo que
utilizar Flume es principalmente un ejercicio de configuración para encajar las piezas.
Caso de uso sencillo a modo de ejemplo
Para mostrar cómo funciona Flume, comencemos con una configuración que:

· Vigile nuevos archivos de texto en un directorio local


· Envía cada línea de cada archivo a la consola a medida que se añaden los archivos

Añadiremos los archivos a mano, pero es fácil imaginar un proceso como el de un servidor
web que crea nuevos archivos que queremos ingestar continuamente con Flume. Además,
en un sistema real, en lugar de registrar el contenido del archivo en el log, escribiríamos el
contenido en HDFS para su posterior procesamiento.

En este ejemplo, el agente Flume ejecuta una única fuente-canal-receptor, configurado con
un archivo de propiedades de Java. La configuración controla los tipos de fuentes,
receptores y canales que se utilizan, así como también la forma en que se conectan entre
sí.

Los nombres de propiedades forman una jerarquía con el nombre del agente en el nivel
superior. En este ejemplo, tenemos un único agente, llamado agent1. Los nombres de los
diferentes componentes de un agente se definen en el siguiente nivel, por lo que
agent1.sources lista los nombres de las fuentes que se deben ejecutar en agent1 (aquí es
una fuente única, source1). Del mismo modo, agent1 tiene un receptor (sink1) y un canal
(channel1).

Las propiedades de cada componente se definen en el siguiente nivel de la jerarquía. Las


propiedades de configuración disponibles para un componente dependen del tipo de
componente. En este caso, agent1.sources.source1.type está configurado en spooldir,
que es un origen que supervisa nuevos archivos en una cola de directorio. El origen de la
cola de directorio define una propiedad spoolDir, por lo que para source1, la clave
completa es agent1.sources.source1.spoolDir. Los canales de la fuente se establecen
con agent1.sources.source1.channels.

El receptor es de tipo logger para registrar eventos en la consola. También debe estar
conectado al canal (con la propiedad agent1.sinks.sink1.channel). El canal es un canal de
tipo file, lo que significa que los eventos del canal se persisten a disco para una mayor
durabilidad. El sistema se muestra en la figura
Antes de ejecutar el ejemplo, necesitamos crear el directorio de spooling en el sistema de
archivos local:

% mkdir /tmp/spooldir

Entonces podemos iniciar el agente Flume usando el comando flume-ng:

% flume-ng agent \
--conf-file spool-to-logger.properties \
--name agent1 \
--conf $FLUME_HOME/conf \
-Dflume.root.logger=INFO,console

El nombre del agente también se debe pasar con --name (ya que un archivo de propiedades
de Flume puede definir varios agentes, tenemos que decir cuál ejecutar). El indicador --conf
le dice a Flume dónde encontrar su configuración general, como la configuración del
entorno.

En una nueva terminal, crea un archivo en el directorio de spooling. La fuente del directorio
de spooling espera que los archivos sean inmutables. Para evitar que los archivos
parcialmente escritos sean leídos por la fuente, escribimos el contenido completo en un
archivo oculto. Luego, hacemos un cambio de nombre atómico para que la fuente pueda
leerlo:

% echo "Hello Flume" > /tmp/spooldir/.file1.txt

% mv /tmp/spooldir/.file1.txt /tmp/spooldir/file1.txt

De vuelta al terminal del agente, vemos que Flume ha detectado y procesado el archivo:

Preparing to move file /tmp/spooldir/file1.txt to


/tmp/spooldir/file1.txt.COMPLETED
Event: { headers:{} body: 48 65 6C 6C 6F 20 46 6C 75 6D 65 Hello Flume }

La fuente del directorio de spooling ingiere el archivo dividiéndolo en líneas y creando un


evento Flume para cada línea. Los eventos tienen cabeceras opcionales y un cuerpo
binario, que es la representación UTF-8 de la línea de texto. El logger receptor registra el
cuerpo en el log en forma hexadecimal y de cadena. El archivo que colocamos en el
directorio de cola solo tenía una línea, por lo que solo se registró un evento en este caso.
También vemos que el archivo fue renombrado como file1.txt.COMPLETED por la fuente, lo
que indica que Flume ha terminado de procesarlo y no lo procesará nuevamente.

Clickstreams

Clickstream es la grabación de partes de la pantalla en las que el usuario hace clic mientras
navega por la web. La acción del usuario se captura en el navegador del lado del cliente.
Por lo tanto, los datos del flujo de clics son La URL generada por cada usuario que hace clic
en los elementos del sitio.
Por ejemplo, en el portal de compras en línea, un flujo de clics de datos puede verse así:

http://xxx.com:8080/electronics/products?userID = id3 & productName = iPhone10 & price =


500 & location =Londres.

Cada vez que el usuario abre una nueva sesión, un nuevo contexto de usuario es
capturado. La ID de contexto se agregaría al clic de cada usuario datos.

Uso potencial de Los datos de clickstream en portales de comercio electrónico pueden ser:
• ¿Cuál es el camino más eficiente para que la navegación de un visitante al sitio termine en
la compra?
¿Cuáles son los productos que un visitante del sitio tiende a comprar juntos?
y que se prevé que compre en el futuro?
• ¿Dónde deberían dedicar su tiempo los desarrolladores del sitio web?
para mejorar la experiencia del usuario

Los sitios de comercio electrónico recopilan clickstream con diferentes intenciones


y difieren en volumen de datos y herramientas que usan.

La solución más simple al problema es recopilar los archivos de registro del navegador web
y luego empujarlos en HDFS.
Desventaja: no hay procesamiento en tiempo real.
Como los eventos de flujo de clics están sin procesar no están estructurados, la inserción
directa también requerirá un análisis más detallado, y limpieza y reinserción en la base de
datos.

Otro enfoque sería, un evento es generado en el lado del cliente y entregado al servicio de
back-end para manejar el procesamiento de eventos e inicio de sesión mientras está en
tránsito sin necesidad de almacenarlo.
• Ventajas: Procesamiento en tiempo real. Permite personalizar eventos procesados desde
JavaScript para ser procesados durante el vuelo antes de llevados a HDFS. Esto hace que
el procesamiento respuesta en tiempo real o casi en tiempo real.

Mover datos en tiempo real a través de Internet puede hacer que la red se cargue en todo
momento. Si el rango de respuesta por milisegundo no se requiere, podemos elegir ir por el
modo de procesamiento por lote como Apache Flume. También, moviendo una pequeña
cantidad de datos en tiempo real puede ser particularmente un problema para
almacenamiento HDFS ya que Hadoop está diseñado para archivos grandes.
Por lo tanto, para fuentes con muchos archivos pequeños, el agentes Flume podría
recopilarlos y juntar los datos en modo por lotes como un gran archivo único.

BIBLIOGRAFIA

http://spaceanalytics.blogspot.com/2018/01/ingesta-flume.html
https://www.researchgate.net/publication/332112448_Big_Data_Real-
Time_Clickstream_Data_Ingestion_Paradigm_for_E-Commerce_Analytics

Potrebbero piacerti anche