una pila de datos moderna de código abierto para blockchain

1. El desafío para la pila de datos moderna de blockchain

Hay varios desafíos a los que se puede enfrentar una empresa moderna de indexación de blockchain, que incluyen:

• Grandes cantidades de datos. A medida que aumenta la cantidad de datos en la cadena de bloques, el índice de datos deberá ampliarse para manejar el aumento de la carga y proporcionar un acceso eficiente a los datos. En consecuencia, conduce a mayores costos de almacenamiento, cálculo lento de métricas y mayor carga en el servidor de la base de datos.
• Tubería de procesamiento de datos compleja. La tecnología Blockchain es compleja, y la creación de un índice de datos integral y confiable requiere una comprensión profunda de las estructuras de datos y los algoritmos subyacentes. La diversidad de implementaciones de blockchain lo hereda. Dados ejemplos específicos, los NFT en Ethereum generalmente se crean dentro de contratos inteligentes siguiendo los formatos ERC721 y ERC1155. Por el contrario, la implementación de Polkadot, por ejemplo, generalmente se construye directamente dentro del tiempo de ejecución de blockchain. Esos deben considerarse NFT y deben guardarse como tales.
• Capacidades de integración. Para brindar el máximo valor a los usuarios, es posible que una solución de indexación de blockchain deba integrar su índice de datos con otros sistemas, como plataformas de análisis o API. Esto es un desafío y requiere un esfuerzo significativo puesto en el diseño de la arquitectura.

A medida que la tecnología de cadena de bloques se ha generalizado, la cantidad de datos almacenados en la cadena de bloques ha aumentado. Esto se debe a que más personas usan la tecnología y cada transacción agrega nuevos datos a la cadena de bloques. Además, la tecnología blockchain ha evolucionado desde aplicaciones simples de transferencia de dinero, como las que involucran el uso de Bitcoin, hasta aplicaciones más complejas que involucran la implementación de la lógica comercial dentro de los contratos inteligentes. Estos contratos inteligentes pueden generar grandes cantidades de datos, lo que contribuye a aumentar la complejidad y el tamaño de la cadena de bloques. Con el tiempo, esto ha llevado a una cadena de bloques más grande y compleja.

En este artículo, revisamos la evolución de la arquitectura tecnológica de Footprint Analytics en etapas como un caso de estudio para explorar cómo la pila de tecnología Iceberg-Trino aborda los desafíos de los datos en cadena.

Footprint Analytics ha indexado alrededor de 22 datos públicos de blockchain, 17 mercados de NFT, 1900 proyectos de GameFi y más de 100,000 XNUMX colecciones de NFT en una capa de datos de abstracción semántica. Es la solución de almacén de datos de cadena de bloques más completa del mundo.

Independientemente de los datos de blockchain, que incluyen más de 20 mil millones de filas de registros de transacciones financieras, que los analistas de datos consultan con frecuencia. es diferente de los registros de ingreso en los almacenes de datos tradicionales.

Hemos experimentado 3 actualizaciones importantes en los últimos meses para cumplir con los crecientes requisitos comerciales:

2. Arquitectura 1.0 Bigquery

Al comienzo de Footprint Analytics, usábamos Consulta grande de Google como nuestro motor de almacenamiento y consulta; Bigquery es un gran producto. Es increíblemente rápido, fácil de usar y proporciona poder aritmético dinámico y una sintaxis UDF flexible que nos ayuda a hacer el trabajo rápidamente.

Sin embargo, Bigquery también tiene varios problemas.

• Los datos no se comprimen, lo que genera altos costos, especialmente cuando se almacenan datos sin procesar de más de 22 cadenas de bloques de Footprint Analytics.
• Simultaneidad insuficiente: Bigquery solo admite 100 consultas simultáneas, lo que no es adecuado para escenarios de alta simultaneidad para Footprint Analytics cuando atiende a muchos analistas y usuarios.
• Conéctese con Google Bigquery, que es un producto de código cerrado。

Así que decidimos explorar otras arquitecturas alternativas.

3. Arquitectura 2.0 OLAP

