Iceberg + Spark + Trino: Tumpukan Data Sumber Terbuka Modern untuk Blockchain

1. Tantangan untuk tumpukan data blockchain modern

Ada beberapa tantangan yang mungkin dihadapi oleh startup pengindeksan blockchain modern, termasuk:

• Sejumlah besar data. Karena jumlah data pada blockchain meningkat, indeks data perlu ditingkatkan untuk menangani beban yang meningkat dan memberikan akses yang efisien ke data. Akibatnya, ini mengarah pada biaya penyimpanan yang lebih tinggi; perhitungan metrik yang lambat dan menambah beban pada server database.
• Pipa pemrosesan data yang kompleks. Teknologi Blockchain itu kompleks, dan membangun indeks data yang komprehensif dan andal memerlukan pemahaman mendalam tentang struktur dan algoritme data yang mendasarinya. Itu diwarisi oleh keragaman implementasi blockchain. Diberikan contoh spesifik, NFT di Ethereum biasanya dibuat dalam kontrak pintar yang mengikuti format ERC721 dan ERC1155, sedangkan penerapannya di Polkadot, misalnya, biasanya dibangun langsung dalam runtime blockchain. Pada akhirnya, itu harus dianggap sebagai NFT dan harus disimpan seperti itu.
• Kemampuan integrasi. Untuk memberikan nilai maksimal kepada pengguna, solusi pengindeksan blockchain mungkin perlu mengintegrasikan indeks datanya dengan sistem lain, seperti platform analitik atau API. Ini menantang dan membutuhkan upaya yang signifikan untuk desain arsitektur.

Karena penggunaan teknologi blockchain semakin meluas, jumlah data yang disimpan di blockchain telah meningkat. Ini karena semakin banyak orang yang menggunakan teknologi ini, dan setiap transaksi menambahkan data baru ke dalam blockchain. Selain itu, penggunaan teknologi blockchain telah berkembang dari aplikasi transfer uang sederhana, seperti yang melibatkan penggunaan Bitcoin, hingga aplikasi yang lebih kompleks yang melibatkan penerapan logika bisnis dalam kontrak pintar. Kontrak pintar ini dapat menghasilkan data dalam jumlah besar, yang berkontribusi pada peningkatan kompleksitas dan ukuran blockchain. Seiring waktu, ini mengarah pada blockchain yang lebih besar dan lebih kompleks.

Dalam artikel ini, kami meninjau evolusi Footprint Analytics' arsitektur teknologi secara bertahap sebagai studi kasus untuk mengeksplorasi bagaimana tumpukan teknologi Iceberg-Trino mengatasi tantangan data on-chain.

Footprint Analytics telah mengindeks sekitar 22 data blockchain publik, dan 17 pasar NFT, 1900 proyek GameFi, dan lebih dari 100.000 koleksi NFT ke dalam lapisan data abstraksi semantik. Ini adalah solusi gudang data blockchain terlengkap di dunia.

Terlepas dari data blockchain, yang mencakup lebih dari 20 miliar baris catatan transaksi keuangan, yang sering ditanyakan oleh analis data. ini berbeda dari log ingression di gudang data tradisional.

Kami telah mengalami 3 peningkatan besar dalam beberapa bulan terakhir untuk memenuhi kebutuhan bisnis yang berkembang:

2. Arsitektur 1.0 Bigquery

Di awal Footprint Analytics, kami menggunakanGoogle Permintaan Besarsebagai mesin penyimpanan dan kueri kami; Bigquery adalah produk hebat. Ini sangat cepat, mudah digunakan, dan memberikan kekuatan aritmatika yang dinamis dan sintaks UDF yang fleksibel yang membantu kami menyelesaikan pekerjaan dengan cepat.

Namun, Bigquery juga memiliki sejumlah masalah.

• Data tidak dikompresi, menghasilkan biaya penyimpanan yang tinggi, terutama jika menyangkut penyimpanan data mentah lebih dari 22 blockchain dari Footprint Analytics.
• Konkurensi tidak memadai: Bigquery hanya mendukung 100 kueri simultan, yang tidak sesuai untuk skenario konkurensi tinggi untuk Footprint Analytics, saat melayani sejumlah besar analis dan pengguna.
• Kunci dengan Google Bigquery, yang merupakan produk sumber tertutup。

Jadi kami memutuskan untuk mengeksplorasi arsitektur alternatif lainnya.

3. Arsitektur 2.0 OLAP

