Die Herausforderung für moderne Blockchain-Datenstapel

Es gibt mehrere Herausforderungen, mit denen ein modernes Blockchain-Indizierungs-Startup konfrontiert sein kann, darunter:

• Riesige Datenmengen. Da die Datenmenge in der Blockchain zunimmt, muss der Datenindex skaliert werden, um die erhöhte Last zu bewältigen und einen effizienten Zugriff auf die Daten zu ermöglichen. Folglich führt es zu höheren Lagerkosten; verlangsamt die Metrikberechnung und erhöht die Belastung des Datenbankservers.

• Komplexe Datenverarbeitungspipeline. Die Blockchain-Technologie ist komplex und der Aufbau eines umfassenden und zuverlässigen Datenindex erfordert ein tiefes Verständnis der zugrunde liegenden Datenstrukturen und Algorithmen. Es wird von der Vielfalt der Blockchain-Implementierungen geerbt. Konkrete Beispiele: NFTs in Ethereum werden normalerweise im Rahmen von Smart Contracts erstellt, die dem ERC721- und ERC1155-Format folgen, während die Implementierung dieser NFTs beispielsweise auf Polkadot normalerweise direkt innerhalb der Blockchain-Laufzeit erstellt wird. Letztendlich sollten diese als NFTs betrachtet und als solche gespeichert werden.

• Integrationsmöglichkeiten. Um den Benutzern den größtmöglichen Nutzen zu bieten, muss eine Blockchain-Indexierungslösung möglicherweise ihren Datenindex mit anderen Systemen wie Analyseplattformen oder APIs integrieren. Dies ist eine Herausforderung und erfordert einen erheblichen Aufwand für die Gestaltung der Architektur.
  Mit zunehmender Verbreitung der Blockchain-Technologie hat auch die Menge der auf der Blockchain gespeicherten Daten zugenommen. Dies liegt daran, dass immer mehr Menschen die Technologie nutzen und jede Transaktion neue Daten zur Blockchain hinzufügt. Darüber hinaus hat sich der Einsatz der Blockchain-Technologie von einfachen Geldtransferanwendungen, beispielsweise solchen, die den Einsatz von Bitcoin beinhalten, zu komplexeren Anwendungen entwickelt, die die Implementierung von Geschäftslogik in Smart Contracts beinhalten. Diese intelligenten Verträge können große Datenmengen generieren, was zur erhöhten Komplexität und Größe der Blockchain beigetragen hat. Dies hat im Laufe der Zeit zu einer größeren und komplexeren Blockchain geführt.

In diesem Artikel betrachten wir die schrittweise Entwicklung der Technologiearchitektur von Footprint Analytics als Fallstudie, um zu untersuchen, wie der Iceberg-Trino-Technologie-Stack die Herausforderungen von On-Chain-Daten bewältigt.

Footprint Analytics hat etwa 22 öffentliche Blockchain-Daten und 17 NFT-Marktplätze, 1900 GameFi-Projekte und über 100.000 NFT-Sammlungen in einer semantischen Abstraktionsdatenschicht indiziert. Es handelt sich um die umfassendste Blockchain-Data-Warehouse-Lösung der Welt.

Unabhängig von Blockchain-Daten, die über 20 Milliarden Zeilen mit Aufzeichnungen von Finanztransaktionen umfassen und häufig von Datenanalysten abgefragt werden. Es unterscheidet sich von Eingangsprotokollen in herkömmlichen Data Warehouses.

Wir haben in den letzten Monaten drei große Upgrades durchgeführt, um den wachsenden Geschäftsanforderungen gerecht zu werden:

Architektur 1.0 BigQuery

Zu Beginn von Footprint Analytics verwendeten wir Google Bigquery als unsere Speicher- und Abfrage-Engine; Bigquery ist ein großartiges Produkt. Es ist unglaublich schnell, einfach zu bedienen und bietet dynamische Rechenleistung und eine flexible UDF-Syntax, die uns hilft, unsere Arbeit schnell zu erledigen.

Allerdings weist Bigquery auch eine Reihe von Problemen auf.

• Daten werden nicht komprimiert, was zu hohen Speicherkosten führt, insbesondere wenn es um die Speicherung von Rohdaten von über 22 Blockchains von Footprint Analytics geht.

• Unzureichende Parallelität: Bigquery unterstützt nur 100 gleichzeitige Abfragen, was für Szenarios mit hoher Parallelität für Footprint Analytics nicht geeignet ist, wenn eine große Anzahl von Analysten und Benutzern bedient wird.

• Nutzen Sie Google BigQuery, ein Closed-Source-Produkt.
  Deshalb haben wir beschlossen, andere alternative Architekturen zu erkunden.

Architektur 2.0 OLAP

Wir waren sehr an einigen der OLAP-Produkte interessiert, die sich großer Beliebtheit erfreuten. Der attraktivste Vorteil von OLAP ist seine Abfrage-Antwortzeit, die in der Regel weniger als Sekunden dauert, um Abfrageergebnisse für riesige Datenmengen zurückzugeben, und es kann auch Tausende gleichzeitiger Abfragen unterstützen.

