Topik wawancara representatif

Wawancara Data: Bagaimana Anda merancang upsert inkremental yang andal dengan DuckDB 1.4 MERGE?

DataSulit
Tim Redaksi Offer.ccDipublikasikan Diperbarui

Pertanyaan

Saat menggabungkan file perubahan harian ke dalam tabel analitis DuckDB, bagaimana cara Anda menghindari pembaruan ganda, penimpaan yang salah, dan kegagalan parsial?

Petunjuk dan konteks

Sebuah tim membaca file perubahan Parquet dengan DuckDB dan mengelola dimensi pelanggan serta riwayat harga secara lokal. Jelaskan kapan harus menggunakan MERGE INTO, dan bagaimana menangani kunci duplikat, penghapusan, SCD Tipe 2, eksekusi ulang, dan pemulihan.

Apa yang diuji oleh pewawancara

Mereka menguji pemahaman Anda tentang predikat pencocokan, urutan tindakan, keunikan sumber, dan batasan transaksi, serta kemampuan Anda untuk mengubah kemudahan SQL menjadi alur kerja yang dapat dijalankan ulang dengan kualitas, audit, dan rollback.

Pertanyaan untuk klarifikasi

Tanyakan tentang kunci bisnis, pengurutan waktu peristiwa (event-time), dan apakah riwayat data diperlukan. Klarifikasi data duplikat, data terlambat, dan data penghapusan, serta apakah target dapat dibangun ulang setelah kegagalan. Jangan memperlakukan MERGE sebagai CDC exactly-once otomatis.

Jawaban 30 detik

“Saya akan melakukan deduplikasi di staging berdasarkan kunci bisnis dan waktu peristiwa, memverifikasi paling banyak satu perubahan yang berlaku per kunci target, dan menjalankan MERGE di dalam transaksi. Tabel status saat ini menggunakan pembaruan untuk data yang cocok dan penyisipan untuk yang tidak cocok; tabel SCD Tipe 2 menutup versi lama dan menyisipkan versi baru. Penghapusan dan eksekusi ulang memerlukan semantik yang eksplisit. Setiap batch mencatat snapshot input dan pemeriksaannya, dan kegagalan akan memicu rollback lalu mencoba ulang snapshot yang sama.”

Pembahasan mendalam langkah demi langkah

Menentukan semantik target

Pisahkan snapshot saat ini dari riwayat. Tabel saat ini memerlukan status terbaru; SCD Tipe 2 memerlukan valid_from, valid_to, is_current, dan batasan versi.

Bangun staging yang dapat diaudit terlebih dahulu

Simpan file sumber, ID batch, waktu pembacaan, dan hash baris. Lakukan deduplikasi berdasarkan kunci bisnis, waktu peristiwa, dan prioritas sumber; karantina data seri yang tidak dapat diselesaikan.

Rancang pencocokan dan tindakan

Gunakan kunci bisnis yang stabil dalam predikat pencocokan, bukan atribut yang dapat berubah. Tentukan pembaruan untuk yang cocok, penyisipan untuk yang tidak cocok, dan kebijakan penghapusan jika tidak cocok dengan sumber agar data yang datang terlambat tidak terhapus secara tidak sengaja.

Menangani SCD Tipe 2

Tutup baris saat ini sebelum menyisipkan versi yang diubah; konten yang identik tidak boleh membuat versi baru. Pastikan setiap kunci hanya memiliki satu baris saat ini dengan batasan (constraint) atau kueri kualitas.

Menjamin eksekusi ulang dan transaksi

ID batch dan snapshot input yang dibekukan membuat eksekusi dapat diulang. Tempatkan MERGE, audit, dan status batch dalam satu transaksi; coba ulang data staging yang sama daripada membaca ulang file yang terus berubah.

Pantau dan lakukan rollback

Bandingkan jumlah penyisipan, pembaruan, dan penghapusan antara sumber dan target; periksa kunci tanpa induk (orphan keys), duplikat baris saat ini, dan waktu yang terbalik. Simpan snapshot sebelumnya atau jalur pembangunan ulang dan lakukan rollback berdasarkan batch jika terjadi anomali.

Jawaban model

Saya akan memasukkan file Parquet ke staging dengan metadata batch, melakukan deduplikasi berdasarkan kunci bisnis dan waktu peristiwa, serta menerapkan gerbang kualitas pada jumlah baris, nilai null, dan rasio penghapusan. Tabel saat ini menggunakan pembaruan/penyisipan berbasis kunci stabil; tabel riwayat menutup versi yang diubah dan menyisipkan yang baru sehingga setiap kunci memiliki satu baris saat ini. MERGE, audit, dan status batch berbagi satu transaksi, dan kegagalan akan mencoba ulang snapshot yang sama. Saya memantau delta per-batch dan versi duplikat, serta melakukan rollback atau membangun ulang per batch jika diperlukan.

Kesalahan umum

Menggabungkan file mentah secara langsung

Baris sumber yang duplikat dapat membuat hasil ambigu atau melakukan pembaruan dua kali; lakukan staging, deduplikasi, dan gerbang kualitas terlebih dahulu.

Mencocokkan pada kolom yang dapat berubah

Nama pelanggan yang diubah dapat terlihat seperti kunci baru. Cocokkan pada pengidentifikasi bisnis yang stabil.

Hanya melakukan insert untuk SCD Tipe 2

Versi lama tetap berstatus saat ini dan kueri akan mengembalikan beberapa baris saat ini. Pertahankan validitas dan keunikan.

Membaca ulang file saat mencoba lagi

File mungkin telah berubah atau file baru mungkin muncul. Bekukan snapshot input dan ID batch.

Pertanyaan lanjutan

Bagaimana jika dua peristiwa berbeda untuk satu kunci tiba bersamaan?

Pilih salah satu dengan aturan waktu peristiwa, versi, atau prioritas sumber yang eksplisit; jika tidak, karantina data tersebut alih-alih menimpanya secara diam-diam.

Bagaimana Anda menangani penghapusan yang terlambat?

Bandingkan waktu peristiwa penghapusan dengan versi target, catat penanda hapus (tombstone), dan cegah penghapusan lama menimpa pembaruan yang lebih baru.

Bagaimana Anda membuktikan bahwa MERGE yang gagal tidak diterapkan sebagian?

Pertahankan MERGE, audit, dan status batch dalam satu transaksi; periksa jumlah target dan status setelah kegagalan, lalu coba ulang snapshot staging yang sama.

Kapan Anda akan menghindari MERGE?

Untuk penggantian yang hampir menyeluruh, pencocokan yang rumit, atau transaksi lintas sistem, buat tabel baru dan lakukan pertukaran secara atomik (atomic swap) untuk mengurangi ketidakpastian tindakan pada tingkat baris.

Sumber publik

Pertanyaan terkait