GeminiStateBackend は、ストリーム処理向けに設計されたキーバリュー (KV) ストレージエンジンです。これは、Realtime Compute for Apache Flink のデフォルトの状態バックエンドです。このトピックでは、GeminiStateBackend のコア設計について説明し、そのパフォーマンスを RocksDBStateBackend と比較します。
概要
ステートフルコンピューティングは、ストリーム処理における複雑で困難なシナリオです。ストリーム処理におけるデータアクセスには、以下の特徴があります。
範囲クエリは少なく、大量のランダムアクセスが発生する。
データトラフィックとホットスポットは動的かつ頻繁に変化する。これは、同じ演算子の異なる同時実行インスタンスでさえ、データアクセスパターンが異なる可能性があることを意味します。
GeminiStateBackend は、これらの特徴に対処するために設計されています。そのコア設計には、以下のハイライトが含まれます。
包括的なパフォーマンス向上のための新しいアーキテクチャとデータ構造設計。
GeminiStateBackend の全体的なアーキテクチャは、Log-Structured Merge-tree (LSM-tree) データ構造に基づいています。これには、データ規模とアクセスパターンに基づく適応的調整、ホットデータとコールドデータの階層型ストレージ、アンチキャッシングとキャッシングアーキテクチャ間の柔軟な切り替えという 3 つの主要な機能が含まれます。さらに、ランダムクエリに最適化されたハッシュベースのストレージ構造も備えています。Nexmark パフォーマンス比較の結果が示すように、GeminiStateBackend は RocksDBStateBackend を大幅に上回っています。ユースケースの約半数において、GeminiStateBackend のパフォーマンスは RocksDBStateBackend よりも 70% 以上優れています。
ストレージとコンピューティングの分離 (デカップリング) をサポートし、状態データのローカルディスクストレージの制限を克服。
ローカルディスク領域が限られている環境では、大規模な状態を持つジョブはディスク領域を使い果たしてしまうことがよくあります。RocksDBStateBackend を使用するジョブは、通常、同時実行数を増やすなどのリソースを追加することでこの問題を解決します。GeminiStateBackend は、ストレージとコンピューティングを分離します。これにより、状態ストレージがローカルディスクから独立して動作できるようになり、状態データがローカルディスク容量を超えたことによるジョブの失敗を防ぎます。ストレージとコンピューティングの分離の設定方法については、「ストレージとコンピューティングの分離の設定」をご参照ください。
適応型キーバリュー分離をサポートし、デュアルストリームまたはマルチストリームの結合ジョブのパフォーマンスを大幅に向上。
デュアルストリームまたはマルチストリームの結合は、ストリーム処理における最も困難なシナリオの 1 つであり、状態ストレージがボトルネックになり得る典型的なケースです。これらのシナリオの多くでは、結合の成功率が低いか、状態データの値が大きくなります。これに対処するため、GeminiStateBackend はキーバリュー (KV) 分離技術を導入しています。この技術は、デュアルストリームまたはマルチストリームの結合ジョブのパフォーマンスを大幅に向上させます。この機能は完全な適応型であり、追加の設定やチューニングは不要です。この技術は、Alibaba Group の「独身の日 (Double 11)」ショッピングフェスティバル期間中に、同社の中核サービスによって検証されました。KV 分離を有効にすると、ジョブのスループット容量が 50% から 70% 増加しました。計算リソースの平均使用率は 50% 増加し、最も恩恵を受けたシナリオでは 100% から 200% 増加しました。KV 分離の設定方法については、「KV 分離の設定」をご参照ください。
軽量なジョブスナップショットにより、大規模な状態を持つジョブのチェックポイントとスナップショットの完了を大幅に高速化。
GeminiStateBackend は、より詳細なジョブスナップショットをサポートし、チェックポイントを LSM コンパクションメカニズムから分離します。これにより、チェックポイントとスナップショットがより高速かつ安定します。さらに、GeminiStateBackend はネイティブの増分セーブポイントをサポートしています。Realtime Compute for Apache Flink が提供するネイティブスナップショットと組み合わせることで、これらのセーブポイントのパフォーマンスはチェックポイントに匹敵し、スナップショットの可用性を大幅に向上させます。
適応型パラメータチューニングにより、手動チューニングを不要に。
ストリーム処理タスクでは、演算子ごとに状態アクセスパターンが異なることがよくあります。状態ストレージは、最適なパフォーマンスを達成するために、通常、異なるパラメータの組み合わせを必要とします。これらのパラメータは数が多く、低レベルの詳細に関わるため、手動でのチューニングは困難で時間がかかります。GeminiStateBackend は、適応型パラメータチューニング技術を使用して、現在のデータアクセスパターンとトラフィックに基づいて実行時にパラメータを自動的に調整します。これにより、さまざまなシナリオで最適なパフォーマンスを実現します。この技術は、Alibaba Group の「独身の日 (Double 11)」ショッピングフェスティバル期間中に、同社の中核サービスによって検証されました。95% 以上のケースで手動チューニングが不要になり、シングルコアのスループット容量が 10% から 40% 増加しました。適応型パラメータチューニングの設定方法については、「適応型パラメータチューニングの設定」をご参照ください。
Nexmark パフォーマンス比較
Nexmark の状態がボトルネックとなるユースケースと同一のハードウェアリソースを使用して、RocksDBStateBackend と GeminiStateBackend のパフォーマンスをテストおよび比較しました。
Nexmark の Web サイトはサードパーティのサイトです。このサイトへのアクセスは、遅延したり利用できなくなったりする場合があります。
結果は、GeminiStateBackend がシングルコアのスループット容量で測定されるジョブ全体の効率を大幅に向上させることを示しています。具体的な結果を次の表に示します。
ケース名 | Gemini TPS/Core | RocksDB TPS/Core | Gemini の RocksDB に対する改善率 |
q4 | 83.63 K/s | 53.26 K/s | 57.02% |
q5 | 84.52 K/s | 57.86 K/s | 46.08% |
q8 | 468.96 K/s | 361.37 K/s | 29.77% |
q9 | 59.42 K/s | 26.56 K/s | 123.72% |
q11 | 93.08 K/s | 48.82 K/s | 90.66% |
q18 | 150.93 K/s | 87.37 K/s | 72.75% |
q19 | 143.46 K/s | 58.5 K/s | 145.23% |
q20 | 75.69 K/s | 22.44 K/s | 237.30% |
参考
状態セットの作成、表示、削除、および指定した状態からの回復方法については、「状態セットの管理」をご参照ください。
状態データの移行における RocksDB と Gemini の移行効率とジョブパフォーマンスの違いについては、「概要」をご参照ください。
SQL の変更による互換性の影響の詳細については、「SQL の変更と互換性」をご参照ください。
Nexmark を使用して Realtime Compute for Apache Flink のパフォーマンスをテストする手順については、「パフォーマンスホワイトペーパー (Nexmark パフォーマンステスト)」をご参照ください。
Realtime Compute for Apache Flink のシステムチェックポイントまたはジョブスナップショットに関するよくある質問 (FAQ) については、「チェックポイントに関するよくある質問」をご参照ください。