e modernen Open Source Datestack fir Blockchain

1.D'Erausfuerderung fir modern Blockchain Daten Stack

Et gi verschidde Erausfuerderunge fir e modernen Blockchain Indexéierungsstartup, dorënner:

• Massive Quantitéiten un Daten. Wéi d'Quantitéit vun Daten op der Blockchain eropgeet, muss den Dateindex opskaléieren fir déi verstäerkte Belaaschtung ze handhaben an en effizienten Zougang zu den Daten ze bidden. Dofir féiert et zu méi héije Späicherkäschten, luesen Metriken Berechnung, a verstäerkte Belaaschtung um Datebankserver.
• Komplex Datenveraarbechtungspipeline. Blockchain Technologie ass komplex, a bauen en ëmfaassenden an zouverlässeg Dateindex erfuerdert en déif Verständnis vun den ënnerierdesche Datestrukturen an Algorithmen. D'Diversitéit vu Blockchain Implementatiounen ierft et. Gitt spezifesch Beispiller, NFTs an Ethereum ginn normalerweis bannent Smart Kontrakter erstallt no den ERC721 an ERC1155 Formater. Am Géigesaz, ass d'Ëmsetzung vun deenen op Polkadot, zum Beispill, normalerweis direkt bannent Blockchain Runtime gebaut. Déi sollten als NFTs ugesi ginn a sollen als déi gespäichert ginn.
• Integratioun Kënnen. Fir maximal Wäert un d'Benotzer ze bidden, kann eng Blockchain Indexéierungsléisung hiren Dateindex mat anere Systemer z'integréieren, wéi zB Analytikplattformen oder APIen. Dëst ass Erausfuerderung a erfuerdert bedeitend Effort an den Architekturdesign gesat.

Wéi d'Blockchain Technologie méi verbreet ass, ass d'Quantitéit vun Daten, déi op der Blockchain gespäichert sinn, eropgaang. Dëst ass well méi Leit d'Technologie benotzen, an all Transaktioun füügt nei Daten un d'Blockchain. Zousätzlech huet d'Blockchain Technologie vun einfache Geldtransfer Uwendungen evoluéiert, sou wéi déi, déi d'Benotzung vu Bitcoin involvéieren, op méi komplex Uwendungen, déi d'Ëmsetzung vun der Geschäftslogik bannent intelligente Kontrakter involvéieren. Dës intelligent Kontrakter kënne grouss Quantitéiten un Daten generéieren, bäidroe fir d'Erhéijung vun der Komplexitéit an der Gréisst vum Blockchain. Mat der Zäit huet dëst zu enger méi grousser a méi komplexer Blockchain gefouert.

An dësem Artikel iwwerpréifte mir d'Evolutioun vun der Technologiearchitektur vun der Footprint Analytics an Etappen als Fallstudie fir ze entdecken wéi den Iceberg-Trino Technologie Stack d'Erausfuerderunge vun On-Chain Daten adresséiert.

Footprint Analytics huet ongeféier 22 ëffentlech Blockchain Daten indexéiert, a 17 NFT Maartplaz, 1900 GameFi Projet, an iwwer 100,000 NFT Sammlungen an eng semantesch Abstraktiounsdatenschicht. Et ass déi ëmfaassendst Blockchain Date warehouse Léisung op der Welt.

Onofhängeg vun Blockchain Daten, déi iwwer 20 Milliarde Reihen vu Rekorder vu Finanztransaktiounen enthalen, déi Datenanalyten dacks ufroen. et ass anescht wéi Ingressiounsprotokoller an traditionellen Datelager.

Mir hunn 3 grouss Upgrades an de leschte Méint erlieft fir déi wuessend Geschäftsfuerderunge gerecht ze ginn:

2. Architektur 1.0 Bigquery

Am Ufank vu Footprint Analytics hu mir benotzt Google Bigquery als eise Späicher- a Querymotor; Bigquery ass e super Produkt. Et ass blénkeg séier, einfach ze benotzen, a bitt dynamesch arithmetesch Kraaft an eng flexibel UDF Syntax déi eis hëlleft séier d'Aarbecht fäerdeg ze kréien.

Wéi och ëmmer, Bigquery huet och verschidde Probleemer.

• D'Donnéeën ginn net kompriméiert, wat zu héije Käschte resultéiert, besonnesch wann Dir Matière Daten vun iwwer 22 Blockchaine vu Footprint Analytics späichert.
• Net genuch Gläichzäiteg: Bigquery ënnerstëtzt nëmmen 100 simultan Ufroen, wat net gëeegent ass fir héich Gläichzäitegkeet Szenarie fir Footprint Analytics wann Dir vill Analysten a Benotzer servéiert.
• Spär mat Google Bigquery, dat ass e zouenen Quell Produkt.

Also hu mir beschloss aner alternativ Architekturen ze entdecken.

3. Architektur 2.0 OLAP

