Le défi de la pile de données de la blockchain moderne

Une startup moderne d'indexation de la blockchain peut être confrontée à plusieurs défis, notamment :

• Des quantités massives de données. Au fur et à mesure que la quantité de données sur la blockchain augmente, l'index de données devra s'adapter pour gérer la charge accrue et fournir un accès efficace aux données. Par conséquent, cela entraîne des coûts de stockage plus élevés, des calculs de métriques plus lents et une augmentation de la charge sur le serveur de base de données.

• Pipeline complexe de traitement des données. La technologie Blockchain est complexe, et la construction d'un index de données complet et fiable nécessite une compréhension approfondie des structures de données et des algorithmes sous-jacents. Elle est héritée de la diversité des implémentations de la blockchain. Pour donner des exemples précis, les NFT dans Ethereum sont généralement créés dans le cadre de contrats intelligents qui suivent les formats ERC721 et ERC1155, alors que la mise en œuvre de ces contrats sur Polkadot, par exemple, est généralement construite directement dans le runtime de la blockchain. En fin de compte, ils devraient être considérés comme des NFT et être sauvegardés en tant que tels.

• Capacités d'intégration. Afin d'offrir une valeur maximale aux utilisateurs, une solution d'indexation de blockchain peut avoir besoin d'intégrer son index de données à d'autres systèmes, tels que des plateformes d'analyse ou des API. Il s'agit d'un défi qui exige des efforts considérables dans la conception de l'architecture.
  L'utilisation de la technologie blockchain s'étant généralisée, la quantité de données stockées sur la blockchain a augmenté. En effet, de plus en plus de personnes utilisent cette technologie et chaque transaction ajoute de nouvelles données à la blockchain. En outre, l'utilisation de la technologie blockchain a évolué, passant de simples applications de transfert d'argent, telles que celles impliquant l'utilisation du bitcoin, à des applications plus complexes qui impliquent la mise en œuvre d'une logique commerciale au sein de contrats intelligents. Ces contrats intelligents peuvent générer de grandes quantités de données, ce qui a contribué à accroître la complexité et la taille de la blockchain. Au fil du temps, cela a conduit à une blockchain plus grande et plus complexe.

Dans cet article, nous examinons l'évolution de l'architecture technologique de Footprint Analytics par étapes, en tant qu'étude de cas, afin d'explorer la manière dont la pile technologique Iceberg-Trino relève les défis des données de la chaîne.

Footprint Analytics a indexé environ 22 données blockchain publiques, 17 places de marché NFT, 1900 projets GameFi et plus de 100 000 collections NFT dans une couche de données d'abstraction sémantique. Il s'agit de la solution d'entrepôt de données blockchain la plus complète au monde.

Indépendamment des données de la blockchain, qui comprend plus de 20 milliards de lignes d'enregistrements de transactions financières, qui sont fréquemment interrogées par les analystes de données. il est différent des journaux d'entrée dans les entrepôts de données traditionnels.

Nous avons connu trois mises à jour majeures au cours des derniers mois pour répondre aux besoins croissants de l'entreprise :

Architecture 1.0 Bigquery

Au début de Footprint Analytics, nous avons utilisé Google Bigquery comme moteur de stockage et de requête ; Bigquery est un excellent produit. Il est extrêmement rapide, facile à utiliser et offre une puissance arithmétique dynamique ainsi qu'une syntaxe UDF flexible qui nous aide à accomplir rapidement notre travail.

Cependant, Bigquery présente également un certain nombre de problèmes.

• Les données ne sont pas compressées, ce qui entraîne des coûts de stockage élevés, en particulier lorsqu'il s'agit de stocker les données brutes de plus de 22 blockchains de Footprint Analytics.

• Concurrence insuffisante : Bigquery ne prend en charge que 100 requêtes simultanées, ce qui n'est pas adapté aux scénarios à forte concurrence de Footprint Analytics, lorsqu'il s'agit de servir un grand nombre d'analystes et d'utilisateurs.

• Verrouiller avec Google Bigquery, qui est un produit à source fermée。
  Nous avons donc décidé d'explorer d'autres architectures alternatives.

Architecture 2.0 OLAP

