isang modernong open source data stack para sa blockchain

1.Ang hamon para sa modernong blockchain data stack

Mayroong ilang mga hamon na maaaring harapin ng isang modernong blockchain indexing startup, kabilang ang:

• Napakalaking dami ng data. Habang tumataas ang dami ng data sa blockchain, ang data index ay kailangang mag-scale up para mahawakan ang tumaas na load at magbigay ng mahusay na access sa data. Dahil dito, humahantong ito sa mas mataas na mga gastos sa imbakan, mabagal na pagkalkula ng mga sukatan, at pagtaas ng pagkarga sa server ng database.
• Kumplikadong pipeline ng pagproseso ng data. Ang teknolohiya ng Blockchain ay kumplikado, at ang pagbuo ng isang komprehensibo at maaasahang index ng data ay nangangailangan ng malalim na pag-unawa sa pinagbabatayan na mga istruktura at algorithm ng data. Ang pagkakaiba-iba ng mga pagpapatupad ng blockchain ay nagmamana nito. Dahil sa mga partikular na halimbawa, ang mga NFT sa Ethereum ay karaniwang ginagawa sa loob ng mga smart contract kasunod ng mga format na ERC721 at ERC1155. Sa kabaligtaran, ang pagpapatupad ng mga nasa Polkadot, halimbawa, ay karaniwang binuo nang direkta sa loob ng blockchain runtime. Ang mga iyon ay dapat ituring na mga NFT at dapat na i-save bilang mga iyon.
• Mga kakayahan sa pagsasama. Upang magbigay ng pinakamataas na halaga sa mga user, maaaring kailanganin ng isang blockchain indexing solution na isama ang data index nito sa iba pang mga system, gaya ng mga analytics platform o API. Ito ay mapaghamong at nangangailangan ng malaking pagsisikap na inilagay sa disenyo ng arkitektura.

Habang ang teknolohiya ng blockchain ay naging mas malawak, ang dami ng data na nakaimbak sa blockchain ay tumaas. Ito ay dahil mas maraming tao ang gumagamit ng teknolohiya, at ang bawat transaksyon ay nagdaragdag ng bagong data sa blockchain. Bukod pa rito, ang teknolohiya ng blockchain ay umunlad mula sa mga simpleng application na naglilipat ng pera, tulad ng mga may kinalaman sa paggamit ng Bitcoin, hanggang sa mas kumplikadong mga application na kinasasangkutan ng pagpapatupad ng lohika ng negosyo sa loob ng mga matalinong kontrata. Ang mga matalinong kontrata na ito ay maaaring makabuo ng malaking halaga ng data, na nag-aambag sa pagtaas ng pagiging kumplikado at laki ng blockchain. Sa paglipas ng panahon, ito ay humantong sa isang mas malaki at mas kumplikadong blockchain.

Sa artikulong ito, sinusuri namin ang ebolusyon ng arkitektura ng teknolohiya ng Footprint Analytics bilang isang case study para tuklasin kung paano tinutugunan ng Iceberg-Trino technology stack ang mga hamon ng on-chain na data.

Ang Footprint Analytics ay nag-index ng humigit-kumulang 22 pampublikong blockchain data, at 17 NFT marketplace, 1900 GameFi project, at mahigit 100,000 NFT na koleksyon sa isang semantic abstraction data layer. Ito ang pinakakomprehensibong blockchain data warehouse solution sa mundo.

Anuman ang data ng blockchain, na kinabibilangan ng higit sa 20 bilyong hanay ng mga talaan ng mga transaksyong pinansyal, na madalas itanong ng mga data analyst. iba ito sa mga log ng ingression sa mga tradisyunal na warehouse ng data.

Nakaranas kami ng 3 pangunahing pag-upgrade sa nakalipas na ilang buwan upang matugunan ang lumalaking pangangailangan sa negosyo:

2. Arkitektura 1.0 Bigquery

Sa simula ng Footprint Analytics, ginamit namin Google Bigquery bilang aming storage at query engine; Ang Bigquery ay isang mahusay na produkto. Ito ay napakabilis, madaling gamitin, at nagbibigay ng dynamic na arithmetic power at isang flexible na UDF syntax na tumutulong sa aming mabilis na matapos ang trabaho.

Gayunpaman, ang Bigquery ay mayroon ding ilang mga problema.

• Hindi na-compress ang data, na nagreresulta sa mataas na gastos, lalo na kapag nag-iimbak ng raw data ng higit sa 22 blockchain ng Footprint Analytics.
• Hindi sapat na concurrency: Sinusuportahan lamang ng Bigquery ang 100 sabay-sabay na mga query, na hindi angkop para sa mataas na concurrency na mga sitwasyon para sa Footprint Analytics kapag nagsisilbi sa maraming analyst at user.
• I-lock in gamit ang Google Bigquery, na isang closed-source na produkto.

Kaya nagpasya kaming galugarin ang iba pang mga alternatibong arkitektura.

3. Arkitektura 2.0 OLAP

