Introduciendo Galexie: Extraer y Almacenar Datos de Stellar de Manera Eficiente

Bienvenido a la última entrega de nuestra serie sobre la Plataforma de Datos Componible, la próxima generación de plataforma de acceso a datos en Stellar. Hoy, estamos emocionados de presentar el primer componente, Galexie, una aplicación ligera que extrae datos del libro mayor de la red Stellar. ¡Sigue leyendo para saber más!

Uno de los principales desafíos al trabajar con datos de la red Stellar es la estrecha vinculación entre los procesos de extracción y transformación de datos. Los desarrolladores tienen herramientas limitadas disponibles para leer y guardar datos directamente de la red Stellar, lo que limita la flexibilidad en el diseño de sus aplicaciones. Para abordar esto, creamos Galexie como una aplicación extractora dedicada, desacoplando la ingesta de datos de la transformación. Este enfoque ofrece mayor versatilidad en comparación con alojar un servicio monolítico, como Horizon o Hubble.

La función principal de Galexie es exportar de manera eficiente todo el corpus de datos de la red Stellar y almacenarlo en un lago de datos basado en la nube. Esto crea una base de datos preprocesados que se puede acceder y transformar rápidamente por varias aplicaciones personalizadas adaptadas a necesidades específicas.

Los datos exportados por Galexie apoyan herramientas como Hubble y Horizon en la construcción de datos derivados. A diferencia de los libros mayores crudos escritos en los Archivos de Historia, que es una vista sin procesar de la historia de la red, Galexie exporta metadatos de transacciones completos, ofreciendo datos precalculados que están listos para usar.

Este diseño no solo apoya las herramientas existentes sino que también permite un procesamiento de datos más eficiente y abre nuevas posibilidades para el análisis de datos dentro del ecosistema Stellar. En las siguientes secciones, exploraremos las características, arquitectura y aplicaciones potenciales de Galexie.

Galaxie es una aplicación simple y ligera que agrupa datos de la red Stellar, los procesa y los escribe en un almacenamiento de datos externo. Incluye las siguientes capacidades:

• Extracción de Datos: Extraer metadatos de transacciones de la red Stellar.
• Compresión: Comprimir los metadatos de transacciones para un almacenamiento optimizado.
• Opciones de Almacenamiento: Conectar a un almacén de datos de tu elección, comenzando con Google Cloud Storage (GCS).
• Modos de Operación: Subir un rango fijo de libros mayores al almacenamiento en la nube, o transmitir continuamente nuevos libros mayores al almacenamiento en la nube a medida que se escriben en la red Stellar.

Galexie se construye alrededor de unos pocos principios de diseño clave:

• Simplicidad: Hacer solo una cosa, exportar datos del libro mayor de manera eficiente, y hacerlo bien.
• Portabilidad: Escribir datos de manera plana, por lo que no hay necesidad de mecanismos de indexación complejos en el sistema de almacenamiento. Esto nos permite cambiar fácilmente una opción de almacenamiento de datos por otra.
• Descentralización: Animar a los creadores a poseer y gestionar sus propios datos.
• Extensibilidad: Facilitar la adición de soporte para nuevos sistemas de almacenamiento
• Resiliencia: Hacer posible que las operaciones interrumpidas se reanuden limpiamente después de un reinicio. Un operador debería poder ejecutar varias instancias para redundancia sin conflicto.

No-objetivo: Galexie no está destinado o diseñado para la ingesta en vivo o interactuar con la red Stellar. El núcleo cautivo es mucho más adecuado para la ingesta en vivo.

A continuación, un diagrama de arquitectura que muestra los diversos componentes dentro de Galexie.

Al igual que Stellar Core, Galaxie emite metadatos de transacciones en el formato XDR estándar. Este formato es compatible con sistemas existentes, como Horizon y Hubble, lo que permite a los desarrolladores cambiar sin esfuerzo la fuente de datos XDR de los backends de sus aplicaciones.

Decidimos admitir el almacenamiento de múltiples libros mayores en cada archivo exportado. Esto reduce el número de archivos escritos en un almacén de datos y lo hace significativamente más eficiente para descargar grandes rangos de datos. Encontramos durante la experimentación que la descarga masiva de datos para el mismo rango de libros mayores es dos veces más rápida cuando los archivos contienen un paquete de 64 libros mayores en comparación con archivos que contienen un solo libro mayor.

Todos los archivos subidos se comprimen usando Zstandard como el algoritmo de compresión predeterminado para ahorrar ancho de banda de subida y descarga así como espacio de almacenamiento.

Para permitir una mayor organización de los datos, agregamos soporte para la partición de datos a través de una estructura de directorios. Tanto el número de libros mayores por archivo como el número de archivos por partición son configurables.

Decidimos codificar información adicional en los nombres de archivos y directorios. Estos nombres actúan como un token de ordenación y eliminan la necesidad de una indexación separada. El formato del nombre del archivo incluye dos componentes:

• Cada nombre de directorio contiene los números del primer y último libro mayor contenidos dentro de la partición, los nombres de archivos contienen los números de inicio y fin del libro mayor contenidos dentro del archivo.
• Además, los nombres de los directorios están prefijados con un token de ordenación, que es la representación hexadecimal de (uint_max - libro mayor inicial de la partición). El nombre del archivo está prefijado con la representación hexadecimal de (uint_max - libro mayor inicial del archivo). Estos tokens actúan como identificadores de ordenación.