Nous étions très intéressés par certains produits OLAP qui étaient devenus très populaires. L'avantage le plus intéressant de l'OLAP est son temps de réponse aux requêtes, qui prend généralement moins de quelques secondes pour renvoyer les résultats d'une requête portant sur des quantités massives de données, et qui peut également prendre en charge des milliers de requêtes simultanées.

Nous avons choisi l'une des meilleures bases de données OLAP, Doris, pour l'essayer. Ce moteur est performant. Cependant, à un moment donné, nous avons rapidement rencontré d'autres problèmes :

• Les types de données tels que Array ou JSON ne sont pas encore pris en charge (novembre 2022). Les tableaux sont un type de données courant dans certaines blockchains. Par exemple, le champ topic dans les logs evm. L'impossibilité de calculer sur Array affecte directement notre capacité à calculer de nombreuses mesures commerciales.

• Soutien limité à la TCD et aux déclarations de fusion. Il s'agit d'exigences courantes pour les ingénieurs de données dans les scénarios ETL/ELT, où nous devons mettre à jour des données nouvellement indexées.
  Cela dit, nous ne pouvions pas utiliser Doris pour l'ensemble de notre pipeline de données en production. Nous avons donc essayé d'utiliser Doris comme base de données OLAP pour résoudre une partie de notre problème dans le pipeline de production de données, en agissant comme un moteur de requêtes et en fournissant des capacités de requêtes rapides et hautement simultanées.

Malheureusement, nous ne pouvions pas remplacer Bigquery par Doris, et nous avons donc dû synchroniser périodiquement les données de Bigquery vers Doris en l'utilisant uniquement comme moteur de requête. Ce processus de synchronisation présentait un certain nombre de problèmes, dont l'un était que les écritures de mise à jour s'empilaient rapidement lorsque le moteur OLAP était occupé à servir des requêtes aux clients frontaux. Par la suite, la vitesse du processus d'écriture a été affectée, et la synchronisation a pris beaucoup plus de temps et a même parfois été impossible à terminer.

Nous nous sommes rendu compte que l'OLAP pouvait résoudre plusieurs problèmes auxquels nous étions confrontés, mais ne pouvait pas devenir la solution clé en main de Footprint Analytics, en particulier pour le pipeline de traitement des données. Notre problème est plus important et plus complexe, et nous pourrions dire que l'OLAP en tant que moteur de requête n'était pas suffisant pour nous.

Architecture 3.0 Iceberg + Trino

Bienvenue dans l'architecture 3.0 de Footprint Analytics, une refonte complète de l'architecture sous-jacente. Nous avons repensé l'ensemble de l'architecture de A à Z, afin de séparer le stockage, le calcul et l'interrogation des données en trois parties distinctes. En tirant les leçons des deux architectures précédentes de Footprint Analytics, et en s'inspirant de l'expérience d'autres projets de big data réussis comme Uber, Netflix, et Databricks.

Introduction du lac de données

Nous nous sommes d'abord intéressés aux lacs de données, un nouveau type de stockage de données structurées et non structurées. Le lac de données est parfait pour le stockage des données de la chaîne, car les formats de ces données varient considérablement, allant des données brutes non structurées aux données d'abstraction structurées pour lesquelles Footprint Analytics est bien connu. Nous pensions utiliser le lac de données pour résoudre le problème du stockage des données, et idéalement, il devrait également prendre en charge les moteurs de calcul courants tels que Spark et Flink, afin qu'il ne soit pas difficile d'intégrer différents types de moteurs de traitement au fur et à mesure de l'évolution de Footprint Analytics.

Iceberg s'intègre très bien avec Spark, Flink, Trino et d'autres moteurs de calcul, et nous pouvons choisir le calcul le plus approprié pour chacune de nos mesures. Par exemple：

• Pour ceux qui ont besoin d'une logique de calcul complexe, le choix se portera sur Spark.

• Flink pour le calcul en temps réel.

• Pour les tâches ETL simples qui peuvent être effectuées à l'aide de SQL, nous utilisons Trino.

  Moteur de recherche

Iceberg ayant résolu les problèmes de stockage et de calcul, nous avons dû réfléchir au choix d'un moteur de recherche. Il n'y a pas beaucoup d'options disponibles, les alternatives que nous avons envisagées sont les suivantes

• Trino : Moteur de requête SQL

• Presto : Moteur de requête SQL

