blockchain için modern bir açık kaynak veri yığını

1.Modern blockchain veri yığınının zorluğu

Modern bir blockchain indeksleme girişiminin karşılaşabileceği çeşitli zorluklar vardır:

• Büyük miktarda veri. Blok zincirindeki veri miktarı arttıkça, artan yükün üstesinden gelmek ve verilere verimli erişim sağlamak için veri indeksinin ölçeklenmesi gerekecektir. Sonuç olarak, daha yüksek depolama maliyetlerine, yavaş ölçüm hesaplamasına ve veritabanı sunucusunda artan yüke yol açar.
• Karmaşık veri işleme boru hattı. Blockchain teknolojisi karmaşıktır ve kapsamlı ve güvenilir bir veri dizini oluşturmak, altta yatan veri yapılarının ve algoritmaların derinlemesine anlaşılmasını gerektirir. Blockchain uygulamalarının çeşitliliği onu miras alır. Spesifik örnekler verildiğinde, Ethereum'daki NFT'ler genellikle ERC721 ve ERC1155 formatlarını izleyen akıllı sözleşmeler içinde oluşturulur. Buna karşılık, örneğin Polkadot'takilerin uygulanması, genellikle doğrudan blockchain çalışma zamanı içinde oluşturulur. Bunlar NFT olarak kabul edilmeli ve bunlar olarak kaydedilmelidir.
• Entegrasyon yetenekleri. Kullanıcılara maksimum değer sağlamak için bir blockchain indeksleme çözümünün veri indeksini analiz platformları veya API'ler gibi diğer sistemlerle entegre etmesi gerekebilir. Bu zorlu bir iştir ve mimari tasarıma yönelik önemli bir çaba gerektirir.

Blok zinciri teknolojisi yaygınlaştıkça, blok zincirinde depolanan veri miktarı da arttı. Bunun nedeni, teknolojiyi daha fazla insanın kullanması ve her işlemin blok zincirine yeni veriler eklemesidir. Ek olarak, blockchain teknolojisi, Bitcoin kullanımını içerenler gibi basit para transferi uygulamalarından, akıllı sözleşmelerde iş mantığının uygulanmasını içeren daha karmaşık uygulamalara doğru gelişmiştir. Bu akıllı sözleşmeler, blok zincirinin artan karmaşıklığına ve boyutuna katkıda bulunan büyük miktarda veri üretebilir. Zamanla, bu daha büyük ve daha karmaşık bir blok zincirine yol açtı.

Bu makalede, Iceberg-Trino teknoloji yığınının zincir üstü verilerin zorluklarını nasıl ele aldığını keşfetmek için bir vaka çalışması olarak Footprint Analytics'in teknoloji mimarisinin gelişimini aşamalı olarak inceliyoruz.

Footprint Analytics, yaklaşık 22 genel blockchain verisini ve 17 NFT pazar yerini, 1900 GameFi projesini ve 100,000'den fazla NFT koleksiyonunu semantik bir soyutlama veri katmanına endeksledi. Dünyadaki en kapsamlı blockchain veri ambarı çözümüdür.

Veri analistlerinin sıklıkla sorguladığı 20 milyar satırdan fazla mali işlem kaydını içeren blockchain verilerinden bağımsız olarak. geleneksel veri ambarlarındaki giriş günlüklerinden farklıdır.

Artan iş gereksinimlerini karşılamak için son birkaç ayda 3 büyük yükseltme yaşadık:

2. Mimari 1.0 Büyük Sorgu

Footprint Analytics'in başlangıcında, Google Büyük Sorgusu depolama ve sorgulama motorumuz olarak; Bigquery harika bir üründür. Çarpıcı derecede hızlı, kullanımı kolay ve dinamik aritmetik güç ve işi hızla bitirmemize yardımcı olan esnek bir UDF söz dizimi sağlıyor.

Ancak Bigquery'nin de birkaç sorunu var.

• Veriler sıkıştırılmaz, bu da özellikle Footprint Analytics'in 22'den fazla blok zincirinin ham verilerini depolarken yüksek maliyetlerle sonuçlanır.
• Yetersiz eşzamanlılık: Bigquery yalnızca 100 eşzamanlı sorguyu destekler; bu, birçok analist ve kullanıcıya hizmet verirken Footprint Analytics için yüksek eşzamanlılık senaryoları için uygun değildir.
• Kapalı kaynaklı bir ürün olan Google Bigquery ile kilitlenin.

Bu yüzden diğer alternatif mimarileri keşfetmeye karar verdik.

3. Mimari 2.0 OLAP

