Realtime Compute for Apache Flinkは、状態データの互換性チェック機能と状態データの移行機能を提供します。このトピックでは、Realtime Compute for Apache Flinkが、選択した状態データとSQLデプロイメント間の互換性をどのようにチェックするかについて説明します。また、状態データの移行におけるRocksDBとGeminiの状態バックエンドの移行効率とデプロイメントパフォーマンスの違いについても説明します。
背景情報
Realtime Compute for Apache Flinkは、SQLデプロイメントの中間計算結果を状態データに保存します。状態データには、チェックポイントとセーブポイントが含まれます。Flink SQLは、さまざまなストリーム処理シナリオに適しています。開発の反復やビジネス開発の要件に合わせて、SQLデプロイメントを常に変更する必要がある場合があります。SQLデプロイメントを変更し、元の状態データを使用してデプロイメントを再起動した後、デプロイメントが状態データと互換性がない状態になる可能性があります。
エンジンバージョンがvvr-4.0.11-flink-1.13以降のRealtime Compute for Apache Flinkは、状態データの互換性チェック機能と状態データの移行機能を提供します。これらの機能は、元の状態データの再利用を最大化し、SQLデプロイメントを迅速に更新するのに役立ちます。デプロイメントのドラフトを変更して公開した後、状態データに基づいてデプロイメントを開始すると、システムは選択した状態データとデプロイメント間の互換性をチェックします。詳細については、「Flink状態データの互換性」をご参照ください。
状態データを新しいデプロイメントに適応させるには、状態データを移行する必要があります。Realtime Compute for Apache Flinkは、RocksDBとGeminiの2つの状態バックエンドをサポートしています。RocksDBとGeminiの状態バックエンドの移行効率とデプロイメントパフォーマンスの違いの詳細については、「Flink状態データの互換性」をご参照ください。
互換性
SQLデプロイメントの [ジョブの開始] パネルで [再開モード] を選択すると、Realtime Compute for Apache Flinkは、SQLステートメント、ランタイムパラメータ構成、およびデプロイメントのエンジンバージョンの変更を自動的に検出します。デプロイメントの変更が検出された場合は、[状態の互換性] の横にある [クリックして検出] をクリックして、デプロイメントと状態データの互換性をチェックすることをお勧めします。次に、互換性チェックの結果に基づいて、後続のアクションを決定します。
SQLデプロイメントを変更する場合は、デプロイメントに対して再開モードを選択する前に、デプロイメントと状態データの互換性をチェックする必要があります。すべての条件が満たされ、デプロイメントが状態データと互換性がある場合、デプロイメントは再開されます。
次のチェック結果と提案が提供されます。
完全に互換性があります
現在のデプロイメントは、最新の状態データと完全に互換性があります。この場合、最新の状態データに基づいて実行されるデプロイメントの計算結果は、履歴データに基づいて実行されるデプロイメントの計算結果と同じになります。デプロイメントを開始することをお勧めします。
部分的に互換性があります
現在のデプロイメントは、最新の状態データと部分的に互換性があります。この場合、状態データに基づいて実行されるデプロイメントの特定の列のみの計算結果は、履歴データに基づいて実行されるデプロイメントの計算結果と同じになります。残りの列には状態データにデータがないため、計算結果に部分的な不整合が生じます。デプロイメントが状態データと完全に互換性があることを確認するには、他の状態に基づいて、または状態なしでデプロイメントを開始することをお勧めします。
互換性がありません
警告状態データに基づいてデプロイメントを開始すると、デプロイメントが開始に失敗する可能性が高いか、デプロイメントの実行結果が期待どおりにならない可能性があります。注意して進んでください。他の状態に基づいて、または状態なしでデプロイメントを開始することをお勧めします。
再起動後に互換性が決定されます（互換性は不明）
警告状態データに基づいてデプロイメントを開始すると、デプロイメントが開始に失敗するか、デプロイメントの実行結果が期待どおりにならない可能性があります。注意して進んでください。
状態データの移行
RocksDBとGeminiの移行効率とデプロイメントパフォーマンスには、次の違いがあります。
RocksDB
RocksDB状態バックエンドは、デプロイメントの開始時にすべての状態データを移行します。デプロイメントが開始されると、デプロイメントはRUNNING状態になります。ただし、データの移行が必要なオペレーターはINITIALIZING状態であり、データは消費または処理されません。オペレーターのすべてのデータが移行されると、オペレーターはRUNNING状態になり、データの消費を開始します。
説明この例では、デプロイメントの集計関数が変更されています。したがって、RocksDB状態バックエンドは、デプロイメントの開始時にすべての状態データを移行します。前の図では、GroupAggregateオペレーターはINITIALIZING状態です。この場合、オペレーターはデータを処理できません。
Gemini
RocksDB状態バックエンドは、デプロイメントの開始時にすべての状態データを移行します。RocksDBと比較して、Gemini状態バックエンドは、デプロイメントの実行中にビジネス要件に基づいてデータを移行します。したがって、Gemini状態バックエンドは、特定のデータレコードがアクセスされた場合にのみ、状態データ内のそのデータレコードを移行します。デプロイメントが開始されると、デプロイメントはRUNNING状態になります。状態データの移行が必要なオペレーターは、INITIALIZING状態からRUNNING状態にすぐに変わり、データの消費を開始します。状態データの移行中、1秒あたりのトランザクション数（TPS）の値は徐々に通常のレベルに戻ります。これは、すべての状態データが移行されたことを示します。Gemini状態バックエンドは、RocksDB状態バックエンドよりも状態データの移行に要する時間が短くなります。
説明Gemini状態バックエンドとRocksDB状態バックエンドを個別に使用して同じSQLデプロイメントの状態データを移行する場合、Gemini状態バックエンドの方が移行効率が高くなります。Gemini状態バックエンドは、データの移行が必要なオペレーターの状態をINITIALIZINGからRUNNINGに迅速に変更し、オペレーターがデータを処理できるようにします。INITIALIZING状態は、オペレーターがデータを読み込んでいることを示します。