Masalah dan cakupan
Python 3.14 menambahkan dukungan Zstandard melalui modul pustaka standar compression.zstd, termasuk fungsi one-shot, open(), ZstdFile, serta kelas kompresor dan dekompresor inkremental. Pertanyaan ini menguji semantik API, batasan stream, batas atas sumber daya, dan kompatibilitas bertahap; kategorinya adalah coding. Ketersediaan pustaka standar tidak berarti setiap deployment telah ditingkatkan versinya, atau bahwa zstd lebih cepat atau menghasilkan ukuran lebih kecil untuk setiap dataset.
Apa yang diuji oleh pewawancara
Menjelaskan kompresi one-shot versus inkremental, batasan antara FLUSH_BLOCK dan FLUSH_FRAME, serta penanganan pemotongan data (truncation), input yang tidak dikenal, dan risiko decompression bomb. Selain itu, cakup juga tingkat kompresi, kamus (dictionaries), threading, fallback pada versi Python yang lebih lama, dan tolok ukur (benchmark) untuk throughput, rasio, latensi, dan memori puncak (peak memory).
Pertanyaan klarifikasi
- Apakah datanya berupa file lengkap, log terpotong-potong (chunked), atau stream jaringan yang harus dikirim saat ditulis?
- Apakah penerima mendukung zstd, dan bisakah seluruh deployment beralih ke Python 3.14 secara bersamaan?
- Apakah prioritasnya adalah throughput, rasio, tail latency, atau memori puncak?
- Berapa ukuran frame maksimum dan batas percobaan ulang (retry boundary) setelah terjadi kegagalan?
- Bisakah input disediakan oleh pengguna yang tidak tepercaya, dan bagaimana dekompresi akan dibatasi sumber dayanya?
- Apakah diperlukan interoperabilitas lintas bahasa, negosiasi kamus, atau parameter yang dapat diaudit?
Kerangka jawaban 30 detik
"Pertama, konfirmasikan protokol, potongan data (chunks), dan versi runtime, lalu pilih API one-shot atau streaming. Untuk input besar gunakan ZstdCompressor, tulis chunks, dan lakukan flush pada batas frame di akhir pesan; batasi ukuran output dan konkurensi saat dekompresi. Lakukan benchmark zstd terhadap gzip saat ini atau pustaka eksternal pada data yang identik untuk mengukur rasio, throughput, p95, CPU, dan RSS. Gunakan fallback yang telah teruji pada Python versi lama dan catat versi format serta parameternya."
Jawaban langkah demi langkah
Langkah 1: Pilih API dan batasannya
Gunakan compress() untuk objek lengkap dan berukuran terbatas; gunakan open() atau ZstdFile untuk antarmuka file. Untuk stream yang berjalan lama dan log besar, gunakan objek inkremental dan petakan setiap pesan atau batch ke batasan frame yang eksplisit, alih-alih menggabungkan beberapa tenant ke dalam satu frame yang tidak dapat dibagi.
Langkah 2: Rancang streaming flush
Panggilan compress() inkremental akan menghasilkan output perantara. flush(FLUSH_BLOCK) mengakhiri sebuah blok sambil mempertahankan frame, sedangkan flush(FLUSH_FRAME) mengakhiri frame saat ini. Lakukan flush hanya ketika protokol memungkinkan penerima untuk mendekode; mengakhiri frame untuk setiap fragmen kecil akan menambah overhead.
from compression import zstd
cctx = zstd.ZstdCompressor(level=3)
out = cctx.compress(chunk)
tail = cctx.flush(zstd.ZstdCompressor.FLUSH_FRAME)Langkah 3: Kendalikan risiko dekompresi
Input dengan kompresi tinggi dapat mengonsumsi memori yang jauh lebih besar setelah diekspansi dibandingkan dengan ukuran jaringannya. Tetapkan batas maksimum byte output, konkurensi per permintaan, dan batas waktu (timeout) untuk input yang tidak tepercaya; verifikasi kelengkapan frame dan bedakan antara kesalahan format, pemotongan data, dan pembatalan. Ukuran terkompresi bukanlah anggaran memori.
Langkah 4: Tangani kompatibilitas dan fallback
Periksa ketersediaan compression.zstd saat startup dan negosiasikan enkoding dalam protokol. Python 3.13 dan versi sebelumnya memerlukan backport yang versinya dipatok (pinned) atau pustaka eksternal; jangan mengubah format transmisi data (wire format) secara diam-diam. Sistem lintas bahasa harus menguji interoperabilitas frame zstd standar, tidak hanya jalur Python-ke-Python.
Langkah 5: Biarkan benchmark menentukan peluncuran (rollout)
Pertahankan konsistensi data, ukuran chunk, tingkat kompresi, dan konkurensi. Ukur rasio, throughput menyeluruh (end-to-end), CPU, p50/p95, RSS, alokasi memori, dan jumlah frame. Uji teks, log yang berulang, data acak, dan payload kecil; chunk yang sangat kecil bisa didominasi oleh overhead pemanggilan dan header frame. Pertahankan enkoding lama sebagai fallback yang dapat dipantau selama rollout bertahap.
Contoh jawaban model
"compression.zstd cocok untuk layanan Python 3.14 ketika diperlukan zstd pustaka standar, batasan streaming yang jelas, dan kontrol sumber daya. Saya akan menggunakan API one-shot untuk objek terbatas dan kompresi inkremental untuk stream besar, dengan menentukan batas blok, frame, batas output, dan pembatalan di dalam protokol. Dekompresor akan membatasi ekspansi dan konkurensi, menegosiasikan kemampuan saat startup, dan menggunakan fallback eksplisit pada runtime lama. Kemudian saya akan membandingkan rasio, throughput, tail latency, CPU, dan RSS pada data tetap, memverifikasi frame lintas bahasa, dan melakukan rollout hanya berdasarkan bukti terukur."
Kesalahan umum
- Menganggap
flush()menutup objek → itu mungkin hanya menyelesaikan sebuah blok atau frame → pilih mode flush dan siklus hidup secara eksplisit. - Membatasi dekompresi berdasarkan byte jaringan → input berasio tinggi dapat menghabiskan memori → batasi byte hasil ekspansi dan konkurensi.
- Membuat kompresor untuk setiap baris log → overhead inisialisasi dan frame akan berlipat ganda → gunakan kembali objek inkremental per batch.
- Mengasumsikan setiap runtime memiliki API 3.14 → deployment lama akan gagal saat startup → periksa dan tetapkan fallback.
- Hanya melakukan benchmark pada data acak → keuntungan pada log yang berulang tidak akan terlihat → cakup berbagai distribusi dan ukuran payload.
- Hanya menguji dari Python ke Python → frame atau parameter lintas bahasa mungkin berbeda → uji dengan implementasi zstd lainnya.
Pertanyaan lanjutan
Lanjutan 1: Kapan Anda harus menggunakan compress() one-shot?
Gunakan untuk input lengkap dan berukuran terbatas yang tidak perlu dikirim secara bertahap. Input besar atau situasi backpressure membutuhkan API inkremental agar seluruh hasil terkompresi tidak dibangun sekaligus.
Lanjutan 2: Mengapa membedakan blok dari frame?
Blok adalah batas flush di dalam sebuah frame; frame adalah unit terkompresi yang dapat didekode secara independen. Jika setiap pesan harus didekode secara terpisah, lakukan flush frame saat pesan selesai daripada hanya melakukan flush blok.
Lanjutan 3: Bagaimana cara runtime versi lama tetap berfungsi?
Periksa kapabilitas modul saat startup dan negosiasikan enkoding. Tetapkan (pin) dan uji backport atau pustaka eksternal, verifikasi semantik frame zstd yang setara, dan catat jalur enkoding mana yang benar-benar dijalankan.
Lanjutan 4: Apa yang paling mudah terlewatkan dalam sebuah benchmark?
RSS dekompresor, p95, jumlah frame, perubahan level, dan fixed overhead pada payload kecil sering kali diabaikan. Bandingkan semuanya bersama-sama dengan throughput dan rasio.