Konteks dan cakupan
Ini adalah pertanyaan umum dalam perancangan data-platform dan analytics-engineering. Tujuannya adalah membedah "data yang andal" menjadi dimensi yang dapat diukur dan menghubungkannya dengan penggunaan konsumen serta remediasi, alih-alih hanya membuat daftar beberapa pemeriksaan.
Hal yang dievaluasi oleh pewawancara
- Apakah Anda membedakan freshness, kelengkapan (completeness), validitas, akurasi, konsistensi, dan keunikan (uniqueness).
- Apakah target mencerminkan setiap produk data dan konsumen, alih-alih menggunakan satu ambang batas global.
- Apakah deteksi, peringatan berbasis tingkat keparahan (severity-based alerting), pemblokiran downstream, dan pemulihan dirancang secara terpadu.
- Apakah bukti kualitas, versi, dan lineage dipertahankan agar peringatan tetap dapat ditindaklanjuti.
Pertanyaan klarifikasi untuk diajukan terlebih dahulu
Konfirmasikan input batch versus streaming, event time versus arrival time, tabel atau field yang digunakan oleh pelanggan, keuangan, atau model, batas keterlambatan yang ditoleransi, partisi terlambat dan zona waktu, serta apakah konsumen harus diblokir, mengalami degradasi, atau menampilkan snapshot tepercaya terakhir selama insiden.
Struktur jawaban 30 detik
Saya akan menentukan kontrak data berdasarkan penggunaan konsumen, lalu mengonfigurasi pemeriksaan freshness, volume, kelengkapan, dan validitas untuk setiap dataset. Pipeline menyimpan hasil kualitas dan lineage, merutekan peringatan serta kegagalan pemblokiran ke pemilik data, dan memungkinkan job downstream membaca status kualitas. Untuk rilis yang diblokir, konsumen mendapatkan snapshot tepercaya bertanda waktu; pemulihan menggunakan backfill, komputasi ulang, dan rekonsiliasi untuk menutup insiden.
Jawaban mendalam
1. Menghubungkan dimensi kualitas dengan penggunaan
Freshness memeriksa kapan data terbaru yang dapat digunakan diproduksi; kelengkapan memeriksa apakah field atau partisi yang diperlukan telah tiba; volume memeriksa perkiraan baris atau byte; validitas memeriksa format dan rentang nilai; konsistensi memeriksa hubungan lintas tabel; keunikan memeriksa duplikasi. Ambang batas harus berbeda untuk penyelesaian keuangan (settlement), dashboard operasional, dan pelatihan model offline.
2. Menentukan SLA dan SLO yang dapat dieksekusi
Catat tenggat waktu bisnis, keterlambatan maksimum, rasio kehilangan yang ditoleransi, kondisi pemblokiran, pemilik, dan waktu eskalasi untuk setiap dataset. Lacak "data tiba tetapi gagal validasi" secara terpisah dari "upstream tidak memproduksi data baru". Berikan batas jendela backfill untuk data yang terlambat; setelah kedaluwarsa, tandai partisi sebagai tidak tersedia alih-alih menunggu tanpa batas waktu.
3. Menyimpan bukti berversi
Simpan versi aturan, batch atau partisi, nilai yang diamati, ambang batas, waktu eksekusi, lineage input dan output, serta hasil pengujian. Expectations atau sistem deklaratif lainnya dapat mendefinisikan pemeriksaan, sementara ledger kualitas yang dapat di-query membuat kegagalan dapat diaudit. Evaluasi ambang batas baru terhadap baseline historis agar perubahan konfigurasi tidak menyembunyikan regresi.
4. Merancang peringatan, pemblokiran, dan degradasi
Rutekan peringatan berdasarkan dampak dan tingkat keparahan kepada pemilik data, tim on-call platform, dan konsumen bisnis. Partisi hilang yang dapat dipulihkan dapat ditandai tertunda sementara snapshot tepercaya tetap tersedia; kegagalan yang dapat mencemari data keuangan atau model harus memblokir publikasi. Setiap pemblokiran memerlukan kondisi eskalasi, persetujuan, dan rilis agar konsumen tidak dapat langsung memotongnya (bypass).
5. Menutup siklus dengan backfill dan rekonsiliasi
Setelah memperbaiki upstream, lakukan backfill berdasarkan partisi atau waktu bisnis, jalankan kembali versi transformasi dan aturan yang sama, dan catat batch perbaikan untuk mencegah penulisan duplikat. Rekonsiliasi baris input, baris output, data yang ditolak, rekaman yang terlambat, dan konsumsi downstream. Tutup insiden hanya setelah metrik kembali ke baseline, lalu sesuaikan aturan, ambang batas, atau kepemilikan dalam tinjauan pasca-insiden.
Contoh jawaban yang kuat
Saya akan mendefinisikan kontrak berdasarkan konsumen. Tabel settlement harus tiba dalam waktu satu jam dari batas waktu hariannya dengan ambang kelengkapan yang wajib dipenuhi, sementara dashboard eksplorasi dapat mentoleransi lebih banyak keterlambatan. Setiap dataset mendapatkan pemeriksaan freshness, jumlah partisi, field wajib, rentang nilai, dan lintas tabel; setiap hasil menyimpan versi aturan, hasil observasi, batch, lineage, dan pemilik. Batas waktu freshness akan memicu peringatan terlebih dahulu, tetapi kegagalan kelengkapan pada data keuangan akan memblokir publikasi dan menyajikan snapshot tepercaya bertanda waktu. Setelah perbaikan upstream, saya melakukan backfill berdasarkan waktu bisnis, menggunakan kembali transformasi dan pemeriksaan yang sama, merekonsiliasi input, output, data yang ditolak, dan hitungan konsumen, serta menutup insiden hanya ketika metrik telah pulih.
Kesalahan umum
- Hanya memantau keberhasilan job tanpa memeriksa apakah data tersebut segar, lengkap, dan valid.
- Menerapkan satu ambang batas global untuk dataset dengan konsumen dan batas waktu yang berbeda.
- Menuliskan hasil kualitas hanya ke log, tanpa tautan ke batch, versi aturan, atau lineage.
- Memblokir setiap konsumen downstream untuk kegagalan yang hanya terbatas pada satu dataset atau partisi.
- Menimpa riwayat selama perbaikan tanpa batch backfill, rekonsiliasi, atau proteksi deduplikasi.
- Melaporkan satu skor tunggal yang tidak memberi tahu konsumen dimensi mana yang tidak tersedia.
Pertanyaan lanjutan
Bagaimana jika job upstream berhasil tetapi tidak ada data baru yang masuk?
Periksa waktu kedatangan dan waktu bisnis secara terpisah, lalu bandingkan partisi tepercaya terakhir dengan frekuensi pembaruan yang diharapkan. Job yang sukses hanya membuktikan eksekusi, bukan kepatuhan SLA; batas waktu yang terlampaui harus memicu insiden kualitas.
Bagaimana Anda menangani false positive dalam aturan kualitas?
Pertahankan observasi, ambang batas, dan versi aturan; amati baseline dalam mode bayangan (shadow mode) sebelum menerapkannya secara ketat. Gunakan ambang batas bertingkat dan rasio anomali, catat dampak pada konsumen, dan tinjau perubahan alih-alih menonaktifkan peringatan secara diam-diam.
Haruskah setiap kegagalan memblokir semua sistem downstream?
Batasi cakupan respons berdasarkan lineage dan penggunaan. Kegagalan yang dapat mencemari settlement atau model dapat memblokir publikasi terkait, sementara dataset eksplorasi yang independen dapat menggunakan versi sebelumnya dengan peringatan. Baik cakupan maupun kondisi rilis harus dapat diaudit.
Bagaimana Anda membuktikan bahwa pemulihan tidak menghilangkan baris data?
Rekonsiliasi batch, partisi, jumlah input dan output, data yang ditolak, rekaman terlambat, dan konsumsi downstream, lalu ambil sampel kumpulan primary-key. Batch perbaikan harus dapat diputar ulang (replayable) dan dilacak, serta eksekusi berulang harus menghasilkan hasil yang sama.