1.De uitdaging voor moderne blockchain data stack
Er zijn verschillende uitdagingen waarmee een moderne blockchain-indexeringsstartup te maken kan krijgen, waaronder:
- Massieve hoeveelheden gegevens. Naarmate de hoeveelheid gegevens op de blockchain toeneemt, zal de gegevensindex moeten opschalen om de toegenomen belasting aan te kunnen en efficiënte toegang tot de gegevens te bieden. Bijgevolg leidt dit tot hogere opslagkosten, trage metriekberekening en verhoogde belasting van de databaseserver.
- Complexe gegevensverwerkingspijplijn. Blockchaintechnologie is complex, en het bouwen van een uitgebreide en betrouwbare gegevensindex vereist een diepgaand begrip van de onderliggende gegevensstructuren en algoritmen. De diversiteit van blockchainimplementaties erft dit. Specifieke voorbeelden: NFT’s in Ethereum worden meestal gecreëerd binnen smart contracts volgens de ERC721 en ERC1155 formaten. De implementatie daarvan op Polkadot, bijvoorbeeld, wordt daarentegen meestal rechtstreeks binnen de runtime van de blockchain gebouwd. Die moeten worden beschouwd als NFT’s en moeten worden opgeslagen als.
- Integratiemogelijkheden. Om gebruikers maximale waarde te bieden, moet een blockchain indexeringsoplossing mogelijk zijn gegevensindex integreren met andere systemen, zoals analyseplatforms of API’s. Dit is een uitdaging en vereist aanzienlijke inspanningen voor het architectuurontwerp.
Naarmate de blockchaintechnologie meer ingang heeft gevonden, is de hoeveelheid op de blockchain opgeslagen gegevens toegenomen. Dat komt omdat meer mensen de technologie gebruiken en elke transactie nieuwe gegevens aan de blockchain toevoegt. Bovendien is de blockchaintechnologie geëvolueerd van eenvoudige geldoverboekingstoepassingen, zoals die waarbij Bitcoin wordt gebruikt, naar complexere toepassingen waarbij bedrijfslogica wordt geïmplementeerd in slimme contracten. Deze slimme contracten kunnen grote hoeveelheden gegevens genereren, wat bijdraagt tot de toegenomen complexiteit en omvang van de blockchain. Na verloop van tijd heeft dit geleid tot een grotere en complexere blockchain.
In dit artikel bekijken we de evolutie van de technologiearchitectuur van Footprint Analytics in stappen als casestudy om te onderzoeken hoe de Iceberg-Trino technologiestack de uitdagingen van on-chain data aanpakt.
Footprint Analytics heeft ongeveer 22 openbare blockchaingegevens, en 17 NFT marktplaats, 1900 GameFi project, en meer dan 100.000 NFT collecties geïndexeerd in een semantische abstractie datalaag. Het is de meest uitgebreide blockchain data warehouse oplossing ter wereld.
Ongeacht blockchaingegevens, die meer dan 20 miljard rijen records van financiële transacties omvatten, die gegevensanalisten vaak bevragen. het is anders dan ingressielogboeken in traditionele datawarehouses.
We hebben de afgelopen maanden 3 grote upgrades meegemaakt om aan de groeiende zakelijke eisen te voldoen:
2. Architectuur 1.0 Bigquery
In het begin van Footprint Analytics gebruikten we Google Bigquery als onze opslag- en query-engine; Bigquery is een geweldig product. Het is razendsnel, eenvoudig te gebruiken en biedt dynamische rekenkracht en een flexibele UDF-syntaxis die ons helpt de klus snel te klaren.
Bigquery heeft echter ook een aantal problemen.
- Data wordt niet gecomprimeerd, wat resulteert in hoge kosten, vooral bij het opslaan van ruwe data van meer dan 22 blockchains van Footprint Analytics.
- Onvoldoende concurrency: Bigquery ondersteunt slechts 100 gelijktijdige query’s, wat ongeschikt is voor hoge concurrency scenario’s voor Footprint Analytics bij het bedienen van veel analisten en gebruikers.
- Koppel met Google Bigquery, wat een closed-source product is。
Dus besloten we andere alternatieve architecturen te onderzoeken.
3. Architectuur 2.0 OLAP
We waren erg geïnteresseerd in enkele OLAP-producten die erg populair waren geworden. Het meest aantrekkelijke voordeel van OLAP is de responstijd voor query’s, die doorgaans in subseconden terugkomt voor enorme hoeveelheden gegevens, en die ook duizenden gelijktijdige query’s kan ondersteunen.
Wij kozen een van de beste OLAP-databases, Doris, om het uit te proberen. Deze engine presteert goed. Maar op een gegeven moment liepen we tegen een aantal andere problemen aan:
- Datatatatatypes zoals Array of JSON worden nog niet ondersteund (nov, 2022). Arrays zijn een veelvoorkomend type gegevens in sommige blockchains. Bijvoorbeeld het topic veld in evm logs. Het niet kunnen berekenen op Array heeft directe gevolgen voor ons vermogen om veel zakelijke statistieken te berekenen.
- Beperkte ondersteuning voor DBT, en voor merge statements. Dit zijn algemene vereisten voor data engineers voor ETL/ELT scenario’s waar we nieuwe geïndexeerde data moeten bijwerken.
Dat gezegd zijnde, konden we Doris niet gebruiken voor onze hele gegevenspijplijn op productie, dus probeerden we Doris te gebruiken als een OLAP-database om een deel van ons probleem in de gegevenspijplijn op te lossen, door te fungeren als een query-engine en snelle en zeer gelijktijdige query-mogelijkheden te bieden.
Helaas konden we Bigquery niet vervangen door Doris, dus moesten we periodiek gegevens synchroniseren van Bigquery naar Doris met behulp van deze query-engine. Dit synchronisatieproces had verschillende problemen, waarvan er één was dat het schrijven van updates zich snel opstapelde wanneer de OLAP-engine bezig was met het serveren van queries aan de front-end clients. Bijgevolg werd de snelheid van het schrijfproces aangetast, en de synchronisatie duurde veel langer en werd soms zelfs onmogelijk om te voltooien.
We realiseerden ons dat OLAP verschillende problemen kon oplossen waarmee we werden geconfronteerd en niet de kant-en-klare oplossing van Footprint Analytics kon worden, met name voor de gegevensverwerkingspijplijn. Ons probleem is groter en complexer, en we konden zeggen dat OLAP als query engine alleen niet genoeg was voor ons.
4. Architectuur 3.0 Iceberg + Trino
Welkom bij Footprint Analytics architectuur 3.0, een complete revisie van de onderliggende architectuur. We hebben de hele architectuur van de grond af herontworpen om de opslag, berekening en bevraging van gegevens in drie verschillende stukken te scheiden. We hebben lessen getrokken uit de twee eerdere architecturen van Footprint Analytics en geleerd van de ervaringen van andere succesvolle big data projecten zoals Uber, Netflix en Databricks.
4.1. Introductie van het data lake
We richtten onze aandacht eerst op het data lake, een nieuw type gegevensopslag voor zowel gestructureerde als ongestructureerde gegevens. Data lake is perfect voor on-chain dataopslag omdat de formaten van on-chain data sterk variëren van ongestructureerde ruwe data tot gestructureerde abstractiegegevens waar Footprint Analytics bekend om staat. We verwachtten data lake te gebruiken om het probleem van dataopslag op te lossen, en idealiter zou het ook mainstream compute engines zoals Spark en Flink ondersteunen, zodat het niet lastig zou zijn om te integreren met verschillende soorten processing engines als Footprint Analytics zich verder ontwikkelt.
Iceberg integreert heel goed met Spark, Flink, Trino en andere rekenmachines, en we kunnen voor elk van onze metrieken de meest geschikte berekening kiezen. Bijvoorbeeld：
- Voor degenen die complexe rekenlogica vereisen, zal Spark de keuze zijn.
- Flink voor real-time berekeningen.
- Voor eenvoudige ETL-taken die met SQL kunnen worden uitgevoerd, gebruiken we Trino.
4.2. Query engine
Met Iceberg als oplossing voor de opslag- en rekenproblemen moesten we nadenken over de keuze van een query engine. Er zijn niet veel opties beschikbaar. De alternatieven die we overwogen waren
- Trino: SQL Query Engine
- Presto: SQL Query Engine
- Kyuubi: Serverloze Spark SQL
Het belangrijkste waar we rekening mee hielden voordat we de diepte in gingen was dat de toekomstige query engine compatibel moest zijn met onze huidige architectuur.
- Om Bigquery als gegevensbron te ondersteunen.
- Om DBT te ondersteunen, waarop we vertrouwen voor het produceren van veel metriek.
- Om de BI-tool metabase te ondersteunen
Op basis van het bovenstaande kozen we voor Trino, dat zeer goede ondersteuning biedt voor Iceberg en het team was zo responsief dat we een bug meldden, die de volgende dag werd opgelost en de week daarop werd vrijgegeven voor de nieuwste versie. Dit was de beste keuze voor het Footprint-team, dat ook een hoge uitvoeringsresponsiviteit vereist.
4.3. Testen van de prestaties
Toen we onze richting hadden bepaald, deden we een performancetest op de combinatie Trino + Iceberg om te zien of die aan onze behoeften kon voldoen en tot onze verrassing waren de queries 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: join een grote dataset
Een 800 GB tabel1 voegt zich samen met een andere 50 GB tabel2 en voert complexe bedrijfsberekeningen uit.
case2: gebruik een grote enkele tabel om een afzonderlijke query te doen
Test sql: selecteer distinct(adres) uit de tabel group by day