• Kyuubi : Serverless Spark SQL
  La chose la plus importante à laquelle nous avons pensé avant d'aller plus loin était que le futur moteur de requête devait être compatible avec notre architecture actuelle.

• Pour prendre en charge Bigquery en tant que source de données

• Pour soutenir la DBT, sur laquelle nous nous appuyons pour produire de nombreuses mesures.

• Pour soutenir l'outil de BI metabase
  Sur la base de ce qui précède, nous avons choisi Trino, qui a un très bon support pour Iceberg et l'équipe a été si réactive que nous avons soulevé un bogue, qui a été corrigé le jour suivant et mis à la disposition de la dernière version la semaine d'après. C'était sans aucun doute le meilleur choix pour l'équipe de Footprint, qui a également besoin d'une grande réactivité dans la mise en œuvre.

Tests de performance

Une fois que nous avons décidé de notre orientation, nous avons effectué un test de performance sur la combinaison Trino + Iceberg pour voir si elle pouvait répondre à nos besoins et, à notre grande surprise, les requêtes étaient incroyablement rapides.

Sachant que Presto + Hive a été le pire comparateur pendant des années dans tout le battage OLAP, la combinaison de Trino + Iceberg nous a complètement époustouflés.

Voici les résultats de nos tests.

• cas 1 : joindre un grand ensemble de données

  Une table 1 de 800 Go rejoint une autre table 2 de 50 Go et effectue des calculs commerciaux complexes.

• Cas 2 : utiliser une grande table unique pour effectuer une requête distincte

  Test sql : select distinct(address) from table group by day

La combinaison Trino+Iceberg est environ 3 fois plus rapide que Doris dans la même configuration.

En outre, il y a une autre surprise, car Iceberg peut utiliser des formats de données tels que Parquet, ORC, etc. qui compressent les données et les stockent. Le stockage des tables d'Iceberg n'occupe qu'environ 1/5 de l'espace des autres entrepôts de données. La taille de stockage d'une même table dans les trois bases de données est la suivante :

Note : Les tests ci-dessus sont des exemples individuels que nous avons rencontrés dans la production réelle et ne sont donnés qu'à titre de référence.

・Effet de mise à niveau

Les rapports des tests de performance nous ont donné suffisamment de performances pour que notre équipe mette environ deux mois à achever la migration, et voici un diagramme de notre architecture après la mise à niveau.

• Plusieurs moteurs informatiques répondent à nos différents besoins.

• Trino supporte DBT, peut interroger Iceberg directement, nous n'avons donc plus à nous occuper de la synchronisation des données.

• L'incroyable performance de Trino + Iceberg nous permet d'ouvrir toutes les données de Bronze (données brutes) à nos utilisateurs.

  Résumé

Depuis son lancement en août 2021, l'équipe de Footprint Analytics a réalisé trois mises à niveau architecturales en moins d'un an et demi, grâce à son désir et à sa détermination d'apporter les avantages de la meilleure technologie de base de données à ses utilisateurs de crypto-monnaie, et à une exécution solide de la mise en œuvre et de la mise à niveau de son infrastructure et de son architecture sous-jacentes.

La mise à jour 3.0 de l'architecture de Footprint Analytics a offert une nouvelle expérience à ses utilisateurs, permettant à des utilisateurs d'horizons différents d'obtenir des informations dans le cadre d'utilisations et d'applications plus variées :

• Conçu avec l'outil Metabase BI, Footprint permet aux analystes d'accéder aux données décodées de la chaîne, d'explorer avec une liberté totale de choix d'outils (sans code ou avec enregistrement), d'interroger l'ensemble de l'historique, d'examiner les ensembles de données de manière croisée, pour obtenir des informations en un rien de temps.

• Intégrer les données sur la chaîne et hors de la chaîne pour l'analyse à travers web2 + web3 ;

• En construisant / interrogeant des métriques sur la base de l'abstraction commerciale de Footprint, les analystes ou les développeurs gagnent du temps sur 80% du travail répétitif de traitement des données et se concentrent sur des métriques significatives, des recherches et des solutions de produits basées sur leur activité.

• Expérience transparente de l'empreinte Web aux appels d'API REST, tous basés sur SQL

• Alertes en temps réel et notifications exploitables sur les signaux clés pour soutenir les décisions d'investissement