1. Pertanyaan dan Konteks
Pertanyaan ini menguji penilaian platform data, data engineering, dan analytics engineering. Fokusnya adalah kesehatan dan dampak dari data itu sendiri, bukan hanya apakah tugas orkestrasi telah selesai. Jawaban yang kuat mencakup dimensi, baseline, kepemilikan, tingkat keparahan peringatan, dan pemulihan.
2. Hal yang Dievaluasi oleh Pewawancara
- Apakah Anda menguraikan observabilitas menjadi freshness, volume, skema, kelengkapan, distribusi, keunikan, dan integritas relasional.
- Apakah aturan bervariasi berdasarkan penggunaan dataset, lineage, dan dampak bisnis, alih-alih berbagi satu ambang batas yang sama.
- Apakah observasi mempertahankan versi aturan dan bukti eksekusi, memisahkan kegagalan pemblokiran, peringatan, dan status yang tidak diketahui.
- Apakah peringatan mengarah pada karantina, backfill, rekonsiliasi, dan peninjauan, alih-alih pesan tanpa pemilik.
Panduan wawancara data engineering publik MentorCruise secara langsung menanyakan arti data observability dan mencantumkan freshness, volume, schema drift, nilai null, duplikat, distribusi, dan lineage. Great Expectations mendokumentasikan distribusi, freshness, integritas, data yang hilang, skema, keunikan, dan volume sebagai kasus penggunaan kualitas data, serta mendefinisikan Expectation sebagai asersi yang dapat diverifikasi tentang data.
3. Pertanyaan Klarifikasi Sebelum Anda Menjawab
- Apakah dataset digunakan untuk pelaporan, settlement, rekomendasi, atau pelatihan model? Apa dampak latensi dan kesalahannya?
- Apakah sumber data berupa batch, streaming, atau hybrid? Bagaimana waktu peristiwa (event time) dan waktu kedatangan (arrival time) didefinisikan?
- Kegagalan mana yang memblokir publikasi, dan mana yang hanya memberikan peringatan? Apakah snapshot tepercaya (trusted snapshot) tersedia untuk degradasi yang terkendali?
- Siapa pemilik aset, lineage, dan peringatan? Partisi mana yang memerlukan backfill dan konsumen mana yang memerlukan pemberitahuan?
4. Kerangka Jawaban 30 Detik
Saya akan menyusun tingkatan dataset berdasarkan dampak bisnis, lalu menetapkan pemeriksaan freshness, volume, skema, kelengkapan, distribusi, dan relasi untuk setiap aset penting. Setiap eksekusi mencatat versi aturan, batch, observasi, lineage, dan pemilik; hasilnya diarahkan sebagai pemblokiran, peringatan, atau informasi. Pembaca downstream mengonsumsi status kualitas, dengan karantina atau snapshot tepercaya bertanda waktu jika diperlukan. Setelah perbaikan, saya menjalankan ulang versi pemeriksaan yang sama, merekonsiliasi catatan input, output, yang ditolak, dan yang dikonsumsi, serta menyesuaikan ambang batas selama peninjauan.
5. Pembahasan Mendalam Langkah demi Langkah
Langkah 1: Tentukan Aset dan Tingkat Kekritisan
Berikan identitas yang stabil pada tabel, topik, file, dan input model, lengkap dengan pemilik, konsumen, sensitivitas, dan lineage. Tangani aset berdampak tinggi seperti settlement dan metrik yang berhadapan langsung dengan pelanggan terlebih dahulu; jika tidak, biaya pemeriksaan dan volume peringatan akan meningkat tanpa kendali.
Langkah 2: Pilih Sinyal yang Saling Melengkapi
Freshness memeriksa stempel waktu bisnis dan kedatangan; volume memeriksa baris, file, atau byte; skema memeriksa bidang, tipe, dan kompatibilitas; kelengkapan memeriksa nilai wajib, duplikat, dan referensi; distribusi memeriksa rentang, kuantil, atau frekuensi kategori. Simpan ukuran sampel, jendela waktu, ambang batas, dan versi aturan untuk setiap metrik sehingga satu skor tidak dapat menyembunyikan dimensi kegagalan.
Langkah 3: Buat Pemeriksaan yang Dapat Ditindaklanjuti dan Dijelaskan
Pertahankan asersi deklaratif dan kueri kustom dalam peninjauan kode dan penerapan. Berikan tingkat keparahan, tindakan kegagalan, dan pemilik pada aturan penting; gunakan baseline dan jendela waktu berurutan untuk aset bervolume rendah atau musiman. Tulis hasilnya ke buku besar kualitas (quality ledger) yang ditautkan ke partisi, eksekusi, perubahan upstream, dan dampak downstream.
Langkah 4: Hubungkan Peringatan, Karantina, dan Pemulihan
Blokir publikasi saat data buruk berpotensi mengontaminasi keuangan atau model. Karantina anomali lokal dan pertahankan snapshot tepercaya bertanda waktu jika pemblokiran yang lebih luas tidak diperlukan. Peringatan mencakup aset, dimensi, observasi, ambang batas, lineage, dan tindakan yang disarankan. Setelah perbaikan upstream, lakukan backfill berdasarkan waktu bisnis dan gunakan penulisan idempoten ditambah rekonsiliasi input/output untuk membuktikan tidak ada data yang hilang atau duplikat.
6. Contoh Jawaban Berkualitas Tinggi
Saya akan menyusun tingkatan aset berdasarkan dampak bisnis dan mendaftarkan pemilik, konsumen, serta lineage untuk aset yang kritis. Setiap pemuatan memeriksa waktu kedatangan dan bisnis, volume baris atau byte, skema, bidang wajib, duplikat, relasi, dan distribusi nilai kunci. Hasilnya mempertahankan versi aturan, batch, ukuran sampel, observasi, dan dampak downstream; tingkat keparahan menentukan apakah publikasi diblokir, diberi peringatan, atau hanya dicatat.
Jika tabel settlement gagal dalam pemeriksaan kelengkapan, saya mengarantina batch tersebut dan memblokir publikasi. Dasbor independen dapat menggunakan snapshot tepercaya sebelumnya beserta stempel waktunya. Peringatan tersebut menyebutkan dimensi yang gagal dan kemungkinan perubahan upstream, bukan hanya menampilkan satu skor yang tidak jelas. Setelah perbaikan, saya melakukan backfill pada partisi, menjalankan ulang pemeriksaan yang sama, merekonsiliasi catatan input, output, yang ditolak, dan yang dikonsumsi, serta menutup insiden hanya setelah metrik pulih. Terakhir, saya memanfaatkan alarm palsu, kegagalan deteksi, dan waktu penanganan untuk menyesuaikan ambang batas dan cakupan.
7. Pola Kegagalan yang Umum
- Hanya memeriksa apakah DAG berhasil, bukan apakah data tersebut segar, lengkap, dan dapat digunakan.
- Menerapkan satu ambang batas untuk setiap aset sambil mengabaikan konsumen, faktor musiman, dan ukuran sampel.
- Menghilangkan versi aturan, batch, atau lineage sehingga peringatan tidak dapat direproduksi.
- Memblokir seluruh platform untuk setiap kegagalan, atau mencoba ulang pengiriman data buruk secara otomatis ke sistem downstream.
- Menimpa riwayat setelah perbaikan tanpa mencatat backfill, rekonsiliasi, dan perlindungan penulisan duplikat.
8. Pertanyaan Lanjutan dan Tanggapan
Pertanyaan Lanjutan 1: Apa perbedaan antara kualitas data dan data observability?
Pemeriksaan kualitas memverifikasi suatu asersi. Observabilitas juga menghubungkan sinyal kesehatan dengan konteks eksekusi, lineage, kepemilikan, dampak, dan tindakan. Kualitas adalah salah satu sinyal dalam siklus operasional, bukan keseluruhan siklus itu sendiri.
Pertanyaan Lanjutan 2: Bagaimana cara mengurangi alarm palsu?
Gunakan baseline historis berdasarkan aset dan segmen, pertahankan ukuran sampel, terapkan syarat jendela waktu berurutan, dan gunakan tingkat keparahan. Amati aturan baru dalam mode bayangan (shadow mode) dan pertahankan versi lama saat meninjau biaya dari alarm palsu.
Pertanyaan Lanjutan 3: Haruskah setiap pemeriksaan yang gagal memblokir publikasi?
Tentukan berdasarkan dampak dan lineage. Kegagalan yang dapat mengontaminasi settlement, komitmen pelanggan, atau pelatihan model harus memblokir publikasi terkait; konsumen berisiko rendah dapat membaca snapshot tepercaya yang diberi peringatan. Cakupan, batas waktu eskalasi, dan ketentuan rilis harus dapat diaudit.