një grumbull modern i të dhënave me burim të hapur për blockchain

1. Sfida për grumbullin e të dhënave moderne të blockchain

Ka disa sfida me të cilat mund të përballet një startup modern i indeksimit të blockchain, duke përfshirë:

• Sasi masive të dhënash. Ndërsa sasia e të dhënave në blockchain rritet, indeksi i të dhënave do të duhet të rritet për të trajtuar ngarkesën e rritur dhe për të siguruar qasje efikase në të dhëna. Rrjedhimisht, kjo çon në kosto më të larta të ruajtjes, llogaritje të ngadalta të metrikës dhe rritje të ngarkesës në serverin e bazës së të dhënave.
• Tubacioni kompleks i përpunimit të të dhënave. Teknologjia Blockchain është komplekse dhe ndërtimi i një indeksi gjithëpërfshirës dhe të besueshëm të të dhënave kërkon një kuptim të thellë të strukturave dhe algoritmeve themelore të të dhënave. Shumëllojshmëria e zbatimeve të blockchain e trashëgon atë. Duke pasur parasysh shembuj specifikë, NFT-të në Ethereum zakonisht krijohen brenda kontratave inteligjente duke ndjekur formatet ERC721 dhe ERC1155. Në të kundërt, zbatimi i atyre në Polkadot, për shembull, zakonisht ndërtohet direkt brenda kohës së funksionimit të blockchain. Ato duhet të konsiderohen NFT dhe duhet të ruhen si ato.
• Aftësitë integruese. Për të ofruar vlerën maksimale për përdoruesit, një zgjidhje e indeksimit të blockchain mund të duhet të integrojë indeksin e saj të të dhënave me sisteme të tjera, të tilla si platformat analitike ose API. Kjo është sfiduese dhe kërkon përpjekje të konsiderueshme të vendosura në dizajnin e arkitekturës.

Ndërsa teknologjia blockchain është bërë më e përhapur, sasia e të dhënave të ruajtura në blockchain është rritur. Kjo është për shkak se më shumë njerëz po përdorin teknologjinë dhe çdo transaksion shton të dhëna të reja në blockchain. Për më tepër, teknologjia blockchain ka evoluar nga aplikacione të thjeshta të transferimit të parave, të tilla si ato që përfshijnë përdorimin e Bitcoin, në aplikacione më komplekse që përfshijnë zbatimin e logjikës së biznesit brenda kontratave inteligjente. Këto kontrata inteligjente mund të gjenerojnë sasi të mëdha të dhënash, duke kontribuar në rritjen e kompleksitetit dhe madhësisë së blockchain. Me kalimin e kohës, kjo ka çuar në një blockchain më të madh dhe më kompleks.

Në këtë artikull, ne shqyrtojmë evolucionin e arkitekturës së teknologjisë së Footprint Analytics në faza si një rast studimor për të eksploruar se si grumbulli i teknologjisë Iceberg-Trino adreson sfidat e të dhënave në zinxhir.

Footprint Analytics ka indeksuar rreth 22 të dhëna publike të blockchain dhe 17 tregje NFT, 1900 projekt GameFi dhe mbi 100,000 koleksione NFT në një shtresë të dhënash abstraksioni semantik. Është zgjidhja më gjithëpërfshirëse e magazinës së të dhënave të blockchain në botë.

Pavarësisht nga të dhënat e blockchain, të cilat përfshijnë mbi 20 miliardë rreshta regjistrimesh të transaksioneve financiare, të cilat analistët e të dhënave shpesh i pyesin. është i ndryshëm nga regjistrat e hyrjes në magazinat tradicionale të të dhënave.

Ne kemi përjetuar 3 përmirësime të mëdha në muajt e fundit për të përmbushur kërkesat në rritje të biznesit:

2. Arkitekturë 1.0 Bigquery

Në fillim të Footprint Analytics, ne përdorëm Google Bigquery si motori ynë i ruajtjes dhe kërkimit; Bigquery është një produkt i shkëlqyer. Është jashtëzakonisht i shpejtë, i lehtë për t'u përdorur dhe ofron fuqi dinamike aritmetike dhe një sintaksë fleksibël UDF që na ndihmon ta kryejmë shpejt punën.

Sidoqoftë, Bigquery gjithashtu ka disa probleme.

• Të dhënat nuk kompresohen, duke rezultuar në kosto të larta, veçanërisht kur ruhen të dhëna të papërpunuara të mbi 22 zinxhirëve të bllokut të Footprint Analytics.
• Konkurrenca e pamjaftueshme: Bigquery mbështet vetëm 100 pyetje të njëkohshme, gjë që është e papërshtatshme për skenarët e konkurencës së lartë për Analitikën e gjurmës kur u shërben shumë analistëve dhe përdoruesve.
• Bllokohu me Google Bigquery, i cili është një produkt me burim të mbyllur.

Kështu që vendosëm të eksploronim arkitektura të tjera alternative.

3. Arkitektura 2.0 OLAP

