Iceberg + Spark + Trino: ブロックチェーン向けの最新のオープンソース データ スタック

1. 最新のブロックチェーン データ スタックの課題

最新のブロックチェーン インデックス作成のスタートアップが直面する可能性のあるいくつかの課題があります。

• 大量のデータ。ブロックチェーン上のデータ量が増加するにつれて、増加した負荷を処理し、データへの効率的なアクセスを提供するために、データ インデックスをスケールアップする必要があります。その結果、保管コストが高くなります。メトリクスの計算が遅くなり、データベース サーバーの負荷が増加します。
• 複雑なデータ処理パイプライン。ブロックチェーン テクノロジは複雑であり、包括的で信頼性の高いデータ インデックスを構築するには、基盤となるデータ構造とアルゴリズムを深く理解する必要があります。それは、ブロックチェーンの実装の多様性によって継承されます。具体的な例を挙げると、Ethereum の NFT は通常、ERC721 および ERC1155 形式に従うスマート コントラクト内で作成されますが、たとえば、Polkadot での NFT の実装は通常、ブロックチェーン ランタイム内で直接構築されます。結局のところ、それらは NFT と見なされ、それらとして保存されるべきです。
• 統合機能。ユーザーに最大の価値を提供するために、ブロックチェーン インデックス ソリューションは、そのデータ インデックスを分析プラットフォームや API などの他のシステムと統合する必要がある場合があります。これは困難であり、アーキテクチャの設計に多大な労力を費やす必要があります。

ブロックチェーン技術の普及に伴い、ブロックチェーンに保存されるデータ量が増加しています。これは、このテクノロジーを使用する人が増え、トランザクションごとに新しいデータがブロックチェーンに追加されるためです。さらに、ブロックチェーン テクノロジの使用は、ビットコインの使用を含む単純な送金アプリケーションから、スマート コントラクト内のビジネス ロジックの実装を含むより複雑なアプリケーションへと進化しています。これらのスマート コントラクトは大量のデータを生成する可能性があり、ブロックチェーンの複雑さとサイズの増加に貢献しています。時間が経つにつれて、これはより大規模で複雑なブロックチェーンにつながりました.

この記事では、フットプリント分析の進化について説明します' Iceberg-Trino テクノロジー スタックがオンチェーン データの課題にどのように対処するかを調べるためのケース スタディとして、テクノロジー アーキテクチャを段階的に説明します。

Footprint Analytics は、約 22 の公開ブロックチェーン データ、17 の NFT マーケットプレイス、1900 の GameFi プロジェクト、および 100,000 を超える NFT コレクションをセマンティック抽象化データ レイヤーにインデックス化しました。これは、世界で最も包括的なブロックチェーン データ ウェアハウス ソリューションです。

金融取引の 200 億行以上のレコードを含むブロックチェーン データに関係なく、データ アナリストによって頻繁に照会されます。従来のデータ ウェアハウスの進入ログとは異なります。

増大するビジネス要件を満たすために、過去数か月間に 3 つの主要なアップグレードが行われました。

2. アーキテクチャ 1.0 BigQuery

フットプリント分析の開始時に、Google ビッグクエリストレージおよびクエリ エンジンとして。 BigQuery は優れた製品です。これは非常に高速で使いやすく、動的演算機能と柔軟な UDF 構文を提供するため、作業を迅速に完了できます。

ただし、Bigquery には多くの問題もあります。

• データは圧縮されていないため、特にフットプリント分析の 22 を超えるブロックチェーンの生データを保存する場合は、ストレージ コストが高くなります。
• 不十分な同時実行: Bigquery は 100 の同時クエリのみをサポートします。これは、多数のアナリストとユーザーにサービスを提供する場合、フットプリント アナリティクスの同時実行数の多いシナリオには適していません。
• クローズドソース製品であるGoogle Bigqueryでロックイン。

そこで、他の代替アーキテクチャを検討することにしました。

