Acelerando la Analítica en Stellar

Mientras que la primera tubería de datos se actualizaba diariamente, una tasa de actualización más rápida permite casos de uso más interesantes, como la toma de decisiones en tiempo real. También queríamos una tubería de datos más robusta para permitir características de observabilidad cruciales como reintentos automáticos en caso de fallo y registros detallados. Esta tubería en tiempo real y altamente observable requirió varias piezas de software fundamentales.

Primero, el stellar-etl extrae datos de nuestros archivos de historia y de stellar core. Es una interfaz de línea de comandos independiente escrita en Go. ETL significa extraer, transformar y cargar. El stellar-etl extrae datos de los archivos de historia usando el nuevo sistema de ingestión de horizon, transforma en JSON y carga los datos en un archivo de texto.

Con el stellar-etl, puedes ejecutar un comando simple como:

stellar-etl export_operations -s 1000 -e 2000

y obtener todas las operaciones desde el ledger 1000-2000.

El nuevo sistema de ingestión de horizon utiliza archivos de historia para proporcionar información detallada sobre la actividad histórica de la red, lo cual es más amigable para los desarrolladores y más rápido que usar las bases de datos de stellar-core y horizon. Los archivos de historia por sí solos no deben ser considerados fiables ya que un actor malicioso podría alterarlos, por lo tanto, el stellar-etl también utiliza una instancia de stellar-core para verificar los datos. Si te interesa saber más, revisa la charla de Eric Saunders, líder del Equipo de Horizon, Meridian talk sobre la nueva arquitectura de Horizon. Nota que los archivos de historia se actualizan en cada ledger de control, o cada 64 ledgers. Dado que un ledger se cierra cada 5 segundos en promedio, hay un ledger de control cada 5 minutos. ¡Así que, el stellar-etl puede actualizar nuestro nuevo conjunto de datos cada 5 minutos!

Para construir una tubería de datos más grande, tuvimos que orquestar muchas tareas diferentes, escalar de manera elegante y manejar fallos. Decidimos usar Apache Airflow, un sistema genérico de gestión de tareas open sourced por Airbnb. Desde que fue hecho open-source, se ha convertido en una de las herramientas más populares en la industria para la gestión de flujos de trabajo de ciencia de datos.

En Airflow, el usuario define unidades atómicas de trabajo llamadas tareas. Una tarea puede involucrar cualquier cosa desde enviar un correo electrónico hasta consultar una base de datos. El usuario puede enlazar tareas para formar Grafos Acíclicos Dirigidos (DAGs), que actúan como flujos de trabajo completos. El usuario puede entonces establecer horarios para los DAGs definidos.

Entonces, Airflow maneja todo lo relacionado con las tareas: programación, reintentos en caso de fallo y avance. Nota que a diferencia de nuestro sistema anterior, ¡este es un proceso componente por componente! Esto significa que Airflow puede reintentar tareas individuales que fallaron en lugar de reiniciar toda la tubería.

Con Airflow, construimos DAGs que actuaron como tuberías de datos completas. Por ejemplo, nuestro DAG de exportación de archivos de historia exporta datos dentro de un rango de tiempo. La primera tarea convierte el rango de tiempo en un rango de ledgers. Luego, cuatro tareas diferentes llaman a los comandos de exportación de stellar-etl para ledgers, transacciones, operaciones, y trades. El siguiente paso en la tubería sube cada uno de los archivos exportados a Google Cloud Storage. Finalmente, añadimos los archivos a sus correspondientes tablas de BigQuery. Revisa estos diagramas de DAG para saber más sobre los DAGs y sus tareas componentes.

Consideramos dos caminos principales para desplegar Airflow. El primero es una configuración personalizada de Kubernetes. Aquí, el desarrollador define y configura las piezas que Airflow necesita. Aquí tienes una lista rápida:

• Despliegues para Airflow servidor web y programador pods
• Acceso a definiciones de DAG a través de un volumen persistente de Kubernetes o sincronizando con repositorio git[@portabletext/react] Unknown block type "span", specify a component for it in the `components.types` prop
• Requisitos de backend para Airflow CeleryExecutor y pods de trabajadores
• Base de datos para metadatos de tareas de Airflow
• Espacio de almacenamiento para registros de Airflow

Como puedes ver, hay muchas partes móviles, pero afortunadamente puedes usar gráficos de helm en línea como plantillas para tu configuración de Airflow. Uno de estos gráficos está disponible aquí.

El segundo camino es Cloud Composer, el servicio gestionado por Google para desplegar Airflow. Esto proporciona una configuración de Kubernetes integrada con el Entorno de Google Cloud. El servidor web de Airflow, el programador y el ejecutor pueden funcionar en la nube y extraer de una base de datos común en la nube. Las instrucciones para una configuración de Cloud Composer se pueden encontrar aquí.

Estamos realmente emocionados de hacer nuestra tubería de datos lo más cercana a tiempo real posible, y ya estamos pensando en maneras de obtener nuevos datos y métricas usando las nuevas herramientas. Por ejemplo, estamos investigando almacenar libros de órdenes históricos para analizar mercados pasados, lo cual ahora podemos hacer gracias a la capacidad de stellar-etl de transformar grandes cantidades de datos en un formato compacto. También estamos ansiosos por ver lo que la comunidad de Stellar puede construir con nuestra nueva tubería de datos y herramientas. ¿Tienes ideas? Nos encantaría escucharlas. Esto es un recurso gratuito y open-source para que cualquiera lo use, y estamos emocionados de ver lo que puedes descubrir.

Revisa el stellar-etl o nuestra configuración de airflow. Siéntete libre de abrir incidencias en Github si tienes preguntas, preocupaciones, o te gustaría solicitar nuevas características.