Datalenses

Datalenses fue nuestro primer producto de datos en Numia. Un dashboard analítico para el ecosistema Cosmos centrado en Osmosis, Cosmos Hub, dYdX, Celestia y varias cadenas más. Si un equipo de protocolo o una institución quería métricas básicas, le tocaba pelearse con datos en bruto de blockchain o montarse su propio indexer. Les dimos métricas agregadas que podían abrir cada mañana, construidas sobre NumiaSQL, nuestro warehouse de datos indexados.

El problema

Los datos blockchain son públicos, pero "público" y "usable" son cosas muy distintas. Si querías sacar algo útil de los datos de cadenas Cosmos, las opciones eran malas: montar tu propia infraestructura y mantenerla para siempre, o lanzar SQL contra tablas que nadie diseñó para análisis. Ninguna servía para equipos de protocolo que quieren seguir su crecimiento ni para instituciones haciendo due diligence.

Lo que faltaba era una capa analítica. No otro explorador de bloques para buscar transacciones sueltas, sino métricas agregadas: tendencias de TVL, volúmenes de trading, retención de usuarios, flujos cross-chain por IBC. El tipo de datos con los que se toman decisiones.

El producto

Nos sentamos con los equipos de las cadenas e inversores hasta entender qué necesitaban en su día a día. El dashboard cubre tres cosas:

• Métricas por cadena. TVL, volumen de trading, flujos IBC y datos de liquidez. Lo que equipos de protocolo e inversores abren cada mañana para ver cómo va el ecosistema.
• Snapshots históricos. Exportar balances y métricas en CSV para cualquier fecha. Los participantes en gobernanza lo usan antes de votar, las instituciones para sus informes.
• Calculadoras. Herramientas como el estimador de ahorro de costes de Celestia, para modelar escenarios con datos reales.

La arquitectura

Hicimos números para analítica en tiempo real en más de 5 cadenas. Más de 50.000 $/mes solo en cómputo. Éramos una startup; ese presupuesto no existía.

Así que hicimos la pregunta obvia: ¿nuestros usuarios necesitan de verdad datos en tiempo real? Hablamos con ellos. Los equipos de protocolo miran el dashboard una vez al día, como mucho dos. Las instituciones generan informes semanales. Elegimos batch en vez de streaming. Latencias de 15 minutos a 1 hora en lugar de tiempo real. Solo esa decisión nos rebajó la factura de infraestructura un 80%.

Los datos parten de NumiaSQL, que ya se encarga de la ingesta, la gestión de reorgs y la normalización de las cadenas Cosmos que cubrimos. En vez de montar pipelines desde cero, creamos modelos de transformación en DBT sobre las tablas limpias de NumiaSQL y añadimos las agregaciones propias de Datalenses. El sistema tiene tres capas:

• Ingesta y transformación. NumiaSQL captura los datos raw de más de 5 cadenas Cosmos en BigQuery. Los modelos incrementales de DBT los transforman en métricas del dashboard a intervalos programados. Verificaciones de calidad validan todo antes de servirlo.
• Capa de consulta. BigQuery es demasiado lento para servir lecturas de dashboard, así que sincronizamos los datos procesados a Postgres. p99 por debajo de 150ms.
• Dashboard. El frontend que sirve las métricas a equipos de protocolo, inversores y la comunidad.

Resultados

Datalenses demostró que el modelo funcionaba. Osmosis lo adoptó como su fuente oficial de métricas y deprecó su propia página de info. Las instituciones empezaron a citar nuestras cifras en informes de investigación. La herramienta de snapshots tuvo mucho tirón durante votaciones de gobernanza y airdrops, un caso de uso para el que no lo habíamos diseñado.

• p99 de queries del dashboard por debajo de 150ms
• ~80% de reducción de costes frente a procesamiento en tiempo real
• Añadir cadenas nuevas lleva días, no semanas
• Calidad de datos suficiente para informes institucionales

De ahí salieron dos productos especializados. Celestia Data adaptó el mismo modelo a una capa de DA, donde las métricas giran en torno a blob submissions y economía de rollups en lugar de actividad DeFi. Token Pulse fue por el camino opuesto, bajando la latencia por debajo de un segundo para seguir en tiempo real el comportamiento de holders y flujos de exchanges. Ambos parten de la misma base, pero cubren necesidades que un dashboard generalista no resolvía bien.

Lo que aprendí

Apostar por batch en vez de real-time salvó el proyecto. No es lo más vistoso. Nadie se sube a un escenario a hablar de ejecuciones programadas de DBT. Pero esa reducción del 80% en costes es la razón de que Datalenses exista hoy. Vimos a competidores lanzar con dashboards en tiempo real y cerrar seis meses después cuando llegaron las facturas de cloud. Elegimos lo sostenible y seguimos aquí.

Todos los equipos de protocolo nos pedían "datos en tiempo real". Pero al observar qué hacían de verdad, eran consultas diarias e informes semanales. La herramienta de snapshots, que casi no construimos porque casi nadie la pidió, acabó siendo una de las funcionalidades más usadas en votaciones de gobernanza y airdrops. Escuchar lo que piden importa, pero fijarte en lo que hacen es de donde salen las buenas ideas.

Construir sobre NumiaSQL nos permitió dedicar el tiempo a los modelos de Datalenses y al dashboard en vez de a fontanería de datos. Las partes difíciles (ingesta, reorgs, cambios de esquema) ya estaban resueltas. Un equipo pequeño pudo sacar un producto analítico multi-chain que habría llevado meses más partiendo de cero.