GeminiStateBackend は、ストリーム処理用に設計されたキーバリュー型ストレージエンジンであり、Realtime Compute for Apache Flink のデフォルトの状態バックエンドです。このトピックでは、エンタープライズレベルの状態バックエンドストレージである GeminiStateBackend の利点と、GeminiStateBackend と RocksDBStateBackend のパフォーマンス比較について説明します。
概要
ステートフルコンピューティングは、ストリーム処理において複雑で困難なシナリオです。ストリーム処理のデータアクセスには、次の特性があります。
ランダムアクセスが多く、範囲クエリはほとんど実行されません。
データトラフィックとホットスポットは頻繁に変化します。この場合、同じ演算子の異なる並列スレッドは、異なるデータアクセスモードを使用します。
GeminiStateBackend には次の利点があります。
新しいアーキテクチャとデータ構造設計を使用して、全体的なデータ処理パフォーマンスを向上させます。
GeminiStateBackend の全体的なアーキテクチャは、ログ構造化マージツリー(LSM ツリー)データ構造に基づいて設計されています。 GeminiStateBackend は、データ量とアクセス特性の変化への適応、ホットデータとコールドデータの階層型ストレージ、およびアンチキャッシングアーキテクチャとキャッシングアーキテクチャ間の切り替えという 3 つの機能を提供します。 GeminiStateBackend は、ランダムアクセスを可能にするハッシュストレージ構造もサポートしています。Nexmark を使用したパフォーマンス比較では、GeminiStateBackend は RocksDBStateBackend よりも優れたパフォーマンスを提供することが示されています。 GeminiStateBackend のユースケースの約半分の パフォーマンスは、RocksDBStateBackend のユースケースの パフォーマンスよりも 70% 以上高くなっています。
コンピューティングとストレージの分離をサポートして、状態データのローカルディスクへの依存を排除します。
ローカルディスクの容量は限られています。したがって、大量の状態データを持つデプロイメントでは、ローカルディスク容量が不足するという問題が発生することがよくあります。ほとんどの場合、RocksDBStateBackend に基づいて実行されているデプロイメントでローカルディスク容量が不足するという問題が発生した場合、スレッドの並列性を高めるか、他の方法を使用してリソースを増やす必要があります。 GeminiStateBackend は、コンピューティングとストレージの分離をサポートしています。これにより、状態ストレージをローカルディスクから独立させることができます。これにより、過剰なローカル状態データによって発生するデプロイメントの失敗を防ぎます。コンピューティングとストレージの分離に関連する構成の詳細については、コンピューティングとストレージの分離のパラメーターをご参照ください。
適応型キーバリュー分離をサポートして、デュアルストリーム JOIN またはマルチストリーム JOIN を伴うデプロイメントのパフォーマンスを大幅に向上させます。
デュアルストリーム JOIN またはマルチストリーム JOIN は、ストリーム処理における最も困難なシナリオの 1 つであり、状態ストレージがボトルネックに遭遇する典型的なシナリオです。 GeminiStateBackend は、JOIN 操作の成功率が低い場合、または状態データ値の長さが長い場合に適応するキーバリュー分離機能を提供します。これにより、デュアルストリーム JOIN またはマルチストリーム JOIN を伴うデプロイメントのパフォーマンスが大幅に向上します。キーバリュー分離機能は、手動による構成や最適化を必要とせずに適応調整をサポートします。 Alibaba グループの Double 11 Shopping Festival 中の検証では、キーバリュー分離機能を有効にすると、デプロイメントのスループットが 50% から 70% 以上向上し、コンピューティングリソース使用率が平均 50% 向上することが示されています。典型的なシナリオでは、コンピューティングリソース使用率は 100% から 200% 向上します。キーバリュー分離に関連する構成の詳細については、キーバリュー分離のパラメーターをご参照ください。
軽量のセーブポイントを使用することで、大量の状態データを含むデプロイメントのチェックポイントとセーブポイントの作成を大幅に高速化します。
GeminiStateBackend は、よりきめ細かいデプロイメントセーブポイントをサポートし、チェックポイント機能を LSM ツリーの圧縮メカニズムから分離します。これにより、チェックポイントとセーブポイントの作成が高速化および安定化されます。 GeminiStateBackend は、ネイティブ増分セーブポイント機能もサポートしています。この機能は、Realtime Compute for Apache Flink のネイティブセーブポイントと組み合わせて使用され、チェックポイントのパフォーマンスと同様のパフォーマンスを提供します。これにより、セーブポイントの可用性が向上します。
適応型パラメーター調整をサポートすることで、手動パラメーター調整のワークロードを防ぎます。
ストリーム処理タスクでは、演算子ごとに状態アクセスモードが異なります。ほとんどの場合、状態ストレージの最適なパフォーマンスを実現するには、異なるパラメーターの組み合わせが必要です。これらのパラメーターの構成には、基盤となるテクノロジーが関係しています。手動パラメーター調整には、学習と理解に高いコストがかかります。この問題を解決するために、GeminiStateBackend は適応型パラメーター調整テクノロジーをサポートしています。デプロイメントの実行中に、現在のデータアクセスモードとトラフィックに基づいてパラメーター構成を自動的に調整し、さまざまなシナリオで状態ストレージの最適なパフォーマンスを実現できます。 Alibaba グループの Double 11 Shopping Festival 中の検証では、このテクノロジーにより、手動パラメーター調整を 95% 以上削減し、シングルコアスループットを 10% から 40% 向上できることが示されています。適応型パラメーター調整に関連する構成の詳細については、適応型パラメーター調整のパラメーターをご参照ください。
Nexmark を使用したパフォーマンス比較
この例では、Nexmark の状態ボトルネックとハードウェアリソースに関連するユースケースを使用して、RocksDBStateBackend と GeminiStateBackend のパフォーマンスを比較します。
Nexmark リンクはサードパーティの Web サイトからのものです。 Web サイトにアクセスすると、Web サイトにアクセスできないか、Web サイトへのアクセスが遅れる可能性があります。
比較結果によると、GeminiStateBackend はデプロイメントの全体的なパフォーマンス(シングルコアスループット)を大幅に最適化していることがわかります。次の表に比較結果を示します。
ケース名 | GeminiStateBackend TPS/コア | RocksDBStateBackend TPS/コア | GeminiStateBackend によるパフォーマンス向上 |
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% |
参照
デプロイメントの状態の作成、表示、削除、または指定された状態からのデプロイメントの復元方法の詳細については、状態セットの管理をご参照ください。
RocksDBStateBackend と GeminiStateBackend 間の状態データ移行中の移行効率とデプロイメントパフォーマンスの違いの詳細については、Flink状態データの互換性をご参照ください。
デプロイメントの SQL ステートメントの変更が、デプロイメントと状態データ間の互換性に与える影響の詳細については、SQL の変更と互換性への影響をご参照ください。
Realtime Compute for Apache Flink の Nexmark パフォーマンステストの詳細については、パフォーマンスホワイトペーパー(Nexmark パフォーマンステスト)をご参照ください。
Realtime Compute for Apache Flink のチェックポイントまたはセーブポイントに関するよくある質問への回答については、デプロイメントのチェックポイントまたはセーブポイントに関する FAQをご参照ください。