Bus de Datos Abiertos
Switch branches/tags
Nothing to show
Clone or download
Pull request Compare This branch is 32 commits behind mxabierto:master.
Fetching latest commit…
Cannot retrieve the latest commit at this time.
Permalink
Failed to load latest commit information.
.github
_datasets
agent
examples
front
manager
schemas
services
.eslintignore
.eslintrc
.gitignore
LICENSE
README.md

README.md

#BUDA

Stories in Ready

Bus de Datos Abiertos

API

BUDA está disponible en api.datos.gob.mx

El catálogo de datasets se puede consultar en http://api.datos.gob.mx/v1/catalog.json

Arquitectura

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; a cada dataset son asignados un agente y 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

Agentes disponibles

agent/csv

agent/geojson

agent/json

agent/jsonl

agent/xml

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 distintos datasets que conforman el catálogo

FAQ

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

Consideraciones

  • 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 sólo 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