een moderne open source datastack voor blockchain

1.De uitdaging voor de moderne blockchain-datastack

Er zijn verschillende uitdagingen waarmee een moderne blockchain-indexering-startup te maken kan krijgen, waaronder:

• Enorme hoeveelheden gegevens. Naarmate de hoeveelheid gegevens op de blockchain toeneemt, moet de gegevensindex worden opgeschaald om de toegenomen belasting aan te kunnen en efficiënte toegang tot de gegevens te bieden. Bijgevolg leidt dit tot hogere opslagkosten, trage berekening van statistieken en een verhoogde belasting van de databaseserver.
• Complexe pijplijn voor gegevensverwerking. Blockchain-technologie is complex en het bouwen van een uitgebreide en betrouwbare data-index vereist een grondige kennis van de onderliggende datastructuren en algoritmen. De diversiteit aan blockchain-implementaties erft het. Gegeven specifieke voorbeelden, worden NFT's in Ethereum meestal gemaakt binnen slimme contracten volgens de formaten ERC721 en ERC1155. De implementatie van die op bijvoorbeeld Polkadot wordt daarentegen meestal rechtstreeks in de blockchain-runtime gebouwd. Die moeten worden beschouwd als NFT's en moeten als die worden opgeslagen.
• Integratie mogelijkheden. Om gebruikers maximale waarde te bieden, moet een blockchain-indexeringsoplossing mogelijk de gegevensindex integreren met andere systemen, zoals analyseplatforms of API's. Dit is een uitdaging en vereist een aanzienlijke inspanning in het architectuurontwerp.

Naarmate blockchain-technologie wijdverspreider is geworden, is de hoeveelheid gegevens die op de blockchain is opgeslagen, toegenomen. Dit komt omdat meer mensen de technologie gebruiken en elke transactie nieuwe gegevens toevoegt aan de blockchain. Bovendien is blockchain-technologie geëvolueerd van eenvoudige toepassingen voor het overmaken van geld, zoals die waarbij Bitcoin wordt gebruikt, naar complexere toepassingen waarbij bedrijfslogica in slimme contracten wordt geïmplementeerd. Deze slimme contracten kunnen grote hoeveelheden gegevens genereren, wat bijdraagt ​​aan de toegenomen complexiteit en omvang van de blockchain. Dit heeft in de loop van de tijd geleid tot een grotere en complexere blockchain.

In dit artikel bekijken we de evolutie van de technologiearchitectuur van Footprint Analytics in fasen als een casestudy om te onderzoeken hoe de Iceberg-Trino-technologiestapel de uitdagingen van on-chain data aanpakt.

Footprint Analytics heeft ongeveer 22 openbare blockchain-gegevens en 17 NFT-marktplaatsen, 1900 GameFi-projecten en meer dan 100,000 NFT-collecties geïndexeerd in een semantische abstractiegegevenslaag. Het is de meest uitgebreide blockchain-datawarehouse-oplossing ter wereld.

Ongeacht blockchain-gegevens, die meer dan 20 miljard rijen records van financiële transacties bevatten, die data-analisten vaak doorzoeken. het is anders dan ingangslogboeken in traditionele datawarehouses.

We hebben de afgelopen maanden 3 grote upgrades ondergaan om aan de groeiende zakelijke vereisten te voldoen:

2. Architectuur 1.0 BigQuery

Aan het begin van Footprint Analytics gebruikten we Google BigQuery als onze opslag- en query-engine; BigQuery is een geweldig product. Het is razendsnel, gebruiksvriendelijk en biedt dynamische rekenkracht en een flexibele UDF-syntaxis die ons helpt de klus snel te klaren.

Bigquery heeft echter ook verschillende problemen.

• Gegevens worden niet gecomprimeerd, wat resulteert in hoge kosten, vooral bij het opslaan van onbewerkte gegevens van meer dan 22 blockchains van Footprint Analytics.
• Onvoldoende gelijktijdigheid: Bigquery ondersteunt slechts 100 gelijktijdige query's, wat niet geschikt is voor scenario's met hoge gelijktijdigheid voor Footprint Analytics wanneer veel analisten en gebruikers worden bediend.
• Sluit u aan bij Google Bigquery, een product met gesloten bron。

Dus besloten we om andere alternatieve architecturen te verkennen.

3. Architectuur 2.0 OLAP