3. アーキテクチャ 2.0 OLAP

私たちは、非常に人気のある OLAP 製品のいくつかに非常に興味を持っていました。 OLAP の最も魅力的な利点は、クエリの応答時間です。通常、大量のデータのクエリ結果を返すのに 1 秒未満しかかからず、数千の同時クエリもサポートできます。

最高の OLAP データベースの 1 つを選びました。ドリス、試してみてください。このエンジンはうまく機能します。しかし、ある時点ですぐに他の問題に遭遇しました。

• 配列や JSON などのデータ型はまだサポートされていません (2022 年 11 月)。配列は、一部のブロックチェーンで一般的なタイプのデータです。たとえば、トピック フィールドevm ログで。配列で計算できないことは、多くのビジネス メトリックを計算する能力に直接影響します。
• DBT およびマージ ステートメントの限定的なサポート。これらは、新しくインデックス付けされたデータを更新する必要がある ETL/ELT シナリオのデータ エンジニアにとって一般的な要件です。

そうは言っても、本番環境のデータ パイプライン全体に Doris を使用することはできませんでした。そのため、Doris を OLAP データベースとして使用して、クエリ エンジンとして機能し、高速なサービスを提供するデータ プロダクション パイプラインの問題の一部を解決しようとしました。高度な同時クエリ機能。

残念ながら、Bigquery を Doris に置き換えることはできなかったため、Bigquery をクエリ エンジンとしてのみ使用して、定期的に Bigquery から Doris にデータを同期する必要がありました。この同期プロセスには多くの問題がありました。そのうちの 1 つは、OLAP エンジンがフロントエンド クライアントへのクエリの提供でビジー状態になると、更新の書き込みがすぐに積み重なってしまうことでした。その後、書き込みプロセスの速度が低下し、同期に時間がかかり、完了できなくなることさえありました。

私たちは、OLAP が私たちが直面しているいくつかの問題を解決できることに気付きました。特にデータ処理パイプラインに関しては、フットプリント分析のターンキー ソリューションになることはできません。私たちの問題はより大きく複雑であり、クエリ エンジンとしての OLAP だけでは十分ではなかったと言えます。

4. アーキテクチャ 3.0 アイスバーグ + トリノ

Footprint Analytics アーキテクチャ 3.0 へようこそ。基盤となるアーキテクチャの完全なオーバーホールです。アーキテクチャ全体をゼロから再設計し、データのストレージ、計算、およびクエリを 3 つの異なる部分に分離しました。 Footprint Analytics の以前の 2 つのアーキテクチャから教訓を得て、Uber、Netflix、Databricks などの他の成功したビッグ データ プロジェクトの経験から学びます。

4.1.データレイクの導入

最初に注目したのは、構造化データと非構造化データの両方に対応する新しいタイプのデータ ストレージであるデータ レイクです。オンチェーン データの形式は、構造化されていない生データから構造化された抽象化データまで多岐にわたるため、データ レイクはオンチェーン データ ストレージに最適です。私たちは、データ レイクを使用してデータ ストレージの問題を解決することを期待していました。理想的には、Spark や Flink などの主流のコンピューティング エンジンもサポートし、フットプリント分析が進化するにつれてさまざまなタイプの処理エンジンと統合するのが面倒にならないようにします。 .

Iceberg は、Spark、Flink、Trino、およびその他の計算エンジンと非常によく統合されており、各メトリクスに最適な計算を選択できます。例えば：

• 複雑な計算ロジックが必要な場合は、Spark が最適です。
• リアルタイム計算用の Flink。
• SQL を使用して実行できる単純な ETL タスクには、Trino を使用します。

4.2.クエリ エンジン

Iceberg がストレージと計算の問題を解決したので、クエリ エンジンの選択方法を検討する必要がありました。利用可能なオプションは多くありません。私たちが検討した代替案は

• 三位一体: SQL クエリ エンジン
• 後で: SQL クエリ エンジン
• Kyuubi: サーバーレス Spark SQL

