un moderno stack di dati open source per blockchain

1.La sfida per il moderno stack di dati blockchain

Ci sono diverse sfide che una moderna startup di indicizzazione blockchain può affrontare, tra cui:

• Enormi quantità di dati. Con l'aumentare della quantità di dati sulla blockchain, l'indice dei dati dovrà essere ridimensionato per gestire l'aumento del carico e fornire un accesso efficiente ai dati. Di conseguenza, comporta costi di archiviazione più elevati, calcolo lento delle metriche e aumento del carico sul server del database.
• Complessa pipeline di elaborazione dati. La tecnologia blockchain è complessa e la creazione di un indice di dati completo e affidabile richiede una profonda comprensione delle strutture e degli algoritmi dei dati sottostanti. La diversità delle implementazioni blockchain lo eredita. Dati esempi specifici, gli NFT in Ethereum vengono solitamente creati all'interno di contratti intelligenti seguendo i formati ERC721 e ERC1155. Al contrario, l'implementazione di quelli su Polkadot, ad esempio, è solitamente costruita direttamente all'interno del runtime blockchain. Quelli dovrebbero essere considerati NFT e dovrebbero essere salvati come quelli.
• Capacità di integrazione. Per fornire il massimo valore agli utenti, una soluzione di indicizzazione blockchain potrebbe dover integrare il proprio indice di dati con altri sistemi, come piattaforme di analisi o API. Questo è impegnativo e richiede uno sforzo significativo nella progettazione dell'architettura.

Man mano che la tecnologia blockchain è diventata più diffusa, la quantità di dati archiviati sulla blockchain è aumentata. Questo perché più persone utilizzano la tecnologia e ogni transazione aggiunge nuovi dati alla blockchain. Inoltre, la tecnologia blockchain si è evoluta da semplici applicazioni per il trasferimento di denaro, come quelle che prevedono l'uso di Bitcoin, ad applicazioni più complesse che prevedono l'implementazione della logica aziendale all'interno di contratti intelligenti. Questi contratti intelligenti possono generare grandi quantità di dati, contribuendo alla maggiore complessità e dimensione della blockchain. Nel tempo, questo ha portato a una blockchain più grande e complessa.

In questo articolo, esaminiamo l'evoluzione dell'architettura tecnologica di Footprint Analytics in più fasi come caso di studio per esplorare come lo stack tecnologico Iceberg-Trino affronta le sfide dei dati on-chain.

Footprint Analytics ha indicizzato circa 22 dati blockchain pubblici e 17 marketplace NFT, 1900 progetti GameFi e oltre 100,000 raccolte NFT in un livello di dati di astrazione semantica. È la soluzione di data warehouse blockchain più completa al mondo.

Indipendentemente dai dati blockchain, che includono oltre 20 miliardi di righe di record di transazioni finanziarie, che gli analisti di dati interrogano frequentemente. è diverso dai log di ingresso nei data warehouse tradizionali.

Abbiamo sperimentato 3 importanti aggiornamenti negli ultimi mesi per soddisfare i crescenti requisiti aziendali:

2. Architettura 1.0 Bigquery

All'inizio di Footprint Analytics, abbiamo utilizzato Google BigQuery come nostro motore di archiviazione e query; BigQuery è un ottimo prodotto. È incredibilmente veloce, facile da usare e fornisce potenza aritmetica dinamica e una sintassi UDF flessibile che ci aiuta a portare a termine rapidamente il lavoro.

Tuttavia, anche BigQuery ha diversi problemi.

• I dati non vengono compressi, con conseguenti costi elevati, soprattutto quando si archiviano dati grezzi di oltre 22 blockchain di Footprint Analytics.
• Concorrenza insufficiente: BigQuery supporta solo 100 query simultanee, il che non è adatto per scenari di concorrenza elevata per Footprint Analytics quando serve molti analisti e utenti.
• Collegati con Google BigQuery, che è un prodotto closed-source。

Quindi abbiamo deciso di esplorare altre architetture alternative.

3. Architettura 2.0 OLAP

