Petunjuk dan konteks
Pertanyaan ini menguji apakah Anda dapat mengubah “berapa lama kita harus menyimpannya?” menjadi sistem siklus hidup data yang dapat dieksekusi, dapat dijelaskan, dan dapat dipulihkan. Versi, snapshot, replika, cadangan, dan ekspor downstream tidak memiliki semantik penghapusan yang sama; kedaluwarsa snapshot Apache Iceberg juga mengharuskan pemeriksaan bahwa file-file tersebut tidak lagi direferensikan oleh snapshot yang dipertahankan. Cakup sumber kebijakan, prioritas, pelaksana (executor), penemuan dependensi, bukti penghapusan, dan pemulihan kegagalan. Periode retensi bergantung pada hukum dan kontrak tertentu, sehingga sistem harus mendukung tinjauan hukum daripada menggantikan pertimbangan hukum.
Apa yang sedang dievaluasi oleh pewawancara
- Apakah Anda membedakan antara retensi bisnis, penangguhan hukum (legal hold), permintaan penghapusan, jendela pencadangan, dan pembersihan teknis.
- Apakah Anda merancang kebijakan yang berversi, terlingkup, disetujui, dan sadar akan pengecualian daripada melakukan hard-coding pada satu TTL.
- Apakah Anda menangani referensi tersembunyi dalam snapshot, replika, cache, ekspor, tabel downstream, dan file yatim (orphan files).
- Apakah Anda menyediakan dry run, eksekusi yang dapat diobservasi, bukti penghapusan, percobaan ulang (retry), batasan rollback, dan jejak audit.
Pertanyaan klarifikasi untuk diajukan terlebih dahulu
Konfirmasikan kelas data, cakupan subjek atau tenant, tujuan bisnis, wilayah, kontrak, dan sumber hukum. Apakah suatu kebijakan berlaku untuk tabel, kolom, rekaman, objek, atau peristiwa? Siapa yang menyetujui dan melepaskan legal hold jika bertentangan dengan permintaan penghapusan? Salinan dan jalur pemulihan apa saja yang ada untuk snapshot lakehouse, topik, penyimpanan objek, cadangan, dan indeks pencarian? Apakah sistem harus membuktikan penghapusan fisik, atau membuktikan penghapusan dari permukaan kueri online sementara cadangan kedaluwarsa secara alami? Jika terjadi kegagalan, apakah eksekusi boleh dijeda, diulang, atau me-rollback metadata?
Kerangka jawaban 30 detik
Saya akan memodelkan kebijakan dengan sumber, versi, cakupan, prioritas, dan validitas, memisahkan retensi biasa, legal hold, permintaan penghapusan, dan pengecualian cadangan. Kompiler memetakan entitas katalog ke pelaksana snapshot, topik, objek, indeks, dan cadangan, serta terlebih dahulu menghasilkan dry-run yang menunjukkan dampak dan konflik. Eksekusi menggunakan grafik dependensi dan pemeriksaan referensi sehingga file yang dibutuhkan oleh snapshot atau pemulihan tidak terhapus, melakukan commit secara bertahap (batch), dan mencatat setiap langkah. Bukti yang dihasilkan mencakup cakupan, waktu, kegagalan, dan sisa jendela pencadangan. Setiap ketidakpastian akan menjeda rencana untuk ditinjau alih-alih melewatinya secara diam-diam.
Pembahasan mendalam langkah demi langkah
1. Memodelkan sumber kebijakan dan prioritas
Kebijakan harus mencakup cakupan subjek, label data, tujuan pemrosesan, durasi retensi, peristiwa awal, wilayah, sumber, versi, pemberi persetujuan, dan pengecualian. Representasikan permintaan penghapusan, legal hold, periode kontrak, dan kedaluwarsa cadangan alami sebagai batasan yang berbeda dengan jalur konflik dan eskalasi yang terdokumentasi. Simpan snapshot input yang digunakan untuk setiap kalkulasi sehingga sistem dapat menjelaskan mengapa suatu rekaman tetap dipertahankan.
2. Membangun katalog entitas dan referensi
Katalog menautkan tabel, partisi, snapshot, objek, topik, indeks, ekspor, dan cadangan ke pemilik serta silsilahnya (lineage). Untuk lakehouse, identifikasi file yang direferensikan oleh snapshot, branch, atau tag yang dipertahankan; untuk pipeline asinkron, catat apakah peristiwa penghapusan sampai ke konsumen downstream. Ketika sebuah referensi tidak dapat dipastikan, simpan data tersebut dan buat work item alih-alih menebak-nebak.
3. Mengompilasi rencana yang dapat dieksekusi
Kompiler membuat waktu kedaluwarsa, tindakan, pemeriksaan prasyarat, persyaratan persetujuan, dan batasan rollback untuk setiap entitas. Tindakan dapat berupa pemblokiran penulisan baru, penyembunyian data dari kueri, pengedaluwarsaan snapshot, penghapusan file yatim, pengiriman peristiwa penghapusan downstream, atau menunggu jendela pencadangan. Sertakan versi rencana dan kunci idempoten sehingga percobaan ulang tidak menduplikasi efek samping; dry run melaporkan konflik, estimasi jumlah objek, dan risiko.
4. Merancang eksekusi bertahap (batch) dan guardrail
Partisi eksekusi berdasarkan tenant, wilayah, tabel, atau partisi dan batasi konkurensi serta penghapusan per batch. Sebelum penghapusan fisik, periksa kembali snapshot aktif, pekerjaan pemulihan, legal hold, dan penulisan terbaru; tindakan berisiko tinggi memerlukan persetujuan ganda atau jendela pembekuan singkat. Dukung jeda, lanjutkan, dan exponential backoff agar layanan penyimpanan atau katalog tidak kelebihan beban. Catat versi rencana, digest input, hasil, dan kelas kesalahan untuk setiap batch.
5. Menghasilkan bukti penghapusan yang dapat diverifikasi
Bukti lebih dari sekadar log “pekerjaan berhasil”. Ini mencakup versi kebijakan, entitas yang dicakup, waktu mulai dan selesai, jumlah yang diproses dan gagal, pemeriksaan referensi, konfirmasi penerimaan (acknowledgement) downstream, kedaluwarsa cadangan, dan batasan yang tidak dapat diverifikasi. Catat kedaluwarsa snapshot, penghapusan file, dan pembersihan indeks secara terpisah. Jika cadangan tidak dapat dihapus secara fisik dengan segera, nyatakan bahwa permukaan online telah dihapus, kapan cadangan akan kedaluwarsa, dan siapa yang menyetujui batasan tersebut.
6. Menangani kegagalan, pemulihan, dan audit berkelanjutan
Commit perubahan metadata dan penghapusan fisik secara bertahap, dengan mempertahankan snapshot yang diperlukan atau jendela soft-delete untuk pemulihan. Jika suatu kebijakan salah, hentikan batch berikutnya, tandai entitas yang terpengaruh, dan jalankan rencana kompensasi. Data yang dihapus secara fisik tidak dapat dianggap dapat dikembalikan; pulihkan data tersebut dari replika yang diizinkan atau pembangunan ulang upstream. Pantau backlog kedaluwarsa, blok penghapusan, keterlambatan konfirmasi downstream, residu cadangan, dan konflik kebijakan, serta tinjau sumber kebijakan dan izin secara berkala.
Contoh jawaban berkualitas tinggi
Saya akan memodelkan label data, tujuan, cakupan subjek, peristiwa awal, retensi, wilayah, sumber, versi, pemberi persetujuan, dan pengecualian, lalu menentukan konflik antara retensi biasa, legal hold, permintaan penghapusan, dan jendela pencadangan. Katalog akan menautkan tabel, partisi, snapshot lakehouse, topik, indeks, ekspor, dan cadangan; referensi yang tidak diketahui akan tetap terlindungi. Kompiler membuat rencana berversi dan idempoten serta menjalankan dry run sebelum melakukan batching berdasarkan tenant dan partisi. Sebelum penghapusan, sistem memeriksa ulang snapshot aktif, pekerjaan pemulihan, legal hold, dan penulisan terbaru, lalu mencatat setiap hasilnya. Bukti mencantumkan cakupan, versi kebijakan, penghapusan dan konfirmasi penerimaan downstream, kegagalan, dan kedaluwarsa cadangan, dengan membedakan penghapusan online dari penghapusan fisik. Anomali apa pun akan menjeda batch berikutnya untuk kompensasi atau persetujuan. Audit berkelanjutan akan melacak backlog, penghapusan yang diblokir, residu, dan izin.
Kesalahan umum
- Memperlakukan setiap sistem penyimpanan sebagai satu key-value store dengan TTL.
- Hanya menyimpan tanggal kedaluwarsa akhir dan kehilangan konteks tujuan, sumber, versi, persetujuan, dan konflik.
- Mengabaikan snapshot, branch, cadangan, indeks, dan salinan downstream sebelum penghapusan.
- Menyebut pekerjaan yang berhasil sebagai bukti penghapusan tanpa cakupan atau batasan kegagalan.
- Mengabaikan dry run, jeda, batching, idempotensi, dan guardrail persetujuan manusia.
- Mengklaim bahwa penghapusan fisik dapat langsung dibatalkan atau mengabaikan kedaluwarsa alami cadangan.
- Menyajikan konfigurasi sistem sebagai nasihat hukum dan kehilangan sumber hukum atau kontraknya.
Pertanyaan lanjutan dan jawabannya
Bagaimana jika legal hold bertentangan dengan permintaan penghapusan?
Modelkan keduanya sebagai batasan terpisah, terapkan prioritas yang dikonfirmasi oleh kebijakan hukum, dan catat pemberi persetujuan, alasan, serta waktu mulai dan pencabutannya. Sistem dapat membekukan penghapusan atau membatasi akses online, tetapi tidak boleh mengarang pengecualian hukum.
Bagaimana Anda membuktikan kedaluwarsa snapshot tidak akan menghapus file yang direferensikan?
Baca snapshot aktif, branch, tag, dan referensi pekerjaan pemulihan sebelum eksekusi, serta hanya proses snapshot dan file di luar himpunan yang dipertahankan. Pindai lagi setelah pengiriman dan catat pemeriksaannya. Referensi yang tidak diketahui tetap terlindungi dan dijadikan work item.
Bagaimana jika cadangan tidak dapat dihapus dengan segera?
Representasikan penghapusan online, ketidaktersediaan cadangan, dan kedaluwarsa media fisik sebagai status yang terpisah. Catat retensi cadangan, rencana pemusnahan enkripsi atau kedaluwarsa alami, dan pembatasan akses. Bukti harus menyatakan batasan dan pemilik data yang belum dihapus secara fisik.
Apa yang terjadi setelah penghapusan yang tidak disengaja?
Hentikan kebijakan dan batch berikutnya, bekukan versi rencana dan bukti audit, serta nilai entitas yang terpengaruh. Pulihkan dari snapshot yang diizinkan, cadangan, atau pembangunan ulang upstream, kemudian terapkan kebijakan yang telah diperbaiki dan catat remediasi, persetujuan, serta notifikasi.