Çok popüler hale gelen bazı OLAP ürünleriyle çok ilgilendik. OLAP'ın en çekici avantajı, çok büyük miktarda veri için sorgu sonuçlarını döndürmek genellikle saniyelerin altında olan sorgu yanıt süresidir ve aynı zamanda binlerce eşzamanlı sorguyu destekleyebilir.

En iyi OLAP veritabanlarından birini seçtik, Doris, denemek için. Bu motor iyi performans gösteriyor. Ancak, bir noktada kısa süre sonra başka sorunlarla karşılaştık:

• Array veya JSON gibi veri türleri henüz desteklenmemektedir (Kas 2022). Diziler, bazı blok zincirlerinde yaygın olarak kullanılan bir veri türüdür. Örneğin, konu alanı evm günlüklerinde. Array üzerinde hesaplama yapamamak, birçok iş ölçümünü hesaplama yeteneğimizi doğrudan etkiler.
• DBT ve birleştirme ifadeleri için sınırlı destek. Bunlar, bazı yeni endekslenmiş verileri güncellememiz gereken ETL/ELT senaryoları için veri mühendisleri için yaygın gereksinimlerdir.

Bununla birlikte, üretimdeki tüm veri hattımız için Doris'i kullanamadık, bu nedenle veri üretim hattındaki sorunumuzun bir kısmını çözmek için Doris'i bir OLAP veritabanı olarak kullanmaya çalıştık, bir sorgu motoru görevi gördü ve hızlı ve yüksek düzeyde veri sağladı. eşzamanlı sorgulama yetenekleri.

Ne yazık ki, Bigquery'yi Doris ile değiştiremedik, bu nedenle Bigquery'den Doris'i bir sorgu motoru olarak kullanarak verileri periyodik olarak senkronize etmek zorunda kaldık. Bu eşitleme işleminin birkaç sorunu vardı; bunlardan biri, OLAP altyapısı ön uç istemcilere sorgular sunmakla meşgulken güncelleme yazma işlemlerinin hızla birikmesiydi. Akabinde yazma işleminin hızı etkilendi ve senkronizasyon çok daha uzun sürdü ve hatta bazen bitirilmesi imkansız hale geldi.

OLAP'ın karşılaştığımız birçok sorunu çözebileceğini ve özellikle veri işleme ardışık düzeni için Footprint Analytics'in anahtar teslimi çözümü olamayacağını fark ettik. Bizim sorunumuz daha büyük ve daha karmaşık ve sorgu motoru olarak OLAP'ın tek başına bize yetmediğini söyleyebiliriz.

4. Mimari 3.0 Buzdağı + Trino

Altta yatan mimarinin eksiksiz bir revizyonu olan Footprint Analytics mimarisi 3.0'a hoş geldiniz. Verilerin depolanmasını, hesaplanmasını ve sorgulanmasını üç farklı parçaya ayırmak için tüm mimariyi sıfırdan yeniden tasarladık. Footprint Analytics'in önceki iki mimarisinden dersler alarak ve Uber, Netflix ve Databricks gibi diğer başarılı büyük veri projelerinin deneyimlerinden ders alarak.

4.1. Veri gölünün tanıtımı

İlk olarak, hem yapılandırılmış hem de yapılandırılmamış veriler için yeni bir veri depolama türü olan veri gölüne odaklandık. Data Lake, zincir üstü veri depolama için mükemmeldir çünkü zincir üstü veri formatları, yapılandırılmamış ham verilerden yapılandırılmış soyutlama verilerine kadar geniş bir aralıktadır. Ayak İzi Analitiği ünlüdür. Veri depolama sorununu çözmek için data lake kullanmayı bekliyorduk ve ideal olarak Spark ve Flink gibi ana akım bilgi işlem motorlarını da destekleyecekti, böylece Footprint Analytics geliştikçe farklı işleme motorları türleriyle entegre etmek zahmetli olmayacaktı. .

Iceberg, Spark, Flink, Trino ve diğer hesaplama motorlarıyla çok iyi bütünleşir ve her bir ölçümümüz için en uygun hesaplamayı seçebiliriz. Örneğin:

• Karmaşık hesaplama mantığına ihtiyaç duyanlar için tercih Spark olacaktır.
• Gerçek zamanlı hesaplama için Flink.
• SQL kullanılarak gerçekleştirilebilen basit ETL görevleri için Trino kullanıyoruz.

4.2. Sorgu motoru

Iceberg, depolama ve hesaplama sorunlarını çözerken, bir sorgu motoru seçmeyi düşünmemiz gerekti. Çok fazla seçenek yok. Düşündüğümüz alternatifler

Daha derine inmeden önce düşündüğümüz en önemli şey, gelecekteki sorgulama motorunun mevcut mimarimizle uyumlu olması gerektiğiydi.

