本記事はこちらのブログを参考にしています。
翻訳にはアリババクラウドのModelStudio(Qwen)を使用しております。

Fluss: カッティングエッジなストリーミングストレージシステム

前回のブログ記事で、Kafkaを使用してリアルタイム分析を行う際の課題について議論しました。本日は、リアルタイム分析を強力にサポートする最新のストリーミングストレージシステムであるFlussを紹介します。Flussのアーキテクチャ、設計原則、主要な機能、そしてKafkaを使用したリアルタイム分析の課題に対する対応方法について探求していきます。

Flussの主要な機能

コラムベースのストリーム

予想通り、Flussはコラムベースのストリーミングストレージであり、その基盤となるファイルストレージにはApache Arrow IPC Streaming Formatを利用しています。これにより、Flussはミリ秒レベルのストリーミング読み書き能力を維持しながら、効率的な列選択（column pruning）を実現できます。FlussとKafkaのベンチマーク比較では、横軸が読み取る列数、縦軸が読み取りスループットを示しています。結果は、読み取る列数が減少するに従ってFlussの読み取り性能が比例して向上することを明確に示しています。例えば、列数が90%減少すると、Flussの読み取りスループットは10倍になります。Flussの重要な利点は、列選択がサーバーサイドで行われ、必要な列データのみがクライアント側に転送されることです。このアーキテクチャ設計はパフォーマンスを向上させるだけでなく、ネットワークコストとリソース消費を削減し、Flussをリアルタイムストリーミング分析に非常に効率的なソリューションにしています。

リアルタイム更新とチェンジログ

リアルタイム更新とチェンジログは、ストリーミング分析とFlinkにとって非常に重要な機能です。Flussストリーミングストレージの核心はLog Tabletに基づいており、Logの上にキー・バリュー（KV）インデックスが構築されています。LogとKVの関係は、ストリームとテーブルの二重性（stream-table duality）の概念を反映しており、KVの更新により生成されたチェンジログがLogに書き込まれます。障害発生時には、Logからデータを復元してKVを再構築します。KVインデックスは、大規模なリアルタイム更新をサポートするためにLog-Structured Merge (LSM)ツリーとして実装されており、部分更新もサポートしています。これにより、幅広いテーブルを効率的に構築できます。また、KVによって生成されたチェンジログは、追加の重複除去コストなしでFlinkから直接読み取ることができ、多くの計算リソースを節約します。

クエリ可能

組み込みのKVインデックスにより、高性能なプライマリキー検索が可能になり、Flussは次元テーブル結合などのリアルタイム処理タスクに適しています。ユーザーはFlussを使って直接データ探索を行うこともでき、LIMITやCOUNTなどの操作を含むクエリを実行して、Fluss内のデータのデバッグを容易に行うことができます。

ストリームとLakehouseの統一

Flussの目立つ特長の一つは、ストリームとLakehouseの統一です。従来のLambdaアーキテクチャでは、リアルタイムレイヤーとバッチレイヤーの両方にデータを複製する必要がありました。しかし、Flussはストリームと湖倉（Lakehouse）に格納されたデータを統一することで、この冗長性を排除します。この統一により、一貫性のあるデータとメタデータが確保され、ストレージコストが削減され、データワークフローが簡素化されます。Flussの中心には、ストリームと湖倉ストレージ間のシームレスな統合を確保する圧縮サービスが組み込まれています。このサービスは自動的かつ継続的にFlussデータをデータ湖形式に変換します。ここでの重要な特長はShared Dataです。湖倉ストレージは、長期データの保存に最適化された歴史データ層としてストリーミングストレージを補完し、分単位の遅延で動作します。一方、ストリーミングストレージは、ミリ秒単位の遅延で動作する短期データの保存に最適化されたリアルタイムデータ層として湖倉ストレージを補完します。データは相互に共有され、単一のテーブルとして公開されます。テーブルに対するストリーミングクエリでは、まず湖倉ストレージを歴史データとして使用して効率的なキャッチアップ読み取りを行い、その後、リアルタイムデータのためにシームレスにストリーミングストレージに移行します。これにより、重複データの読み取りが防げます。テーブルに対するバッチクエリでは、ストリーミングストレージが湖倉ストレージのリアルタイムデータを補完し、湖倉分析のセコンドレベルの新鮮さを実現します。この機能はUnion Readと呼ばれ、両レイヤーが協調して高度に効率的かつ正確なデータアクセスを可能にします。さらに、自動的に変換されたデータ湖テーブルは、既存のクエリエンジン（Apache Spark, StarRocks, Trinoなど）との互換性を確保するオープンテーブル形式プロトコルに完全に準拠しています。これらのエンジンは、湖倉ストレージ上のデータを直接クエリし、ユーザーの既存の湖倉アーキテクチャにシームレスに統合することができます。FlussはすでにApache Paimonとの統合を完了しており、Apache Icebergとの統合も進行中です。この互換性へのコミットメントにより、Flussは現代のデータスタックにおいて柔軟で強力なコンポーネントとして、リアルタイムデータと歴史データの橋渡しを行い、統一された分析とストレージ効率を実現します。

全体的なアーキテクチャ

これが、リアルタイム分析向けに特別に設計された最新のストリーミングストレージソリューションであるFlussの全体的なアーキテクチャです。Flussはサーバクラスターを運用して、高パフォーマンスなリアルタイム読み書き能力を提供し、リモートストレージを利用してデータティアリングを行い、ストレージコストを最適化します。さらに、Flussは湖倉アーキテクチャとシームレスに統合し、堅牢なクエリ機能と統一されたデータエコシステムを実現します。Flussの主要な特長には、リアルタイムストリーミング読み書き、列選択、ストリーミング更新

この革新の正式化

私たちは、この革新を正式化するために、Delta Join FLIP-486 提案をApache Flinkコミュニティに提出しました。興味のある方々には、この革新的な進歩についてレビューし、貢献していただけますようお願い申し上げます。

Flussによって実現されたDelta Joinは、リソース消費の大幅な削減、パフォーマンスの向上、およびステートフルストリーム処理における柔軟性の解放により、リアルタイム分析において画期的な進歩をもたらします。

今後の計画

Flussの将来計画は、以下の3つの主要な側面に焦点を当てており、それぞれが3つのオープンソースソフトウェアプロジェクトとの関係に対応しています：

Apache Kafkaプロトコル互換性

これは、既存のストリーミングデータがFlussへより効果的に移行できるようにすることを目指しています。

Apache Flink向けのストレージ

Flussは、Apache Flinkとストリーミング分析向けの最適なストレージを目指しており、ストレージ、オプティマイザー、実行レイヤー全体でFlinkとの深いつながりを持つことを目指しています。Delta Joinは私たちの最初の大きな一歩であり、これからの多くの興奮する機能が予定されています。

Apache Iceberg用のリアルタイムデータレイヤー

ストリームとLakehouseを統合することで、FlussはApache IcebergとApache Paimon向けの堅牢なリアルタイムデータレイヤーを提供することにコミットしています。このビジョンには、リアルタイム分析とオフライン分析の両方をサポートする統一されたストレージソリューションの作成が含まれています。

コミュニティでは他にも多くの興奮する取り組みが行われています。詳細な将来計画については、Fluss Roadmapをご覧ください。