統合CDCパイプラインのスマートなクローズ
統合されたCDCパイプラインは、トリガーモードで実行されます。各更新は、ソースデータベースから変更を抽出し、それらを宛先テーブルに適用してから停止します。 スマートクロージャー は、更新が停止するのに十分な作業を完了したと判断するポリシーです。すべての更新を固定された時間実行する代わりに、スマートクロージャーは各更新の期間をソースの変更データの量に適応させます。
スマートクローズは、変更抽出機能と適用機能を個別のコンポーネントとしてではなく、単一のトリガーされたパイプラインで一緒に実行する統合CDCパイプライン（ダイレクトCDCとも呼ばれます）に適用されます。これは、取り込みゲートウェイが継続的に実行される標準のゲートウェイベースのアーキテクチャには適用されません。SQL Server向けの統合CDCパイプラインを作成するを参照してください。
更新が停止したとき
以下のいずれかの条件が満たされた場合、更新は停止します。
条件 | 完了理由 | 意味 |
|---|---|---|
ソースは最新の状態です。 |
| 更新によって保留中の変更バックログが適用され、ソースにほぼ最新の状態に保たれています。これは、処理するものがほとんどない増分更新の一般的なケースです。 |
ランタイムの制限に達しました。 |
| ソースに大量のバックログがあったため（たとえば、パイプラインが長期間実行されなかったなど）、更新は上限のあるランタイムの後に停止しました。次回の更新は、停止した時点から再開します。 |
スマートクロージャーの活用法
- 変更が少ない場合のコスト削減と更新の高速化： 更新は、固定された期間実行されるのではなく、現状に追いつくとすぐに終了するため、増分更新ではコンピュート時間が少なくて済みます。
- 境界のある、予測可能なランタイム： 大量のバックログがある場合でも、1回の更新がいつまでも実行され続けることはありません。各更新には上限があり、大規模なワークロードは後続のスケジュールされた更新に分散されます。
- 完了状況の可視性：各更新は、それが終了した理由を記録するため、ソースに追いついたのか、それともランタイム制限で停止したのかを判別できます。
更新完了を監視
完了理由は、パイプライン イベント ログの COMPLETED イベントのメッセージに表示されます。ソースに追いついた更新は理由lag-convergedで完了し、ランタイムの制限で停止した更新は理由max-runtime-cap-hitで完了します。
完了理由を確認するには、エクストラクタの COMPLETED イベントについてパイプラインイベントログをクエリします。<pipeline-id> をパイプライン ID に置き換えます：
SELECT timestamp, message
FROM event_log('<pipeline-id>')
WHERE message LIKE '%Direct Cdc Extraction has COMPLETED%'
ORDER BY timestamp DESC
イベントメッセージには理由が埋め込まれています。たとえば Direct Cdc Extraction has COMPLETED (reason=lag-converged)。
定期的な更新をスケジュール
更新の所要時間はソースの変更データの量によって異なるため、大量のバックログは1回の更新では完了しない可能性があります。定期的なスケジュールでデータを取り込むには、パイプラインを実行するLakeflow Jobsタスクを作成します。後続の更新が遅れずに処理されるよう、十分な頻度でスケジュールしてください。ほとんどのワークロードには、60分という開始点が適切です。以前の更新がまだ実行中にトリガーが起動した場合、パイプラインは新しい更新をキューに入れます。