Eravamo molto interessati ad alcuni dei prodotti OLAP che erano diventati molto popolari. Il vantaggio più interessante di OLAP è il tempo di risposta alle query, che in genere richiede meno di secondi per restituire i risultati delle query per enormi quantità di dati e può anche supportare migliaia di query simultanee.

Abbiamo scelto uno dei migliori database OLAP, Doris, per fare un tentativo. Questo motore funziona bene. Tuttavia, a un certo punto ci siamo presto imbattuti in altri problemi:

• I tipi di dati come Array o JSON non sono ancora supportati (novembre 2022). Gli array sono un tipo comune di dati in alcune blockchain. Ad esempio, il campo tematico nei log di evm. L'impossibilità di calcolare su Array influisce direttamente sulla nostra capacità di calcolare molte metriche aziendali.
• Supporto limitato per DBT e per istruzioni di unione. Questi sono requisiti comuni per i data engineer per gli scenari ETL/ELT in cui è necessario aggiornare alcuni dati appena indicizzati.

Detto questo, non potevamo utilizzare Doris per l'intera pipeline di dati in produzione, quindi abbiamo provato a utilizzare Doris come database OLAP per risolvere parte del nostro problema nella pipeline di produzione dei dati, fungendo da motore di query e fornendo informazioni rapide e altamente funzionalità di query simultanee.

Sfortunatamente, non siamo riusciti a sostituire Bigquery con Doris, quindi abbiamo dovuto sincronizzare periodicamente i dati da Bigquery a Doris utilizzandolo come motore di query. Questo processo di sincronizzazione presentava diversi problemi, uno dei quali era che le scritture di aggiornamento si accumulavano rapidamente quando il motore OLAP era impegnato a servire le query ai client front-end. Successivamente, la velocità del processo di scrittura è stata influenzata e la sincronizzazione ha richiesto molto più tempo e talvolta è diventata persino impossibile da completare.

Ci siamo resi conto che l'OLAP poteva risolvere diversi problemi che stiamo affrontando e non poteva diventare la soluzione chiavi in ​​mano di Footprint Analytics, in particolare per la pipeline di elaborazione dei dati. Il nostro problema è più grande e più complesso e potremmo dire che OLAP come motore di query da solo non era sufficiente per noi.

4. Architettura 3.0 Iceberg + Trino

Benvenuto nell'architettura Footprint Analytics 3.0, una revisione completa dell'architettura sottostante. Abbiamo riprogettato l'intera architettura da zero per separare l'archiviazione, il calcolo e l'interrogazione dei dati in tre parti diverse. Prendendo lezioni dalle due precedenti architetture di Footprint Analytics e imparando dall'esperienza di altri progetti di big data di successo come Uber, Netflix e Databricks.

4.1. Introduzione del data lake

Per prima cosa abbiamo rivolto la nostra attenzione al data lake, un nuovo tipo di archiviazione dei dati sia per i dati strutturati che per quelli non strutturati. Il data lake è perfetto per l'archiviazione dei dati on-chain poiché i formati dei dati on-chain vanno ampiamente dai dati grezzi non strutturati ai dati di astrazione strutturati per cui Footprint Analytics è ben noto. Ci aspettavamo di utilizzare il data lake per risolvere il problema dell'archiviazione dei dati e, idealmente, supporterebbe anche motori di calcolo tradizionali come Spark e Flink, in modo che non sarebbe un problema integrarsi con diversi tipi di motori di elaborazione man mano che Footprint Analytics si evolve .

Iceberg si integra molto bene con Spark, Flink, Trino e altri motori computazionali e possiamo scegliere il calcolo più appropriato per ciascuna delle nostre metriche. Per esempio:

• Per coloro che richiedono una logica computazionale complessa, Spark sarà la scelta.
• Flink per il calcolo in tempo reale.
• Per semplici attività ETL che possono essere eseguite utilizzando SQL, utilizziamo Trino.

4.2. Motore di interrogazione

Con Iceberg che risolve i problemi di archiviazione e calcolo, abbiamo dovuto pensare alla scelta di un motore di query. Non ci sono molte opzioni disponibili. Le alternative che abbiamo considerato erano

La cosa più importante che abbiamo considerato prima di approfondire è stata che il futuro motore di query doveva essere compatibile con la nostra attuale architettura.

