Plataforma de Datos Componible: Una Nueva Forma de Acceder a Datos en Stellar

Este artículo es el primero de una amplia serie sobre la Plataforma de Datos Componible, la próxima generación de plataforma de acceso a datos en Stellar. Este artículo ofrecerá una visión general de la arquitectura, así como de sus objetivos y capacidades. Los siguientes artículos profundizarán en los diferentes componentes de la arquitectura, se adentrarán en casos de uso significativos y explorarán cómo puedes utilizar esto para potenciar tus propias aplicaciones.

El Estado del Mundo

Hoy en día, SDF posee y opera dos productos que median datos desde la blockchain de Stellar: Horizon, una API que interactúa con la red, y Hubble, un conjunto de datos analíticos de historial completo. Actualmente, SDF aloja versiones públicas de estos productos para fomentar el desarrollo y la experimentación a pequeña escala en la red. Este modelo ha llevado a desafíos en el ecosistema:

• Flexibilidad Limitada - la naturaleza monolítica de los productos actuales fuerza un enfoque de todo o nada. Los proveedores deben adoptar el modelo de datos elegido por SDF o desarrollar su propia integración independiente desde cero. Construir una aplicación desde cero consume mucho tiempo y requiere experiencia de dominio a nivel de SME.
• Centralización Lógica - los productos actuales son difíciles de ejecutar, haciendo que los productos alojados por SDF sean un recurso de respaldo comunitario. Esto ha alentado a muchos a depender de una única organización de infraestructura.

Para apoyar y fomentar una red descentralizada saludable, es importante para nosotros que este almacenamiento y acceso a datos se distribuya entre tantos participantes del ecosistema como sea posible.

Tras el lanzamiento de Soroban y el cambio en la ventana de retención de Horizon de SDF, estamos viendo un fuerte aumento en el interés por proporcionar datos de la red como un servicio de proveedores de análisis, proveedores de infraestructura, indexadores y similares. Desafortunadamente, dado el estado actual del mundo, es más difícil de lo que debería ser para este tipo de proveedores incorporarse rápidamente al intentar servir datos de Stellar. Dada la naturaleza monolítica de Horizon y Hubble, tienden a impulsar un enfoque de todo o nada; o bien te inclinas por adoptar el modelo de datos elegido por SDF, o desarrollas tu propia integración completamente independiente de estas herramientas.

La Plataforma de Datos Componible (en adelante, CDP) es una colección de herramientas y bibliotecas de código abierto que trabajan juntas para agilizar el acceso a datos para el ecosistema Stellar. La intención es permitir que cada participante del ecosistema se conecte y juegue según sea necesario y personalice su solución basada en las necesidades individuales de su aplicación.

Los componentes clave que conforman CDP incluyen:

• Galexie: Extrae datos del libro mayor (metadatos de transacción, o “TxMeta”) de la blockchain utilizando un nodo central de Stellar y los escribe en un tubo, cola o solución de almacenamiento de datos a largo plazo.
• Almacenamiento de Objetos de Datos: Sirve como un mecanismo de almacenamiento a largo plazo para TxMeta crudo e inmutable, almacenado comprimido en el formato XDR de Stellar. Conceptualmente, esto es un lago de datos.
• Backend del Libro Mayor: Ingiere los datos crudos de una fuente de TxMeta configurable. Captive Core o un Lago de Datos pueden servir como fuente de TxMeta.
• Procesadores: Transforman los datos crudos en un formato significativo y legible por humanos y permite a los usuarios finales personalizar su procesamiento de datos según las necesidades específicas de su aplicación.
• Cargadores: Definen esquemas específicos del dominio y cargan los datos en algún lugar para ser consumidos por los usuarios finales de una aplicación.

A primera vista, esto podría parecer bastante simple, incluso obvio. De hecho, esto es en esencia lo que Hubble y Horizon hacen hoy en día. Los dos comparten código para algunos de estos componentes (ya que ambos usan el SDK de ingestión), pero en su mayor parte representan bases de código paralelas y divergentes que a menudo acoplan la mayoría de esta funcionalidad juntos. Esto hace extremadamente difícil (si no imposible) personalizar las implementaciones de los mismos para adaptarlas a tus propias necesidades de datos.

CDP reimagina esa arquitectura monolítica definiendo claramente y luego exponiendo externamente cada uno de esos componentes internos. Los componentes se representan como interfaces independientes que pueden configurarse y operarse de manera independiente, mientras se entrelazan sin problemas con cada otro componente para proporcionar una capa de datos personalizada para tu aplicación.