Mir waren ganz interesséiert fir e puer vun den OLAP Produkter déi ganz populär ginn hunn. Deen attraktivste Virdeel vun OLAP ass seng Ufro-Äntwertzäit, déi typesch Ënner-Sekonne dauert fir Ufroresultater fir massiv Quantitéiten un Daten zréckzeginn, an et kann och Dausende vu gläichzäiteg Ufroen ënnerstëtzen.

Mir hunn eng vun de beschten OLAP Datenbanken erausgesicht, Doris, fir et ze probéieren. Dëse Motor funktionnéiert gutt. Wéi och ëmmer, irgendwann hu mir séier op e puer aner Themen gerannt:

• Datentypen wéi Array oder JSON ginn nach net ënnerstëtzt (Nov, 2022). Arrays sinn eng allgemeng Aart vun Daten an e puer Blockchainen. Zum Beispill, de Thema Feld an evm Logbicher. Net fäeg op Array ze berechnen beaflosst direkt eis Fäegkeet fir vill Geschäftsmetriken ze berechnen.
• Limitéiert Ënnerstëtzung fir DBT, a fir Fusioun Aussoen. Dëst sinn allgemeng Ufuerderunge fir Dateningenieuren fir ETL / ELT Szenarie wou mir e puer nei indexéiert Donnéeën aktualiséieren.

Dat gesot, mir konnten d'Doris net fir eis ganz Datepipeline an der Produktioun benotzen, also hu mir probéiert Doris als OLAP Datebank ze benotzen fir en Deel vun eisem Problem an der Dateproduktiounspipeline ze léisen, als Ufromotor ze handelen a séier an héich ubitt concurrent Query Kënnen.

Leider konnte mir Bigquery net duerch Doris ersetzen, also hu mir periodesch Daten vu Bigquery op Doris missen synchroniséieren andeems se se als Ufromotor benotzt. Dëse Synchroniséierungsprozess hat e puer Probleemer, ee vun deenen war datt d'Aktualiséierungsschreiwe séier opgestockt goufen wann den OLAP-Motor beschäftegt war Ufroen un de Front-End Clienten ze servéieren. Duerno gouf d'Geschwindegkeet vum Schreifprozess beaflosst, an d'Synchroniséierung huet vill méi laang gedauert an heiansdo souguer onméiglech ginn ze kompletéieren.

Mir hu gemierkt datt den OLAP e puer Probleemer léise kéint, déi mir konfrontéieren an net déi schlësselfäerdeg Léisung vu Footprint Analytics kënne ginn, besonnesch fir d'Datenveraarbechtungspipeline. Eise Problem ass méi grouss a méi komplex, a mir kéinte soen datt OLAP als Ufromotor eleng net genuch war fir eis.

4. Architektur 3.0 Äisbierg + Trino

Wëllkomm op Footprint Analytics Architektur 3.0, eng komplett Reform vun der Basisdaten Architektur. Mir hunn d'ganz Architektur vum Buedem nei entworf fir d'Späichere, d'Berechnung an d'Ufro vun Daten an dräi verschidde Stécker ze trennen. Lektioune vun den zwou fréiere Architekturen vu Footprint Analytics huelen an aus der Erfahrung vun aneren erfollegräiche Big Data Projete wéi Uber, Netflix an Databricks léieren.

4.1. Aféierung vun der daten Séi

Mir hunn fir d'éischt eis Opmierksamkeet op Data Lake, eng nei Aart vun Datelagerung fir strukturéiert an onstrukturéiert Daten. Data Lake ass perfekt fir On-Chain Datelagerung well d'Formater vun On-Chain Daten breet reichen vun onstrukturéierten Rohdaten bis strukturéiert Abstraktiounsdaten Footprint Analytics ass bekannt fir. Mir hunn erwaart Data Lake ze benotzen fir de Problem vun der Datelagerung ze léisen, an am Idealfall géif et och Mainstream Rechenmotoren wéi Spark a Flink ënnerstëtzen, sou datt et net schmerzhaft wier mat verschiddenen Zorte vu Veraarbechtungsmotoren z'integréieren wéi Footprint Analytics sech entwéckelt. .

Iceberg integréiert ganz gutt mat Spark, Flink, Trino an aner computational Motore, a mir kënnen déi gëeegent Berechnung fir all vun eise Metriken wielen. Zum Beispill:

• Fir déi, déi komplex computational Logik erfuerderen, wäert Spark d'Wiel sinn.
• Flink fir Echtzäit Berechnung.
• Fir einfach ETL Aufgaben déi mat SQL ausgefouert kënne ginn, benotze mir Trino.

4.2. Query Engine

Mam Iceberg, deen d'Späicher- a Berechnungsproblemer léist, hu mir missen iwwerdenken e Query-Motor ze wielen. Et ginn net vill Optiounen. D'Alternativen, déi mir iwwerluecht hunn, waren

Déi wichtegst Saach, déi mir berücksichtegt ier mer méi déif gaange sinn, war datt den zukünftege Query-Motor mat eiser aktueller Architektur kompatibel muss sinn.

