Wawancara data engineering: Bagaimana Anda membuktikan bahwa nested-field pushdown DataFusion mengurangi biaya pemindaian?

Pertanyaan

DataFusion 53 dapat melakukan pushdown pada ekspresi seperti get_field ke dalam sumber data. Bagaimana Anda merancang kueri, plan, dan tolok ukur (benchmark) untuk membuktikan biaya I/O dan decoding yang lebih rendah tanpa mengubah hasil?

Konteks dan batasan

Asumsikan sebuah tabel Parquet memiliki kolom struct yang lebar bernama s, sedangkan kueri hanya membutuhkan s['label'] dan memfilter pada s['value']. Cakup pemindaian batch, statistik, nilai null, evolusi skema, dan fallback yang aman saat pushdown tidak berlaku. Jangan memperlakukan "proyeksi muncul di dalam plan" sebagai bukti end-to-end.

Hal yang diuji oleh pewawancara

Keahlian yang diuji adalah memisahkan kebenaran semantik, penulisan ulang plan (plan rewriting), kemampuan sumber data, dan manfaat yang dapat diobservasi. DataFusion 53 memindahkan pengaksesan nested-field lebih dekat ke pemindaian sehingga struct penuh tidak perlu dibaca; dokumen konfigurasinya menjelaskan enable_leaf_expression_pushdown mengekstrak get_field dari ekspresi filter, sort, atau join dan mendorongnya ke arah leaf node.

Klarifikasi poin-poin ini terlebih dahulu:

• Apakah sumber data mendukung proyeksi tingkat field (field-level projection), dan apakah format filenya Parquet?
• Apa saja tipe data, semantik null, dan aturan field yang hilang (missing-field rules) untuk s['label'] dan s['value']?
• Apakah baseline-nya berupa optimasi yang dinonaktifkan, versi DataFusion yang lebih lama, atau kueri yang membaca seluruh struct?
• Apakah perbandingan harus berfokus pada byte pemindaian, CPU decoding, memori puncak (peak memory), latensi, atau permintaan object-store?

Jawaban 30 detik

Mulailah dengan SQL yang memuat proyeksi dan pemfilteran bersarang. Kemudian bandingkan logical dan physical plan serta proyeksi pembaca Parquet sebelum dan sesudah optimasi. Terakhir, gunakan data, status cache, dan konkurensi yang identik untuk mengukur byte pemindaian, waktu decode, memori puncak, dan pemeriksaan hasil, sambil menyatakan kapan harus melakukan fallback.

Pembahasan mendalam langkah demi langkah

1. Buat data: buat file Parquet dengan partisi, row group, dan statistik yang identik sambil mengontrol lebar struct, tingkat null, dan selektivitas field.
2. Tentukan baseline: pertahankan versi DataFusion, jumlah thread, latensi object-store, dan status cache tetap konstan untuk pembacaan full-struct, pushdown yang dinonaktifkan, dan pembacaan leaf-field.
3. Periksa plan: konfirmasikan bahwa get_field berada di dekat pemindaian dan proyeksi hanya memuat id, s.label, serta field filter s.value; teks SQL saja tidak cukup.
4. Amati sumber data: catat kolom Parquet yang dibaca, row-group pruning, byte yang diambil, dan batch decode, memisahkan manfaat proyeksi dari manfaat predikat.
5. Periksa hasil: bandingkan hash atau baris yang diurutkan, mencakup field yang hilang, nilai null, perubahan tipe data, struct kosong, dan baris duplikat.
6. Tentukan fallback: jika sumber data tidak memiliki field pushdown, penulisan ulang tidak aman, atau manfaatnya di bawah ambang batas, pertahankan jalur pembacaan penuh yang benar dan catat alasannya.

Contoh jawaban

Saya akan membangun tiga baseline dari satu dataset Parquet yang tetap: membaca s secara penuh, menonaktifkan enable_leaf_expression_pushdown, dan mengaktifkan optimasi sambil memilih leaf field. Kuerinya adalah:

SELECT id, s['label']
FROM events
WHERE s['value'] > 150;

Saya akan menyimpan logical dan physical plan serta memverifikasi bahwa get_field berada di dekat pemindaian dan proyeksi pemindaian tidak lagi mencakup keseluruhan s. Saya akan menjalankan beberapa iterasi cold-cache dan warm-cache, mencatat byte yang dibaca, permintaan object-store, CPU decode Parquet, memori puncak, latensi end-to-end, dan baris output. Saya akan membandingkan hash terurut yang stabil dengan baseline full-struct, secara eksplisit mencakup nilai null, field yang hilang, serta skema lama dan baru. Jika sumber data tidak dapat memproyeksikan field, saya akan mempertahankan pembacaan penuh dan memancarkan metrik daripada mengorbankan kebenaran demi plan yang tampak lebih bagus. Sebelum peluncuran, byte pemindaian dan hash hasil akan dijadikan gerbang regresi (regression gates).

Kesalahan umum

• Hanya membandingkan latensi end-to-end tanpa mengontrol cache, konkurensi, dan tata letak file.
• Menggabungkan proyeksi field, predicate pushdown, dan row-group pruning menjadi satu angka yang tidak dapat dijelaskan.
• Hanya menguji nilai biasa dan mengabaikan nilai null, field yang hilang, serta evolusi skema.
• Menyatakan keberhasilan hanya dari plan yang ditulis ulang tanpa memeriksa kolom dan byte yang sebenarnya dikonsumsi oleh pembaca.
• Memaksakan penulisan ulang saat pushdown gagal alih-alih mempertahankan fallback yang mengutamakan kebenaran.

Jawaban yang kuat menghubungkan SQL, plan, sumber data, dan metrik; memberikan baseline dan pemeriksaan hasil yang dapat direproduksi; serta menjelaskan atribusi dan fallback. Jawaban yang lemah hanya mengatakan "projection pushdown lebih cepat" tanpa kontrol eksperimental atau bukti kebenaran.

Pertanyaan lanjutan dan tanggapan

Mengapa pembacaan leaf-field mungkin tetap tidak menunjukkan manfaat?

File mungkin berorientasi baris (row-oriented), struct mungkin tidak dapat dipisahkan secara fisik, permintaan object-store mungkin mendominasi, atau sumber data mungkin tidak mengimplementasikan proyeksi field. Periksa byte dan waktu decode yang sebenarnya daripada hanya memeriksa plan.

Jika s['value'] sebagian besar bernilai null, bagaimana Anda menjaga kebenaran hasil?

Perbaiki semantik tipe data dan null pada SQL terlebih dahulu, lalu bandingkan baris terhadap baseline pembacaan penuh. Optimasi dapat menghindari field yang tidak diperlukan tetapi tidak boleh memperlakukan null sebagai hilang atau keliru.

Apa yang terjadi pada file lama setelah nested field ditambahkan?

Pembaca harus mencocokkan field berdasarkan nama dan menerapkan semantik null atau default yang telah ditentukan ke file lama. Tolok ukur harus mencakup file lama dan baru serta memvalidasi pemindaian gabungan.

Daftar periksa wawancara

Poin penting dalam satu kalimat

Buktikan pushdown dengan memeriksa penempatan plan, perilaku pemindaian sebenarnya, kesetaraan hasil, dan fallback yang aman saat sumber data tidak dapat melakukan optimasi.