Topik wawancara representatif

Wawancara data engineering: Merancang SLO kesegaran data

DataSulit
Tim Redaksi Offer.ccDipublikasikan Diperbarui

Pertanyaan

Rancang SLO kesegaran data untuk dataset bisnis harian. Jelaskan jam kesegaran, sinyal silsilah dan kualitas, cara memisahkan keterlambatan hulu dari keterlambatan pemrosesan, serta cara memberi peringatan dan memulihkan diri dari pelanggaran.

Perintah dan kasus penggunaan

Sebuah dataset yang memiliki nilai tidak berarti dataset tersebut segar. Jawabannya harus mengubah tenggat ketersediaan bisnis menjadi indikator yang terukur dan menemukan lokasi keterlambatan dalam proses penyerapan, transportasi, pemrosesan, atau publikasi.

Hal yang dievaluasi pewawancara

  • Apakah waktu peristiwa, kedatangan, penyelesaian pemrosesan, dan penyajian data dibedakan.
  • Apakah dataset, partisi, dan penggunaan bisnis mendapatkan SLO yang sesuai.
  • Apakah bukti silsilah, eksekusi, kualitas, dan kesegaran dipertahankan.
  • Apakah pekerjaan yang berhasil dipisahkan dari data yang dapat digunakan.
  • Apakah jalur penekanan peringatan, eskalasi, backfill, dan pemutaran ulang tersedia.
  • Apakah pelanggaran kesegaran dihubungkan dengan dampak pada pengguna hilir.

Klarifikasi sebelum menjawab

  • Berapa tenggat waktu bisnis, frekuensi pembaruan, dan zona waktunya?
  • Apakah kesegaran dimulai sejak pembuatan peristiwa, pendaratan data, atau ketersediaan kueri?
  • Partisi, bidang, dan laporan mana saja yang berada pada jalur kritis?
  • Berapa batas keterlambatan, celah, dan jendela backfill yang dapat diterima?
  • Bisakah hulu menyediakan waktu peristiwa, ID batch, dan metadata percobaan ulang?
  • Saat terjadi pelanggaran, apakah laporan harus dibekukan, menampilkan label status data, atau terus berjalan?

Kerangka jawaban 30 detik

“Saya akan mendefinisikan kesegaran yang dapat dikueri terhadap tenggat waktu bisnis dan mencatat waktu peristiwa, pendaratan, dan penyajian secara terpisah. Untuk setiap dataset kritis, saya akan menghitung SLI kesegaran tingkat partisi dan menggabungkan silsilah, status eksekusi, jumlah baris, serta asersi kualitas untuk menemukan keterlambatan. Peringatan akan memisahkan peringatan dini dari pelanggaran sehingga pekerjaan yang berhasil tidak menyembunyikan celah data. Pemulihan akan menggunakan percobaan ulang, backfill, pemutaran ulang, dan pelabelan hilir, dengan dampak pengguna serta anggaran SLO sebagai panduan perbaikan.”

Pembahasan mendalam langkah demi langkah

Langkah 1: Tentukan semantik waktu. Nyatakan waktu peristiwa versus waktu yang dapat dikueri dan tangani peristiwa yang terlambat, zona waktu, serta daylight saving daripada hanya mengandalkan waktu akhir pekerjaan.

Langkah 2: Tentukan SLI dan SLO. Misalnya, ukur fraksi partisi yang dapat dikueri sebelum tenggat waktu, dengan target berbeda untuk laporan kritis dan data eksploratif.

Langkah 3: Kumpulkan bukti eksekusi. Simpan metadata eksekusi, partisi input dan output, silsilah, jumlah baris, pemeriksaan nilai null, dan asersi kualitas yang ditautkan ke versi dataset.

Langkah 4: Lokalisasi keterlambatan. Uraikan keterlambatan menyeluruh menjadi penyerapan, transportasi, antrean, komputasi, dan publikasi; bedakan ketiadaan data dari hulu dengan kegagalan di hilir.

Langkah 5: Rancang peringatan. Peringatan menggunakan sisa waktu dan tren, sedangkan pelanggaran menggunakan dampak aktual. Lakukan deduplikasi berdasarkan dataset dan partisi serta tetapkan pembungkaman, eskalasi, dan kepemilikan.

