flume ftp source, especificaciones generales y pruebas iniciales

Detalles de la implementación en Java 7 para el SDK del Apache-flume 1.4.0.

Se describe en el presente documento la solución adoptada para utilizar servidores dedicados con y para el protocolo de red/ficheros FTP (21) como fuente de datos para ser procesados por el inyector Apache-flume. Se desarrolla una fuente (source) exclusiva para el protocolo de red en cuestión con capacidad de conectarse e identificarse en el servidor. Completada esta fase se ejecuta el núcleo central de la solución con tres objetivos concretos: buscar, descubrir y procesar:

• buscar: mediante algoritmo de recursividad se recorrerán lo directorios hasta profundidad n + 1, buscando “elementos” de tipo: ficheros (planos, binarios,etc) o con contenido a procesar.

• descubrir: encontrado un elemento se procede a indexarlo mediante mapa key-value, en donde el valor escogido como clave es la codificación interna del elemento computada como hashcode, valor entero único con escasa probabilidad de colisión. A continuación se aloja su tamaño (espacio que ocupa al ser descubierto) en bytes como valor de referencia.

• procesar: se inyectarán los datos de los elementos como lotes de eventos (con payload) que Flume reconocerá y procesará, bien mediante nuevos datos encontrados por elemento descubierto, o nuevos datos anexados a un elemento ya indexado previamente. Siguiendo la recomendación de Flume-developer-guide se le ingestan a flume eventos de menos 1 Mb de tamaño de cuerpo de mensaje, es decir, de carga útil.

Si el proceso (pid) del binario Apache-flume deja de existir, se guardará en archivo físico el estado de la ejecución del inyector en el momento de la interrupción del servicio (serialización). Se mantendrán en dicho archivo el estado absoluto de los elementos en el contexto de ejecución del binario y el nivel de detalle de procesado, es decir,cuántos hilos había pendientes y en estos, qué byte fue el último en ser procesado, si hay más por procesar, y/o si durante la interrupción se han modificado los elementos o hay nuevos.

Como en el caso más general se trata de elementos (ficheros, enlaces) de gran tamaño (gigabytes de datos en un solo elemento), la solución adoptada ha sido la ejecución de un hilo independiente por cada elemento nuevo, mejorando el tiempo de procesamiento y lo que es más importante, la confiabilidad de los datos procesados hasta el momento.

Las pruebas de carga realizadas

1. gran cantidad de elementos creados de modo incremental en los que se anexa información de manera recursiva, tipo log con o sin rotación. La prueba duró 96 horas creando durante este período un total de 18651 ficheros y una media de tamaño del fichero de entre 1 - 5Mb desde su creación hasta el fin de la prueba (max 15 Gb). Con cuatro interrupciones del servicio, es decir, 4 reinicios y 4 recuperaciones.

2. gran cantidad de elementos encontrados en primera instancia. Sobre el ftp de 18651 ficheros, se borra el fichero serializado y se lanza una nueva instancia de flume.

3. ficheros de gran tamaño (> 1 GB) , sobre un total de 3 ficheros de 4,5 GB = 13,5 GB. La prueba realizada ha consistido en anexarle datos mientras aún se estaba procesando el descubrimiento del fichero, es decir, como el procesamiento se hace por lotes y no se espera hasta la carga en canal del total del fichero, la nueva información es anexada de modo normal, en la cola (en el tail ). Este casuística no interrumpe el descubrimiento-procesado del fichero porque, primero, se está ejecutando un hilo independiente por fichero, segundo, por cada tamaño que empieza a procesar, el código bloquea esa porción de bytes y no el fichero entero, facilitando la ingesta del evento a flume y no impidiendo que una aplicación externa (¿la misma que lo creó?) pueda anexarle más información, por ejemplo.