• Veri Kaynağı olarak Bigquery'yi desteklemek için
• Üretilecek birçok ölçüm için güvendiğimiz DBT'yi desteklemek için
• BI aracı metatabanını desteklemek için

Yukarıdakilere dayanarak, Iceberg için çok iyi desteği olan Trino'yu seçtik ve ekip o kadar duyarlıydı ki, ertesi gün düzeltilen ve sonraki hafta en son sürümüyle yayınlanan bir hatayı gündeme getirdik. Bu, aynı zamanda yüksek düzeyde uygulama yanıtı gerektiren Ayak İzi ekibi için en iyi seçimdi.

4.3. Performans testi

Yönümüze karar verdikten sonra, ihtiyaçlarımızı karşılayıp karşılamayacağını görmek için Trino + Iceberg kombinasyonu üzerinde bir performans testi yaptık ve şaşırtıcı bir şekilde, sorgular inanılmaz derecede hızlıydı.

Presto + Hive'ın tüm OLAP aldatmacasında yıllardır en kötü karşılaştırıcı olduğunu bilerek, Trino + Iceberg kombinasyonu tamamen aklımızı başımızdan aldı.

İşte testlerimizin sonuçları.

durum 1: büyük bir veri kümesine katılın

800 GB'lık bir tablo1, başka bir 50 GB'lık tabloya2 katılır ve karmaşık iş hesaplamaları yapar

case2: ayrı bir sorgu yapmak için büyük tek bir tablo kullanın

Test sql: güne göre tablo grubundan farklı (adres) seçin

Trino+Iceberg kombinasyonu, aynı konfigürasyonda Doris'ten yaklaşık 3 kat daha hızlıdır.

Ayrıca bir sürpriz daha var çünkü Iceberg, verileri sıkıştıracak ve saklayacak olan Parquet, ORC vb. veri formatlarını kullanabilir. Iceberg'in tablo depolaması, diğer veri ambarlarının alanının yalnızca yaklaşık 1/5'ini kaplıyor Aynı tablonun üç veritabanındaki depolama boyutu aşağıdaki gibidir:

Not: Yukarıdaki testler, gerçek üretimde karşılaştığımız örneklerdir ve yalnızca referans amaçlıdır.

4.4. Yükseltme etkisi

Performans testi raporları bize yeterli performansı verdi ve ekibimizin geçişi tamamlaması yaklaşık 2 ay sürdü ve bu, yükseltmeden sonraki mimarimizin bir diyagramıdır.

• Birden fazla bilgisayar motoru, çeşitli ihtiyaçlarımızı karşılar.
• Trino, DBT'yi destekler ve Iceberg'i doğrudan sorgulayabilir, bu nedenle artık veri senkronizasyonu ile uğraşmak zorunda değiliz.
• Trino + Iceberg'in inanılmaz performansı, tüm Bronze verilerini (ham verileri) kullanıcılarımıza açmamıza izin veriyor.

5. Özet

Ağustos 2021'deki lansmanından bu yana, Footprint Analytics ekibi, kripto kullanıcılarına en iyi veritabanı teknolojisinin faydalarını sunmaya yönelik güçlü arzusu ve kararlılığı ve uygulama ve temel altyapısını ve mimarisini yükseltmek.

Footprint Analytics mimarisi yükseltmesi 3.0, kullanıcılarına yeni bir deneyim kazandırdı ve farklı geçmişlere sahip kullanıcıların daha çeşitli kullanım ve uygulamalar hakkında bilgi edinmesine olanak sağladı:

• Metabase BI aracıyla oluşturulan Footprint, analistlerin kodu çözülmüş zincir üzerindeki verilere erişmesini, araç seçme özgürlüğüyle (kodsuz veya kablolu) keşfetmesini, tüm geçmişi sorgulamasını ve içgörüler elde etmek için veri kümelerini çapraz incelemesini kolaylaştırır. zaman yok.
• Hem zincir içi hem de zincir dışı verileri web2 + web3 genelinde analize entegre edin;
• Analistler veya geliştiriciler, Footprint'in iş soyutlaması üzerine metrikler oluşturarak / sorgulayarak, tekrarlayan veri işleme işlerinde %80 oranında zaman kazanır ve işlerine dayalı anlamlı metriklere, araştırmaya ve ürün çözümlerine odaklanır.
• Tamamı SQL tabanlı olan Footprint Web'den REST API çağrılarına kadar sorunsuz deneyim
• Yatırım kararlarını desteklemek için önemli sinyallerle ilgili gerçek zamanlı uyarılar ve işlem yapılabilir bildirimler