Konteks dan Permasalahan
Sebuah sistem pembayaran melaporkan 1.000 pesanan kemarin, tetapi laporan data warehouse mencatat 998. Desain pipeline yang menemukan perbedaan di seluruh data source, landing layer, model transformasi, dan laporan.
Jangan membatasi jawaban hanya pada dbt, Airflow, atau data warehouse tertentu. Tujuannya adalah membangun rantai bukti yang dapat diulang untuk membedakan data yang hilang, duplikat, tidak cocok, terlambat (late data), dan data dengan definisi yang berbeda.
Hal yang sedang diuji oleh pewawancara
Grain rekonsiliasi
Tentukan business key, semantik waktu, dan presisi moneter sebelum memilih grain berdasarkan pesanan, merchant, hari, atau batch. Pemeriksaan yang hanya menghitung total baris dapat menyembunyikan kesalahan yang saling meniadakan (offsetting errors).
Pemeriksaan yang dapat dijelaskan
Periksa jumlah baris, nominal nilai, distribusi status, keunikan key, dan sampel data detail. Simpan versi aturan dan snapshot input agar setiap hasil dapat direproduksi kembali.
Insiden loop tertutup (closed-loop incidents)
Klasifikasikan perbedaan, tetapkan pemilik tugas (owner), simpan bukti, dukung replay data, dan catat penyelesaiannya. Email tanpa pelacakan tiket/kasus bukanlah operasional loop tertutup yang baik.
Operasional yang aman
Tangani late data, eksekusi ulang yang idempoten, partisi, perubahan skema, kesegaran data (freshness), dan riwayat audit tanpa membiarkan langkah perbaikan menciptakan ketidakcocokan baru.
Pertanyaan klarifikasi yang perlu diajukan
- Zona waktu dan definisi event-time apa yang digunakan untuk kata "kemarin"?
- Apa business key dari pesanan, dan bagaimana pengembalian dana (refund) serta pembatalan dihitung?
- Bisakah sistem sumber mengirimkan pembaruan atau penghapusan yang terlambat?
- Apakah data warehouse menggunakan arsitektur batch, streaming, atau hybrid?
- Mata uang dan presisi desimal apa yang berlaku?
- Apakah remediasi harus otomatis, di-replay, atau disetujui secara manual terlebih dahulu?
Kerangka jawaban 30 detik
"Saya akan membekukan satu jendela waktu dan snapshot, merekonsiliasi jumlah, nominal, dan status berdasarkan business key pesanan, lalu menelusuri data yang hilang, duplikat, belum tiba, serta kesalahan transformasi. Setiap perbedaan menyimpan versi aturan, ringkasan sumber, ringkasan warehouse, dan pemilik tugas. Watermark dan jendela percobaan ulang (retry window) memisahkan data yang terlambat dari kehilangan data yang sebenarnya. Backfill atau replay yang idempoten akan memperbaiki kasus yang disetujui, kemudian snapshot yang sama direkonsiliasi kembali. Input, output, alert, dan tindakan manual dicatat ke dalam tabel audit."
Pembahasan mendalam langkah demi langkah
Langkah 1: Bekukan cakupan dan snapshot
Catat batch sumber, rentang event-time, processing time, zona waktu, dan snapshot ID. Hasil harus selalu mengacu pada kumpulan input yang sama dan tidak berubah-ubah saat data sumber diperbarui.
Langkah 2: Normalisasi key
Normalisasi ID pesanan, ID merchant, pemetaan status, mata uang, dan presisi nominal. Simpan hash atau ringkasan dari masing-masing sisi; simpan hanya data sensitif minimum yang diperlukan untuk diagnosis.
Langkah 3: Jalankan pemeriksaan bertingkat
Bandingkan jumlah baris dan total nominal terlebih dahulu, kemudian kelompokkan berdasarkan merchant, tanggal, dan status. Lanjutkan dengan pemeriksaan keunikan key, nilai null, duplikat, toleransi selisih, dan anti-join detail. Total nominal yang sama tidak membuktikan detailnya identik.
Langkah 4: Pisahkan keterlambatan data dari revisi data
Gunakan event time dan watermark untuk membedakan data yang belum tiba dari data yang benar-benar hilang. Pertahankan status data sebagai pending di dalam jendela backfill; eskalasikan hanya setelah jendela tersebut ditutup. Hitung ulang pembaruan, refund, dan penghapusan menggunakan versi atau waktu perubahan.
Langkah 5: Klasifikasikan dan lakukan remediasi
Urutkan kasus berdasarkan nominal, jumlah pesanan, dampak bisnis, dan durasi. Perbaikan otomatis dibatasi pada backfill atau replay yang idempoten. Perubahan definisi finansial memerlukan persetujuan serta bukti sebelum dan sesudah perbaikan.
Langkah 6: Jalankan ulang dan lakukan audit
Jalankan secara idempoten berdasarkan snapshot ID, partisi, dan versi aturan. Simpan cakupan input, versi kueri, metrik, perbedaan detail, alert, pemilik tugas, percobaan ulang, dan waktu penyelesaian untuk ditinjau.
Contoh jawaban berkualitas tinggi
"Saya akan membuat snapshot_id untuk setiap batch sumber dan membekukan jendela event-time UTC. Lapisan normalisasi menyelaraskan ID pesanan, status, mata uang, dan presisi nominal. Kami membandingkan jumlah baris, nominal, dan distribusi status, lalu menggunakan anti-join primary key untuk menemukan data yang hanya ada di sumber, hanya ada di warehouse, duplikat, dan data yang nominalnya tidak cocok.
Watermark dan jendela backfill dua jam mengklasifikasikan event yang terlambat sebagai pending; hanya perbedaan yang belum terselesaikan setelah jendela berakhir yang akan dieskalasikan. Tabel perbedaan menyimpan versi aturan, ringkasan kedua sisi data, delta nominal, pemilik tugas, dan bukti pendukung. Replay yang telah disetujui bersifat idempoten berdasarkan snapshot_id ditambah business key. Setelah perbaikan, saya menjalankan ulang snapshot yang sama dan menuliskan rentang input, versi kode, alert, dan waktu penyelesaian ke tabel audit."
Kesalahan umum
- Hanya membandingkan total baris → kesalahan yang saling meniadakan tetap tersembunyi → gunakan anti-join business-key dan simpan perbedaan detailnya.
- Menggunakan processing time sebagai event time → data yang terlambat atau data lintas zona waktu menggeser jendela waktu → definisikan event time, processing time, dan zona waktu secara terpisah.
- Mengabaikan semantik refund, pembatalan, pembaruan, dan penghapusan → setiap layer menjelaskan angka yang berbeda → buat versi untuk pemetaan status dan aturan perlakuan data.
- Membandingkan nominal uang menggunakan floating-point → selisih desimal kecil memicu insiden palsu → gunakan integer minor unit, mata uang, dan nilai toleransi eksplisit.
- Mengirimkan alert langsung untuk setiap data yang terlambat → insiden yang terlalu berisik memicu perbaikan yang salah → gunakan watermark dan jendela backfill dengan status pending.
- Perbaikan yang tidak idempoten → eksekusi ulang menghasilkan baris duplikat → lakukan upsert secara idempoten berdasarkan snapshot dan business key.
- Tidak ada pemilik tugas, bukti, atau status penyelesaian → insiden tidak dapat ditugaskan atau ditinjau → tambahkan tiket kasus dan catatan audit.
- Hanya menyimpan angka akhir → hasil tidak dapat direproduksi → simpan snapshot input, versi aturan, dan versi kode.
Pertanyaan lanjutan dan jawabannya
Pertanyaan lanjutan 1: Bagaimana jika totalnya cocok tetapi baris datanya berbeda?
Gunakan anti-join business key, pemeriksaan key duplikat, dan distribusi agregat untuk menemukan penambahan dan penghapusan data yang saling meniadakan. Simpan perbedaan detail untuk ditinjau.
Pertanyaan lanjutan 2: Bagaimana cara menghindari false alert akibat late data?
Gunakan event time, watermark, dan jendela backfill yang eksplisit. Tandai kasus sebagai pending di dalam jendela tersebut dan eskalasikan kasus yang belum terselesaikan setelah jendela ditutup, sambil mencatat versi jendela waktunya.
Pertanyaan lanjutan 3: Bagaimana cara menjalankan ulang perbaikan dengan aman?
Gunakan snapshot ID, partisi, dan business key sebagai kunci idempotensi; lakukan upsert atau deduplikasi penulisan data; bandingkan jumlah baris dan nominal sebelum dan sesudah setiap percobaan ulang.
Pertanyaan lanjutan 4: Bagaimana Anda menguji aturan rekonsiliasi?
Buat data uji (fixtures) untuk kasus data hilang, duplikat, terlambat, refund, dan perbedaan mata uang. Uji versi aturan, toleransi selisih, tanggal batas, dan zona waktu, lalu pantau tingkat false-positive.
Pertanyaan lanjutan 5: Bagaimana cara merutekan alert dan kepemilikan insiden?
Rutekan berdasarkan nominal, jumlah transaksi, durasi, dan tingkat keparahan bisnis. Tautkan setiap alert ke batch, bukti pendukung, dan tindakan perbaikan; penutupan tiket memerlukan alasan yang jelas dan tetap dapat diaudit.
Sumber 1: dbt sources dan pengujian sumber
Dokumentasi dbt Developer Hub sources menjelaskan cara mendeklarasikan sumber data, membangun silsilah data (lineage), melampirkan pengujian data, dan mengukur freshness—pola tata kelola yang sangat berguna untuk input rekonsiliasi.
Sumber 2: Freshness dan SLA windows
Panduan source-freshness di dbt Developer Hub menunjukkan kolom loaded-at, ambang batas warning/error, dan hasil snapshot untuk pengelolaan freshness, yang dapat menjadi acuan untuk jendela late-data dan eskalasi.
Sumber 3: Pemeriksaan kualitas data
Panduan data-quality dari dbt Labs mencakup keunikan, relasi, pemeriksaan nilai null, dan freshness, yang mengilustrasikan bagaimana pengujian otomatis harus terhubung dengan model berversi dan sistem alert.