1.El reto de una pila de datos moderna para blockchain
Hay varios retos a los que puede enfrentarse una startup moderna de indexación de blockchain, entre ellos:
- Cantidades masivas de datos. A medida que aumenta la cantidad de datos en el blockchain, el índice de datos tendrá que escalar para manejar el aumento de la carga y proporcionar un acceso eficiente a los datos. En consecuencia, esto conlleva mayores costes de almacenamiento, lentitud en el cálculo de métricas y un aumento de la carga en el servidor de la base de datos.
Canal de procesamiento de datos complejo. La tecnología blockchain es compleja, y construir un índice de datos completo y fiable requiere un profundo conocimiento de las estructuras de datos y algoritmos subyacentes. La diversidad de implementaciones de blockchain lo hereda. Por poner ejemplos concretos, las NFT en Ethereum suelen crearse dentro de contratos inteligentes que siguen los formatos ERC721 y ERC1155. En cambio, la implementación de las de Polkadot, por ejemplo, suele construirse directamente dentro del runtime de blockchain. Estos deben ser considerados NFTs y deben ser guardados como aquellos. - Capacidades de integración. Para proporcionar el máximo valor a los usuarios, una solución de indexación de blockchain puede necesitar integrar su índice de datos con otros sistemas, como plataformas analíticas o API. Esto supone un reto y requiere un esfuerzo significativo en el diseño de la arquitectura.
A medida que la tecnología blockchain se ha ido extendiendo, ha aumentado la cantidad de datos almacenados en ella. Esto se debe a que cada vez más personas utilizan esta tecnología y cada transacción añade nuevos datos a la cadena de bloques. Además, la tecnología blockchain ha evolucionado desde simples aplicaciones de transferencia de dinero, como las que implican el uso de Bitcoin, hasta aplicaciones más complejas que implican la implementación de lógica empresarial dentro de 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 un blockchain más grande y complejo.
En este artículo, revisamos la evolución de la arquitectura tecnológica de Footprint Analytics por etapas como un caso de estudio para explorar cómo la pila tecnológica Iceberg-Trino aborda los desafíos de los datos en la cadena.
Footprint Analytics ha indexado alrededor de 22 datos públicos de blockchain, y 17 mercados NFT, 1900 proyectos GameFi, y más de 100.000 colecciones NFT en una capa de datos de abstracción semántica. Es la solución de almacén de datos de blockchain más completa del mundo.
Independientemente de los datos de blockchain, que incluyen más de 20.000 millones de filas de registros de transacciones financieras, que los analistas de datos consultan con frecuencia. es diferente de los registros de entrada de los almacenes de datos tradicionales.
Hemos experimentado 3 actualizaciones importantes en los últimos meses para satisfacer los crecientes requisitos empresariales:
2. Arquitectura 1.0 Bigquery
Al principio de Footprint Analytics, utilizábamos Google Bigquery como motor de almacenamiento y consulta; Bigquery es un gran producto. Es rapidísimo, fácil de usar y ofrece una potencia aritmética dinámica y una sintaxis UDF flexible que nos ayuda a realizar el trabajo con rapidez.
Sin embargo, Bigquery también tiene varios problemas.
- Los datos no se comprimen, lo que resulta en altos costes, especialmente cuando se almacenan datos en bruto de más de 22 blockchains de Footprint Analytics.
- Insuficiente concurrencia: Bigquery solo admite 100 consultas simultáneas, lo que es inadecuado para escenarios de alta concurrencia para Footprint Analytics cuando se atiende a muchos analistas y usuarios.
- Lock in with Google Bigquery, which is a closed-source product。
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 hecho muy populares. La ventaja más atractiva de OLAP es su tiempo de respuesta de consulta, que normalmente tarda sub-segundos para devolver los resultados de consulta para grandes cantidades de datos, y también puede soportar miles de consultas simultáneas.
Elegimos una de las mejores bases de datos OLAP, Doris, para probarla. Este motor funciona bien. Sin embargo, en algún momento nos encontramos con otros problemas:
- Tipos de datos como Array o JSON aún no están soportados (Nov, 2022). Las matrices son un tipo de datos común en algunas blockchains. Por ejemplo, el campo topic en los registros evm. La imposibilidad de calcular sobre Array afecta directamente a nuestra capacidad para calcular muchas métricas de negocio.
- Soporte limitado para DBT, y para sentencias merge. Estos son requisitos comunes de los ingenieros de datos para escenarios ETL/ELT en los que necesitamos actualizar algunos datos recién indexados.
Dicho esto, no podíamos utilizar Doris para todo nuestro pipeline de datos en producción, así que intentamos utilizar Doris como base de datos OLAP para resolver parte de nuestro problema en el pipeline de producción de datos, actuando como motor de consulta y proporcionando capacidades de consulta rápidas y altamente concurrentes.
Desafortunadamente, no podíamos sustituir Bigquery por Doris, así que teníamos que sincronizar periódicamente los datos de Bigquery a Doris utilizándolo como motor de consulta. Este proceso de sincronización presentaba varios problemas, uno de los cuales era que las escrituras de actualización se acumulaban rápidamente cuando el motor OLAP estaba ocupado sirviendo consultas a los clientes front-end. En consecuencia, la velocidad del proceso de escritura se veía afectada y la sincronización tardaba mucho más e incluso a veces resultaba imposible finalizarla.
Nos dimos cuenta de que el OLAP podía resolver varios de los problemas a los que nos enfrentábamos y no podía convertirse en la solución llave en mano de Footprint Analytics, especialmente para el pipeline de procesamiento de datos. Nuestro problema es mayor 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
Bienvenidos a la arquitectura 3.0 de Footprint Analytics, 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 de big data de éxito como Uber, Netflix y Databricks.
4.1. Introducción del lago de datos
En primer lugar, nos centramos en el lago de datos, un nuevo tipo de almacenamiento de datos tanto estructurados como no estructurados. El lago de datos es perfecto para el almacenamiento de datos en la cadena, ya que los formatos de los datos en la cadena varían ampliamente, desde los datos sin estructurar en bruto hasta los datos estructurados de abstracción por los que es conocida Footprint Analytics. Esperábamos utilizar el lago de datos para resolver el problema del almacenamiento de datos, y lo ideal sería que también fuera compatible con los principales motores de computación, como Spark y Flink, para que no fuera 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 de cómputo, y podemos elegir el cómputo más apropiado para cada una de nuestras métricas. Por ejemplo：
- Para aquellas que requieran una lógica computacional compleja, Spark será la elección.
- Flink para computación en tiempo real.
- Para tareas ETL sencillas que puedan realizarse mediante SQL, utilizaremos Trino.
4.2. Motor de consulta
Una vez que Iceberg resolvió los problemas de almacenamiento y cálculo, tuvimos que pensar en elegir un motor de consulta. No hay muchas opciones disponibles. Las alternativas que consideramos fueron
- Trino: Motor de consulta SQL
- Presto: Motor de consulta SQL
- Kyuubi: Spark SQL sin servidor
Lo más importante que tuvimos en cuenta antes de profundizar fue que el futuro motor de consultas tenía que ser compatible con nuestra arquitectura actual.
- Apoyar Bigquery como fuente de datos.
- Soportar DBT, del que dependemos para producir muchas métricas
- Para soportar la metabase de la herramienta BI
En base a lo anterior, elegimos Trino, que tiene muy buen soporte para Iceberg y el equipo fue tan receptivo que planteamos un error, que fue corregido al día siguiente y liberado a la última versión la semana siguiente. Esta fue la mejor elección para el equipo de Footprint, que también requiere una gran capacidad de respuesta en la implementación.
4.3. Pruebas de rendimiento
Una vez decidida nuestra dirección, hicimos una prueba de rendimiento con 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 OLAP, la combinación de Trino + Iceberg nos dejó completamente boquiabiertos.
He aquí los resultados de nuestras pruebas.
caso 1: unir un gran conjunto de datos
Una tabla1 de 800 GB se une a otra tabla2 de 50 GB y realiza cálculos empresariales complejos
caso 2: utilizar una tabla individual de gran tamaño para realizar una consulta de distinción
Prueba sql: select distinct(address) from the table group by day
La combinación Trino+Iceberg es unas 3 veces más rápida que Doris en la misma configuración.
Además, hay otra sorpresa porque Iceberg puede utilizar formatos de datos como Parquet, ORC, etc., que comprimen y almacenan los datos. El almacenamiento de tablas de Iceberg ocupa sólo 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 sólo sirven de referencia.
4.4. Efecto de actualización
Los informes de las pruebas de rendimiento nos dieron suficiente rendimiento como para que nuestro equipo tardara unos 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 distintas necesidades.
- Trino es compatible con DBT y puede consultar Iceberg directamente, por lo que ya no tenemos que ocuparnos de la sincronización de datos.
- El increíble rendimiento de Trino + Iceberg nos permite abrir todos los datos de Bronze (datos en bruto) a nuestros usuarios.
5. Resumen
Desde su lanzamiento en agosto de 2021, el equipo de Footprint Analytics ha completado tres actualizaciones de arquitectura en menos de un año y medio, gracias a su fuerte deseo y determinación de llevar los beneficios de la mejor tecnología de bases de datos a sus usuarios de criptomonedas y a una sólida ejecución en la implementación y actualización de su infraestructura y arquitectura subyacentes.
La actualización 3.0 de la arquitectura de Footprint Analytics ha aportado una nueva experiencia a sus usuarios, permitiendo que usuarios de distintos ámbitos obtengan conocimientos en usos y aplicaciones más diversos:
- Construido con la herramienta de BI Metabase, Footprint facilita a los analistas el acceso a los datos descodificados de la cadena, la exploración con total libertad de elección de herramientas (sin código o hardcord), la consulta de todo el historial y el examen cruzado de conjuntos de datos para obtener información en un abrir y cerrar de ojos.
- Integre tanto los datos de la cadena como los de fuera de ella para realizar análisis en web2 + web3;
- Al construir / consultar métricas sobre la abstracción empresarial de Footprint, los analistas o desarrolladores ahorran tiempo en el 80% del trabajo repetitivo de procesamiento de datos y se centran en métricas significativas, investigación y soluciones de productos basadas en su negocio.
- Experiencia sin fisuras desde Footprint Web hasta las 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