We waren erg geïnteresseerd in enkele van de OLAP-producten die erg populair waren geworden. Het meest aantrekkelijke voordeel van OLAP is de responstijd voor query's, die meestal minder dan een seconde nodig heeft om queryresultaten voor enorme hoeveelheden gegevens te retourneren, en het kan ook duizenden gelijktijdige query's ondersteunen.

We hebben een van de beste OLAP-databases gekozen, Doris, om het eens te proberen. Deze motor presteert goed. Op een gegeven moment liepen we echter al snel tegen een aantal andere problemen aan:

• Gegevenstypen zoals Array of JSON worden nog niet ondersteund (november 2022). Arrays zijn een veelvoorkomend type gegevens in sommige blockchains. Bijvoorbeeld de onderwerp veld in evm-logboeken. Het niet kunnen berekenen op Array heeft rechtstreeks invloed op ons vermogen om veel zakelijke statistieken te berekenen.
• Beperkte ondersteuning voor DBT en voor samenvoegverklaringen. Dit zijn algemene vereisten voor data-engineers voor ETL/ELT-scenario's waarbij we een aantal nieuw geïndexeerde gegevens moeten bijwerken.

Dat gezegd hebbende, konden we Doris niet gebruiken voor onze hele datapijplijn bij productie, dus probeerden we Doris te gebruiken als een OLAP-database om een ​​deel van ons probleem in de dataproductiepijplijn op te lossen, als een query-engine en snel en zeer gelijktijdige querymogelijkheden.

Helaas konden we Bigquery niet vervangen door Doris, dus moesten we periodiek gegevens synchroniseren van Bigquery naar Doris door het als query-engine te gebruiken. Dit synchronisatieproces had verschillende problemen, een daarvan was dat het schrijven van updates snel opliep toen de OLAP-engine bezig was met het bedienen van query's aan de front-end-clients. Vervolgens werd de snelheid van het schrijfproces aangetast en duurde de synchronisatie veel langer en werd het soms zelfs onmogelijk om af te ronden.

We realiseerden ons dat het OLAP verschillende problemen kon oplossen waarmee we worden geconfronteerd en niet de kant-en-klare oplossing van Footprint Analytics kon worden, vooral niet voor de pijplijn voor gegevensverwerking. Ons probleem is groter en complexer, en we zouden kunnen zeggen dat OLAP als query-engine alleen niet genoeg voor ons was.

4. Architectuur 3.0 IJsberg + Trino

Welkom bij Footprint Analytics-architectuur 3.0, een complete revisie van de onderliggende architectuur. We hebben de hele architectuur vanaf het begin opnieuw ontworpen om de opslag, berekening en query van gegevens in drie verschillende delen te scheiden. Lessen trekken uit de twee eerdere architecturen van Footprint Analytics en leren uit de ervaring van andere succesvolle big data-projecten zoals Uber, Netflix en Databricks.

4.1. Introductie van het datameer

We richtten ons eerst op data lake, een nieuwe vorm van dataopslag voor zowel gestructureerde als ongestructureerde data. Data Lake is perfect voor on-chain dataopslag, aangezien de formaten van on-chain data sterk uiteenlopen van ongestructureerde onbewerkte data tot gestructureerde abstractiedata waar Footprint Analytics om bekend staat. We verwachtten dat we data lake zouden gebruiken om het probleem van gegevensopslag op te lossen, en idealiter zou het ook reguliere computerengines zoals Spark en Flink ondersteunen, zodat het geen probleem zou zijn om te integreren met verschillende soorten verwerkingsengines naarmate Footprint Analytics zich verder ontwikkelt .

Iceberg kan heel goed worden geïntegreerd met Spark, Flink, Trino en andere rekenmachines, en we kunnen de meest geschikte berekening kiezen voor elk van onze statistieken. Bijvoorbeeld:

• Voor degenen die complexe computationele logica nodig hebben, is Spark de keuze.
• Flink voor realtime berekeningen.
• Voor eenvoudige ETL-taken die met behulp van SQL kunnen worden uitgevoerd, gebruiken we Trino.

4.2. Query-engine

Nu Iceberg de opslag- en rekenproblemen oploste, moesten we nadenken over het kiezen van een query-engine. Er zijn niet veel opties beschikbaar. De alternatieven die we overwogen waren

Het belangrijkste dat we overwogen voordat we dieper gingen, was dat de toekomstige query-engine compatibel moest zijn met onze huidige architectuur.

