sodoben odprtokodni sklad podatkov za blockchain

1. Izziv za sodoben podatkovni sklad blockchain

Obstaja več izzivov, s katerimi se lahko sooči sodoben zagon indeksiranja blockchain, vključno z:

• Ogromne količine podatkov. Ko se količina podatkov v verigi blokov poveča, se bo moral podatkovni indeks povečati, da bo obvladal povečano obremenitev in zagotovil učinkovit dostop do podatkov. Posledično vodi do višjih stroškov shranjevanja, počasnega izračuna metrik in povečane obremenitve strežnika baze podatkov.
• Kompleksni cevovod za obdelavo podatkov. Tehnologija veriženja blokov je zapletena in izgradnja celovitega in zanesljivega podatkovnega indeksa zahteva globoko razumevanje osnovnih podatkovnih struktur in algoritmov. Raznolikost izvedb blockchaina ga podeduje. Na podlagi posebnih primerov so NFT-ji v Ethereumu običajno ustvarjeni v okviru pametnih pogodb po formatih ERC721 in ERC1155. Nasprotno pa je izvedba tistih na Polkadotu, na primer, običajno zgrajena neposredno znotraj izvajalnega okolja verige blokov. Te je treba šteti za NFT in jih je treba shraniti kot take.
• Integracijske zmogljivosti. Za zagotavljanje največje vrednosti uporabnikom bo morda morala rešitev indeksiranja blockchain integrirati svoj podatkovni indeks z drugimi sistemi, kot so analitične platforme ali API-ji. To je zahtevno in zahteva veliko truda, vloženega v arhitekturno zasnovo.

Ker je tehnologija blockchain postala bolj razširjena, se je količina podatkov, shranjenih v blockchainu, povečala. To je zato, ker več ljudi uporablja tehnologijo in vsaka transakcija doda nove podatke v verigo blokov. Poleg tega se je tehnologija veriženja blokov razvila iz preprostih aplikacij za prenos denarja, kot so tiste, ki vključujejo uporabo Bitcoina, v bolj zapletene aplikacije, ki vključujejo implementacijo poslovne logike znotraj pametnih pogodb. Te pametne pogodbe lahko ustvarijo velike količine podatkov, kar prispeva k povečani kompleksnosti in velikosti verige blokov. Sčasoma je to pripeljalo do večje in bolj zapletene verige blokov.

V tem članku pregledujemo razvoj tehnološke arhitekture Footprint Analytics po stopnjah kot študijo primera za raziskovanje, kako tehnološki sklop Iceberg-Trino obravnava izzive podatkov v verigi.

Footprint Analytics je indeksiral približno 22 javnih podatkov verige blokov in 17 tržnic NFT, 1900 projektov GameFi in več kot 100,000 zbirk NFT v podatkovno plast semantične abstrakcije. Je najobsežnejša rešitev za shranjevanje podatkov v verigi blokov na svetu.

Ne glede na podatke blockchaina, ki vključujejo več kot 20 milijard vrstic zapisov finančnih transakcij, po katerih podatkovni analitiki pogosto povprašujejo. razlikuje se od dnevnikov vstopov v tradicionalnih podatkovnih skladiščih.

V zadnjih nekaj mesecih smo doživeli 3 večje nadgradnje, da bi izpolnili vse večje poslovne zahteve:

2. Arhitektura 1.0 Bigquery

Na začetku analize odtisa smo uporabili Google Bigquery kot naš mehanizem za shranjevanje in poizvedovanje; Bigquery je odličen izdelek. Je izjemno hiter, enostaven za uporabo in zagotavlja dinamično aritmetično moč ter prilagodljivo sintakso UDF, ki nam pomaga hitro opraviti delo.

Vendar ima Bigquery tudi več težav.

• Podatki niso stisnjeni, kar povzroča visoke stroške, zlasti pri shranjevanju neobdelanih podatkov več kot 22 verig blokov Footprint Analytics.
• Nezadostna sočasnost: Bigquery podpira le 100 sočasnih poizvedb, kar je neprimerno za scenarije visoke sočasnosti za Footprint Analytics, ko služi številnim analitikom in uporabnikom.
• Zaklenite se z Google Bigquery, ki je zaprtokodni izdelek.

Zato smo se odločili raziskati druge alternativne arhitekture.

3. Arhitektura 2.0 OLAP

