Datalenses

Datalenses fue nuestro primer producto de datos en Numia. Un dashboard de análisis de datos 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 raw 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 de blockchain son públicos, pero "público" y "usable" no tienen nada que ver. Si querías sacar algo útil de los datos de cadenas Cosmos, las opciones no eran buenas: montarte tu propia infraestructura y mantenerla para siempre, o hacer 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 de análisis. 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 puedes tomar 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 los números para ofrecer análisis 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 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 vez de tiempo real. Solo esa decisión nos bajó 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, construimos 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 nuestros números en informes de investigación. La herramienta de snapshots tuvo mucho uso durante votaciones de gobernanza y airdrops, algo para lo 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

Del enfoque salieron dos productos especializados. Celestia Data adaptó el mismo modelo a una capa de DA, donde las métricas van de blob submissions y economía de rollups en vez de actividad DeFi. Token Pulse tiró por el lado opuesto, bajando la latencia por debajo de un segundo para seguir en tiempo real el comportamiento de holders y flujos de exchanges. Los dos parten de la misma base, pero cubren cosas 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 por la que Datalenses existe hoy. Vimos a competidores lanzar con dashboards en tiempo real y cerrar seis meses después cuando les llegaron las facturas de cloud. Elegimos lo sostenible y seguimos aquí.

Todos los equipos de protocolo nos pedían "datos en tiempo real". Pero cuando miramos 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 durante gobernanza y airdrops. Escuchar lo que piden importa, pero fijarte en lo que hacen es de donde salen las ideas buenas.

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 de análisis multi-chain que habría llevado meses más empezando de cero.