Estábamos muy interesados ​​en algunos de los productos OLAP que se habían vuelto muy populares. La ventaja más atractiva de OLAP es su tiempo de respuesta a las consultas, que normalmente tarda unos segundos en devolver los resultados de la consulta para cantidades masivas de datos, y también puede admitir miles de consultas simultáneas.

Elegimos una de las mejores bases de datos OLAP, Doris, Darle una oportunidad. Este motor funciona bien. Sin embargo, en algún momento nos encontramos con otros problemas:

• Los tipos de datos como Array o JSON aún no son compatibles (noviembre de 2022). Las matrices son un tipo común de datos en algunas cadenas de bloques. por ejemplo, el campo de tema en los registros de evm. No poder calcular en Array afecta directamente nuestra capacidad de calcular muchas métricas comerciales.
• Soporte limitado para DBT y para declaraciones de combinación. Estos son requisitos comunes para los ingenieros de datos para escenarios ETL/ELT en los que necesitamos actualizar algunos datos indexados recientemente.

Dicho esto, no podíamos usar Doris para toda nuestra canalización de datos en producción, así que intentamos usar Doris como una base de datos OLAP para resolver parte de nuestro problema en la canalización de producción de datos, actuando como un motor de consulta y brindando información rápida y altamente Capacidades de consultas simultáneas.

Desafortunadamente, no pudimos reemplazar Bigquery con Doris, por lo que tuvimos que sincronizar periódicamente los datos de Bigquery con Doris usándolo como un motor de consulta. Este proceso de sincronización tenía varios problemas, uno de los cuales era que las escrituras de actualización se acumulaban rápidamente cuando el motor OLAP estaba ocupado atendiendo consultas a los clientes front-end. Posteriormente, la velocidad del proceso de escritura se vio afectada y la sincronización tomó mucho más tiempo y, a veces, incluso se volvió imposible de terminar.

Nos dimos cuenta de que OLAP podría resolver varios problemas a los que nos enfrentamos y no podía convertirse en la solución llave en mano de Footprint Analytics, especialmente para la canalización de procesamiento de datos. Nuestro problema es más grande y más complejo, y podríamos decir que OLAP como motor de consulta por sí solo no era suficiente para nosotros.

4. Arquitectura 3.0 Iceberg + Trino

Bienvenido a la arquitectura Footprint Analytics 3.0, una revisión completa de la arquitectura subyacente. Hemos rediseñado toda la arquitectura desde cero para separar el almacenamiento, el cálculo y la consulta de datos en tres partes diferentes. Tomando lecciones de las dos arquitecturas anteriores de Footprint Analytics y aprendiendo de la experiencia de otros proyectos exitosos de big data como Uber, Netflix y Databricks.

4.1. Introducción del lago de datos

Primero dirigimos nuestra atención al lago de datos, un nuevo tipo de almacenamiento de datos para datos estructurados y no estructurados. El lago de datos es perfecto para el almacenamiento de datos en cadena, ya que los formatos de los datos en cadena varían ampliamente, desde datos en bruto no estructurados hasta datos de abstracción estructurados, por los que Footprint Analytics es bien conocido. Esperábamos utilizar el lago de datos para resolver el problema del almacenamiento de datos e, idealmente, también sería compatible con los principales motores de cómputo, como Spark y Flink, de modo que no sería una molestia integrarse con diferentes tipos de motores de procesamiento a medida que evoluciona Footprint Analytics. .

Iceberg se integra muy bien con Spark, Flink, Trino y otros motores computacionales, pudiendo elegir el cómputo más adecuado para cada una de nuestras métricas. Por ejemplo:

• Para aquellos que requieren una lógica computacional compleja, Spark será la elección.
• Flink para computación en tiempo real.
• Para tareas ETL simples que se pueden realizar con SQL, usamos Trino.

4.2. motor de consulta

Con Iceberg resolviendo los problemas de almacenamiento y computación, tuvimos que pensar en elegir un motor de consulta. No hay muchas opciones disponibles. Las alternativas que consideramos fueron