深く掘り下げる前に検討した最も重要なことは、将来のクエリ エンジンは現在のアーキテクチャと互換性がなければならないということでした。

• BigQuery をデータ ソースとしてサポートするには
• DBT をサポートするため、多くの指標の生成に依存しています
• BI ツールのメタベースをサポートするには

上記に基づいて、Iceberg のサポートが非常に優れている Trino を選択しました。チームは非常に迅速に対応してくれたので、バグを報告しました。これは翌日に修正され、翌週に最新バージョンにリリースされました。これは、高い実装応答性も必要とするフットプリント チームにとって間違いなく最良の選択でした。

4.3.性能試験

方向性を決定したら、Trino + Iceberg の組み合わせでパフォーマンス テストを行い、ニーズを満たすことができるかどうかを確認しました。驚いたことに、クエリは信じられないほど高速でした。

Presto + Hive が OLAP の誇大宣伝の中で何年もの間最悪の比較対象であったことを知っていたので、Trino + Iceberg の組み合わせは完全に私たちの心を吹き飛ばしました。

これが私たちのテストの結果です。

ケース 1: 大規模なデータセットに参加する

800 GB のテーブル1 が別の 50 GB のテーブル2 を結合し、複雑なビジネス計算を実行します

ケース 2: 大きな単一のテーブルを使用して個別のクエリを実行する

SQL のテスト: 日ごとにテーブル グループから個別の (アドレス) を選択します

Trino+Iceberg の組み合わせは、同じ構成の Doris よりも約 3 倍高速です。

これに加えて、別の驚きがあります。Iceberg は、データを圧縮して保存する Parquet、ORC などのデータ形式を使用できるためです。 Iceberg のテーブル ストレージは、他のデータ ウェアハウスの約 1/5 のスペースしか占有しません 3 つのデータベース内の同じテーブルのストレージ サイズは次のとおりです。

4.4.アップグレード効果

パフォーマンス テスト レポートでは、チームが移行を完了するのに約 2 か月かかった十分なパフォーマンスが得られました。これは、アップグレード後のアーキテクチャの図です。

• 複数のコンピュータエンジンが私たちのさまざまなニーズにマッチします。
• Trino は DBT をサポートし、Iceberg に直接クエリを実行できるため、データ同期を処理する必要がなくなりました。
• Trino + Iceberg の驚くべきパフォーマンスにより、すべての Bronze データ (生データ) をユーザーに開放することができます。

5. まとめ

2021 年 8 月の発足以来、フットプリント分析チームは、暗号ユーザーに最高のデータベース技術の利点をもたらすという強い願望と決意、および実装の確実な実行のおかげで、1 年半足らずで 3 つのアーキテクチャのアップグレードを完了しました。基盤となるインフラストラクチャとアーキテクチャをアップグレードします。

Footprint Analytics アーキテクチャ アップグレード 3.0 は、ユーザーに新しいエクスペリエンスを提供し、さまざまなバックグラウンドを持つユーザーがより多様な使用法やアプリケーションで洞察を得ることができるようにします。

• Metabase BI ツールで構築された Footprint は、アナリストがデコードされたオンチェーン データにアクセスし、ツール (コードなしまたはハードコードなし) を完全に自由に選択して探索し、履歴全体をクエリし、データセットをクロス調査して、分析情報を取得することを容易にします。時間。
• オンチェーンとオフチェーンの両方のデータを web2 + web3 全体の分析に統合します。
• Footprint のビジネス抽象化の上にメトリクスを構築/クエリすることで、アナリストまたは開発者は反復的なデータ処理作業の 80% の時間を節約し、ビジネスに基づいた有意義なメトリクス、調査、および製品ソリューションに集中できます。
• Footprint Web から REST API 呼び出しまで、すべて SQL に基づくシームレスなエクスペリエンス
• 重要なシグナルに関するリアルタイムのアラートと実用的な通知により、投資判断をサポート