Ne ishim shumë të interesuar për disa nga produktet OLAP të cilat ishin bërë shumë të njohura. Avantazhi më tërheqës i OLAP është koha e përgjigjes së pyetjes, e cila zakonisht kërkon nën-sekonda për të kthyer rezultatet e pyetjeve për sasi masive të të dhënave, dhe gjithashtu mund të mbështesë mijëra pyetje të njëkohshme.

Ne zgjodhëm një nga bazat e të dhënave më të mira OLAP, Doris, për ta provuar. Ky motor performon mirë. Megjithatë, në një moment ne shpejt u përballëm me disa çështje të tjera:

• Llojet e të dhënave si Array ose JSON nuk mbështeten ende (nëntor 2022). Vargjet janë një lloj i zakonshëm i të dhënave në disa blockchain. Për shembull, fusha e temës në regjistrat evm. Pamundësia për të llogaritur në Array ndikon drejtpërdrejt në aftësinë tonë për të llogaritur shumë metrika të biznesit.
• Mbështetje e kufizuar për DBT, dhe për deklaratat e bashkimit. Këto janë kërkesa të zakonshme për inxhinierët e të dhënave për skenarët ETL/ELT ku duhet të përditësojmë disa të dhëna të reja të indeksuara.

Thënë kjo, ne nuk mund të përdornim Doris për të gjithë tubacionin tonë të të dhënave në prodhim, kështu që u përpoqëm të përdorim Doris si një bazë të dhënash OLAP për të zgjidhur një pjesë të problemit tonë në tubacionin e prodhimit të të dhënave, duke vepruar si një motor kërkimi dhe duke ofruar shpejt dhe shumë aftësitë e pyetjeve të njëkohshme.

Fatkeqësisht, ne nuk mund ta zëvendësonim Bigquery me Doris, kështu që na u desh të sinkronizonim periodikisht të dhënat nga Bigquery në Doris duke i përdorur ato si një motor kërkimi. Ky proces sinkronizimi kishte disa probleme, një prej të cilave ishte se shkrimet e përditësimit u grumbulluan shpejt kur motori OLAP ishte i zënë me shërbimin e pyetjeve për klientët e përparme. Më pas, shpejtësia e procesit të shkrimit u ndikua dhe sinkronizimi zgjati shumë më tepër dhe ndonjëherë edhe bëhej i pamundur të përfundonte.

Kuptuam se OLAP mund të zgjidhte disa çështje me të cilat përballemi dhe nuk mund të bëhej zgjidhja kyçe e Footprint Analytics, veçanërisht për tubacionin e përpunimit të të dhënave. Problemi ynë është më i madh dhe më i ndërlikuar, dhe mund të themi se OLAP si një motor pyetësor nuk ishte i mjaftueshëm për ne.

4. Arkitekturë 3.0 Iceberg + Trino

Mirë se vini në arkitekturën 3.0 të Footprint Analytics, një rishikim i plotë i arkitekturës themelore. Ne kemi ridizajnuar të gjithë arkitekturën nga themeli për të ndarë ruajtjen, llogaritjen dhe kërkimin e të dhënave në tre pjesë të ndryshme. Marrja e mësimeve nga dy arkitekturat e mëparshme të Footprint Analytics dhe mësimi nga përvoja e projekteve të tjera të suksesshme të të dhënave të mëdha si Uber, Netflix dhe Databricks.

4.1. Prezantimi i liqenit të të dhënave

Fillimisht e kthyem vëmendjen te data lake, një lloj i ri i ruajtjes së të dhënave për të dhënat e strukturuara dhe të pastrukturuara. Data Lake është perfekt për ruajtjen e të dhënave në zinxhir pasi formatet e të dhënave në zinxhir variojnë gjerësisht nga të dhënat e papërpunuara të pastrukturuara deri te të dhënat e strukturuara të abstraksionit Footprint Analytics. Ne prisnim të përdornim liqenin e të dhënave për të zgjidhur problemin e ruajtjes së të dhënave, dhe në mënyrë ideale ai do të mbështeste gjithashtu motorët kompjuterikë të zakonshëm si Spark dhe Flink, në mënyrë që të mos ishte e vështirë të integrohej me lloje të ndryshme motorësh përpunues ndërsa evoluon Footprint Analytics. .

Iceberg integrohet shumë mirë me Spark, Flink, Trino dhe motorë të tjerë llogaritës, dhe ne mund të zgjedhim llogaritjen më të përshtatshme për secilën nga metrikat tona. Për shembull:

• Për ata që kërkojnë logjikë komplekse llogaritëse, Spark do të jetë zgjedhja.
• Flink për llogaritje në kohë reale.
• Për detyra të thjeshta ETL që mund të kryhen duke përdorur SQL, ne përdorim Trino.

4.2. Motori i pyetjeve

Me Iceberg që zgjidh problemet e ruajtjes dhe llogaritjes, ne duhej të mendonim për zgjedhjen e një motori të pyetjeve. Nuk ka shumë opsione në dispozicion. Alternativat që kemi shqyrtuar ishin

