o stivă modernă de date open source pentru blockchain

1. Provocarea pentru stiva de date blockchain modernă

Există mai multe provocări cu care se poate confrunta o startup modernă de indexare blockchain, inclusiv:

• Cantități masive de date. Pe măsură ce cantitatea de date din blockchain crește, indexul de date va trebui să se extindă pentru a face față sarcinii crescute și pentru a oferi acces eficient la date. În consecință, duce la costuri de stocare mai mari, calcule lente ale valorilor și încărcare crescută pe serverul bazei de date.
• Conductă complexă de procesare a datelor. Tehnologia blockchain este complexă, iar construirea unui index de date cuprinzător și fiabil necesită o înțelegere profundă a structurilor și algoritmilor de date subiacente. Diversitatea implementărilor blockchain o moștenește. Având în vedere exemple specifice, NFT-urile în Ethereum sunt de obicei create în cadrul contractelor inteligente, urmând formatele ERC721 și ERC1155. În schimb, implementarea celor de pe Polkadot, de exemplu, este de obicei construită direct în timpul de execuție blockchain. Acestea ar trebui considerate NFT și ar trebui salvate ca acestea.
• Capabilitati de integrare. Pentru a oferi o valoare maximă utilizatorilor, o soluție de indexare blockchain poate avea nevoie să-și integreze indexul de date cu alte sisteme, cum ar fi platformele de analiză sau API-urile. Acest lucru este o provocare și necesită un efort semnificativ depus în proiectarea arhitecturii.

Pe măsură ce tehnologia blockchain a devenit mai răspândită, cantitatea de date stocate pe blockchain a crescut. Acest lucru se datorează faptului că mai mulți oameni folosesc tehnologia și fiecare tranzacție adaugă date noi în blockchain. În plus, tehnologia blockchain a evoluat de la aplicații simple de transfer de bani, cum ar fi cele care implică utilizarea Bitcoin, la aplicații mai complexe care implică implementarea logicii de afaceri în cadrul contractelor inteligente. Aceste contracte inteligente pot genera cantități mari de date, contribuind la creșterea complexității și dimensiunii blockchain-ului. De-a lungul timpului, acest lucru a dus la un blockchain mai mare și mai complex.

În acest articol, trecem în revistă evoluția arhitecturii tehnologiei Footprint Analytics în etape, ca un studiu de caz pentru a explora modul în care tehnologia Iceberg-Trino abordează provocările date în lanț.

Footprint Analytics a indexat aproximativ 22 de date blockchain publice și 17 piețe NFT, 1900 de proiecte GameFi și peste 100,000 de colecții NFT într-un strat de date de abstracție semantică. Este cea mai cuprinzătoare soluție de depozit de date blockchain din lume.

Indiferent de datele blockchain, care includ peste 20 de miliarde de rânduri de înregistrări ale tranzacțiilor financiare, pe care analiștii de date le interogează frecvent. este diferit de jurnalele de intrare în depozitele tradiționale de date.

Am experimentat 3 upgrade-uri majore în ultimele câteva luni pentru a îndeplini cerințele de afaceri în creștere:

2. Arhitectură 1.0 Bigquery

La începutul Footprint Analytics, am folosit Google Bigquery ca motor de stocare și interogare; Bigquery este un produs grozav. Este extraordinar de rapid, ușor de utilizat și oferă o putere aritmetică dinamică și o sintaxă UDF flexibilă care ne ajută să facem rapid treaba.

Cu toate acestea, Bigquery are și câteva probleme.

• Datele nu sunt comprimate, ceea ce duce la costuri ridicate, mai ales atunci când se stochează date brute a peste 22 de blockchain-uri ale Footprint Analytics.
• Concurență insuficientă: Bigquery acceptă doar 100 de interogări simultane, ceea ce nu este potrivit pentru scenariile de concurență ridicată pentru Footprint Analytics atunci când deservesc mulți analiști și utilizatori.
• Blocați-vă cu Google Bigquery, care este un produs cu sursă închisă。

Așa că am decis să explorăm alte arhitecturi alternative.

3. Arhitectură 2.0 OLAP

