Perintah dan konteks
Tim sudah memiliki change stream dan ingin memelihara dynamic table yang mendukung soft delete, stream-static join, atau agregasi stateful. Jelaskan bagaimana Anda memutuskan apakah CUSTOM_INCREMENTAL sesuai, menentukan logika inkremental, memvalidasi hasil, dan menyiapkan rollback. Jangan hanya mengulangi catatan rilis Snowflake.
Apa yang dievaluasi oleh pewawancara
- Pemahaman bahwa pengembang menentukan logika MERGE atau INSERT sementara platform menyediakan penjadwalan, percobaan ulang (retry), dan jaminan transaksional.
- Kemampuan untuk membedakan refresh inkremental, refresh penuh (full refresh), dan orkestrasi stream/Task.
- Penanganan key, pengurutan perubahan, event duplikat, soft delete, dan backfill awal.
- Penalaran lengkap tentang lag refresh, retry, biaya, observabilitas, dan rollback.
Pertanyaan klarifikasi yang perlu diajukan
- Apakah sumber bersifat append-only, CDC, atau mampu mengoreksi riwayat? Haruskah penghapusan meninggalkan tombstone di target?
- Apa unique key tabel target? Bagaimana pembaruan yang duplikat, terlambat, dan berulang diurutkan?
- Bisakah logika diekspresikan secara inkremental, atau harus menghitung ulang semuanya secara berkala? Berapa lag yang dapat diterima?
- Siapa yang merekonsiliasi hasil dan peringatan selama pembuatan pertama, retry, perubahan skema, dan rollback?
Kerangka jawaban 30 detik
Pertama-tama saya akan memverifikasi bahwa perubahan dapat diwakili oleh key yang stabil dan watermark, kemudian menguji apakah logika inkremental kustom dapat memelihara target dengan aman. Jika sesuai, saya akan menentukan rentang perubahan, kondisi MERGE/INSERT yang idempoten, perilaku soft-delete, dan kebijakan late-event untuk setiap refresh. Saya akan merekonsiliasi output inkremental dengan hasil sampel full-refresh. Penjadwalan platform, retry, dan transaksi tidak menentukan urutan bisnis atau semantik penghapusan. Sebelum peluncuran, saya akan menetapkan metrik dan kontrol untuk lag, kegagalan, fallback ke refresh standar, dan rebuild penuh.
Pembahasan mendalam langkah demi langkah
1. Tentukan batas inkremental
Pisahkan proyeksi, pemfilteran, join, agregasi, dan semantik penghapusan. Logika inkremental memiliki batas yang dapat diuji hanya ketika baris input yang terpengaruh dan key target dapat diidentifikasi. Pertahankan opsi refresh penuh untuk pengurutan global atau logika non-deterministik yang dampaknya tidak dapat dibatasi.
2. Rancang kontrak penerapan perubahan
Berikan business key, versi, atau waktu event pada setiap perubahan, dan tentukan pemenang untuk konflik pada satu key. Pencocokan MERGE harus idempoten. Soft delete memerlukan penanda hapus atau tombstone sehingga event lama yang terlambat tidak dapat membuat ulang baris yang telah dihapus.
3. Tangani eksekusi pertama dan kegagalan
Mulailah dengan dataset yang terkontrol dan bandingkan output inkremental kustom dengan baseline refresh penuh sebelum memperluas cakupan. Retry harus aman untuk diulang tanpa menghasilkan baris duplikat. Jeda publikasi dan beralihlah ke refresh penuh atau rebuild yang dapat diverifikasi saat terjadi perubahan skema, pergeseran (drift) yang tidak dapat dijelaskan, atau watermark yang rusak.
4. Pantau kebenaran dan biaya
Pantau lag refresh, jumlah baris yang terpengaruh, kegagalan, retry, dan watermark sumber; rekonsiliasi hasil inkremental dan penuh secara berkala. Perkirakan biaya komputasi warehouse, penyimpanan, rebuild, dan kueri downstream secara terpisah, alih-alih hanya melihat durasi satu kali refresh.
Jawaban model
Saya akan memperlakukan CUSTOM_INCREMENTAL sebagai kontrak pemeliharaan inkremental yang kebenarannya harus dibuktikan. Pertama, saya akan mewajibkan business key yang stabil, versi, atau watermark untuk setiap perubahan, dengan aturan eksplisit untuk soft delete, late event, dan konflik; jika baris target yang terpengaruh tidak dapat dibatasi, saya akan mempertahankan refresh penuh. Kemudian saya akan menerapkan logika MERGE/INSERT yang idempoten, merekonsiliasi sampel terkontrol dengan baseline penuh, dan menguji pengulangan, retry, backfill awal, serta perubahan skema. Platform dynamic-table menyediakan penjadwalan, retry, dan jaminan transaksional, tetapi tidak menentukan urutan event atau semantik penghapusan. Di produksi, saya akan memantau watermark, lag, baris yang terpengaruh, drift, dan biaya, dengan jalur jeda, rebuild, dan fallback refresh standar.
Kesalahan umum
- Mengasumsikan
CUSTOM_INCREMENTALdapat secara otomatis menginkrementalkan SQL arbitrer. - Menulis MERGE tanpa key yang stabil, versi, atau aturan event duplikat.
- Mengabaikan soft delete, data yang terlambat, atau backfill penuh awal.
- Memperlakukan transaksi platform sebagai bukti bahwa hasil bisnis sudah benar.
- Menghilangkan rekonsiliasi inkremental versus penuh, peringatan drift, atau rollback.
- Hanya membandingkan latensi dan mengabaikan biaya refresh berkelanjutan serta rebuild.
Pertanyaan lanjutan dan tanggapan
Kapan Anda harus bersikeras menggunakan refresh penuh?
Pilihlah refresh penuh ketika cakupan dampak tidak dapat dibatasi, logika mengandung pengurutan global atau fungsi non-deterministik, atau rekonsiliasi tidak dapat membuktikan hasil inkremental. Persempit rentang data dan frekuensi sebelum memutuskan apakah inkrementalisasi bernilai untuk dilakukan.
Bagaimana Anda menangani late event untuk key yang sama?
Sertakan versi monotonik atau waktu event yang dapat dibandingkan dan hanya terima versi yang lebih baru dalam kondisi MERGE. Jika pengurutan tidak dapat dipercaya, isolasi konflik dan berikan peringatan alih-alih menimpanya secara diam-diam.
Bagaimana Anda membuktikan bahwa hasil inkremental tidak bergeser (drift)?
Hitung ulang baseline penuh secara berkala berdasarkan partisi atau rentang key, bandingkan jumlah baris, checksum, dan metrik bisnis, serta simpan sampel perbedaan dalam tabel audit. Jeda publikasi atau lakukan rebuild saat perbedaannya melebihi ambang batas.