Langkah 6: Pulihkan dan putar ulang. Gunakan batch yang idempoten, checkpoint, dan backfill terbatas, lalu jalankan ulang partisi yang terdampak dan publikasikan status data serta waktu pembaruan.

Langkah 7: Tingkatkan sistem. Lacak konsumsi anggaran, proporsi akar penyebab, dan peringatan palsu, lalu ubah penjadwalan, kapasitas, partisi, atau komitmen produk.

Contoh jawaban berkualitas tinggi

“Laporan pendapatan memiliki tenggat waktu bisnis lokal pukul 08.00. Saya mendefinisikan segar sebagai partisi harian yang dapat dikueri pada pukul 08.15 dan mengukur keterlambatan dari peristiwa hingga pendaratan secara terpisah. Pemantauan membaca partisi input dan output, silsilah, jumlah baris, dan asersi kualitas dari metadata eksekusi; eksekusi yang berhasil dengan partisi yang hilang tetap merupakan risiko kesegaran. Sebelum pukul 08.00 kami memperingatkan berdasarkan sisa waktu, dan setelah pukul 08.15 kami melakukan eskalasi berdasarkan dampak laporan. Pemulihan melakukan backfill secara idempoten berdasarkan ID batch dan melabeli status laporan. Tinjauan rutin menguraikan penggunaan anggaran berdasarkan penyebab penyerapan, transportasi, dan komputasi.”

Kesalahan umum

  • Hanya memantau keberhasilan pekerjaan → celah partisi tetap tersembunyi → periksa partisi yang dapat dikueri dan tenggat waktu bisnis.
  • Hanya menggunakan waktu akhir pemrosesan → peristiwa yang terlambat disalahartikan → pertahankan waktu peristiwa, pendaratan, dan penyajian.
  • Memberikan satu ambang batas untuk setiap dataset → prioritas hilang → buat tingkatan berdasarkan penggunaan dan jalur kritis.
  • Memberi peringatan tanpa pemilik atau eskalasi → tidak ada yang bertindak → ikat jendela waktu, pemilik, dan tindakan pemulihan.
  • Menimpa data selama backfill → duplikat atau versi menjadi tidak jelas → catat batch yang idempoten, rentang, dan versinya.

Pertanyaan lanjutan dan tanggapan

Pertanyaan lanjutan 1: Bagaimana jika hulu tidak memiliki waktu peristiwa?

Gunakan waktu pendaratan sebagai metrik sementara yang dibatasi dengan jelas dan minta hulu untuk menambahkan waktu peristiwa serta metadata batch.

Pertanyaan lanjutan 2: Bagaimana jika data yang terlambat saat ini tidak berdampak pada pengguna?

Lacak SLI teknis dan dampak pengguna secara bersamaan, dan tentukan konsumsi anggaran terhadap komitmen bisnis.

Pertanyaan lanjutan 3: Bagaimana cara mencegah badai peringatan (alert storm)?

Agregasikan akar penyebab melalui silsilah, lalu terapkan jendela peringatan, deduplikasi, pembungkaman, dan eskalasi.

Pertanyaan lanjutan 4: Apa yang harus dilakukan sistem hilir selama backfill?

Publikasikan status data dan waktu pembaruan, bekukan atau beri label pada laporan kritis, dan cegah hasil yang belum lengkap dianggap sebagai hasil akhir.

Pertanyaan lanjutan 5: Bagaimana Anda memvalidasi bahwa SLO mencerminkan kebutuhan bisnis?

Wawancarai pengguna laporan, bandingkan pelanggaran dengan keterlambatan keputusan atau dampak pelanggan, dan kalibrasi ulang jendela waktu secara berkala.

Pertanyaan lanjutan 6: Bagaimana jika data yang terlambat mengubah partisi historis?

Tentukan jendela backfill dan semantik versi, catat rentang komputasi ulang, dan beri tahu cache serta model inkremental di hilir.

Pertanyaan lanjutan 7: Peningkatan apa yang paling penting?

Perbaiki akar masalah yang paling banyak menghabiskan anggaran pada jalur pengguna kritis sebelum menambahkan lebih banyak dasbor.

Sumber publik

Pertanyaan terkait