• Supportare BigQuery come origine dati
• Per supportare DBT, su cui ci affidiamo per la produzione di molte metriche
• Per supportare la metabase dello strumento BI

Sulla base di quanto sopra, abbiamo scelto Trino, che ha un ottimo supporto per Iceberg e il team è stato così reattivo che abbiamo sollevato un bug, che è stato risolto il giorno successivo e rilasciato all'ultima versione la settimana successiva. Questa è stata la scelta migliore per il team Footprint, che richiede anche un'elevata reattività di implementazione.

4.3. Test delle prestazioni

Dopo aver deciso la nostra direzione, abbiamo eseguito un test delle prestazioni sulla combinazione Trino + Iceberg per vedere se poteva soddisfare le nostre esigenze e con nostra sorpresa, le query sono state incredibilmente veloci.

Sapendo che Presto + Hive è stato per anni il peggior comparatore in tutto il clamore OLAP, la combinazione di Trino + Iceberg ci ha completamente sconvolti.

Ecco i risultati dei nostri test.

caso 1: unisciti a un set di dati di grandi dimensioni

Una tabella800 da 1 GB si unisce a un'altra tabella50 da 2 GB ed esegue calcoli aziendali complessi

case2: utilizza una grande tabella singola per eseguire una query distinta

Test sql: seleziona distinto (indirizzo) dal gruppo di tabelle per giorno

La combinazione Trino+Iceberg è circa 3 volte più veloce di Doris nella stessa configurazione.

Inoltre, c'è un'altra sorpresa perché Iceberg può utilizzare formati di dati come Parquet, ORC, ecc., che comprimeranno e memorizzeranno i dati. L'archiviazione della tabella di Iceberg occupa solo circa 1/5 dello spazio di altri data warehouse La dimensione dell'archiviazione della stessa tabella nei tre database è la seguente:

Nota: i test di cui sopra sono esempi che abbiamo riscontrato nella produzione effettiva e sono solo di riferimento.

4.4. Effetto di aggiornamento

I rapporti sui test delle prestazioni ci hanno fornito prestazioni sufficienti che il nostro team ha impiegato circa 2 mesi per completare la migrazione e questo è un diagramma della nostra architettura dopo l'aggiornamento.

• Più motori di computer soddisfano le nostre diverse esigenze.
• Trino supporta DBT e può interrogare direttamente Iceberg, quindi non dobbiamo più occuparci della sincronizzazione dei dati.
• Le straordinarie prestazioni di Trino + Iceberg ci consentono di aprire tutti i dati Bronze (dati grezzi) ai nostri utenti.

5. Riassunto

Dal suo lancio nell'agosto 2021, il team di Footprint Analytics ha completato tre aggiornamenti dell'architettura in meno di un anno e mezzo, grazie al suo forte desiderio e alla sua determinazione di portare i vantaggi della migliore tecnologia di database ai suoi utenti crittografici e alla solida esecuzione nell'implementazione e l'aggiornamento dell'infrastruttura e dell'architettura sottostanti.

L'aggiornamento 3.0 dell'architettura Footprint Analytics ha offerto una nuova esperienza ai suoi utenti, consentendo agli utenti con background diversi di ottenere approfondimenti su usi e applicazioni più diversi:

• Creato con lo strumento Metabase BI, Footprint facilita agli analisti l'accesso ai dati decodificati sulla catena, l'esplorazione con la completa libertà di scelta degli strumenti (senza codice o hardcord), l'interrogazione dell'intera cronologia e l'esame incrociato dei set di dati, per ottenere approfondimenti non c'è tempo.
• Integra i dati on-chain e off-chain per l'analisi su web2 + web3;
• Creando/interrogando le metriche in cima all'astrazione aziendale di Footprint, gli analisti o gli sviluppatori risparmiano tempo sull'80% del lavoro ripetitivo di elaborazione dei dati e si concentrano su metriche, ricerche e soluzioni di prodotto significative basate sulla loro attività.
• Esperienza senza soluzione di continuità da Footprint Web alle chiamate API REST, tutte basate su SQL
• Avvisi in tempo reale e notifiche attuabili sui segnali chiave per supportare le decisioni di investimento