Kami sangat tertarik dengan beberapa produk OLAP yang telah menjadi sangat populer. Keuntungan paling menarik dari OLAP adalah waktu respons kueri, yang biasanya membutuhkan waktu sub-detik untuk mengembalikan hasil kueri untuk sejumlah besar data, dan juga dapat mendukung ribuan kueri bersamaan.

Kami memilih salah satu database OLAP terbaik,Doris, untuk mencobanya. Mesin ini bekerja dengan baik. Namun, pada titik tertentu kami segera mengalami beberapa masalah lain:

• Tipe data seperti Array atau JSON belum didukung (Nov, 2022). Array adalah jenis data yang umum di beberapa blockchain. Misalnya,bidang topikdalam log evm. Tidak dapat menghitung pada Array secara langsung memengaruhi kemampuan kami untuk menghitung banyak metrik bisnis.
• Dukungan terbatas untuk DBT, dan untuk pernyataan gabungan. Ini adalah persyaratan umum bagi teknisi data untuk skenario ETL/ELT, di mana kami perlu memperbarui beberapa data yang baru diindeks.

Karena itu, kami tidak dapat menggunakan Doris untuk seluruh jalur produksi data kami, jadi kami mencoba menggunakan Doris sebagai database OLAP untuk memecahkan sebagian masalah kami dalam jalur produksi data, bertindak sebagai mesin kueri dan menyediakan dengan cepat dan kemampuan kueri yang sangat bersamaan.

Sayangnya, kami tidak dapat mengganti Bigquery dengan Doris, jadi kami harus menyinkronkan data dari Bigquery ke Doris secara berkala dengan menggunakannya sebagai mesin kueri saja. Proses sinkronisasi ini memiliki sejumlah masalah, salah satunya adalah penulisan pembaruan menumpuk dengan cepat saat mesin OLAP sibuk melayani kueri ke klien front-end. Selanjutnya kecepatan proses penulisan terpengaruh, dan sinkronisasi memakan waktu lebih lama dan kadang-kadang bahkan menjadi tidak mungkin untuk diselesaikan.

Kami menyadari bahwa OLAP dapat menyelesaikan beberapa masalah yang kami hadapi, dan tidak dapat menjadi solusi turnkey Footprint Analytics terutama untuk saluran pemrosesan data. Masalah kami lebih besar dan lebih kompleks, dan kami dapat mengatakan, OLAP sebagai mesin kueri saja tidak cukup bagi kami.

4. Arsitektur 3.0 Gunung Es + Trino

Selamat datang di arsitektur Footprint Analytics 3.0, perombakan total arsitektur yang mendasarinya. Kami telah mendesain ulang seluruh arsitektur dari bawah ke atas, untuk memisahkan penyimpanan, komputasi, dan kueri data menjadi tiga bagian berbeda. Mengambil pelajaran dari dua arsitektur Footprint Analytics sebelumnya, dan belajar dari pengalaman proyek big data sukses lainnya seperti Uber, Netflix, dan Databricks.

4.1. Pengenalan danau data

Kami pertama kali mengalihkan perhatian kami ke data lake, jenis penyimpanan data baru untuk data terstruktur dan tidak terstruktur. Data lake sangat cocok untuk penyimpanan data on-chain karena format data on-chain sangat beragam mulai dari data mentah tidak terstruktur hingga data abstraksi terstruktur yang terkenal dengan Footprint Analytics. Kami berharap untuk menggunakan data lake untuk memecahkan masalah penyimpanan data, dan idealnya itu juga akan mendukung mesin komputasi arus utama seperti Spark dan Flink, sehingga tidak akan merepotkan untuk berintegrasi dengan berbagai jenis mesin pemrosesan seiring berkembangnya Footprint Analytics .

Iceberg terintegrasi dengan sangat baik dengan Spark, Flink, Trino, dan mesin komputasi lainnya, dan kami dapat memilih komputasi yang paling tepat untuk setiap metrik kami. Sebagai contoh:

• Bagi mereka yang membutuhkan logika komputasi yang rumit, Spark akan menjadi pilihannya.
• Flink untuk perhitungan waktu nyata.
• Untuk tugas ETL sederhana yang dapat dilakukan menggunakan SQL, kami menggunakan Trino.

4.2. Mesin kueri

Dengan Iceberg memecahkan masalah penyimpanan dan komputasi, kami kemudian harus memikirkan cara memilih mesin kueri. Tidak banyak pilihan yang tersedia, alternatif yang kami pertimbangkan adalah

• tritunggal: Mesin Kueri SQL
• Segera: Mesin Kueri SQL
• Kyuubi: Spark SQL Tanpa Server