Zelo so nas zanimali nekateri izdelki OLAP, ki so postali zelo priljubljeni. Najbolj privlačna prednost OLAP je njegov odzivni čas na poizvedbo, ki običajno traja manj kot sekunde, da vrne rezultate poizvedbe za ogromne količine podatkov, poleg tega pa lahko podpira na tisoče sočasnih poizvedb.

Izbrali smo eno najboljših baz podatkov OLAP, Doris, da poskusim. Ta motor deluje dobro. Vendar smo na neki točki kmalu naleteli na nekaj drugih težav:

• Tipi podatkov, kot sta Array ali JSON, še niso podprti (november 2022). Nizi so običajna vrsta podatkov v nekaterih verigah blokov. Na primer, tematsko polje v dnevnikih evm. Nezmožnost računanja na Array neposredno vpliva na našo sposobnost izračuna številnih poslovnih meritev.
• Omejena podpora za DBT in za izjave o spajanju. To so običajne zahteve za podatkovne inženirje za scenarije ETL/ELT, kjer moramo posodobiti nekaj na novo indeksiranih podatkov.

Kot rečeno, Doris nismo mogli uporabiti za naš celoten podatkovni cevovod v proizvodnji, zato smo poskušali uporabiti Doris kot zbirko podatkov OLAP, da bi rešili del našega problema v produkcijskem cevovodu podatkov, ki je deloval kot mehanizem poizvedb in zagotavljal hitro in visoko zmožnosti sočasnih poizvedb.

Na žalost Bigqueryja nismo mogli zamenjati z Doris, zato smo morali občasno sinhronizirati podatke iz Bigqueryja v Doris in ga uporabljati kot poizvedovalni mehanizem. Ta postopek sinhronizacije je imel več težav, ena od njih je bila, da so se zapisi posodobitev hitro nakopičili, ko je bil mehanizem OLAP zaposlen s streženjem poizvedb sprednjim odjemalcem. Kasneje je bila hitrost pisanja prizadeta, sinhronizacija pa je trajala veliko dlje in včasih celo nemogoča.

Spoznali smo, da bi OLAP lahko rešil več težav, s katerimi se soočamo, in ne bi mogel postati rešitev na ključ za Footprint Analytics, zlasti za cevovod za obdelavo podatkov. Naš problem je večji in kompleksnejši in lahko bi rekli, da nam OLAP kot poizvedovalni mehanizem ni bil dovolj.

4. Arhitektura 3.0 Iceberg + Trino

Dobrodošli v arhitekturi Footprint Analytics 3.0, popolni prenovi osnovne arhitekture. Celotno arhitekturo smo preoblikovali od začetka, da bi shranjevanje, računanje in poizvedovanje podatkov ločili na tri različne dele. Učenje iz dveh prejšnjih arhitektur Footprint Analytics in učenje iz izkušenj drugih uspešnih velikih podatkovnih projektov, kot so Uber, Netflix in Databricks.

4.1. Uvedba podatkovnega jezera

Najprej smo se posvetili podatkovnemu jezeru, novi vrsti podatkovnega shranjevanja za strukturirane in nestrukturirane podatke. Podatkovno jezero je popolno za shranjevanje podatkov v verigi, saj se formati podatkov v verigi zelo razlikujejo od nestrukturiranih neobdelanih podatkov do strukturiranih abstrahiranih podatkov, po katerih je Footprint Analytics dobro znan. Pričakovali smo, da bomo uporabili podatkovno jezero za rešitev problema shranjevanja podatkov, idealno pa bi bilo, da bi podpiralo tudi običajne računalniške motorje, kot sta Spark in Flink, tako da ne bi bilo težav pri integraciji z različnimi vrstami procesnih mehanizmov, ko se Footprint Analytics razvija. .

Iceberg se zelo dobro integrira s Spark, Flink, Trino in drugimi računalniškimi motorji, za vsako od naših metrik pa lahko izberemo najprimernejši izračun. Na primer:

• Za tiste, ki potrebujejo zapleteno računalniško logiko, bo izbira Spark.
• Flink za izračun v realnem času.
• Za enostavne ETL naloge, ki jih lahko izvajamo s SQL, uporabljamo Trino.

4.2. Mehanizem poizvedb

Ker je Iceberg rešil težave s shranjevanjem in računanjem, smo morali razmisliti o izbiri mehanizma poizvedb. Na voljo ni veliko možnosti. Alternative, ki smo jih upoštevali, so bile