Am fost foarte interesați de unele dintre produsele OLAP care au devenit foarte populare. Cel mai atractiv avantaj al OLAP este timpul de răspuns la interogări, care de obicei durează mai puțin de secunde pentru a returna rezultate ale interogărilor pentru cantități masive de date și poate suporta, de asemenea, mii de interogări simultane.

Am ales una dintre cele mai bune baze de date OLAP, Doris, pentru a-i încerca. Acest motor funcționează bine. Cu toate acestea, la un moment dat, ne-am confruntat cu alte probleme:

• Tipurile de date precum Array sau JSON nu sunt încă acceptate (noiembrie 2022). Matricele sunt un tip comun de date în unele blockchain-uri. De exemplu, cel câmp tematic în jurnalele evm. Imposibilitatea de a calcula pe Array afectează direct capacitatea noastră de a calcula multe valori de afaceri.
• Suport limitat pentru DBT și pentru declarațiile de îmbinare. Acestea sunt cerințe comune pentru inginerii de date pentru scenariile ETL/ELT în care trebuie să actualizăm unele date nou indexate.

Acestea fiind spuse, nu am putut folosi Doris pentru întreaga conductă de date în producție, așa că am încercat să folosim Doris ca bază de date OLAP pentru a rezolva o parte a problemei noastre în conducta de producție de date, acționând ca un motor de interogare și oferind rapid și înalt nivel. capabilități de interogare simultană.

Din păcate, nu am putut înlocui Bigquery cu Doris, așa că a trebuit să sincronizăm periodic datele de la Bigquery la Doris folosindu-l ca motor de interogare. Acest proces de sincronizare a avut mai multe probleme, dintre care una a fost că scrierile de actualizare s-au acumulat rapid atunci când motorul OLAP era ocupat cu interogări către clienții front-end. Ulterior, viteza procesului de scriere a fost afectată, iar sincronizarea a durat mult mai mult și uneori chiar a devenit imposibil de finalizat.

Ne-am dat seama că OLAP ar putea rezolva mai multe probleme cu care ne confruntăm și nu ar putea deveni soluția la cheie a Footprint Analytics, în special pentru conducta de procesare a datelor. Problema noastră este mai mare și mai complexă și am putea spune că OLAP ca motor de interogare nu a fost suficient pentru noi.

4. Arhitectură 3.0 Aisberg + Trino

Bun venit la arhitectura Footprint Analytics 3.0, o revizuire completă a arhitecturii de bază. Am reproiectat întreaga arhitectură de la zero pentru a separa stocarea, calculul și interogarea datelor în trei părți diferite. Luând lecții din cele două arhitecturi anterioare ale Footprint Analytics și învățând din experiența altor proiecte de date mari de succes precum Uber, Netflix și Databricks.

4.1. Introducerea lacului de date

Mai întâi ne-am îndreptat atenția către data lake, un nou tip de stocare a datelor atât pentru date structurate, cât și pentru cele nestructurate. Data lake este perfect pentru stocarea datelor în lanț, deoarece formatele datelor în lanț variază pe scară largă, de la date brute nestructurate la date de abstractizare structurate pentru care Footprint Analytics este binecunoscut. Ne așteptam să folosim data lake pentru a rezolva problema stocării datelor și, în mod ideal, ar accepta și motoarele de calcul obișnuite, cum ar fi Spark și Flink, astfel încât să nu fie dificil să se integreze cu diferite tipuri de motoare de procesare pe măsură ce Footprint Analytics evoluează .

Iceberg se integrează foarte bine cu Spark, Flink, Trino și alte motoare de calcul și putem alege cel mai potrivit calcul pentru fiecare dintre valorile noastre. De exemplu:

• Pentru cei care necesită o logică de calcul complexă, Spark va fi alegerea.
• Flink pentru calcul în timp real.
• Pentru sarcini ETL simple care pot fi efectuate folosind SQL, folosim Trino.

4.2. Motor de interogări

Cu Iceberg rezolvarea problemelor de stocare și calcul, a trebuit să ne gândim la alegerea unui motor de interogare. Nu sunt multe opțiuni disponibile. Alternativele pe care le-am luat în considerare au fost

Cel mai important lucru pe care l-am luat în considerare înainte de a aprofunda a fost că viitorul motor de interogări trebuia să fie compatibil cu arhitectura noastră actuală.