Wir haben eine der besten OLAP-Datenbanken, Doris, ausgewählt, um es auszuprobieren. Dieser Motor leistet gut. Irgendwann stießen wir jedoch bald auf andere Probleme:

• Datentypen wie Array oder JSON werden noch nicht unterstützt (November 2022). Arrays sind in einigen Blockchains ein häufiger Datentyp. Zum Beispiel das Themenfeld in EVM-Protokollen. Wenn wir nicht auf dem Array rechnen können, wirkt sich dies direkt auf unsere Fähigkeit aus, viele Geschäftsmetriken zu berechnen.

• Eingeschränkte Unterstützung für DBT und Merge-Anweisungen. Dies sind allgemeine Anforderungen an Dateningenieure für ETL/ELT-Szenarien, in denen wir einige neu indizierte Daten aktualisieren müssen.
  Allerdings konnten wir Doris nicht für unsere gesamte Datenpipeline in der Produktion verwenden, also haben wir versucht, Doris als OLAP-Datenbank zu verwenden, um einen Teil unseres Problems in der Datenproduktionspipeline zu lösen, indem wir als Abfrage-Engine fungierten und schnelle und hochwertige Bereitstellungen lieferten gleichzeitige Abfragefunktionen.

Leider konnten wir Bigquery nicht durch Doris ersetzen, daher mussten wir regelmäßig Daten von Bigquery mit Doris synchronisieren und es nur als Abfrage-Engine verwenden. Bei diesem Synchronisierungsprozess gab es eine Reihe von Problemen. Eines davon bestand darin, dass sich die Update-Schreibvorgänge schnell häuften, wenn die OLAP-Engine damit beschäftigt war, Abfragen an die Front-End-Clients zu verarbeiten. Dadurch wurde die Geschwindigkeit des Schreibvorgangs beeinträchtigt, die Synchronisierung dauerte viel länger und konnte manchmal sogar nicht mehr abgeschlossen werden.

Uns wurde klar, dass OLAP mehrere Probleme, mit denen wir konfrontiert sind, lösen kann und nicht die schlüsselfertige Lösung von Footprint Analytics, insbesondere für die Datenverarbeitungspipeline, werden kann. Unser Problem ist größer und komplexer, und wir könnten sagen, dass OLAP als Abfragemaschine allein für uns nicht ausgereicht hat.

Architektur 3.0 Eisberg + Trino

Willkommen bei der Footprint Analytics-Architektur 3.0, einer kompletten Überarbeitung der zugrunde liegenden Architektur. Wir haben die gesamte Architektur von Grund auf neu gestaltet, um die Speicherung, Berechnung und Abfrage von Daten in drei verschiedene Teile zu unterteilen. Lehren aus den beiden früheren Architekturen von Footprint Analytics ziehen und aus den Erfahrungen anderer erfolgreicher Big-Data-Projekte wie Uber, Netflix und Databricks lernen.

Einführung von Data Lake

Wir haben uns zunächst dem Data Lake zugewandt, einer neuen Art der Datenspeicherung sowohl für strukturierte als auch für unstrukturierte Daten. Data Lake eignet sich perfekt für die On-Chain-Datenspeicherung, da die Formate der On-Chain-Daten von unstrukturierten Rohdaten bis hin zu strukturierten Abstraktionsdaten reichen, für die Footprint Analytics bekannt ist. Wir gingen davon aus, dass Data Lake das Problem der Datenspeicherung lösen würde, und im Idealfall würde es auch gängige Compute-Engines wie Spark und Flink unterstützen, sodass die Integration in verschiedene Arten von Verarbeitungs-Engines im Zuge der Weiterentwicklung von Footprint Analytics problemlos möglich wäre .

Iceberg lässt sich sehr gut in Spark, Flink, Trino und andere Rechen-Engines integrieren, und wir können für jede unserer Metriken die am besten geeignete Berechnung auswählen. Zum Beispiel:

• Für diejenigen, die eine komplexe Rechenlogik benötigen, ist Spark die richtige Wahl.

• Flink für Echtzeitberechnungen.

• Für einfache ETL-Aufgaben, die mit SQL ausgeführt werden können, verwenden wir Trino.

  Abfrage-Engine

Nachdem Iceberg die Speicher- und Rechenprobleme gelöst hatte, mussten wir darüber nachdenken, wie wir eine Abfrage-Engine auswählen sollten. Es stehen nicht viele Optionen zur Verfügung, die von uns in Betracht gezogenen Alternativen waren

• Trino: SQL-Abfrage-Engine

• Presto: SQL-Abfrage-Engine

• Kyuubi: Serverloses Spark SQL
  Das Wichtigste, was wir überlegten, bevor wir näher darauf eingingen, war, dass die zukünftige Abfrage-Engine mit unserer aktuellen Architektur kompatibel sein musste.

