modern nyílt forráskódú adathalmaz a blokklánchoz

1. A kihívás a modern blokklánc adatverem számára

Számos kihívással kell szembenéznie egy modern blokklánc-indexelő startupnak, többek között:

• Hatalmas mennyiségű adat. Ahogy a blokkláncon lévő adatok mennyisége növekszik, az adatindexnek fel kell lépnie, hogy kezelje a megnövekedett terhelést és hatékony hozzáférést biztosítson az adatokhoz. Következésképpen magasabb tárolási költségekhez, lassú metrikák kiszámításához és az adatbázis-kiszolgáló megnövekedett terheléséhez vezet.
• Összetett adatfeldolgozási folyamat. A blokklánc technológia összetett, és egy átfogó és megbízható adatindex felépítéséhez mélyrehatóan ismerni kell a mögöttes adatstruktúrákat és algoritmusokat. A blokklánc-megvalósítások sokfélesége örökli. Konkrét példák alapján az Ethereum NFT-jei általában az ERC721 és ERC1155 formátumot követő intelligens szerződéseken belül jönnek létre. Ezzel szemben például a Polkadot-on lévők megvalósítása általában közvetlenül a blokklánc futási idején belül épül fel. Ezeket NFT-nek kell tekinteni, és úgy kell elmenteni őket.
• Integrációs képességek. Ahhoz, hogy a felhasználók számára maximális értéket biztosítson, a blokklánc-indexelő megoldásnak szükség lehet adatindexének integrálására más rendszerekkel, például elemzési platformokkal vagy API-kkal. Ez kihívást jelent, és jelentős erőfeszítést igényel az építészeti tervezésben.

A blokklánc technológia elterjedésével nőtt a blokkláncon tárolt adatok mennyisége. Ennek az az oka, hogy többen használják a technológiát, és minden tranzakció új adatokat ad a blokklánchoz. Ezenkívül a blokklánc-technológia az egyszerű pénzátutalási alkalmazásoktól, mint például a Bitcoin használatát, a bonyolultabb alkalmazásokig fejlődött, amelyek az intelligens szerződéseken belüli üzleti logikát alkalmazzák. Ezek az intelligens szerződések nagy mennyiségű adatot generálhatnak, hozzájárulva a blokklánc összetettségének és méretének növekedéséhez. Idővel ez egy nagyobb és összetettebb blokklánchoz vezetett.

Ebben a cikkben esettanulmányként a Footprint Analytics technológiai architektúrájának fejlődését szakaszosan tekintjük át annak feltárására, hogy az Iceberg-Trino technológiai köteg hogyan kezeli a láncon belüli adatok kihívásait.

A Footprint Analytics körülbelül 22 nyilvános blokklánc adatot és 17 NFT piacteret, 1900 GameFi projektet és több mint 100,000 XNUMX NFT-gyűjteményt indexelt egy szemantikai absztrakciós adatrétegbe. Ez a világ legátfogóbb blokklánc-adattárház-megoldása.

Függetlenül a blokklánc-adatoktól, amelyek több mint 20 milliárd sornyi pénzügyi tranzakciós rekordot tartalmaznak, amelyeket az adatelemzők gyakran lekérdeznek. eltér a hagyományos adattárházakban található behatolási naplóktól.

Az elmúlt hónapokban 3 jelentős fejlesztésen mentünk keresztül, hogy megfeleljünk a növekvő üzleti követelményeknek:

2. Architektúra 1.0 Bigquery

A Footprint Analytics kezdetén használtuk Google Bigquery mint tároló és lekérdező motorunk; A Bigquery nagyszerű termék. Feltűnően gyors, könnyen használható, dinamikus aritmetikai teljesítményt és rugalmas UDF szintaxist biztosít, amely segít gyorsan elvégezni a munkát.

A Bigquery-nek azonban több problémája is van.

• Az adatok nincsenek tömörítve, ami magas költségeket eredményez, különösen a Footprint Analytics több mint 22 blokkláncának nyers adatainak tárolása esetén.
• Nem elegendő egyidejűség: A Bigquery csak 100 egyidejű lekérdezést támogat, ami nem alkalmas a Footprint Analytics magas egyidejű forgatókönyveihez, amikor sok elemzőt és felhasználót szolgál ki.
• Zárjon be a Google Bigquery segítségével, amely egy zárt forráskódú termék.

Ezért úgy döntöttünk, hogy más alternatív architektúrákat is megvizsgálunk.

3. Architektúra 2.0 OLAP

