状態管理、チェックポイント、ストリーミングパターンのクイズ
この章で扱うFlink/KafkaおよびFlink/Icebergのバージョンの組み合わせを区別できるか確認します。
- RocksDBを選択すると、ヒープ、GC、メモリサイズの検討は不要になりますか？
回答を表示
回答: いいえ。ネイティブキャッシュ、管理メモリ、ユーザーオブジェクト、オペレーター状態、バッファーも引き続きリソースを消費します。
解説: キー付きオペレーターのバックエンドは、スロットのメモリ予算を共有することがあります。固定のMBしきい値を使うのではなく、ワークロードと状態を計測し、チェックポイントと復元を検証してください。
- Flink 2.2では、増分スナップショットを使えるのはRocksDBだけですか？
回答を表示
回答: いいえ。実験的なForStも、非同期の増分スナップショットを使用します。
解説: リモートSSTとローカルキャッシュのモデル、およびAPIとスナップショットに関する制限を確認してください。この章の設定例ではRocksDBを使用します。
- 増分チェックポイントのアップロードサイズは、論理キーの変更だけで決まりますか？
回答を表示
回答: いいえ。新しいSSTとメタデータが永続化され、コンパクションによって大きなファイルが書き換えられることもあります。
解説: 再利用可能な共有SSTは参照されます。まだ参照中のファイルを期限切れにすると、復旧できなくなる場合があります。
- 増分復元では、以前のチェックポイントをすべて順番に再生しますか？
回答を表示
回答: いいえ。選択したチェックポイントが参照するファイルを復元します。
解説: フルチェックポイントが必ず単一ファイルになるわけではありません。復旧にかかるコストは、ネットワーク、ファイル数、I/O、正規状態の再構築に左右されます。
- Savepointは、誰かが手動で削除するまで常に保持されますか？
回答を表示
回答: いいえ。オペレーターによる保持や破棄、CLAIM/NO_CLAIMの所有権によってライフサイクルが変わります。
解説: チェックポイントにも明示的なトリガーと外部化後の保持設定があります。ストレージ、参照関係、削除の責任者を確認してください。
- Operatorのlast-state復旧では、常に最後のチェックポイントファイルを1つ使いますか？
回答を表示
回答: 復旧に使用するデータは、アクセス可能なHAメタデータ、または該当する復旧経路に応じた最後のチェックポイントやsavepointによって決まります。
解説: 有効なメタデータ、状態の互換性、UID、シリアライザーが必要です。last-stateという名前だけでは、復旧や安全な移行は保証されません。
- KafkaのEXACTLY_ONCE保証では、チェックポイントとコンシューマーに何が必要ですか？
回答を表示
回答: トランザクションのコミットはチェックポイント完了と連携し、下流のコンシューマーはread_committedを使用する必要があります。
解説: 再生可能なソースと復旧可能な状態も必要です。シンクや全サブタスクが1つのグローバルトランザクションになるわけではありません。
transactionalIdPrefixは、いつ一意にし、いつ安定させる必要がありますか？
回答を表示
回答: 独立して同時実行するシンクやジョブの間では一意にし、同じ論理実行を再起動するときは安定させます。
解説: 衝突するとフェンシングが発生することがあります。一方、値を変えると、残存トランザクションのクリーンアップやコンシューマーの進行が遅れることがあります。
- チェックポイント間隔が60秒なら、Kafkaに追加されるレイテンシーも最大60秒ですか？
回答を表示
回答: いいえ。チェックポイントの所要時間、コミット、障害と復旧、コンシューマーの遅延も影響します。
解説: トランザクションタイムアウトをブローカーの上限と最悪時の復旧時間に合わせてください。5.0.0のビルダーではデフォルトが1時間です。
- Kafkaコネクターのトランザクション命名戦略は、どれも毎回新しいIDを作成しますか？
回答を表示
回答: いいえ。任意指定のPOOLINGは名前を再利用します。デフォルトのINCREMENTINGとは異なります。
解説: POOLINGにはKafka 3以降が必要で、トピックの読み取り権限の追加や移行時の確認も必要です。高頻度コミットの負荷は別途計測してください。
- どのDynamicIcebergSink APIとランタイムの組み合わせを検証しましたか？
回答を表示
回答: forInput → generator → catalogLoader → appendの順で使用し、Iceberg 1.11.0とFlink 2.1.3を組み合わせました。
解説: generatorはDynamicRecordをCollectorに出力します。Flink 2.1のランタイムJARを、Flink 2.2.1でも検証済みであるかのように扱ってはいけません。
- insert-onlyのDynamic Icebergヘルパーを、変更せずにDebezium CDCプロセッサーとして使えますか？
回答を表示
回答: いいえ。RowKind、等価性フィールド、upsert、テーブル形式、スキーマ進化の制限を検証してください。
解説: マネージドFirehose/MSK Connectを代替案とする場合も、ソース、権限、キー、形式、バッファリング、障害処理を確認する必要があります。
event_time TIMESTAMP列を宣言すれば、SQLウィンドウクエリには十分ですか？
回答を表示
回答: ストリーミングのイベントタイムウィンドウには時刻属性が必要です。この例ではWATERMARKを宣言しています。
解説: 検証済みのプランナーでは、WATERMARKのない通常のTIMESTAMP列を使うとエラーになります。コネクターや形式のJARも必要です。
- S3プラグインと同梱デモには、バージョン固有のどのような制限がありますか？
回答を表示
回答: プラグインにはサポート終了済みのAWS SDK v1.12.779が含まれています。また、StateMachineExampleはコード内でチェックポイント間隔を2秒に設定しています。
解説: v2プロバイダークラスを安易に混在させないでください。設定だけから間隔を推定せず、min-pauseとアプリケーションによる上書きを確認してください。
- ウォーターマークより遅れて届いたレコードは、常に破棄されるか、自動的にサイド出力へ送られますか？
回答を表示
回答: いいえ。ウォーターマークは進行状況の推定値です。許容遅延の期間中にウィンドウが再度発火することがあります。
解説: クリーンアップ後のサイド出力には明示的な設定が必要です。タイムスタンプ抽出、アイドル状態、SQLとDataStreamの違いを確認してください。