• Pentru a accepta Bigquery ca sursă de date
• Pentru a sprijini DBT, pe care ne bazăm pentru ca multe valori să fie produse
• Pentru a sprijini metabaza instrumentului BI

Pe baza celor de mai sus, am ales Trino, care are un suport foarte bun pentru Iceberg, iar echipa a fost atât de receptivă încât am ridicat un bug, care a fost remediat a doua zi și lansat în cea mai recentă versiune săptămâna următoare. Aceasta a fost cea mai bună alegere pentru echipa Footprint, care necesită, de asemenea, o capacitate de răspuns ridicată la implementare.

4.3. Test de performanta

Odată ce ne-am hotărât direcția, am făcut un test de performanță pe combinația Trino + Iceberg pentru a vedea dacă ne poate satisface nevoile și spre surprinderea noastră, interogările au fost incredibil de rapide.

Știind că Presto + Hive a fost cel mai prost comparator de ani de zile în tot hypeul OLAP, combinația Trino + Iceberg ne-a uluit complet.

Iată rezultatele testelor noastre.

cazul 1: alăturați un set de date mare

Un tabel de 800 GB1 se alătură altui tabel de 50 GB2 și face calcule complexe de afaceri

case2: utilizați un singur tabel mare pentru a efectua o interogare distinctă

Test sql: selectați distinct(adresă) din grupul de tabel în funcție de zi

Combinația Trino+Iceberg este de aproximativ 3 ori mai rapidă decât Doris în aceeași configurație.

În plus, există o altă surpriză pentru că Iceberg poate folosi formate de date precum Parquet, ORC etc., care vor comprima și stoca datele. Stocarea tabelului Iceberg ocupă doar aproximativ 1/5 din spațiul altor depozite de date Mărimea de stocare a aceluiași tabel în cele trei baze de date este următoarea:

Notă: Testele de mai sus sunt exemple pe care le-am întâlnit în producția reală și sunt doar pentru referință.

4.4. Efect de upgrade

Rapoartele de testare a performanței ne-au oferit suficientă performanță încât echipa noastră a avut nevoie de aproximativ 2 luni pentru a finaliza migrarea, iar aceasta este o diagramă a arhitecturii noastre după actualizare.

• Mai multe motoare de computer se potrivesc diverselor noastre nevoi.
• Trino acceptă DBT și poate interoga direct Iceberg, așa că nu mai trebuie să ne ocupăm de sincronizarea datelor.
• Performanța uimitoare a lui Trino + Iceberg ne permite să deschidem utilizatorilor noștri toate datele Bronze (date brute).

5. Rezumat

De la lansarea sa în august 2021, echipa Footprint Analytics a finalizat trei upgrade-uri arhitecturale în mai puțin de un an și jumătate, datorită dorinței sale puternice și hotărârii de a aduce beneficiile celei mai bune tehnologii de baze de date utilizatorilor săi cripto și execuției solide în implementarea și modernizarea infrastructurii și arhitecturii de bază.

Actualizarea arhitecturii Footprint Analytics 3.0 a oferit o nouă experiență utilizatorilor săi, permițând utilizatorilor din medii diferite să obțină informații despre utilizarea și aplicațiile mai diverse:

• Creat cu instrumentul Metabase BI, Footprint facilitează analiștilor să obțină acces la date decodificate în lanț, să exploreze cu libertate completă de alegere a instrumentelor (fără cod sau hardcord), să interogheze întregul istoric și să examineze încrucișat seturi de date, pentru a obține informații despre nu este timp.
• Integrați atât datele din lanț, cât și cele din afara lanțului în analize pe web2 + web3;
• Prin construirea/interogarea valorilor pe partea de sus a abstractizării afacerii Footprint, analiștii sau dezvoltatorii economisesc timp pentru 80% din munca repetitivă de procesare a datelor și se concentrează pe valori semnificative, cercetare și soluții de produs bazate pe afacerea lor.
• Experiență perfectă de la Footprint Web la apelurile API REST, toate bazate pe SQL
• Alerte în timp real și notificări acționabile privind semnalele cheie pentru a sprijini deciziile de investiții