• Zur Unterstützung von BigQuery als Datenquelle

• Zur Unterstützung von DBT, auf das wir bei der Erstellung vieler Metriken angewiesen sind

• Zur Unterstützung der BI-Tool-Metabasis
  Basierend auf dem oben Gesagten haben wir uns für Trino entschieden, das Iceberg sehr gut unterstützt, und das Team reagierte so schnell, dass wir einen Fehler gemeldet haben, der am nächsten Tag behoben und in der folgenden Woche in der neuesten Version veröffentlicht wurde. Dies war definitiv die beste Wahl für das Footprint-Team, das außerdem eine hohe Reaktionsfähigkeit bei der Implementierung benötigt.

Leistungstest

Nachdem wir uns für unsere Richtung entschieden hatten, führten wir einen Leistungstest mit der Trino + Iceberg-Kombination durch, um zu sehen, ob sie unseren Anforderungen gerecht werden konnte, und zu unserer Überraschung gingen die Anfragen unglaublich schnell.

Da wir wussten, dass Presto + Hive im OLAP-Hype seit Jahren der schlechteste Vergleichsanbieter war, hat uns die Kombination aus Trino + Iceberg völlig umgehauen.

Hier sind die Ergebnisse unserer Tests.

• Fall 1: Großen Datensatz beitreten

  Eine 800-GB-Tabelle1 verbindet eine weitere 50-GB-Tabelle2 und führt komplexe Geschäftsberechnungen durch

• Fall 2: Verwenden Sie eine große einzelne Tabelle, um eine eindeutige Abfrage durchzuführen

  Testen Sie SQL: Wählen Sie eine eindeutige Adresse (Adresse) aus der Tabellengruppe nach Tag aus

Die Trino+Iceberg-Kombination ist etwa dreimal schneller als Doris in derselben Konfiguration.

Darüber hinaus gibt es noch eine weitere Überraschung, denn Iceberg kann Datenformate wie Parquet, ORC usw. verwenden, die die Daten komprimieren und speichern. Der Tabellenspeicher von Iceberg benötigt nur etwa 1/5 des Speicherplatzes anderer Data Warehouses. Die Speichergröße derselben Tabelle in den drei Datenbanken ist wie folgt:

Hinweis: Bei den oben genannten Tests handelt es sich um einzelne Beispiele, die wir in der tatsächlichen Produktion kennengelernt haben, und dienen nur als Referenz.

・Upgrade-Effekt

Die Leistungstestberichte lieferten uns genügend Leistung, sodass unser Team etwa zwei Monate brauchte, um die Migration abzuschließen. Dies ist ein Diagramm unserer Architektur nach dem Upgrade.

• Mehrere Computer-Engines erfüllen unsere unterschiedlichen Anforderungen.

• Trino unterstützt DBT und kann Iceberg direkt abfragen, sodass wir uns nicht mehr um die Datensynchronisierung kümmern müssen.

• Die erstaunliche Leistung von Trino + Iceberg ermöglicht es uns, alle Bronze-Daten (Rohdaten) für unsere Benutzer zugänglich zu machen.

  Zusammenfassung

Seit seiner Einführung im August 2021 hat das Team von Footprint Analytics in weniger als anderthalb Jahren drei Architektur-Upgrades abgeschlossen, dank seines großen Wunsches und seiner Entschlossenheit, seinen Krypto-Benutzern die Vorteile der besten Datenbanktechnologie zu bieten, und einer soliden Umsetzung bei der Implementierung und die Aktualisierung der zugrunde liegenden Infrastruktur und Architektur.

Das Footprint Analytics-Architektur-Upgrade 3.0 hat seinen Benutzern ein neues Erlebnis beschert, das es Benutzern mit unterschiedlichem Hintergrund ermöglicht, Einblicke in vielfältigere Nutzungen und Anwendungen zu erhalten:

• Footprint wurde mit dem Metabase BI-Tool entwickelt und ermöglicht es Analysten, auf dekodierte On-Chain-Daten zuzugreifen, mit völliger Freiheit bei der Auswahl der Tools (ohne Code oder Hardcord) zu erkunden, den gesamten Verlauf abzufragen, Datensätze zu überprüfen und Einblicke in No-Chain-Daten zu erhalten. Zeit.

• Integrieren Sie sowohl On-Chain- als auch Off-Chain-Daten zur Analyse über web2 + web3;

• Durch die Erstellung/Abfrage von Metriken auf der Grundlage der Geschäftsabstraktion von Footprint sparen Analysten oder Entwickler Zeit bei 80 % der sich wiederholenden Datenverarbeitungsarbeit und können sich auf aussagekräftige Metriken, Recherchen und Produktlösungen basierend auf ihrem Geschäft konzentrieren.

• Nahtloses Erlebnis von Footprint Web bis hin zu REST-API-Aufrufen, alles basierend auf SQL

• Echtzeitwarnungen und umsetzbare Benachrichtigungen zu wichtigen Signalen zur Unterstützung von Investitionsentscheidungen