アイスバーグ+スパーク+トリノ:ブロックチェーンのための最新のオープンソースデータスタック
この章では、フットプリントの主要なアーキテクチャのアップグレード、機能、およびデータ収集と整理のパフォーマンスについて説明します。
最新のブロックチェーンデータスタックの課題
現代のブロックチェーンインデックス作成スタートアップが直面する可能性のあるいくつかの課題があります。
- 大量のデータ。 ブロックチェーン上のデータ量が増加するにつれて、データインデックスは、増加した負荷を処理し、データへの効率的なアクセスを提供するためにスケールアップする必要があります。 その結果、ストレージコストが高くなります。メトリックの計算が遅くなり、データベース サーバーの負荷が増加します。
- 複雑なデータ処理パイプライン。 ブロックチェーン技術は複雑であり、包括的で信頼性の高いデータインデックスを構築するには、基礎となるデータ構造とアルゴリズムを深く理解する必要があります。 これは、ブロックチェーン実装の多様性に受け継がれています。 具体的な例を挙げると、イーサリアムのNFTは通常、ERC721およびERC1155形式に準拠したスマートコントラクト内で作成されますが、たとえばポルカドットでのNFTの実装は通常、ブロックチェーンランタイム内で直接構築されます。 結局のところ、それらはNFTと見なされ、それらとして保存する必要があります。
- 統合機能。 ユーザーに最大の価値を提供するために、ブロックチェーンインデックスソリューションは、そのデータインデックスを分析プラットフォームやAPIなどの他のシステムと統合する必要がある場合があります。 これは困難であり、アーキテクチャの設計に多大な労力を費やしていただきます。
ブロックチェーン技術の使用が普及するにつれて、ブロックチェーンに保存されるデータの量は増加しています。 これは、より多くの人々がテクノロジーを使用しており、各トランザクションがブロックチェーンに新しいデータを追加するためです。 さらに、ブロックチェーン技術の使用は、ビットコインの使用を伴うような単純な送金アプリケーションから、スマートコントラクト内のビジネスロジックの実装を伴うより複雑なアプリケーションへと進化しました。 これらのスマートコントラクトは大量のデータを生成する可能性があり、ブロックチェーンの複雑さとサイズの増加に貢献しています。 時間が経つにつれて、これはより大きく、より複雑なブロックチェーンにつながりました。
本稿では、Iceberg-Trinoテクノロジースタックがオンチェーンデータの課題にどのように対処するかを探るためのケーススタディとして、フットプリントアナリティクスのテクノロジーアーキテクチャの進化を段階的にレビューします。
フットプリント・アナリティクスは、約22のパブリックブロックチェーンデータ、17のNFTマーケットプレイス、1900のGameFiプロジェクト、100,000を超えるNFTコレクションをセマンティック抽象化データレイヤーにインデックス化しました。 これは、世界で最も包括的なブロックチェーンデータウェアハウスソリューションです。
データアナリストによって頻繁に照会される金融取引の200億行以上のレコードを含むブロックチェーンデータに関係なく。 これは、従来のデータ ウェアハウスのイングレッション ログとは異なります。
増大するビジネス要件を満たすために、過去数か月で3つの主要なアップグレードが発生しました。
アーキテクチャ 1.0 Bigquery
フットプリント分析の開始当初は、ストレージおよびクエリエンジンとしてGoogle Bigqueryを使用していました。Bigquery は素晴らしい製品です。 非常に高速で使いやすく、動的な算術パワーと柔軟なUDF構文を提供し、作業をすばやく完了するのに役立ちます。
ただし、Bigquery にはいくつかの問題もあります。
- データは圧縮されないため、特にフットプリント分析の22を超えるブロックチェーンの生データを保存する場合は、ストレージコストが高くなります。
- 同時実行性が不十分: Bigquery は 100 個の同時クエリしかサポートしないため、多数のアナリストやユーザーにサービスを提供するフットプリント アナリティクスの同時実行性の高いシナリオには適していません。
- クローズドソース製品であるGoogle Bigqueryでロックインします。
そこで、他の代替アーキテクチャを検討することにしました。
アーキテクチャ 2.0 OLAP
私たちは、非常に人気があるOLAP製品のいくつかに非常に興味を持っていました。 OLAP の最も魅力的な利点は、大量のデータのクエリ結果を返すのに通常数秒かかるクエリ応答時間であり、数千の同時クエリもサポートできます。
最高のOLAPデータベースの1つであるDorisを選んで試してみました。 このエンジンはうまく機能します。 しかし、ある時点で、すぐに他のいくつかの問題が発生しました。
- 配列やJSONなどのデータ型はまだサポートされていません(2022年11月)。 配列は、一部のブロックチェーンで一般的なタイプのデータです。 たとえば、evm ログのトピック フィールドなどです。 Arrayで計算できないと、多くのビジネスメトリックを計算する能力に直接影響します。
- DBT およびマージ ステートメントのサポートが制限されています。 これらは、新しくインデックス付けされたデータを更新する必要がある ETL/ELT シナリオのデータ エンジニアの一般的な要件です。
そうは言っても、本番環境のデータパイプライン全体にDorisを使用することはできませんでしたので、DorisをOLAPデータベースとして使用して、クエリエンジンとして機能し、高速で高度なクエリ機能を提供して、データプロダクションパイプラインの問題の一部を解決しようとしました。
残念ながら、Bigquery を Dorisに置き換えることはできなかったため、クエリエンジンとしてのみ使用して、Bigquery から Dois に定期的にデータを同期する必要がありました。 この同期プロセスには多くの問題がありましたが、その 1 つは、OLAP エンジンがフロントエンド クライアントへのクエリの処理でビジー状態のときに、更新の書き込みがすぐに積み重なることでした。 その後、書き込みプロセスの速度に影響がかかり、同期に時間がかかり、場合によっては完了できなくなることさえありました。
OLAPは私たちが直面しているいくつかの問題を解決でき、特にデータ処理パイプラインのフットプリント分析のターンキーソリューションにはなれないことに気づきました。 私たちの問題はより大きく、より複雑であり、クエリ エンジンとしての OLAP だけでは十分ではなかったと言えます。
アーキテクチャ3.0氷山+トリノ
基盤となるアーキテクチャの完全なオーバーホールであるフットプリント分析アーキテクチャ3.0へようこそ。 アーキテクチャ全体をゼロから再設計し、データのストレージ、計算、クエリを3つの異なる部分に分離しました。 フットプリント分析の2つの以前のアーキテクチャから教訓を得て、Uber、Netflix、Databricksなどの他の成功したビッグデータプロジェクトの経験から学びます。
データレイクの導入
まず、構造化データと非構造化データの両方に対応する新しいタイプのデータストレージであるデータレイクに注目しました。 データレイクは、オンチェーンデータの形式が非構造化生データから構造化抽象化データまで多岐にわたるため、オンチェーンデータストレージに最適です。 データレイクを使用してデータストレージの問題を解決し、理想的にはSparkやFlinkなどの主流のコンピューティングエンジンもサポートするため、フットプリント分析の進化に合わせてさまざまなタイプの処理エンジンと統合するのが面倒ではありません。
Icebergは、Spark、Flink、Trino、その他の計算エンジンと非常によく統合されており、各メトリックに最も適切な計算を選択できます。 例えば：
- 複雑な計算ロジックが必要な場合は、Sparkが最適です。
- リアルタイム計算のためのフリンク。
- SQL を使用して実行できる単純な ETL タスクには、Trino を使用します。
クエリ エンジン
Iceberg がストレージと計算の問題を解決したので、クエリ エンジンを選択する方法を考える必要がありました。 利用可能なオプションは多くありませんが、私たちが検討した代替案は
- トリノ: SQL クエリ エンジン
- プレスト: SQL クエリ エンジン
- Kyuubi: Serverless Spark SQL
先に進む前に検討した最も重要なことは、将来のクエリ エンジンが現在のアーキテクチャと互換性がある必要があるということでした。
- データソースとして Bigquery をサポートするには
- 多くのメトリックの生成に依存しているDBTをサポートするため
- BI ツールのメタベースをサポートするには
上記に基づいて、Icebergのサポートが非常に優れているTrinoを選択し、チームの応答性が非常に高かったため、バグを提起し、翌日修正され、翌週に最新バージョンにリリースされました。 これは、高い実装応答性も必要とするフットプリントチームにとって間違いなく最良の選択でした。
性能試験
方向性を決定したら、Trino + Icebergの組み合わせでパフォーマンステストを行い、ニーズを満たすことができるかどうかを確認しましたが、驚いたことに、クエリは非常に高速でした。
Presto + HiveがすべてのOLAP誇大宣伝の中で何年にもわたって最悪の比較対象であったことを知って、Trino + Icebergの組み合わせは完全に私たちの心を吹き飛ばしました。
これが私たちのテストの結果です。
ケース 1 : 大規模なデータセットを結合する
800 GB のテーブル 1 が別の 50 GB のテーブル 2 を結合し、複雑なビジネス計算を行う
ケース 2: 大きな 1 つのテーブルを使用して個別のクエリを実行する
テストSQL:日ごとにテーブルグループから個別の(アドレス)を選択します
トリノ+アイスバーグの組み合わせは、同じ構成のドリスよりも約3倍高速です。
これに加えて、Icebergは寄木細工の床、ORCなどのデータ形式を使用してデータを圧縮して保存できるため、別の驚きがあります。 Iceberg のテーブル ストレージは、他のデータ ウェアハウスの約 1/5 のスペースしか占有しません。 3 つのデータベース内の同じテーブルのストレージ サイズは次のとおりです。
注:上記のテストは、実際の本番環境で遭遇した個々の例であり、参照用です。
・アップグレード効果
パフォーマンステストレポートは、チームが移行を完了するのに約2か月かかるほどのパフォーマンスを提供し、これはアップグレード後のアーキテクチャの図です。
- 複数のコンピュータエンジンが私たちのさまざまなニーズにマッチします。
- TrinoはDBTをサポートし、Icebergに直接クエリできるため、データ同期を処理する必要がなくなりました。
- Trino + Icebergの驚くべきパフォーマンスにより、すべてのブロンズデータ(生データ)をユーザーに公開することができます。
概要
2021年8月の立ち上げ以来、Footprint Analyticsチームは、最高のデータベーステクノロジーのメリットを暗号ユーザーにもたらすという幅広い願望と決意、および基盤となるインフラストラクチャとアーキテクチャの実装とアップグレードの堅実な実行のおかげで、1年半足らずで3つのアーキテクチャのアップグレードを完了しました。
フットプリント・アナリティクスのアーキテクチャー・アップグレード3.0は、ユーザーに新しいエクスペリエンスを提供し、さまざまなバックグラウンドを持つユーザーが、より多様な使用法やアプリケーションに関する洞察を得ることができるようになりました。
- Metabase BIツールで構築されたフットプリントは、アナリストがデコードされたオンチェーンデータにアクセスし、ツール(ノーコードまたはハードコード)を完全に自由に選択して探索し、履歴全体を照会し、データセットを相互調査して、すぐに洞察を得るのに役立ちます。
- オンチェーンとオフチェーンの両方のデータをweb2 + web3全体の分析に統合します。
- フットプリントのビジネス抽象化の上にメトリックを構築/クエリすることで、アナリストや開発者は、反復的なデータ処理作業の80%の時間を節約し、ビジネスに基づいた意味のあるメトリック、調査、製品ソリューションに集中できます。
- フットプリント・ウェブからREST API呼び出しまでのシームレスなエクスペリエンス、すべてSQLに基づく
- 投資決定をサポートするための主要なシグナルに関するリアルタイムのアラートと実用的な通知
アイスバーグ+スパーク+トリノ:ブロックチェーンのための最新のオープンソースデータスタック
この章では、フットプリントの主要なアーキテクチャのアップグレード、機能、およびデータ収集と整理のパフォーマンスについて説明します。
最新のブロックチェーンデータスタックの課題
現代のブロックチェーンインデックス作成スタートアップが直面する可能性のあるいくつかの課題があります。
- 大量のデータ。 ブロックチェーン上のデータ量が増加するにつれて、データインデックスは、増加した負荷を処理し、データへの効率的なアクセスを提供するためにスケールアップする必要があります。 その結果、ストレージコストが高くなります。メトリックの計算が遅くなり、データベース サーバーの負荷が増加します。
- 複雑なデータ処理パイプライン。 ブロックチェーン技術は複雑であり、包括的で信頼性の高いデータインデックスを構築するには、基礎となるデータ構造とアルゴリズムを深く理解する必要があります。 これは、ブロックチェーン実装の多様性に受け継がれています。 具体的な例を挙げると、イーサリアムのNFTは通常、ERC721およびERC1155形式に準拠したスマートコントラクト内で作成されますが、たとえばポルカドットでのNFTの実装は通常、ブロックチェーンランタイム内で直接構築されます。 結局のところ、それらはNFTと見なされ、それらとして保存する必要があります。
- 統合機能。 ユーザーに最大の価値を提供するために、ブロックチェーンインデックスソリューションは、そのデータインデックスを分析プラットフォームやAPIなどの他のシステムと統合する必要がある場合があります。 これは困難であり、アーキテクチャの設計に多大な労力を費やしていただきます。
ブロックチェーン技術の使用が普及するにつれて、ブロックチェーンに保存されるデータの量は増加しています。 これは、より多くの人々がテクノロジーを使用しており、各トランザクションがブロックチェーンに新しいデータを追加するためです。 さらに、ブロックチェーン技術の使用は、ビットコインの使用を伴うような単純な送金アプリケーションから、スマートコントラクト内のビジネスロジックの実装を伴うより複雑なアプリケーションへと進化しました。 これらのスマートコントラクトは大量のデータを生成する可能性があり、ブロックチェーンの複雑さとサイズの増加に貢献しています。 時間が経つにつれて、これはより大きく、より複雑なブロックチェーンにつながりました。
本稿では、Iceberg-Trinoテクノロジースタックがオンチェーンデータの課題にどのように対処するかを探るためのケーススタディとして、フットプリントアナリティクスのテクノロジーアーキテクチャの進化を段階的にレビューします。
フットプリント・アナリティクスは、約22のパブリックブロックチェーンデータ、17のNFTマーケットプレイス、1900のGameFiプロジェクト、100,000を超えるNFTコレクションをセマンティック抽象化データレイヤーにインデックス化しました。 これは、世界で最も包括的なブロックチェーンデータウェアハウスソリューションです。
データアナリストによって頻繁に照会される金融取引の200億行以上のレコードを含むブロックチェーンデータに関係なく。 これは、従来のデータ ウェアハウスのイングレッション ログとは異なります。
増大するビジネス要件を満たすために、過去数か月で3つの主要なアップグレードが発生しました。
アーキテクチャ 1.0 Bigquery
フットプリント分析の開始当初は、ストレージおよびクエリエンジンとしてGoogle Bigqueryを使用していました。Bigquery は素晴らしい製品です。 非常に高速で使いやすく、動的な算術パワーと柔軟なUDF構文を提供し、作業をすばやく完了するのに役立ちます。
ただし、Bigquery にはいくつかの問題もあります。
- データは圧縮されないため、特にフットプリント分析の22を超えるブロックチェーンの生データを保存する場合は、ストレージコストが高くなります。
- 同時実行性が不十分: Bigquery は 100 個の同時クエリしかサポートしないため、多数のアナリストやユーザーにサービスを提供するフットプリント アナリティクスの同時実行性の高いシナリオには適していません。
- クローズドソース製品であるGoogle Bigqueryでロックインします。
そこで、他の代替アーキテクチャを検討することにしました。
アーキテクチャ 2.0 OLAP
私たちは、非常に人気があるOLAP製品のいくつかに非常に興味を持っていました。 OLAP の最も魅力的な利点は、大量のデータのクエリ結果を返すのに通常数秒かかるクエリ応答時間であり、数千の同時クエリもサポートできます。
最高のOLAPデータベースの1つであるDorisを選んで試してみました。 このエンジンはうまく機能します。 しかし、ある時点で、すぐに他のいくつかの問題が発生しました。
- 配列やJSONなどのデータ型はまだサポートされていません(2022年11月)。 配列は、一部のブロックチェーンで一般的なタイプのデータです。 たとえば、evm ログのトピック フィールドなどです。 Arrayで計算できないと、多くのビジネスメトリックを計算する能力に直接影響します。
- DBT およびマージ ステートメントのサポートが制限されています。 これらは、新しくインデックス付けされたデータを更新する必要がある ETL/ELT シナリオのデータ エンジニアの一般的な要件です。
そうは言っても、本番環境のデータパイプライン全体にDorisを使用することはできませんでしたので、DorisをOLAPデータベースとして使用して、クエリエンジンとして機能し、高速で高度なクエリ機能を提供して、データプロダクションパイプラインの問題の一部を解決しようとしました。
残念ながら、Bigquery を Dorisに置き換えることはできなかったため、クエリエンジンとしてのみ使用して、Bigquery から Dois に定期的にデータを同期する必要がありました。 この同期プロセスには多くの問題がありましたが、その 1 つは、OLAP エンジンがフロントエンド クライアントへのクエリの処理でビジー状態のときに、更新の書き込みがすぐに積み重なることでした。 その後、書き込みプロセスの速度に影響がかかり、同期に時間がかかり、場合によっては完了できなくなることさえありました。
OLAPは私たちが直面しているいくつかの問題を解決でき、特にデータ処理パイプラインのフットプリント分析のターンキーソリューションにはなれないことに気づきました。 私たちの問題はより大きく、より複雑であり、クエリ エンジンとしての OLAP だけでは十分ではなかったと言えます。
アーキテクチャ3.0氷山+トリノ
基盤となるアーキテクチャの完全なオーバーホールであるフットプリント分析アーキテクチャ3.0へようこそ。 アーキテクチャ全体をゼロから再設計し、データのストレージ、計算、クエリを3つの異なる部分に分離しました。 フットプリント分析の2つの以前のアーキテクチャから教訓を得て、Uber、Netflix、Databricksなどの他の成功したビッグデータプロジェクトの経験から学びます。
データレイクの導入
まず、構造化データと非構造化データの両方に対応する新しいタイプのデータストレージであるデータレイクに注目しました。 データレイクは、オンチェーンデータの形式が非構造化生データから構造化抽象化データまで多岐にわたるため、オンチェーンデータストレージに最適です。 データレイクを使用してデータストレージの問題を解決し、理想的にはSparkやFlinkなどの主流のコンピューティングエンジンもサポートするため、フットプリント分析の進化に合わせてさまざまなタイプの処理エンジンと統合するのが面倒ではありません。
Icebergは、Spark、Flink、Trino、その他の計算エンジンと非常によく統合されており、各メトリックに最も適切な計算を選択できます。 例えば：
- 複雑な計算ロジックが必要な場合は、Sparkが最適です。
- リアルタイム計算のためのフリンク。
- SQL を使用して実行できる単純な ETL タスクには、Trino を使用します。
クエリ エンジン
Iceberg がストレージと計算の問題を解決したので、クエリ エンジンを選択する方法を考える必要がありました。 利用可能なオプションは多くありませんが、私たちが検討した代替案は
- トリノ: SQL クエリ エンジン
- プレスト: SQL クエリ エンジン
- Kyuubi: Serverless Spark SQL
先に進む前に検討した最も重要なことは、将来のクエリ エンジンが現在のアーキテクチャと互換性がある必要があるということでした。
- データソースとして Bigquery をサポートするには
- 多くのメトリックの生成に依存しているDBTをサポートするため
- BI ツールのメタベースをサポートするには
上記に基づいて、Icebergのサポートが非常に優れているTrinoを選択し、チームの応答性が非常に高かったため、バグを提起し、翌日修正され、翌週に最新バージョンにリリースされました。 これは、高い実装応答性も必要とするフットプリントチームにとって間違いなく最良の選択でした。
性能試験
方向性を決定したら、Trino + Icebergの組み合わせでパフォーマンステストを行い、ニーズを満たすことができるかどうかを確認しましたが、驚いたことに、クエリは非常に高速でした。
Presto + HiveがすべてのOLAP誇大宣伝の中で何年にもわたって最悪の比較対象であったことを知って、Trino + Icebergの組み合わせは完全に私たちの心を吹き飛ばしました。
これが私たちのテストの結果です。
ケース 1 : 大規模なデータセットを結合する
800 GB のテーブル 1 が別の 50 GB のテーブル 2 を結合し、複雑なビジネス計算を行う
ケース 2: 大きな 1 つのテーブルを使用して個別のクエリを実行する
テストSQL:日ごとにテーブルグループから個別の(アドレス)を選択します
トリノ+アイスバーグの組み合わせは、同じ構成のドリスよりも約3倍高速です。
これに加えて、Icebergは寄木細工の床、ORCなどのデータ形式を使用してデータを圧縮して保存できるため、別の驚きがあります。 Iceberg のテーブル ストレージは、他のデータ ウェアハウスの約 1/5 のスペースしか占有しません。 3 つのデータベース内の同じテーブルのストレージ サイズは次のとおりです。
注:上記のテストは、実際の本番環境で遭遇した個々の例であり、参照用です。
・アップグレード効果
パフォーマンステストレポートは、チームが移行を完了するのに約2か月かかるほどのパフォーマンスを提供し、これはアップグレード後のアーキテクチャの図です。
- 複数のコンピュータエンジンが私たちのさまざまなニーズにマッチします。
- TrinoはDBTをサポートし、Icebergに直接クエリできるため、データ同期を処理する必要がなくなりました。
- Trino + Icebergの驚くべきパフォーマンスにより、すべてのブロンズデータ(生データ)をユーザーに公開することができます。
概要
2021年8月の立ち上げ以来、Footprint Analyticsチームは、最高のデータベーステクノロジーのメリットを暗号ユーザーにもたらすという幅広い願望と決意、および基盤となるインフラストラクチャとアーキテクチャの実装とアップグレードの堅実な実行のおかげで、1年半足らずで3つのアーキテクチャのアップグレードを完了しました。
フットプリント・アナリティクスのアーキテクチャー・アップグレード3.0は、ユーザーに新しいエクスペリエンスを提供し、さまざまなバックグラウンドを持つユーザーが、より多様な使用法やアプリケーションに関する洞察を得ることができるようになりました。
- Metabase BIツールで構築されたフットプリントは、アナリストがデコードされたオンチェーンデータにアクセスし、ツール(ノーコードまたはハードコード)を完全に自由に選択して探索し、履歴全体を照会し、データセットを相互調査して、すぐに洞察を得るのに役立ちます。
- オンチェーンとオフチェーンの両方のデータをweb2 + web3全体の分析に統合します。
- フットプリントのビジネス抽象化の上にメトリックを構築/クエリすることで、アナリストや開発者は、反復的なデータ処理作業の80%の時間を節約し、ビジネスに基づいた意味のあるメトリック、調査、製品ソリューションに集中できます。
- フットプリント・ウェブからREST API呼び出しまでのシームレスなエクスペリエンス、すべてSQLに基づく
- 投資決定をサポートするための主要なシグナルに関するリアルタイムのアラートと実用的な通知