Nagyon érdeklődtünk néhány OLAP termék iránt, amelyek nagyon népszerűvé váltak. Az OLAP legvonzóbb előnye a lekérdezés válaszideje, amely általában másodpercek alatt visszaadja a lekérdezés eredményét hatalmas mennyiségű adat esetén, és több ezer egyidejű lekérdezést is képes támogatni.

Kiválasztottuk az egyik legjobb OLAP adatbázist, Doris, kipróbálni. Ez a motor jól működik. Egy ponton azonban hamarosan más problémákba ütköztünk:

• Az olyan adattípusok, mint az Array vagy a JSON, még nem támogatottak (2022. november). A tömbök gyakori adattípusok egyes blokkláncokban. Például a témakörben evm naplókban. Ha nem tudunk tömbön számolni, az közvetlenül befolyásolja számos üzleti mutató kiszámításának képességét.
• A DBT és az összevonási nyilatkozatok korlátozott támogatása. Ezek általános követelmények az adatmérnökök számára az ETL/ELT forgatókönyvekhez, ahol frissítenünk kell néhány újonnan indexelt adatot.

Ennek ellenére nem tudtuk használni a Dorist a teljes adatfolyamunkhoz a termelés során, ezért megpróbáltuk a Dorist OLAP-adatbázisként használni, hogy megoldjuk az adatelőállítási folyamatban lévő problémánk egy részét, lekérdező motorként, valamint gyors és magas szintű szolgáltatást biztosítva. párhuzamos lekérdezési lehetőségek.

Sajnos nem tudtuk lecserélni a Bigquery-t Dorisra, ezért rendszeresen szinkronizálnunk kellett a Bigquery és a Doris adatait lekérdezőmotorként. Ennek a szinkronizálási folyamatnak számos problémája volt, amelyek közül az egyik az volt, hogy a frissítési írások gyorsan felhalmozódtak, amikor az OLAP-motor lekérdezéseket szolgáltatott a front-end ügyfeleknek. Ezt követően az írási folyamat sebessége megváltozott, a szinkronizálás sokkal tovább tartott, sőt néha lehetetlenné vált.

Rájöttünk, hogy az OLAP számos problémát megoldhat, amelyekkel szembesülünk, és nem válhat a Footprint Analytics kulcsrakész megoldásává, különösen az adatfeldolgozási folyamatban. A problémánk nagyobb és összetettebb, és mondhatnánk, hogy az OLAP, mint lekérdezőmotor önmagában nem volt elég számunkra.

4. Építészet 3.0 Iceberg + Trino

Üdvözöljük a Footprint Analytics architektúra 3.0-s verziójában, amely az alapul szolgáló architektúra teljes átalakítása. A teljes architektúrát az alapoktól kezdve újraterveztük, hogy az adatok tárolását, számítását és lekérdezését három különböző részre különítsük el. Leckék a Footprint Analytics két korábbi architektúrájából, és más sikeres big data projektek, például az Uber, a Netflix és a Databricks tapasztalataiból.

4.1. Az adattó bemutatása

Elsőként a data lake-re fordítottuk figyelmünket, amely egy új típusú adattárolás strukturált és strukturálatlan adatok számára egyaránt. A Data Lake tökéletes a láncon belüli adattároláshoz, mivel a láncon belüli adatok formátumai széles skálán mozognak a strukturálatlan nyers adatoktól a strukturált absztrakciós adatokig. A Footprint Analytics jól ismert. Arra számítottunk, hogy a Data Lake-et használjuk az adattárolás problémáinak megoldására, és ideális esetben az olyan általános számítási motorokat is támogatná, mint a Spark és a Flink, hogy ne legyen fájdalom a Footprint Analytics fejlődésével együtt integrálni a különböző típusú feldolgozómotorokkal. .

Az Iceberg nagyon jól integrálható a Spark, Flink, Trino és más számítási motorokkal, és mindegyik mérőszámunkhoz kiválaszthatjuk a legmegfelelőbb számítást. Például:

• Azok számára, akik összetett számítási logikát igényelnek, a Spark lesz a választás.
• Flink a valós idejű számításhoz.
• Az SQL segítségével végrehajtható egyszerű ETL-feladatokhoz a Trino-t használjuk.

4.2. Lekérdező motor

Miközben az Iceberg megoldotta a tárolási és számítási problémákat, el kellett gondolkodnunk a lekérdezőmotor kiválasztásán. Nem sok lehetőség áll rendelkezésre. Az általunk mérlegelt alternatívák voltak

A legfontosabb dolog, amit figyelembe vettünk, mielőtt mélyebbre mennénk, az volt, hogy a jövőbeli lekérdezőmotornak kompatibilisnek kell lennie a jelenlegi architektúránkkal.