Najpomembnejša stvar, ki smo jo upoštevali, preden smo se poglobili, je bila, da mora biti prihodnji mehanizem poizvedb združljiv z našo trenutno arhitekturo.

• Podpreti Bigquery kot vir podatkov
• Za podporo DBT, na katerega se zanašamo pri izdelavi številnih metrik
• Za podporo metabaze orodij BI

Na podlagi zgoraj navedenega smo izbrali Trino, ki ima zelo dobro podporo za Iceberg in ekipa je bila tako odzivna, da smo sprožili napako, ki je bila odpravljena naslednji dan in objavljena v najnovejši različici naslednji teden. To je bila najboljša izbira za ekipo Footprint, ki zahteva tudi visoko odzivnost implementacije.

4.3. Testiranje delovanja

Ko smo se odločili za našo usmeritev, smo izvedli preizkus delovanja na kombinaciji Trino + Iceberg, da bi ugotovili, ali lahko ustreza našim potrebam, in na naše presenečenje so bile poizvedbe neverjetno hitre.

Ker vemo, da je bil Presto + Hive že leta najslabši primerjalnik v vsem pompu OLAP, nas je kombinacija Trino + Iceberg popolnoma prevzela.

Tukaj so rezultati naših testov.

primer 1: pridružite se velikemu naboru podatkov

800 GB tabela1 se pridruži drugi 50 GB tabeli2 in izvaja zapletene poslovne izračune

case2: uporabite veliko posamezno tabelo za izvedbo ločene poizvedbe

Test sql: izberite distinct(address) iz skupine tabel po dnevu

Kombinacija Trino+Iceberg je približno 3-krat hitrejša od Doris v enaki konfiguraciji.

Poleg tega je tu še eno presenečenje, saj lahko Iceberg uporablja podatkovne formate, kot so Parquet, ORC itd., ki bodo stisnili in shranili podatke. Shramba tabele Iceberg zavzame le približno 1/5 prostora drugih skladišč podatkov. Velikost shranjevanja iste tabele v treh zbirkah podatkov je naslednja:

Opomba: Zgornji testi so primeri, s katerimi smo se srečali v dejanski proizvodnji, in so samo za referenco.

4.4. Učinek nadgradnje

Poročila o preizkusu delovanja so nam zagotovila dovolj zmogljivosti, da je naša ekipa potrebovala približno 2 meseca, da je dokončala selitev, in to je diagram naše arhitekture po nadgradnji.

• Več računalniških mehanizmov ustreza našim različnim potrebam.
• Trino podpira DBT in lahko neposredno poizveduje po Icebergu, tako da se nam ni več treba ukvarjati s sinhronizacijo podatkov.
• Neverjetna zmogljivost Trino + Iceberg nam omogoča, da uporabnikom odpremo vse Bronze podatke (surove podatke).

5. Povzetek

Od svoje uvedbe avgusta 2021 je ekipa Footprint Analytics zaključila tri arhitekturne nadgradnje v manj kot letu in pol, zahvaljujoč svoji močni želji in odločenosti, da svojim kripto uporabnikom prinese prednosti najboljše tehnologije podatkovnih baz ter solidni izvedbi pri implementaciji in nadgradnjo osnovne infrastrukture in arhitekture.

Nadgradnja arhitekture Footprint Analytics 3.0 je svojim uporabnikom omogočila novo izkušnjo, ki uporabnikom iz različnih okolij omogoča vpogled v bolj raznoliko uporabo in aplikacije:

• Footprint, zgrajen z orodjem Metabase BI, analitikom omogoča dostop do dekodiranih podatkov v verigi, raziskovanje s popolno svobodo izbire orodij (brez kode ali s trdim kablom), poizvedovanje po celotni zgodovini in navzkrižno preizkušanje naborov podatkov, da dobijo vpogled v ni časa.
• Integrirajte tako podatke v verigi kot zunaj verige v analizo prek web2 + web3;
• Z izgradnjo/poizvedovanjem meritev na podlagi Footprintove poslovne abstrakcije analitiki ali razvijalci prihranijo čas pri 80 % ponavljajočih se obdelav podatkov in se osredotočijo na smiselne meritve, raziskave in rešitve izdelkov, ki temeljijo na njihovem poslovanju.
• Brezhibna izkušnja od klicev Footprint Web do REST API, vse temelji na SQL
• Opozorila v realnem času in obvestila o ključnih signalih za podporo naložbenim odločitvam