Petunjuk dan konteks
Sebuah data lake menerima event JSON yang bentuknya sering berubah. Tim ingin mempertahankan kolom arbitrer sambil membuat kolom yang sering di-query dapat dibaca secara kolumnar dan dipangkas (prunable). Jelaskan komponen value dan metadata dari Parquet Variant, typedvalue dan fieldoffset pada Variant Shredding, serta rancang kompatibilitas, evolusi, dan validasinya.
Spesifikasi Apache Parquet merepresentasikan Variant dengan kolom biner value dan metadata; Variant Shredding dapat mengekstrak kolom yang sebagian homogen ke dalam kolom terpisah dan merekonstruksi nilai asli berdasarkan offset. Wawancara ini menguji pemahaman invarian format, semantik pembacaan, dan bukti beban kerja daripada hanya menempatkan JSON ke dalam satu kolom string yang buram.
Apa yang diuji oleh pewawancara
Pewawancara ingin melihat apakah Anda dapat memisahkan metadata yang mendeskripsikan diri sendiri dari nilai Variant dan menjelaskan hubungan antara typedvalue, fieldid, dan field_offset. Anda harus mampu menangani kolom yang hilang, tipe data campuran, urutan kolom, dan evolusi versi; menjelaskan bagaimana shredding memungkinkan proyeksi, predicate pushdown, kompresi, dan fallback; serta membuktikan rancangan tersebut dengan matriks ekuivalensi, performa, dan kompatibilitas.
Pertanyaan untuk diklarifikasi terlebih dahulu
Kolom dan query
Konfirmasikan path yang sering di-query, stabilitas tipe data, kebutuhan untuk mempertahankan kolom arbitrer yang tidak dikenal, dan apakah query engine mendukung Variant serta kolom yang di-shred.
Kompatibilitas dan tata kelola
Konfirmasikan reader lama mana yang harus dapat membuka file, apakah ada schema registry, bagaimana penghapusan dan penggantian nama didefinisikan, serta apakah data yang rusak (malformed) dapat masuk ke dalam kolom Variant mentah.
Target performa
Konfirmasikan fraksi pemindaian, biaya permintaan object-store, latensi penulisan, rasio kompresi, anggaran cache, dan anggaran CPU untuk rekonstruksi. Jangan menyimpulkan nilai hanya dari satu sampel JSON.
Jawaban 30 detik
"Saya memperlakukan Variant sebagai dua komponen biner, value dan metadata, di mana metadata mendeskripsikan kunci objek atau informasi tipe. Saya melakukan shred pada sub-kolom yang stabil dan bervolume tinggi ke dalam kolom typedvalue dan fieldoffset sambil tetap mempertahankan Variant mentah untuk kolom yang tidak dikenal. Pembacaan merekonstruksi semantik berdasarkan field_id dan offset, dengan penanganan eksplisit untuk nilai null atau ketidakcocokan tipe data. Sebelum peluncuran, saya menggunakan matriks reader lama/baru, pengujian ekuivalensi data bersarang acak, pemeriksaan pemangkasan kolom, dan pengukuran biaya pemindaian riil; jika gagal, saya beralih kembali ke kolom yang tidak di-shred."
Jawaban mendalam langkah demi langkah
Langkah 1: Tentukan invarian Variant
Simpan value dan metadata untuk setiap baris rekaman. Metadata harus menjelaskan tipe data, kunci, dan offset di dalam value, dan sebuah field_id harus memiliki interpretasi yang stabil di dalam satu file. Definisikan pengodean untuk null, nilai yang hilang, array, objek, dan tipe numerik.
Langkah 2: Pilih kandidat shred
Ekstrak hanya path dengan tipe data yang stabil, sering di-query, dan memberikan manfaat yang terukur. Pertahankan path yang jarang terisi (sparse) atau sangat polimorfik di dalam Variant untuk menghindari ledakan jumlah kolom berdensitas rendah dan amplifikasi penulisan. Terapkan aturan berdasarkan konfigurasi berversi.
Langkah 3: Rancang typed_value dan offset
Tulis typedvalue untuk path yang sesuai dengan pemrosesan kolumnar. Pertahankan fieldid, field_offset, atau data lokasi yang setara untuk struktur bersarang sehingga reader dapat menyusun kembali sebuah Variant. Jangan pernah berasumsi bahwa urutan kolom objek membawa makna semantik.
Langkah 4: Tangani evolusi skema
Simpan kolom baru di dalam Variant terlebih dahulu, lalu tambahkan aturan shredding setelah pola kuerinya stabil. Ketika suatu tipe data berubah, buat field_id atau versi baru alih-alih mengubah tipe kolom fisik secara diam-diam. Pertahankan interpretasi metadata yang diperlukan untuk membaca snapshot lama setelah terjadi penghapusan.
Langkah 5: Rencanakan pembacaan dan pemangkasan (pruning)
Untuk query yang hanya membutuhkan path yang di-shred, lakukan proyeksi pada typed_value dan gunakan statistik. Untuk path yang tidak dikenal, baca value dan metadata. Predicate pushdown harus dipastikan aman ketika nilainya bernilai null, hilang, atau polimorfik.
read(record, path):
if path has shredded column:
value = typed_value[row]
if value is present: return value
variant = decode(value[row], metadata[row])
return lookup_path(variant, path)Langkah 6: Tambahkan pemeriksaan konsistensi
Jalankan pemeriksaan ekuivalensi rekonstruksi per rekaman, dengan membandingkan tipe data, urutan array, kolom yang hilang, dan semantik null. Ambil sampel batas field_offset, referensi metadata, dan pembacaan lintas row-group; blokir publikasi jika ditemukan ketidakcocokan.
Langkah 7: Ukur biaya dan fallback
Ukur latensi, byte yang dipindai, permintaan object-store, kompresi, dan CPU secara terpisah untuk query khusus shred, query path tak dikenal, dan rekonstruksi penuh. Sediakan sakelar (switch) untuk menulis Variant mentah; lakukan perutean berdasarkan versi file untuk fallback ketika reader tidak memiliki dukungan atau manfaat terukur tidak mencapai ambang batas.
Jawaban model
Saya akan mempertahankan value/metadata Variant sebagai sumber kebenaran tunggal yang lengkap dan hanya melakukan shred pada path yang stabil dan bervolume tinggi. typedvalue menyimpan nilai yang ramah kolumnar; fieldid dan fieldoffset memungkinkan reader merekonstruksi semantik bersarang sesuai spesifikasi, sementara kolom yang tidak dikenal tetap dapat di-query dari Variant mentah. Aturan berversi dan fieldid baru mengelola evolusi tanpa mengubah tipe fisik secara diam-diam. Sebelum rilis, saya akan menguji reader lama dan baru, nilai yang hilang/null, array polimorfik, keamanan pemangkasan, dan ekuivalensi rekonstruksi, lalu mengaktifkan fitur ini berdasarkan byte yang dipindai, jumlah permintaan, dan CPU.
Kesalahan umum
- Kesalahan: Memperlakukan Variant sebagai satu kolom string JSON tunggal. → Mengapa gagal: Kehilangan metadata deskriptif diri dan manfaat ekstraksi kolumnar. → Solusi: Jelaskan peran value, metadata, field_id, dan offset.
- Kesalahan: Melakukan shred pada setiap path. → Mengapa gagal: Path yang sparse menyebabkan ledakan jumlah kolom dan amplifikasi penulisan. → Solusi: Pilih path berdasarkan frekuensi query, stabilitas tipe data, dan densitas.
- Kesalahan: Mengganti field_id dengan urutan kolom. → Mengapa gagal: Perubahan urutan objek tidak boleh mengubah arti data. → Solusi: Rekonstruksi dengan identifier dan offset yang telah ditentukan.
- Kesalahan: Hanya membandingkan hasil query dan melewatkan pengujian pada reader lama. → Mengapa gagal: Masalah dukungan format dan risiko fallback baru muncul di produksi. → Solusi: Bangun matriks versi file, versi reader, dan kapabilitas.
Pertanyaan lanjutan dan tanggapan
Kapan Anda harus menghindari shredding?
Pertahankan Variant tetap utuh jika path sangat jarang terisi (sparse), tipe data terus berubah, jarang di-query, atau reader tidak memiliki dukungan. Putuskan berdasarkan ambang batas pemindaian dan rekonstruksi yang terukur.
Bagaimana cara mencegah pemangkasan predikat (predicate pruning) yang tidak aman?
Lakukan pushdown pada predikat hanya jika statistik mencakup path tersebut dan dapat membedakan antara nilai yang hilang, null, dan ketidakcocokan tipe data; jika tidak, baca baris kandidat dan interpretasikan Variant.
Bagaimana cara menguji ekuivalensi rekonstruksi?
Hasilkan objek bersarang, array, kunci duplikat, null, kolom yang hilang, dan beberapa tipe numerik. Bandingkan Variant asli yang dinormalisasi dengan Variant hasil rekonstruksi di berbagai versi file.
Bagaimana jika reader lama tidak dapat membaca Variant?
Rute berdasarkan kapabilitas file ke format penulisan yang kompatibel atau gunakan layanan konversi sidecar. Jangan mengubah error akibat pengodean yang tidak didukung menjadi hasil kosong; hapus fallback hanya setelah migrasi selesai sepenuhnya.