• Fir Bigquery als Datequell z'ënnerstëtzen
• Fir DBT z'ënnerstëtzen, op déi mir vertrauen fir vill Metriken ze produzéieren
• Fir de BI Tool Metabase z'ënnerstëtzen

Baséierend op der uewen, hu mir Trino gewielt, déi ganz gutt Ënnerstëtzung fir Iceberg huet an d'Team waren esou reaktiounsfäeger datt mir e Feeler opgeworf hunn, deen den nächsten Dag fixéiert gouf an d'nächst Woch op déi lescht Versioun verëffentlecht gouf. Dëst war déi bescht Wiel fir d'Footprint Team, déi och héich Implementéierungsreaktiounsfäegkeet erfuerdert.

4.3. Leeschtung Testen

Nodeems mir eis Richtung decidéiert hunn, hu mir e Performance Test op der Trino + Iceberg Kombinatioun gemaach fir ze kucken ob et eise Bedierfnesser entsprécht an eis Iwwerraschung, d'Ufroen waren onheemlech séier.

Wësse datt Presto + Hive de schlëmmste Vergläicher zënter Joeren am ganzen OLAP Hype war, huet d'Kombinatioun vun Trino + Iceberg eis Gedanken komplett geblosen.

Hei sinn d'Resultater vun eisen Tester.

Fall 1: bäitrieden eng grouss Datesaz

Eng 800 GB table1 bäitrieden aner 50 GB table2 a mécht komplex Affär Berechnungen

case2: Benotzt e groussen eenzegen Dësch fir eng z'ënnerscheedde Ufro ze maachen

Test sql: wielt ënnerscheet (Adress) aus der Tabellegrupp vum Dag

D'Trino + Äisbierg Kombinatioun ass ongeféier 3 Mol méi séier wéi Doris an der selwechter Konfiguratioun.

Zousätzlech gëtt et eng aner Iwwerraschung, well Iceberg kann Datenformate wéi Parquet, ORC, etc. benotzen, déi d'Donnéeën kompriméieren an späicheren. Iceberg's Dëschlagerung hëlt nëmmen ongeféier 1/5 vum Raum vun aneren Datelager D'Späichergréisst vum selwechten Dësch an den dräi Datenbanken ass wéi follegt:

Notiz: Déi uewe genannte Tester si Beispiller déi mir an der aktueller Produktioun begéint hunn a sinn nëmme fir Referenz.

4.4. Upgrade Effekt

D'Performance Testberichter hunn eis genuch Leeschtung ginn datt et eis Team ongeféier 2 Méint gedauert huet fir d'Migratioun ofzeschléissen, an dëst ass en Diagramm vun eiser Architektur nom Upgrade.

• Multiple Computermotoren passen eis verschidde Bedierfnesser.
• Trino ënnerstëtzt DBT, a kann direkt Äisbierg ufroen, sou datt mir net méi mat Datensynchroniséierung ze dinn hunn.
• Déi erstaunlech Leeschtung vum Trino + Äisbierg erlaabt eis all Bronzedaten (Rohdaten) fir eis Benotzer opzemaachen.

5. Resumé

Zënter dem Start am August 2021 huet d'Footprint Analytics Team dräi architektonesch Upgrades a manner wéi engem Joer an en halleft fäerdeg gemaach, dank sengem staarke Wonsch an Entschlossenheet fir d'Virdeeler vun der beschter Datebanktechnologie fir seng Krypto Benotzer an eng zolidd Ausféierung bei der Ëmsetzung an seng Basisdaten Infrastruktur an Architektur Upgrade.

D'Footprint Analytics Architektur Upgrade 3.0 huet eng nei Erfahrung fir seng Benotzer kaaft, wat d'Benotzer aus verschiddenen Hannergrënn erlaabt Abléck a méi divers Notzung an Uwendungen ze kréien:

• Gebaut mam Metabase BI-Tool, Footprint erliichtert Analysten Zougang zu dekodéierten On-Chain-Daten ze kréien, entdecken mat voller Fräiheet vun der Wiel vun Tools (kee Code oder Hardcord), d'ganz Geschicht ufroen, a Kräiz-Untersuchung Datesätz, fir Abléck ze kréien keng Zäit.
• Integréiert souwuel on-chain an off-chain Donnéeën fir Analyse iwwer Web2 + web3;
• Andeems Dir Metriken opbaut / ufroen uewen op der Geschäftsabstraktioun vun der Footprint, spueren Analysten oder Entwéckler Zäit op 80% vun der repetitiver Dateveraarbechtungsaarbecht a fokusséiere sech op sënnvoll Metriken, Fuerschung a Produktléisungen op Basis vun hirem Geschäft.
• Nahtlos Erfahrung vu Footprint Web bis REST API Uriff, alles baséiert op SQL
• Echtzäit Alarmer an handhabbar Notifikatiounen iwwer Schlësselsignaler fir Investitiounsentscheedungen z'ënnerstëtzen