lromang / buda Goto Github PK

#BUDA

Bus de Datos Abiertos

Qué se pretende?

Definir un diseño modular para la plataforma que cumpla con los requerimientos de la misma basado en la filosofía de UNIX:

Pequeños programas que hacen una cosa y la hacen bien. +

Diseño != Implementación

Prioritariamente se debe trabajar e invertir tiempo en la definición, refinación y justificación del diseño; pensado desde el punto de vista de la plataforma y agnóstico a algúna tecnología especifica; debe ser lo más sencillo y claro posible.

Cuales son las metas principales a alcanzar?

Idealmente la plataforma debe:

• Poder procesar de forma independiente datos en distintos formatos y de distintas fuentes
• Ser fácilmente extensible en el futuro para soportar distintos formatos y fuentes de datos
• Realizar el procesamiento de forma eficiente en terminos de consumo de recursos ( CPU, memoria, etc ) para poder trabajar con grandes cargas de datos
• Deberá soportar streams de datos para eficientar el manejo de grandes cantidades de información
• Presentar un API tipo REST para poder consultar de forma flexible y eficiente los datos procesados y almacenados
• Permitir el desarrollo de herramientas visuales para tareas de administración y consumo de información
• Ser agnóstica en cuanto a tecnología de forma que sus componentes puedan ser escritos incluso en distintos lenguajes de programación favoreciendo así un diseño loosely coupled

Master: buda

Ejecutable binario que manipula proceso(s) manager; se comunica con el manager mediante su interfaz tipo REST

Manager: buda-manager

Proceso que se ejecuta en modo daemon y se encarga de administrar un catálogo de datos formado por distintos datasets; conserva en todo momento una lista de los datasets activos y sus respectivos agentes

Datasets: csv_sample.bdds

Entradas independientes en el catálogo de datos; se describen mediante un archivo de especifición ( JSON o YAML ); estos archivos son utilizados por el manager para crear agentes; un agente es asignado a cada dataset; a cada dataset es asignado un ID que se calcula como un SHA a partir del archivo utilizado para crearlo

Agents: buda-agent-{data.type}

Proceso tipo de worker, se inicia por el manager y ejecuta en modo daemon; abre un stream de lectura en el "hotspot" marcado por su dataset y espera por datos de entrada; cada paquete de datos recibido es procesado y almacenado de acuerdo a las configuraciones de la zona; los agentes son procesos especializados de acuerdo al tipo de dato que se procesará en el dataset; cada dataset indica tambien donde debera reportar errores el agente mediante un stream de escritura

Front: buda-front

Ademas del manager, front es el otro proceso de primer nivel en la plataforma; se encarga de presentar una interfaz de consumo mediante HTTP/S al usuario para realizar consultas de toda la información procesada y almancenada en los distintas datasets que conformán el catálogo

• Cada componente de la arquitectura es independiente, el mantenimiento del proyecto es sencillo y se puede realizar en paralelo en distintos frentes
• Para agregar soporte a distintos tipos de datos ( XML, feeds, etc ) basta con escribir un agente adecuado por lo que la plataforma es extensible
• Implementar esta arquitectura como un ambiente de microservicios es simple porque todas las capas estan bien delimitadas, son sencillas e independientes entre sí
• El eje central de la arquitectura es la especificación de dataset y esto puede desarrollarse y mejorarse con el apoyo de la comunidad :)
• Todos los componentes son procesos livianos y utilizan streams de datos por lo que los requerimientos de CPU y memoria son bajos
• Un master puede fácilmente comunicarse con distintos managers e iniciar distintos fronts por lo que el sistema puede manejarse de forma distribuida
• Los agentes son solo procesos hijos asi que la implementación específica es un detalle irrelevante para el resto de la plataforma; i.e. pueden escribirse agentes en Python, Ruby, Go, etc
• En una versión para producción los agentes incluso pueden desplegarse como containers en el cluster de forma relativamente sencilla
• Los datasets son solo un archivo JSON/YAML por lo que implementar herramientas visuales para diseñarlos es trivial
• Ya que los datasets son archivos de texto plano se puede montar un sistema de entrega continua de forma sencilla, por ejemplo: se almacenan en un repositorio Git, se configuran hooks de 'pre' y 'post' update que mediante al manager 'eliminan' y/o '(re)inician' los datasets que han sido modificados
• El manager implementa una interfaz RESTful HTTP para comunicarse con el master por lo que implementar herramientas visuales para administrarlos es trivial
• Los datasets incluyen un elemento hotspot que no es mas que el endpoint del stream utilizado para recibir datos; estos endpoints pueden ser UNIX sockets, TCP sockets o algun otro mecanismo más avanzando ( por ejemplo torrents para implementarse como sistemas realmente descentralizados 😎 )
• En caso de utilizar UNIX sockets se pueden "montar" en la maquina local de forma segura utilizando un SSH tunnel; en caso de sockets TCP se pueden implementar de forma segura mediante conexiones HTTPS
• Una vez creado el dataset se pueden implementar herramientas visuales tipo drag & drop para enviar datos de forma sencilla ya que lo único que la herramienta debe hacer es iniciar el streaming de paquetes hacia el hotspot utilizado