¡Esto desbloquea posibilidades infinitas! Importante, te da, al desarrollador, el poder de personalizar completamente tu consumo de datos y patrones de acceso, dependiendo del tipo de aplicación que estés construyendo. Por ejemplo:

• Elige tu fuente de XDR (TxMeta) basada en los requisitos únicos de vivacidad, consistencia y disponibilidad de tu propia aplicación
• Abstrae tu fuente de datos XDR, permitiéndote cambiarla por configuración con cero cambios en el código de tu aplicación
• Elimina la necesidad de que tu backend de aplicación en vivo ejecute Captive Core dentro de la aplicación misma, reduciendo drásticamente sus requisitos de recursos
• Personaliza qué procesadores XDR usas (¡o crea los tuyos!), permitiéndote ingerir y almacenar solo los datos que te importan, lo cual protege contra costos excesivos de almacenamiento a largo plazo
• Implementa tu propio esquema (y Cargador de Datos), permitiéndote elegir la base de datos óptima para tu aplicación, en lugar de estar limitado a PostgreSQL (Horizon) o BigQuery (Hubble)
• Contribuye con Backends de Libro Mayor, opciones de almacenamiento TxMeta o Procesadores útiles, divertidos o únicos al ecosistema de código abierto

Considera las elecciones arquitectónicas de backend vastamente diferentes que podrían hacerse a través de estos ejemplos:

• Backend de billetera que solo le importan los datos relacionados con las cuentas de sus clientes
• Emisor de activos que solo le importan los datos relacionados con sus activos
• Desarrollador de contratos que solo le importan los datos de depuración relacionados con sus contratos
• Intercambio centralizado que solo le importan las transacciones de entrada y salida de sus cuentas ómnibus
• Bot de comercio que solo le importan los últimos datos de ofertas y comercio

En última instancia, solo tú sabes qué datos necesita tu aplicación, así que solo tú puedes decidir el esquema óptimo (y almacenamiento de datos) para contenerlo. Si necesitas ayuda para pensar en opciones o averiguar cómo encaja CDP, contáctanos en Discord! Tenemos dos canales: #hubble para preguntas de análisis, y #horizon para preguntas operativas, en tiempo real. Estamos disponibles para ayudar a generar ideas, y tus comentarios nos ayudarán a decidir qué extensiones significativas agregamos a continuación a CDP.

La primera pieza del rompecabezas, Galexie, está fuera y disponible para uso público; ¡chécalo en github o docker hub! Actualmente soporta una única opción de almacenamiento de objetos (GCS), y estamos ansiosos por escuchar comentarios sobre qué medios de almacenamiento podrían ser más valiosos para ti en el futuro.

Estamos aprovechando las ganancias de rendimiento y la simplicidad de CDP al refactorizar partes de nuestros productos existentes, Hubble y Horizon. El Hubble de SDF ahora utiliza un lago de datos GCS exportado por Galexie como su backend - ve stellar-etl para detalles. El soporte de Horizon para reingestión desde un lago de datos exportado por Galexie está disponible en v2.32.0. Tendremos publicaciones en esta serie que profundizan en cómo refactorizamos nuestros servicios, así como lo que puedes esperar en términos de costo y tiempo si optas por utilizar estos nuevos componentes.

Para empezar a construir tu propia aplicación independiente de Horizon o Hubble, echa un vistazo a nuestro SDK de ingestión. Esto encapsula la interfaz del Backend del Ledger de CDP, y esto se puede usar para construir tu propio pipeline de ingestión configurado para consumir desde un lago de datos exportado por Galexie.

Estén atentos para la publicación de la próxima semana sobre Galexie, donde haremos una inmersión profunda en la instalación, desarrollo y uso. Este es el primer componente principal que compone el CDP, permitiendo a los desarrolladores exportar y memorizar de manera eficiente los datos de la red Stellar para su procesamiento.

Estamos trabajando activamente en desarrollar una biblioteca para albergar nuestros procesadores (o transformaciones), lo que ayudará a transformar el formato XDR bruto en modelos de datos que te resultarán más familiares si estás acostumbrado a utilizar Horizon o Hubble para el acceso a datos.

Todo esto puede sonar un poco abrumador y abstracto, pero saldremos con implementaciones de ejemplo extensas para desmitificar la nueva plataforma. También saldremos con más contenido en esta serie, donde destacaremos los casos de uso clave existentes, e ilustraremos cómo podrías utilizar el pleno poder del CDP en tu propia aplicación.

Mientras tanto, únete a nosotros en nuestro Discord de Desarrolladores para charlar sobre cualquier pregunta, preocupación o solicitud de características mientras trabajamos para modernizar el acceso a datos en Stellar!