Gjëja më e rëndësishme që kemi marrë parasysh përpara se të thellojmë ishte se motori i kërkimit të ardhshëm duhej të ishte i pajtueshëm me arkitekturën tonë aktuale.

• Për të mbështetur Bigquery si një burim të dhënash
• Për të mbështetur DBT, në të cilën ne mbështetemi për të prodhuar shumë metrika
• Për të mbështetur metabazën e veglave BI

Bazuar në sa më sipër, ne zgjodhëm Trino, e cila ka mbështetje shumë të mirë për Iceberg dhe ekipi ishte aq i përgjegjshëm sa ngritëm një gabim, i cili u rregullua të nesërmen dhe u lëshua në versionin më të fundit javën e ardhshme. Kjo ishte zgjidhja më e mirë për ekipin e Footprint, i cili gjithashtu kërkon një përgjegjshmëri të lartë të zbatimit.

4.3. Testimi i performancës

Pasi vendosëm për drejtimin tonë, bëmë një test të performancës në kombinimin Trino + Iceberg për të parë nëse ai mund të plotësonte nevojat tona dhe për habinë tonë, pyetjet ishin tepër të shpejta.

Duke ditur që Presto + Hive ka qenë krahasuesi më i keq për vite me radhë në të gjithë zhurmën e OLAP, kombinimi i Trino + Iceberg na shpërtheu plotësisht.

Këtu janë rezultatet e testeve tona.

rasti 1: bashkoni një grup të madh të dhënash

Një tabelë 800 GB1 bashkohet me një tabelë tjetër 50 GB2 dhe bën llogaritje komplekse biznesi

rasti 2: përdorni një tabelë të madhe të vetme për të bërë një pyetje të veçantë

Test sql: zgjidhni të dallueshme(adresa) nga grupi i tabelës sipas ditës

Kombinimi Trino+Iceberg është rreth 3 herë më i shpejtë se Doris në të njëjtin konfigurim.

Përveç kësaj, ka edhe një surprizë tjetër sepse Iceberg mund të përdorë formate të dhënash si Parket, ORC etj., të cilat do të kompresojnë dhe ruajnë të dhënat. Ruajtja e tabelës së Iceberg zë vetëm rreth 1/5 e hapësirës së magazinës së të dhënave të tjera. Madhësia e ruajtjes së së njëjtës tabelë në tre bazat e të dhënave është si më poshtë:

Shënim: Testet e mësipërme janë shembuj që kemi hasur në prodhimin aktual dhe janë vetëm për referencë.

4.4. Efekti i përmirësimit

Raportet e testit të performancës na dhanë performancë të mjaftueshme sa që ekipit tonë iu deshën rreth 2 muaj për të përfunduar migrimin, dhe ky është një diagram i arkitekturës sonë pas përmirësimit.

• Motorë të shumtë kompjuterësh përputhen me nevojat tona të ndryshme.
• Trino mbështet DBT dhe mund të kërkojë drejtpërdrejt Iceberg, kështu që ne nuk duhet të merremi më me sinkronizimin e të dhënave.
• Performanca e mahnitshme e Trino + Iceberg na lejon të hapim të gjitha të dhënat Bronze (të dhëna të papërpunuara) për përdoruesit tanë.

5. përmbledhje

Që nga fillimi i tij në gusht 2021, ekipi i Footprint Analytics ka përfunduar tre përmirësime arkitekturore në më pak se një vit e gjysmë, falë dëshirës dhe vendosmërisë së tij të fortë për të sjellë përfitimet e teknologjisë më të mirë të bazës së të dhënave për përdoruesit e tij të kriptove dhe ekzekutimit të fortë në zbatimin dhe përmirësimin e infrastrukturës dhe arkitekturës së saj themelore.

Përmirësimi 3.0 i arkitekturës së Footprint Analytics ka blerë një përvojë të re për përdoruesit e tij, duke i lejuar përdoruesit me prejardhje të ndryshme të marrin njohuri për përdorime dhe aplikacione më të ndryshme:

• E ndërtuar me mjetin Metabase BI, Footprint lehtëson analistët të kenë akses në të dhënat e deshifruara në zinxhir, të eksplorojnë me lirinë e plotë të zgjedhjes së mjeteve (pa kod ose hard kordë), të kërkojnë të gjithë historinë dhe të shqyrtojnë grupet e të dhënave, për të marrë njohuri në nuk ka kohë.
• Integroni të dhënat brenda dhe jashtë zinxhirit për analiza në web2 + ueb3;
• Duke ndërtuar metrika / pyetje në krye të abstraksionit të biznesit të Footprint, analistët ose zhvilluesit kursejnë kohë në 80% të punës së përsëritur të përpunimit të të dhënave dhe fokusohen në metrikë kuptimplotë, kërkime dhe zgjidhje produkti bazuar në biznesin e tyre.
• Përvojë pa probleme nga Footprint Web në thirrjet REST API, të gjitha të bazuara në SQL
• Sinjalizime në kohë reale dhe njoftime vepruese për sinjalet kryesore për të mbështetur vendimet e investimeve