Hal terpenting yang kami pertimbangkan sebelum masuk lebih dalam adalah bahwa mesin kueri masa depan harus kompatibel dengan arsitektur kami saat ini.

• Untuk mendukung Bigquery sebagai Sumber Data
• Untuk mendukung DBT, yang kami andalkan untuk menghasilkan banyak metrik
• Untuk mendukung metabase alat BI

Berdasarkan hal di atas, kami memilih Trino, yang memiliki dukungan yang sangat baik untuk Iceberg dan timnya sangat responsif sehingga kami mengangkat bug, yang diperbaiki keesokan harinya dan dirilis ke versi terbaru minggu berikutnya. Ini jelas merupakan pilihan terbaik bagi tim Footprint, yang juga membutuhkan respons implementasi yang tinggi.

4.3. Pengujian kinerja

Setelah kami memutuskan arah kami, kami melakukan tes kinerja pada kombinasi Trino + Iceberg untuk melihat apakah itu dapat memenuhi kebutuhan kami dan yang mengejutkan kami, pertanyaannya sangat cepat.

Mengetahui bahwa Presto + Hive telah menjadi pembanding terburuk selama bertahun-tahun di semua hype OLAP, kombinasi Trino + Iceberg benar-benar mengejutkan kami.

Berikut adalah hasil pengujian kami.

kasus 1: gabungkan kumpulan data besar

Table1 800 GB bergabung dengan table2 50 GB lainnya dan melakukan perhitungan bisnis yang kompleks

case2: gunakan tabel tunggal besar untuk melakukan kueri yang berbeda

Uji sql: pilih perbedaan (alamat) dari grup tabel berdasarkan hari

Kombinasi Trino+Iceberg sekitar 3 kali lebih cepat dari Doris dalam konfigurasi yang sama.

Selain itu, ada kejutan lain, karena Iceberg dapat menggunakan format data seperti Parquet, ORC, dll., yang akan memampatkan data dan menyimpannya. Penyimpanan tabel Iceberg hanya membutuhkan sekitar 1/5 dari ruang gudang data lainnya. Ukuran penyimpanan tabel yang sama di ketiga database adalah sebagai berikut:

4.4. Efek peningkatan

Laporan pengujian kinerja memberi kami kinerja yang cukup sehingga tim kami membutuhkan waktu sekitar 2 bulan untuk menyelesaikan migrasi, dan ini adalah diagram arsitektur kami setelah peningkatan.

• Beberapa mesin komputer sesuai dengan berbagai kebutuhan kita.
• Trino mendukung DBT, bisa query Iceberg langsung, jadi kita tidak lagi harus berurusan dengan sinkronisasi data.
• Performa luar biasa dari Trino + Iceberg memungkinkan kami untuk membuka semua data Perunggu (data mentah) kepada pengguna kami.

5. Ringkasan

Sejak diluncurkan pada Agustus 2021, tim Footprint Analytics telah menyelesaikan tiga peningkatan arsitektur dalam waktu kurang dari satu setengah tahun, berkat keinginan dan tekad yang kuat untuk menghadirkan manfaat teknologi database terbaik bagi pengguna crypto, dan eksekusi yang solid dalam penerapannya. dan meningkatkan infrastruktur dan arsitektur dasarnya.

Pembaruan arsitektur Footprint Analytics 3.0 telah memberikan pengalaman baru bagi penggunanya, memungkinkan pengguna dari berbagai latar belakang untuk mendapatkan wawasan dalam penggunaan dan aplikasi yang lebih beragam:

• Dibangun dengan alat Metabase BI, Footprint memfasilitasi analis untuk mendapatkan akses ke data on-chain yang didekodekan, menjelajahi dengan kebebasan penuh untuk memilih alat (tanpa kode atau hardcord), menanyakan seluruh riwayat, memeriksa ulang kumpulan data, untuk mendapatkan wawasan tanpa- waktu.
• Mengintegrasikan data on-chain dan off-chain untuk dianalisis di seluruh web2 + web3;
• Dengan membuat metrik kueri di atas abstraksi bisnis Footprint, analis atau pengembang menghemat waktu 80% dari pekerjaan pemrosesan data berulang dan fokus pada metrik, penelitian, dan solusi produk yang bermakna berdasarkan bisnis mereka.
• Pengalaman mulus dari Footprint Web ke panggilan REST API, semua berdasarkan SQL
• Peringatan waktu nyata dan pemberitahuan yang dapat ditindaklanjuti pada sinyal utama untuk mendukung keputusan investasi