Este esquema de nomenclatura asegura que los archivos y directorios estén ordenados en orden descendente, con los libros mayores más recientes apareciendo primero, optimizando la recuperación de los últimos libros mayores.

Por ejemplo, usando 64,000 archivos por directorio y 64 libros mayores por archivo, el directorio y archivo que contienen los libros mayores 64065 a 64128 se nombrarían:

• Nombre del directorio: FFFF05FE-64001-128000/
• Nombre del archivo: 0xFFFF05BE-64065-64128.xdr.gz

El enfoque de almacenamiento de datos de Galexie mejora significativamente la eficiencia operacional y la escalabilidad de las herramientas Stellar. En lugar de depender de Captive Core para generar metadatos de transacciones, estas herramientas ahora pueden acceder a metadatos de transacciones precalculados desde el almacén de datos. ¡Este enfoque mejora la velocidad de recuperación de datos por un orden de magnitud!

Además, al eliminar la dependencia en Captive Core, que es un componente intensivo en cómputo, Galaxie reduce los requisitos de hardware y los costos.

Aquí hay dos ejemplos que demuestran la efectividad de usar este enfoque de almacenamiento de datos.

Hubble (Stellar-ETL)

Antes de Galexie, Hubble, la Plataforma de Análisis Stellar, usaba Captive Core para ingerir datos de la Red. Para el procesamiento por lotes, esto era intensivo en recursos porque la fase de puesta al día de Captive Core tomaba más tiempo que leer y procesar ese lote de datos de la Red. Al aprovechar un lago de datos, Hubble se desacopla de Captive Core, lo que significa que puede acceder a metadatos de transacciones directamente desde GCS sin incurrir en el costoso costo de inicio de Captive Core. Esto reduce significativamente el tiempo de ejecución y la sobrecarga.

Horizon

Horizon, el servidor API de Stellar, tiene la capacidad de reingerir datos históricos dentro de rangos de libros mayores especificados usando una instancia interna de Captive Core. Para gestionar rangos de libros mayores de manera eficiente, Horizon puede ejecutar múltiples procesos de reingestión simultáneamente, cada uno accediendo a su propio Captive Core. Sin embargo, este enfoque es altamente intensivo en recursos. Desacoplar la reingestión de Horizon de Captive Core permite la reingestión directa de datos desde el lago de datos, mejorando tanto la velocidad como la escalabilidad.

Ejecutar tu propia instancia de Galexie te permite crear un lago de datos personalizado con datos extraídos del libro mayor crudo. Este enfoque ofrece un par de beneficios:

• Flexibilidad: Personalizar el esquema y la estrategia de retención de tus datos.
• Mejora en la Accesibilidad de Datos: Obtener acceso directo a los datos, eliminando la dependencia de Horizon o Stellar Core.
• Escalabilidad: Almacenar toda la historia de la red Stellar de manera rentable, con la capacidad de rellenar o reingerir la historia según sea necesario.

Para instrucciones detalladas sobre cómo instalar y ejecutar el servicio, consulta la Guía del Administrador.

Rendimiento

Creamos un lago de datos usando Galexie y notamos las siguientes observaciones:

• Se recomienda ejecutar una sola instancia de Galexie para la ingesta de datos desde ese punto en adelante solo. Rellenar toda la historia de la red tomaría 150 días ejecutando una sola instancia.
• Se recomienda ejecutar múltiples instancias en paralelo para llenar un lago de datos.
  • Por ejemplo, ejecutamos más de 40 instancias paralelas de Galexie (en motores de cómputo e2-standard2 motores de cálculo) al crear un lago de datos del pubnet tomó menos de 5 días con un costo estimado de cálculo de $600 USD para rellenar 10 años de datos.
• El tamaño del lago de datos para toda la historia de Stellar Pubnet es de ~3TB.
• El costo operativo de ejecutar Galexie para exportar continuamente datos de la Red es de ~$160 USD por mes. Esto incluye $60 por mes en cálculo y otros $100 por mes en costos de almacenamiento.

Nota: Las estimaciones de tiempo relacionadas con el rellenado de un lago de datos dependen de varios factores como el número de libros contables agrupados en un solo archivo, la latencia de la red y el ancho de banda.

Desarrollo Futuro

Nuestro objetivo en SDF es avanzar en aplicaciones verdaderamente descentralizadas y construir componentes de software más pequeños y reutilizables. Galexie se alinea con esta visión, jugando un papel importante en la construcción de la Plataforma de Datos Componible. Nuestro objetivo es expandir la funcionalidad de Galexie agregando soporte para otros almacenes de objetos e integrando con nuevas herramientas de transformación.

Cómo Puedes Contribuir

Damos la bienvenida a contribuciones de la comunidad para apoyar estos desarrollos futuros. Tu participación puede ayudar a extender las capacidades de Galexie, añadir soporte para soluciones adicionales de almacenamiento en la nube e integrar nuevas herramientas. Para más detalles sobre cómo involucrarte, consulta nuestra Guía para Desarrolladores.

¿Qué Sigue?

En las próximas publicaciones del blog, nos centraremos en casos de uso específicos, incluyendo la refactorización de los backends de Hubble y Horizon para usar un lago de datos generado por Galexie. Mantente atento mientras profundizamos en estas aplicaciones y sus benchmarks, y proporcionamos insights sobre cómo Galexie puede mejorar el manejo de datos y el rendimiento.

Comentarios

Si tienes preguntas, sugerencias o comentarios, únete a nosotros en Discord en los canales #hubble y #horizon. Nuestro equipo y los miembros de la comunidad están allí para discutir y brindar soporte.