プロンプトとコンテキスト
チームにはすでに変更ストリームが存在し、論理削除、ストリームと静的テーブルの結合、またはステートフルな集計をサポートするダイナミックテーブルを維持したいと考えています。CUSTOM_INCREMENTALが適しているかどうかをどのように判断し、増分ロジックを定義し、結果を検証し、ロールバックを準備するかを説明してください。単にSnowflakeのリリースノートを繰り返すだけにしないでください。
面接官が評価するポイント
- 開発者がMERGEまたはINSERTのロジックを定義し、プラットフォームがスケジューリング、リトライ、トランザクション保証を提供するという理解。
- 増分リフレッシュ、フルリフレッシュ、およびストリーム/Taskオーケストレーションを区別する能力。
- キー、変更順序、重複イベント、論理削除、および初期バックフィルの処理。
- リフレッシュラグ、リトライ、コスト、オブザーバビリティ、およびロールバックに関する完全な論理的考察。
確認すべき明確化の質問
- ソースは追記のみ（append-only）ですか、CDCですか、それとも履歴を修正可能ですか？削除によってターゲットにトゥームストーンを残す必要がありますか？
- ターゲットテーブルの一意キーは何ですか？重複、遅延、および反復された更新はどのように順序付けられますか？
- ロジックは増分で表現できますか、それとも定期的にすべてを再計算する必要がありますか？許容されるラグはどれくらいですか？
- 初回作成時、リトライ時、スキーマ変更時、およびロールバック時に、誰が結果を照合しアラートを発行しますか？
30秒の回答フレームワーク
まず、変更が安定したキーとウォーターマークで表現できることを確認し、次にカスタム増分ロジックでターゲットを安全に維持できるかをテストします。適合する場合は、リフレッシュごとに変更範囲、冪等なMERGE/INSERT条件、論理削除の動作、および遅延イベントポリシーを指定します。増分出力とサンプリングしたフルリフレッシュの結果を照合します。プラットフォームのスケジューリング、リトライ、トランザクションは、ビジネス上の順序や削除セマンティクスを定義するものではありません。ローンチ前に、ラグ、障害、標準リフレッシュへのフォールバック、およびフルリビルドに関するメトリクスとコントロールを設定します。
ステップごとの詳細解説
1. 増分の境界を定義する
射影、フィルタリング、結合、集計、および削除のセマンティクスを分離します。増分ロジックにテスト可能な境界が存在するのは、影響を受ける入力行とターゲットキーを特定できる場合のみです。影響範囲を限定できないグローバルな順序付けや非決定論的ロジックについては、フルリフレッシュのオプションを残しておきます。
2. 変更適用コントラクトを設計する
各変更にビジネスキー、バージョン、またはイベント時刻を付与し、1つのキーにおける競合の勝者を定義します。MERGEの一致条件は冪等でなければなりません。古い遅延イベントが削除された行を再作成しないよう、論理削除には削除マーカーまたはトゥームストーンが必要です。
3. 初回実行と障害を処理する
スコープを広げる前に、制御されたデータセットから開始し、カスタム増分出力をフルリフレッシュのベースラインと比較します。リトライは行を重複させることなく安全に繰り返せる必要があります。スキーマ変更、説明のつかないドリフト、または破損したウォーターマークが発生した場合は、公開を一時停止し、検証可能なフルリフレッシュまたはリビルドにフォールバックします。
4. 正確性とコストを監視する
リフレッシュラグ、影響を受けた行数、障害、リトライ、およびソースウォーターマークを監視します。定期的に増分結果とフルリフレッシュ結果を照合します。単一のリフレッシュ時間だけを見るのではなく、ウェアハウスのコンピュート、ストレージ、リビルド、およびダウンストリームのクエリコストを個別に評価します。
模範回答
私はCUSTOM_INCREMENTALを、正確性を実証しなければならない増分メンテナンスのコントラクトとして扱います。まず、各変更に対して安定したビジネスキー、バージョン、またはウォーターマークを要求し、論理削除、遅延イベント、競合に関する明確なルールを設定します。影響を受けるターゲット行を限定できない場合は、フルリフレッシュを維持します。次に、冪等なMERGE/INSERTロジックを実装し、制御されたサンプルをフルのベースラインと照合し、繰り返し実行、リトライ、初期バックフィル、スキーマ変更をテストします。ダイナミックテーブルのプラットフォームはスケジューリング、リトライ、トランザクション保証を提供しますが、イベント順序や削除セマンティクスを決定することはありません。本番環境では、ウォーターマーク、ラグ、影響を受けた行数、ドリフト、コストを監視し、一時停止、リビルド、標準リフレッシュへのフォールバックパスを整備します。
よくある間違い
CUSTOM_INCREMENTALが任意のSQLを自動的に増分化できると思い込むこと。- 安定したキー、バージョン、または重複イベントルールなしにMERGEを記述すること。
- 論理削除、遅延データ、または初期のフルバックフィルを無視すること。
- プラットフォームのトランザクションをビジネス結果が正しいことの証明として扱うこと。
- 増分とフルの照合、ドリフトアラート、またはロールバックを省略すること。
- レイテンシのみを比較し、継続的なリフレッシュとリビルドのコストを無視すること。
フォローアップ質問と回答
フルリフレッシュを主張すべきなのはどのような場合ですか？
影響範囲を限定できない場合、ロジックにグローバルな順序付けや非決定論的関数が含まれている場合、または照合によって増分結果を証明できない場合は、フルリフレッシュを選択します。増分化する価値があるかどうかを判断する前に、データ範囲と頻度を絞り込んでください。
同じキーに対する遅延イベントをどのように処理しますか？
単調増加するバージョンまたは比較可能なイベント時刻を保持し、MERGE条件で新しいバージョンのみを受け入れます。順序付けを信頼できない場合は、暗黙的に上書きするのではなく競合を隔離してアラートを出します。
増分結果がドリフトしていないことをどのように証明しますか？
パーティションまたはキー範囲ごとに定期的にフルのベースラインを再計算し、行数、チェックサム、ビジネスメトリクスを比較して、差異のサンプルを監査テーブルに保持します。差異がしきい値を超えた場合は、公開を一時停止するかリビルドを行います。