Masalah dan ruang lingkup
S3 Metadata tables menyediakan metadata objek tabular untuk bucket serbaguna: tabel journal mencatat perubahan objek dan metadata, sedangkan tabel live inventory melakukan backfill snapshot dari objek yang ada. Pertanyaan ini menguji penggabungan peristiwa dan snapshot, latensi dan konsistensi, kontrol akses, biaya, serta pemulihan; kategorinya adalah system-design. Ini bukan indeks eksternal yang konsisten kuat dari setiap permintaan S3.
Hal yang diuji oleh pewawancara
Menjelaskan peran journal dan inventory, dampak backfill pertama, peristiwa penghapusan dan siklus proses (lifecycle), melakukan kueri pada tabel Iceberg, serta menangani keterlambatan, duplikat, dan celah data (gaps). Mencakup IAM untuk table bucket, akses lintas akun, metadata sensitif, pemartisian dan biaya pemindaian, retensi, serta prosedur pembangunan ulang.
Pertanyaan klarifikasi
- Apakah kueri memerlukan status saat ini, riwayat perubahan, atau keduanya?
- Berapa keterlambatan penemuan yang dapat diterima, dan apakah penghapusan atau transisi siklus proses harus bersifat real-time?
- Berapa jumlah objek, volume perubahan harian, dimensi kueri, dan periode retensi?
- Siapa yang boleh membaca metadata, termasuk bidang penyewa (tenant), enkripsi, tag, atau bidang kustom?
- Apakah diperlukan penggunaan lintas akun atau lintas Wilayah (Region), atau hanya satu akun AWS?
- Berapa target waktu pemulihan (recovery-time objective) jika konfigurasi tabel dihapus atau backfill gagal?
Kerangka jawaban 30 detik
“Gunakan inventory untuk menetapkan baseline objek saat ini dan journal untuk melacak perubahan selanjutnya; buat jaminan snapshot dan riwayat menjadi eksplisit dalam kontrak kueri. Selama backfill, tunjukkan status belum lengkap, lakukan deduplikasi konsumen berdasarkan waktu peristiwa dan versi objek, serta berikan peringatan untuk keterlambatan dan celah data. Batasi pembacaan dengan kebijakan sumber daya table bucket, pangkas kueri umum, dan buat model biaya penyimpanan, pemindaian, serta per objek. Jika konfigurasi hilang, pertahankan S3 sumber dan ekspor audit, bangun ulang dari konfigurasi berversi, dan rekonsiliasi baseline.”
Jawaban langkah demi langkah
Langkah 1: Tentukan batasan produk data
Jadikan “katalog saat ini” dan “log perubahan” sebagai kontrak kueri yang terpisah. Katalog menemukan objek yang tidak terenkripsi atau akan kedaluwarsa; journal memicu alur kerja tata kelola dan audit. Sistem downstream tidak boleh memperlakukan tabel peristiwa sebagai tabel status saat ini yang bebas dari celah data.
Langkah 2: Rancang backfill dan peralihan (cutover)
Buat konfigurasi dan amati backfill inventory sebelum mengekspos kueri yang mengklaim cakupan penuh. Selama backfill, klasifikasikan objek sebagai tercakup, tertunda, atau gagal untuk dicoba ulang, sehingga objek yang belum dipindai tidak dilaporkan sebagai tidak ada. Hubungkan journal sebagai sumber inkremental hanya setelah baseline siap.
Langkah 3: Gabungkan snapshot dan peristiwa
Jadikan pemrosesan idempoten dengan kunci objek, waktu peristiwa, dan jenis peristiwa. Simpan catatan audit untuk penghapusan, penimpaan (overwrite), dan perubahan siklus proses. Konsumen harus memutar ulang (replay) journal dan secara berkala merekonsiliasi dengan inventory, memperbaiki celah data daripada menyetel ulang indeks secara membabi buta.
Langkah 4: Lindungi akses dan bidang sensitif
Gunakan kebijakan sumber daya IAM pada table bucket dan tabel untuk membatasi prinsipal, prefiks, dan operasi. Berikan otorisasi untuk bidang penyewa, tag, dan enkripsi berdasarkan kelas data, serta kembalikan hanya kolom yang diperlukan. Untuk penggunaan lintas akun, tentukan kepemilikan bucket, kepemilikan biaya kueri, dan penyebaran pencabutan akses.
Langkah 5: Kendalikan biaya dan pulihkan dari kegagalan
Partisi atau buat tabel turunan terwujud (materialized derived tables) untuk filter umum, membatasi pemindaian penuh dan kueri ad-hoc yang sering. Lacak volume journal, inventory, pemindaian, dan biaya per objek. Jika konfigurasi dihapus, Wilayah tidak didukung, atau layanan gagal, pertahankan peristiwa sumber dan snapshot yang diekspor, bangun ulang dari konfigurasi berversi, dan lakukan rekonsiliasi kembali.
Contoh jawaban model
“Saya akan memperlakukan inventory sebagai baseline objek yang ada dan journal sebagai sumber perubahan, dengan jaminan latensi dan konsistensi yang eksplisit untuk setiap kueri. Setelah mengaktifkan konfigurasi, saya akan memantau backfill dan tidak memublikasikan kesimpulan cakupan penuh sampai selesai; kemudian menggabungkannya secara idempoten berdasarkan kunci objek, waktu peristiwa, dan jenis, dengan rekonsiliasi inventory secara berkala. Saya akan membatasi IAM table bucket, bidang sensitif, biaya lintas akun, dan pemindaian kueri secara terpisah. Selama kegagalan, pertahankan S3 sumber dan ekspor audit, bangun ulang dari konfigurasi, dan verifikasi celah data alih-alih memperlakukan tabel metadata sebagai indeks yang konsisten kuat.”
Kesalahan umum
- Memperlakukan journal sebagai snapshot → pemutaran ulang atau kehilangan menyebabkan status yang salah → rekonsiliasi dengan inventory dan pertahankan status turunan.
- Memublikasikan hasil kepatuhan sebelum backfill selesai → objek yang belum dipindai tampak tidak ada → tampilkan status dan cakupan backfill.
- Mengabaikan urutan penimpaan dan penghapusan → peristiwa lama menimpa status baru → gunakan waktu peristiwa, jenis peristiwa, dan kunci idempotensi.
- Memberikan akses baca table bucket kepada semua orang → metadata sensitif bocor → beri otorisasi berdasarkan prinsipal, kolom, dan penyewa.
- Hanya memantau penyimpanan → biaya pemindaian dan per objek membengkak → pantau volume, frekuensi, dan total biaya.
- Menyetel ulang indeks setelah kehilangan konfigurasi → silsilah (lineage) audit dan celah data hilang → buat versi pembangunan ulang dari sumber yang dipertahankan dan lakukan rekonsiliasi.
Pertanyaan lanjutan
Pertanyaan lanjutan 1: Bagaimana journal dan inventory bekerja bersama?
Inventory menyediakan snapshot dari objek yang ada; journal mencatat perubahan selanjutnya. Bangun baseline dari inventory, terapkan perubahan journal, dan lakukan rekonsiliasi secara berkala dengan inventory baru untuk memperbaiki peristiwa yang hilang atau duplikat.
Pertanyaan lanjutan 2: Bagaimana Anda mendeteksi backfill yang tidak lengkap?
Lacak status backfill, cakupan, dan kegagalan serta teruskan status tidak lengkap ke lapisan kueri. Kesimpulan cakupan penuh menunggu penyelesaian atau secara eksplisit menandai hasil sebagai tidak lengkap.
Pertanyaan lanjutan 3: Bagaimana Anda menangani peristiwa duplikat?
Hasilkan kunci idempotensi dari kunci objek, waktu peristiwa, jenis peristiwa, dan informasi versi yang tersedia. Konsumsi duplikat menjadi no-op; urutan yang tidak pasti diperbaiki oleh rekonsiliasi snapshot.
Pertanyaan lanjutan 4: Kapan Anda harus menghindari S3 Metadata tables?
Jika bisnis membutuhkan konsistensi read-after-write tingkat milidetik, transactional join yang kompleks, atau tata kelola bidang kustom sepenuhnya, evaluasi indeks atau database khusus. Tabel metadata cocok untuk penemuan objek, audit, dan sumber tata kelola batch.