Lubos kaming interesado sa ilan sa mga produkto ng OLAP na naging napakasikat. Ang pinakakaakit-akit na bentahe ng OLAP ay ang oras ng pagtugon sa query nito, na karaniwang tumatagal ng mga sub-segundo upang maibalik ang mga resulta ng query para sa napakalaking dami ng data, at maaari rin itong suportahan ang libu-libong kasabay na mga query.

Pinili namin ang isa sa mga pinakamahusay na database ng OLAP, Doris, upang subukan ito. Mahusay na gumaganap ang makinang ito. Gayunpaman, sa ilang sandali ay nakatagpo kami ng ilang iba pang mga isyu:

• Ang mga uri ng data gaya ng Array o JSON ay hindi pa sinusuportahan (Nob, 2022). Ang mga array ay isang karaniwang uri ng data sa ilang mga blockchain. Halimbawa, ang larangan ng paksa sa mga evm log. Ang hindi makapag-compute sa Array ay direktang nakakaapekto sa aming kakayahang mag-compute ng maraming sukatan ng negosyo.
• Limitadong suporta para sa DBT, at para sa mga merge statement. Ito ang mga karaniwang kinakailangan para sa mga inhinyero ng data para sa mga sitwasyong ETL/ELT kung saan kailangan naming mag-update ng ilang bagong na-index na data.

Iyon ay sinabi, hindi namin magagamit ang Doris para sa aming buong pipeline ng data sa produksyon, kaya sinubukan naming gamitin ang Doris bilang isang database ng OLAP upang malutas ang bahagi ng aming problema sa pipeline ng produksyon ng data, na kumikilos bilang isang query engine at nagbibigay ng mabilis at mataas. sabay-sabay na mga kakayahan sa query.

Sa kasamaang palad, hindi namin mapapalitan ang Bigquery ng Doris, kaya kailangan naming pana-panahong i-synchronize ang data mula sa Bigquery hanggang Doris gamit ito bilang isang query engine. Ang proseso ng pag-synchronise na ito ay nagkaroon ng ilang mga isyu, isa na rito ay ang pag-update ng mga pagsusulat ay mabilis na nakasalansan kapag ang OLAP engine ay abala sa paghahatid ng mga query sa mga front-end na kliyente. Kasunod nito, ang bilis ng proseso ng pagsulat ay naapektuhan, at ang pag-synchronize ay tumagal nang mas matagal at kung minsan ay naging imposibleng matapos.

Napagtanto namin na maaaring malutas ng OLAP ang ilang isyu na kinakaharap namin at hindi maaaring maging turnkey na solusyon ng Footprint Analytics, lalo na para sa pipeline ng pagproseso ng data. Ang aming problema ay mas malaki at mas kumplikado, at maaari naming sabihin na ang OLAP bilang isang query engine lamang ay hindi sapat para sa amin.

4. Arkitektura 3.0 Iceberg + Trino

Maligayang pagdating sa Footprint Analytics architecture 3.0, isang kumpletong pag-overhaul ng pinagbabatayan na arkitektura. Muli naming idinisenyo ang buong arkitektura mula sa simula upang paghiwalayin ang storage, computation at query ng data sa tatlong magkakaibang piraso. Kumuha ng mga aral mula sa dalawang naunang arkitektura ng Footprint Analytics at natututo mula sa karanasan ng iba pang matagumpay na malalaking proyekto ng data tulad ng Uber, Netflix, at Databricks.

4.1. Panimula ng data lake

Una naming ibinaling ang aming pansin sa data lake, isang bagong uri ng data storage para sa parehong structured at unstructured na data. Ang data lake ay perpekto para sa on-chain na pag-iimbak ng data dahil ang mga format ng on-chain na data ay malawak na saklaw mula sa hindi nakabalangkas na raw data hanggang sa structured abstraction na data ng Footprint Analytics ay kilala para sa. Inaasahan naming gagamit ng data lake para lutasin ang problema sa pag-iimbak ng data, at pinakamainam na susuportahan din nito ang mga mainstream na compute engine gaya ng Spark at Flink, nang sa gayon ay hindi mahirap na isama sa iba't ibang uri ng mga processing engine habang umuunlad ang Footprint Analytics .

Napakahusay na pinagsama ng Iceberg sa Spark, Flink, Trino at iba pang mga computational engine, at maaari naming piliin ang pinakaangkop na pagkalkula para sa bawat isa sa aming mga sukatan. Halimbawa:

• Para sa mga nangangailangan ng kumplikadong computational logic, Spark ang pipiliin.
• Flink para sa real-time na pagtutuos.
• Para sa mga simpleng gawain sa ETL na maaaring gawin gamit ang SQL, ginagamit namin ang Trino.

4.2. Query engine

Sa paglutas ng Iceberg sa mga problema sa pag-iimbak at pag-compute, kinailangan naming mag-isip tungkol sa pagpili ng isang query engine. Walang maraming mga pagpipilian na magagamit. Ang mga alternatibong naisip namin ay

Ang pinakamahalagang bagay na isinasaalang-alang namin bago lumalim ay ang hinaharap na query engine ay kailangang tugma sa aming kasalukuyang arkitektura.