• A Bigquery mint adatforrás támogatása
• A DBT támogatása, amelyre számos mérőszám előállítása során támaszkodunk
• A BI eszköz metabázisának támogatása

A fentiek alapján a Trino-t választottuk, amely nagyon jól támogatja az Iceberget, és a csapat annyira érzékeny volt, hogy felvettünk egy hibát, amit másnap kijavítottunk, és a következő héten kiadtuk a legújabb verzióra. Ez volt a legjobb választás a Footprint csapat számára, akik szintén magas szintű implementációs reakciókészséget igényelnek.

4.3. Teljesítményfelmérés

Miután eldöntöttük az irányt, teljesítménytesztet végeztünk a Trino + Iceberg kombináción, hogy megnézzük, megfelel-e az igényeinknek, és meglepetésünkre a lekérdezések hihetetlenül gyorsak voltak.

Tudva, hogy a Presto + Hive évek óta a legrosszabb összehasonlító eszköz az OLAP hírverésben, a Trino + Iceberg kombinációja teljesen felborította a fejünket.

Itt vannak tesztjeink eredményei.

1. eset: csatlakozzon egy nagy adatkészlethez

Egy 800 GB-os tábla1 csatlakozik egy másik 50 GB-os táblához2, és összetett üzleti számításokat végez

eset2: használjon egy nagy táblát egy külön lekérdezéshez

Teszt sql: válasszon külön(cím)-t a táblázatcsoportból napok szerint

A Trino+Jéghegy kombináció körülbelül háromszor gyorsabb, mint a Doris ugyanabban a konfigurációban.

Ezen kívül van még egy meglepetés, mert az Iceberg olyan adatformátumokat tud használni, mint a Parquet, ORC stb., amelyek tömörítik és tárolják az adatokat. Az Iceberg tábla tárolása a többi adattárház területének csak körülbelül 1/5-ét foglalja el. Ugyanazon tábla tárterülete a három adatbázisban a következő:

Megjegyzés: A fenti tesztek példák, amelyekkel a tényleges gyártás során találkoztunk, és csak referenciaként szolgálnak.

4.4. Frissítési hatás

A teljesítményteszt-jelentések elegendő teljesítményt nyújtottak ahhoz, hogy csapatunknak körülbelül 2 hónapjába telt az áttelepítés, és ez a frissítés utáni architektúránk diagramja.

• Több számítógépes motor felel meg különféle igényeinknek.
• A Trino támogatja a DBT-t, és közvetlenül le tudja kérdezni az Iceberget, így nem kell többé adatszinkronizálással foglalkoznunk.
• A Trino + Iceberg elképesztő teljesítménye lehetővé teszi, hogy minden bronz adatot (nyers adatot) megnyissunk a felhasználók számára.

5. összefoglalás

2021. augusztusi indulása óta a Footprint Analytics csapata kevesebb mint másfél év alatt három építészeti frissítést hajtott végre, köszönhetően annak erős vágyának és eltökéltségének, hogy a legjobb adatbázis-technológia előnyeit kripto-felhasználói számára nyújtsa, valamint a megvalósítás és a szilárd végrehajtás. a mögöttes infrastruktúra és architektúra korszerűsítése.

A Footprint Analytics architektúra 3.0-s frissítése új élményt adott felhasználóinak, lehetővé téve a különböző hátterű felhasználók számára, hogy betekintést nyerjenek a sokrétűbb használatba és alkalmazásokba:

• A Metabase BI eszközzel felépített Footprint lehetővé teszi az elemzők számára, hogy hozzáférjenek a dekódolt láncon belüli adatokhoz, felfedezzék az eszközök (kód nélküli vagy merev vezeték nélküli) teljes szabadságát, lekérdezzék a teljes előzményeket, és keresztvizsgálatot végezzenek az adatkészletekben, hogy betekintést nyerhessenek nincs idő.
• Integrálja mind a láncon belüli, mind a láncon kívüli adatokat a web2 + web3 elemzéséhez;
• Azzal, hogy a Footprint üzleti absztrakciójára építenek/lekérdeznek mérőszámokat, az elemzők vagy fejlesztők időt takarítanak meg az ismétlődő adatfeldolgozási munka 80%-án, és az üzleti tevékenységükön alapuló értelmes mérőszámokra, kutatásokra és termékmegoldásokra összpontosítanak.
• Zökkenőmentes élmény a Footprint Webtől a REST API-hívásokig, mindez SQL-en alapul
• Valós idejű riasztások és végrehajtható értesítések a kulcsfontosságú jelzésekről a befektetési döntések támogatása érdekében