• Ter ondersteuning van BigQuery als gegevensbron
• Ter ondersteuning van DBT, waarop we vertrouwen voor het produceren van veel statistieken
• Ter ondersteuning van de metabase van de BI-tool

Op basis van het bovenstaande hebben we gekozen voor Trino, dat zeer goede ondersteuning biedt voor Iceberg en het team reageerde zo snel dat we een bug hebben gemeld, die de volgende dag werd verholpen en de volgende week werd vrijgegeven naar de nieuwste versie. Dit was de beste keuze voor het Footprint-team, dat ook een hoge mate van responsiviteit bij de implementatie vereist.

4.3. Prestatietesten

Nadat we onze richting hadden bepaald, hebben we een prestatietest gedaan op de Trino + Iceberg-combinatie om te zien of deze aan onze behoeften kon voldoen en tot onze verbazing waren de vragen ongelooflijk snel.

Wetende dat Presto + Hive al jaren de slechtste vergelijker is in alle OLAP-hype, deed de combinatie van Trino + Iceberg ons volledig versteld staan.

Hier zijn de resultaten van onze tests.

case 1: sluit je aan bij een grote dataset

Een tafel van 800 GB1 voegt zich bij een andere tafel van 50 GB2 en voert complexe zakelijke berekeningen uit

case2: gebruik een grote enkele tabel om een ​​aparte query uit te voeren

Test sql: selecteer distinct(address) uit de tabelgroep per dag

De combinatie Trino+Iceberg is ongeveer 3 keer sneller dan Doris in dezelfde configuratie.

Daarnaast is er nog een verrassing omdat Iceberg dataformaten kan gebruiken zoals Parquet, ORC, etc., die de data comprimeren en opslaan. De tabelopslag van Iceberg neemt slechts ongeveer 1/5 van de ruimte van andere datawarehouses in beslag. De opslaggrootte van dezelfde tabel in de drie databases is als volgt:

Opmerking: de bovenstaande tests zijn voorbeelden die we in de daadwerkelijke productie zijn tegengekomen en zijn alleen ter referentie.

4.4. Upgrade-effect

De prestatietestrapporten gaven ons voldoende prestaties zodat ons team ongeveer 2 maanden nodig had om de migratie te voltooien, en dit is een diagram van onze architectuur na de upgrade.

• Meerdere computer-engines voldoen aan onze verschillende behoeften.
• Trino ondersteunt DBT en kan Iceberg direct bevragen, zodat we niet langer te maken hebben met gegevenssynchronisatie.
• Dankzij de geweldige prestaties van Trino + Iceberg kunnen we alle Bronze-gegevens (onbewerkte gegevens) openstellen voor onze gebruikers.

5. Overzicht

Sinds de lancering in augustus 2021 heeft het Footprint Analytics-team drie architecturale upgrades voltooid in minder dan anderhalf jaar, dankzij de sterke wens en vastberadenheid om de voordelen van de beste databasetechnologie naar zijn crypto-gebruikers te brengen en solide uitvoering bij het implementeren en het upgraden van de onderliggende infrastructuur en architectuur.

De Footprint Analytics-architectuurupgrade 3.0 heeft een nieuwe ervaring voor zijn gebruikers gekocht, waardoor gebruikers met verschillende achtergronden inzicht kunnen krijgen in meer divers gebruik en toepassingen:

• Footprint is gebouwd met de Metabase BI-tool en stelt analisten in staat toegang te krijgen tot gedecodeerde on-chain data, met volledige vrijheid van keuze van tools (no-code of hardcord) te verkennen, de hele geschiedenis te doorzoeken en datasets te onderzoeken om inzicht te krijgen in geen tijd.
• Integreer zowel on-chain als off-chain data voor analyse over web2 + web3;
• Door statistieken op te bouwen/op te vragen bovenop de zakelijke abstractie van Footprint, besparen analisten of ontwikkelaars tijd op 80% van het repetitieve gegevensverwerkingswerk en kunnen ze zich richten op zinvolle statistieken, onderzoek en productoplossingen op basis van hun bedrijf.
• Naadloze ervaring van Footprint Web tot REST API-aanroepen, allemaal gebaseerd op SQL
• Realtime waarschuwingen en bruikbare meldingen over belangrijke signalen om investeringsbeslissingen te ondersteunen