• Para suportahan ang Bigquery bilang Data Source
• Upang suportahan ang DBT, kung saan kami umaasa para sa maraming sukatan na gagawin
• Para suportahan ang BI tool metabase

Batay sa itaas, pinili namin ang Trino, na may napakagandang suporta para sa Iceberg at ang koponan ay napaka-responsive na naglabas kami ng isang bug, na naayos sa susunod na araw at inilabas sa pinakabagong bersyon sa susunod na linggo. Ito ang pinakamahusay na pagpipilian para sa koponan ng Footprint, na nangangailangan din ng mataas na pagtugon sa pagpapatupad.

4.3. Subukan ang performance

Kapag nakapagpasya na kami sa aming direksyon, gumawa kami ng pagsubok sa pagganap sa kumbinasyon ng Trino + Iceberg upang makita kung matutugunan nito ang aming mga pangangailangan at sa aming sorpresa, ang mga query ay napakabilis.

Dahil alam na ang Presto + Hive ang naging pinakamasamang comparator sa loob ng maraming taon sa lahat ng hype ng OLAP, ang kumbinasyon ng Trino + Iceberg ay lubos na nabalisa sa aming isipan.

Narito ang mga resulta ng aming mga pagsubok.

kaso 1: sumali sa isang malaking dataset

Ang 800 GB na talahanayan1 ay sumasali sa isa pang 50 GB na talahanayan2 at gumagawa ng mga kumplikadong kalkulasyon ng negosyo

case2: gumamit ng isang malaking solong talahanayan upang makagawa ng isang natatanging query

Subukan ang sql: piliin ang distinct(address) mula sa pangkat ng talahanayan ayon sa araw

Ang kumbinasyon ng Trino+Iceberg ay halos 3 beses na mas mabilis kaysa sa Doris sa parehong configuration.

Bilang karagdagan, may isa pang sorpresa dahil ang Iceberg ay maaaring gumamit ng mga format ng data tulad ng Parquet, ORC, atbp., na mag-compress at mag-imbak ng data. Ang imbakan ng talahanayan ng Iceberg ay tumatagal lamang ng humigit-kumulang 1/5 ng espasyo ng iba pang mga bodega ng data Ang laki ng imbakan ng parehong talahanayan sa tatlong database ay ang mga sumusunod:

Tandaan: Ang mga pagsubok sa itaas ay mga halimbawang nakatagpo namin sa aktwal na produksyon at para sa sanggunian lamang.

4.4. I-upgrade ang epekto

Ang mga ulat sa pagsubok sa pagganap ay nagbigay sa amin ng sapat na pagganap na inabot ng aming koponan ng humigit-kumulang 2 buwan upang makumpleto ang paglipat, at ito ay isang diagram ng aming arkitektura pagkatapos ng pag-upgrade.

• Maramihang computer engine ang tumutugma sa aming iba't ibang pangangailangan.
• Sinusuportahan ng Trino ang DBT, at maaaring direktang mag-query sa Iceberg, kaya hindi na namin kailangang harapin ang pag-synchronize ng data.
• Ang kamangha-manghang pagganap ng Trino + Iceberg ay nagbibigay-daan sa amin na buksan ang lahat ng Bronze data (raw data) sa aming mga user.

5. Buod

Mula nang ilunsad ito noong Agosto 2021, nakumpleto ng Footprint Analytics team ang tatlong pag-upgrade sa arkitektura sa loob ng wala pang isang taon at kalahati, salamat sa matinding pagnanais at determinasyon nitong dalhin ang mga benepisyo ng pinakamahusay na teknolohiya ng database sa mga gumagamit nito ng crypto at solidong pagpapatupad sa pagpapatupad at pag-upgrade ng pinagbabatayan nitong imprastraktura at arkitektura.

Ang pag-upgrade ng arkitektura ng Footprint Analytics 3.0 ay bumili ng bagong karanasan sa mga user nito, na nagpapahintulot sa mga user mula sa iba't ibang background na makakuha ng mga insight sa mas magkakaibang paggamit at mga application:

• Binuo gamit ang Metabase BI tool, pinapadali ng Footprint ang mga analyst na makakuha ng access sa na-decode na on-chain na data, mag-explore nang may kumpletong kalayaan sa pagpili ng mga tool (walang code o hardcord), mag-query ng buong kasaysayan, at mag-cross-examine ng mga dataset, para makakuha ng mga insight sa walang oras.
• Isama ang parehong on-chain at off-chain na data sa pagsusuri sa web2 + web3;
• Sa pamamagitan ng pagbuo / pag-query ng mga sukatan sa ibabaw ng abstraction ng negosyo ng Footprint, ang mga analyst o developer ay nakakatipid ng oras sa 80% ng paulit-ulit na pagpoproseso ng data at tumuon sa makabuluhang sukatan, pananaliksik, at mga solusyon sa produkto batay sa kanilang negosyo.
• Seamless na karanasan mula sa Footprint Web hanggang sa mga REST API na tawag, lahat ay nakabatay sa SQL
• Mga real-time na alerto at naaaksyong notification sa mga pangunahing signal para suportahan ang mga desisyon sa pamumuhunan