Lo más importante que consideramos antes de profundizar fue que el futuro motor de consultas tenía que ser compatible con nuestra arquitectura actual.

• Para admitir Bigquery como fuente de datos
• Para admitir DBT, en el que confiamos para producir muchas métricas
• Para admitir la metabase de herramientas de BI

Basándonos en lo anterior, elegimos Trino, que tiene muy buen soporte para Iceberg y el equipo fue tan receptivo que planteamos un error, que se solucionó al día siguiente y se lanzó a la última versión la semana siguiente. Esta fue la mejor opción para el equipo de Footprint, que también requiere una alta capacidad de respuesta de implementación.

4.3. Pruebas de rendimiento

Una vez que decidimos nuestra dirección, hicimos una prueba de rendimiento en la combinación Trino + Iceberg para ver si podía satisfacer nuestras necesidades y, para nuestra sorpresa, las consultas fueron increíblemente rápidas.

Sabiendo que Presto + Hive ha sido el peor comparador durante años en todo el bombo de OLAP, la combinación de Trino + Iceberg nos dejó completamente boquiabiertos.

Aquí están los resultados de nuestras pruebas.

caso 1: unirse a un gran conjunto de datos

Una tabla800 de 1 GB se une a otra tabla50 de 2 GB y realiza cálculos comerciales complejos

case2: use una sola tabla grande para hacer una consulta distinta

Prueba sql: seleccione distinto (dirección) del grupo de tablas por día

La combinación Trino+Iceberg es aproximadamente 3 veces más rápida que Doris en la misma configuración.

Además, hay otra sorpresa porque Iceberg puede usar formatos de datos como Parquet, ORC, etc., que comprimirán y almacenarán los datos. El almacenamiento de tablas de Iceberg ocupa solo alrededor de 1/5 del espacio de otros almacenes de datos. El tamaño de almacenamiento de la misma tabla en las tres bases de datos es el siguiente:

Nota: Las pruebas anteriores son ejemplos que hemos encontrado en la producción real y son solo para referencia.

4.4. Efecto de actualización

Los informes de las pruebas de rendimiento nos dieron suficiente rendimiento, por lo que nuestro equipo tardó aproximadamente 2 meses en completar la migración, y este es un diagrama de nuestra arquitectura después de la actualización.

• Múltiples motores informáticos se adaptan a nuestras diversas necesidades.
• Trino admite DBT y puede consultar Iceberg directamente, por lo que ya no tenemos que lidiar con la sincronización de datos.
• El asombroso rendimiento de Trino + Iceberg nos permite abrir todos los datos de bronce (datos sin procesar) a nuestros usuarios.

5. Resumen

Desde su lanzamiento en agosto de 2021, el equipo de Footprint Analytics completó tres actualizaciones arquitectónicas en menos de un año y medio, gracias a su fuerte deseo y determinación de brindar los beneficios de la mejor tecnología de base de datos a sus criptousuarios y su sólida ejecución en la implementación y actualizar su infraestructura y arquitectura subyacentes.

La actualización 3.0 de la arquitectura de Footprint Analytics ha comprado una nueva experiencia para sus usuarios, lo que les permite a los usuarios de diferentes orígenes obtener información sobre usos y aplicaciones más diversos:

• Creado con la herramienta Metabase BI, Footprint facilita a los analistas obtener acceso a datos decodificados en cadena, explorar con total libertad de elección de herramientas (sin código o hardcord), consultar el historial completo y examinar conjuntos de datos para obtener información en no hay tiempo.
• Integre datos dentro y fuera de la cadena para el análisis en web2 + web3;
• Al construir / consultar métricas sobre la abstracción comercial de Footprint, los analistas o desarrolladores ahorran tiempo en el 80 % del trabajo de procesamiento de datos repetitivo y se enfocan en métricas significativas, investigación y soluciones de productos basadas en su negocio.
• Experiencia perfecta desde Footprint Web hasta llamadas REST API, todo basado en SQL
• Alertas en tiempo real y notificaciones procesables sobre señales clave para respaldar las decisiones de inversión