Wawancara Rekayasa Data: Bagaimana Cara Mendiagnosis dan Memperbaiki Masalah Small-Files di Lakehouse?

Konteks Pertanyaan dan Penerapan

Sebuah tabel event Apache Iceberg pada object storage memiliki 20 TiB data aktif. Pekerjaan streaming melakukan commit micro-batch setiap satu menit. Pekerjaan ini menambahkan sekitar 200 GiB per hari tetapi membuat sekitar 80.000 file data Parquet yang ukuran mediannya hanya 3 MiB. Query p95 baru-baru ini meningkat dari 20 detik menjadi 95 detik, sementara fase perencanaan (planning) naik dari 4 detik menjadi 32 detik. Bisnis harus mempertahankan penyerapan data mendekati waktu nyata (near-real-time ingestion), mempertahankan time travel selama tujuh hari, dan tidak pernah menghapus objek tabel secara langsung dari penyimpanan.

Jelaskan bagaimana Anda membuktikan bahwa file-file kecil mendominasi regresi performa, menemukan penyebab penulisan dan partisi, menghentikan pertumbuhannya, dan memadatkan file yang ada dengan aman. Sertakan kontrol konkurensi, penganggaran sumber daya, rollback, dan kriteria penerimaan.

Semua kapasitas, jumlah file, latensi, dan nilai throughput adalah asumsi wawancara, bukan tolok ukur universal. Pertanyaan ini cocok untuk peran data engineering, analytics platform, lakehouse infrastructure, dan data-platform SRE. Kompetensi intinya adalah tata letak data dan pemeliharaan tabel, sehingga kategorinya adalah data; ini bukan sekadar pertanyaan konfigurasi Spark atau operasi object-storage.

Apa yang Sedang Dievaluasi oleh Pewawancara

Pertama, dapatkah kandidat membangun rantai bukti? Jumlah file yang tinggi saja tidak membuktikan hubungan sebab-akibat. Jumlah file aktif, distribusi ukuran, skew partisi, waktu pembacaan manifes, startup task, dan overhead pembukaan file harus dihubungkan secara terpisah dengan perencanaan dan pemindaian (scanning) kueri.

Kedua, dapatkah kandidat membedakan perbaikan backlog dari pencegahan? Pemadatan menangani file yang sudah ada. Jika frekuensi micro-batch, jumlah writer, distribusi data, dan partisi yang terlalu granular tetap tidak berubah, tabel akan terfragmentasi lagi.

Ketiga, apakah kandidat menghormati batasan transaksi format tabel? Pemadatan Iceberg menulis ulang file data dan melakukan commit snapshot baru. Snapshot yang lebih lama masih dapat merujuk ke file lama, sehingga menghapus objek di belakang metadata tidaklah aman.

Keempat, dapatkah kandidat membuat trade-off yang terukur? Bin packing terutama mengubah ukuran file. Pengurutan (sorting) atau Z-ordering juga mengubah pengelompokan (clustering) dan dapat meningkatkan pemangkasan (pruning), tetapi membutuhkan lebih banyak shuffle, pengurutan, dan penyimpanan sementara.

Kelima, dapatkah kandidat mengukur rencana operasional? Jawaban yang kuat memperkirakan byte yang ditulis ulang per hari, target jumlah file, rentang waktu pekerjaan (job window), dan risiko konflik, lalu menggunakan metrik kebenaran dan performa untuk memutuskan apakah akan memperluas peluncuran (rollout).

Pertanyaan Klarifikasi Sebelum Menjawab

• Target apa yang mendefinisikan "kecil"? Baca write.target-file-size-bytes, lalu pilih ambang batas menggunakan selektivitas kueri, volume harian per partisi, dan pengujian engine. Satu ukuran tetap tidak tepat untuk setiap tabel.
• Apakah 80.000 file aktif dalam snapshot saat ini atau dihitung di seluruh snapshot historis? Mulai dengan files untuk jalur kueri; gunakan all_files dan referensi snapshot untuk retensi dan biaya penyimpanan.
• Apakah latensi terjadi pada perencanaan atau pemindaian? Porsi perencanaan yang meningkat mengarah pada manifes dan task file. Throughput pemindaian yang menurun juga memerlukan pemeriksaan skew, file delete, kompresi, statistik kolom, dan sumber daya downstream.
• Bagaimana spesifikasi partisi dan distribusi penulisan? Kardinalitas tinggi atau partisi waktu yang terlalu granular mungkin tidak akan pernah mengakumulasi file berukuran target. Terlalu banyak writer paralel dapat membuat masing-masing menulis file yang hanya terisi sebagian.
• Apakah tabel menggunakan copy-on-write atau merge-on-read? Merge-on-read dapat mengakumulasi file delete posisi atau kesetaraan (equality), sehingga memadatkan file data saja mungkin tidak cukup.
• Partisi mana yang masih menerima data terlambat (late data)? Prioritaskan partisi dingin yang sudah ditutup. Partisi panas membutuhkan grup file yang lebih kecil, konkurensi terkontrol, dan percobaan ulang konflik (conflict retries).
• Apa arti retensi tujuh hari? Konfirmasikan kemampuan kueri snapshot, retensi cabang (branch) atau tag, dan siklus hidup object-store secara terpisah. Penghapusan direktori tidak dapat menggantikan ketiganya.

Kerangka Jawaban 30 Detik

"Saya akan memprofilkan file aktif, persentil ukuran, dan partisi dari snapshot Iceberg saat ini, lalu memisahkan perencanaan dari pemindaian. Pada 200 GiB per hari, 80.000 file dibandingkan dengan sekitar 400 file ideal berukuran 512 MiB menjadikan micro-batch, writer, dan granularitas partisi sebagai tersangka utama.

Saya akan menghentikan fragmentasi baru dengan memperbesar batch, mendistribusikan berdasarkan partition key, dan mengontrol jumlah writer. Kemudian saya akan melakukan bin-packing pada satu partisi dingin dengan konkurensi terikat, hanya melakukan pengurutan ketika uji pemangkasan membenarkannya. Pemadatan melakukan commit snapshot baru; file lama mengikuti retensi tujuh hari dan tidak pernah dihapus secara langsung. Rekonsiliasi data, persentil file, p95 perencanaan dan kueri, lag, dan konflik akan menentukan apakah peluncuran diperluas."

Pembahasan Mendalam Langkah demi Langkah

Langkah 1: Profilkan File dari Snapshot Saat Ini

Kueri metadata Iceberg alih-alih mendaftar direktori object-store secara rekursif. Direktori tersebut dapat berisi file yang hanya dirujuk oleh snapshot historis atau objek yatim (orphaned), sehingga tidak mewakili apa yang direncanakan oleh kueri saat ini. SQL berikut mengilustrasikan katalog Spark dan Iceberg; sesuaikan nama katalog dan fungsi persentil dengan engine yang sebenarnya:

SELECT
  partition,
  COUNT(*) AS active_files,
  SUM(file_size_in_bytes) AS active_bytes,
  percentile_approx(file_size_in_bytes, array(0.5, 0.9, 0.99)) AS size_percentiles
FROM lakehouse.analytics.events.files
GROUP BY partition
ORDER BY active_files DESC;

Catat ID snapshot saat ini, jumlah file data dan file delete, jumlah manifes, persentil ukuran file berdasarkan partisi, dan persentase file di bawah ambang batas kandidat. Nilai rata-rata menyembunyikan long tail: sebuah partisi dapat memiliki beberapa file besar dan puluhan ribu file berukuran 1 hingga 3 MiB. Minimal, periksa p50, p90, p99, dan sebuah histogram.

Bagi p95 kueri menjadi resolusi katalog dan manifes, perencanaan file, penjadwalan task, waktu hingga byte pertama (time to first byte), dan pemindaian. Hubungan sebab-akibat menjadi lebih kuat ketika jumlah file dan waktu perencanaan naik bersamaan dan partisi uji dengan total byte yang sama merencanakan jauh lebih cepat setelah pemadatan. Jika perencanaan stabil tetapi pemindaian melambat, selidiki selektivitas, statistik kolom, file delete, skew, dan sumber daya komputasi sebagai gantinya.

Langkah 2: Temukan Penyebab Regenerasi di Jalur Penulisan

Skenario ini menghasilkan 1.440 batch satu-menit per hari. Delapan puluh ribu file rata-rata sekitar 56 file per batch. Ketika setiap writer atau kombinasi writer-partisi menerima terlalu sedikit data, menetapkan target 512 MiB tidak dapat mengubah output 3 MiB menjadi file penuh. write.target-file-size-bytes adalah target, bukan jaminan bahwa setiap file mencapainya.

Akar penyebabnya sering kali merupakan kombinasi: micro-batch terlalu sering; paralelisme upstream berlebihan untuk setiap batch; baris tidak dikelompokkan berdasarkan partition key tabel sebelum penulisan; dimensi per jam, tenant, atau pengguna mempartisi tabel secara berlebihan; hot key menyebabkan skew; percobaan ulang menambah commit; atau pembaruan merge-on-read menciptakan tumpukan file delete.

Tafsirkan "kecil" per partisi. Partisi bervolume rendah yang valid yang hanya menerima 40 MiB per hari tidak akan pernah bisa mengisi file 512 MiB. Terima target yang lebih kecil, sederhanakan spesifikasi partisi, atau gunakan bucket atau hidden partitioning daripada meningkatkan frekuensi pemadatan terus-menerus.

Langkah 3: Berhenti Menghasilkan Fragmentasi yang Sama

Lakukan perubahan sisi penulisan terkecil dalam skema canary. Dalam batasan SLA kesegaran data (freshness SLA), gabungkan commit satu-menit menjadi batch pemicu yang lebih besar. Distribusikan baris secara hash atau rentang (range) berdasarkan partition key Iceberg. Tentukan jumlah writer dari byte per batch daripada paralelisme kluster maksimum. Hindari mempartisi langsung pada kolom berkardinalitas tinggi.

Uji ukuran file target terhadap rasio kompresi nyata, lebar baris, selektivitas kueri, dan volume harian per partisi. Skenario ini menggunakan 512 MiB, atau 536.870.912 byte, sebagai kandidat karena default Iceberg memberikan titik awal yang wajar. Ini tidak menutup kemungkinan 128 MiB, 256 MiB, atau nilai yang lebih besar. Jika suatu partisi jauh lebih kecil dari target, ubah spesifikasi partisi. Jika ada cukup data tetapi setiap writer menerima sedikit baris, perbaiki distribusi dan paralelisme.

Jalankan perbandingan A/B pada dua partisi dengan beban serupa. Bandingkan jumlah file, distribusi ukuran, latensi commit, lag pemrosesan stream, dan pemulihan kegagalan pada volume data yang sama. Pemadatan backlog hanya akan berkelanjutan setelah laju pembuatan file baru turun secara material.

Langkah 4: Batasi Pemadatan Berdasarkan Manfaat dan Risiko Konflik

Untuk tahap pertama, pilih satu partisi dingin yang jendela data terlambat dan koreksi bisnisnya telah ditutup, dan setidaknya kecualikan jam yang sedang ditulis saat ini. Apakah suatu partisi masih dapat berubah dan apakah snapshot dipertahankan selama tujuh hari adalah garis waktu yang terpisah. Mulailah dengan bin packing karena tujuan langsungnya adalah menurunkan overhead metadata dan pembukaan file. Tingkatkan ke sorting atau Z-ordering hanya jika kolom filter umum saling tumpang tindih secara signifikan antar file dan benchmark membenarkan shuffle tambahan.

CALL lakehouse.system.rewrite_data_files(
  table => 'analytics.events',
  strategy => 'binpack',
  options => map(
    'target-file-size-bytes', '536870912',
    'min-input-files', '5',
    'max-concurrent-file-group-rewrites', '3',
    'partial-progress.enabled', 'true'
  ),
  where => 'event_date = DATE ''2026-07-10'''
);

Predikat where memilih file yang mungkin berisi baris yang cocok. Selaraskan dengan batas partisi dan periksa byte kandidat sebelum eksekusi. Grup file membatasi setiap unit kerja. Konkurensi yang terkontrol mencegah object storage, shuffle, dan kluster kueri menjadi jenuh secara bersamaan. Progres parsial (partial progress) melakukan commit grup secara terpisah, mengurangi biaya percobaan ulang akibat konflik, tetapi membuat beberapa snapshot dan memerlukan pemantauan serta rollback tingkat grup.

Jika partisi panas tidak dapat dihindari, persempit rentang waktu dan grup file, buat penjadwalan menjadi idempoten, dan bedakan konflik data-file dari konflik commit metadata yang dapat dicoba lagi. Jangan pernah menjalankan dua pekerjaan pemadatan dengan rentang tabel yang tumpang tindih.

Langkah 5: Perkirakan Target Jumlah File, I/O, dan Jendela Waktu

Membagi 200 GiB dengan 512 MiB menghasilkan jumlah ideal sekitar 400 file target. Batas partisi, kompresi, dan sisa data membuat jumlah sebenarnya agak lebih tinggi. Perkiraan ini menangkap kesalahan skala besaran (order-of-magnitude); ini bukan janji pasti akan ada tepat 400 output.

Memadatkan satu partisi harian penuh membaca sekitar 200 GiB dan menulis sekitar 200 GiB, atau sekitar 400 GiB I/O data, ditambah shuffle, penyimpanan sementara, metadata, dan percobaan ulang. Jika tolok ukur mengukur throughput end-to-end berkelanjutan sebesar 100 MiB/s berdasarkan byte input, durasi idealnya adalah:

200 GiB * 1024 MiB/GiB / 100 MiB/s = 2,048 s ≈ 34.1 min

Tambahkan margin untuk skew, kueri bersamaan, dan percobaan ulang. Jendela 60 hingga 90 menit adalah anggaran skenario yang wajar, bersama dengan batasan pada byte kandidat, grup file bersamaan, laju permintaan object-store, dan disk sementara. Jika pemadatan hanya dapat memproses 150 GiB per hari sementara 200 GiB masuk, backlog pasti akan bertambah. Tingkatkan throughput yang berkelanjutan atau kurangi pembuatan file baru terlebih dahulu.

Langkah 6: Pisahkan Retensi Snapshot dari Pembersihan Fisik

Setelah pemadatan, snapshot baru merujuk ke file-file besar. Kueri yang sudah membaca snapshot lama masih dapat selesai, dan time travel tujuh hari masih membutuhkan file lama. Menghapus objek Parquet asli secara langsung akan merusak kedua perilaku tersebut.

Validasi snapshot baru dan amati siklus bisnis penuh sebelum menjalankan expire_snapshots. Pertahankan jendela tujuh hari, branch atau tag yang diperlukan, dan jumlah snapshot minimum. Kedaluwarsa snapshot hanya menghapus file yang tidak lagi diperlukan oleh snapshot yang dipertahankan. File yatim (orphan files) adalah kelas yang berbeda: tidak ada metadata tabel yang merujuknya. Jalankan remove_orphan_files secara terpisah, mulai dengan dry_run, pilih older_than yang konservatif, dan verifikasi skema jalur, otoritas, serta penulisan terlama yang sedang berjalan (in-flight) sebelum menghapus.

Kedaluwarsa snapshot bukanlah pemadatan, dan pembersihan file yatim bukanlah pengganti untuk mengakhiri referensi snapshot lama. Berikan jadwal, izin, dan catatan audit independen untuk ketiganya.

Langkah 7: Canary, Validasi, dan Tentukan Kondisi Berhenti

Sematkan (pin) snapshot pra-pemadatan dan partisi kandidat. Catat jumlah baris, jumlah business-key yang unik, agregat jumlah atau event penting, waktu event minimum dan maksimum, serta jumlah null. Hitung ulang rentang logis yang sama setelahnya. Total jumlah baris saja dapat menyembunyikan satu baris yang hilang yang diimbangi oleh satu duplikat, sehingga tabel kritis harus menambahkan checksum bertingkat (bucketed checksums) atau sampel business-key.

Untuk performa, bandingkan jumlah file aktif, ukuran p50/p90/p99, jumlah manifes, p50/p95 perencanaan, p95 kueri end-to-end, byte yang dipindai, byte yang ditulis ulang, dan biaya sumber daya. Metrik operasional mencakup laju pembuatan file kecil, lag pemadatan, grup file yang gagal, konflik commit, jumlah snapshot, dan byte yang dapat dipulihkan (reclaimable).

Hentikan ekspansi jika hasil kebenaran berbeda, waktu perencanaan tidak membaik, biaya mengganggu SLA penyerapan data, atau throughput pemadatan tetap di bawah laju fragmentasi baru. Snapshot tabel dapat me-rollback pointer metadata, tetapi tidak dapat membatalkan kedaluwarsa snapshot dan penghapusan fisik yang sudah selesai dengan sendirinya.

Contoh Jawaban Berkualitas Tinggi

"Saya tidak akan langsung menjalankan pemadatan. Saya akan membuktikan bottleneck-nya terlebih dahulu. Direktori object-store mencampur file historis dan yatim, jadi saya akan menggunakan tabel metadata files dari snapshot Iceberg saat ini untuk mengukur file aktif, total byte, dan ukuran p50/p90/p99 berdasarkan partisi. Saya kemudian akan memisahkan resolusi katalog dan manifes, perencanaan task, pembukaan file, dan pemindaian. Dalam skenario ini, 200 GiB per hari menghasilkan 80.000 file dengan median 3 MiB. Target kandidat 512 MiB menyiratkan sekitar 400 file ideal, jadi tata letak penulisan adalah petunjuk kuat, tetapi saya masih akan memastikan bahwa partisi yang dipadatkan dengan byte yang sama merencanakan lebih cepat.

Selanjutnya saya akan memperbaiki regenerasi file. Ada 1.440 batch satu-menit per hari dan sekitar 56 file per batch. Saya akan memeriksa paralelisme writer, kardinalitas partisi, distribusi pra-penulisan, skew, percobaan ulang, dan file delete merge-on-read. Dalam SLA kesegaran data, saya akan memperbesar batch commit, mendistribusikan secara hash atau rentang berdasarkan partition key, dan menyesuaikan jumlah writer dari byte batch. Nilai 512 MiB hanyalah titik awal. Partisi bervolume rendah yang tidak dapat mengisinya membutuhkan partisi yang lebih besar atau target yang lebih kecil.

Untuk backlog, saya akan melakukan canary pada satu partisi dingin dengan bin packing rewrite_data_files, predikat partisi, konkurensi grup file yang dibatasi, dan batasan byte kandidat. Saya akan menggunakan sorting atau Z-ordering hanya jika pengujian filter umum menunjukkan nilai yang jelas karena pengurutan menambah shuffle dan penyimpanan sementara. Jika partisi panas harus diproses, saya akan menggunakan grup file yang lebih kecil, progres parsial, dan percobaan ulang konflik yang terikat. Saya akan mencegah pemadatan yang tumpang tindih.

Pada 200 GiB dan 512 MiB, output ideal adalah sekitar 400 file. Satu tahap membaca sekitar 200 GiB dan menulis 200 GiB. Pada laju end-to-end terukur sebesar 100 MiB/s berdasarkan byte input, waktu proses ideal adalah 34,1 menit; saya akan mencadangkan 60 hingga 90 menit dan membuktikan bahwa kapasitas harian melebihi input harian.

Pemadatan melakukan commit snapshot baru secara atomik. Kueri yang ada dan time travel tujuh hari tetap merujuk ke file lama, jadi saya tidak akan pernah menghapus objek secara langsung. Setelah memvalidasi jumlah baris, agregat bisnis, checksum bertingkat, dan p95 kueri pada snapshot baru, saya akan mengakhiri masa berlaku snapshot di bawah kebijakan tujuh hari. Pembersihan file yatim tetap menjadi pekerjaan terpisah yang mendahulukan dry-run dan ditunda secara konservatif. Dasbor peluncuran akan melacak kebenaran data, laju file kecil baru, persentil file, p95 perencanaan, lag pemadatan, konflik, dan manfaat per GiB. Setiap regresi inti akan menghentikan ekspansi."

Kesalahan Umum

• Mengasumsikan jumlah file yang tinggi membuktikan penyebabnya → File historis bukanlah file kueri saat ini → Profilkan snapshot saat ini dan pisahkan perencanaan dari pemindaian.
• Menjalankan satu pemadatan lalu berhenti → Micro-batch, writer, dan partisi yang terlalu detail terus menghasilkan fragmen → Kurangi laju pembuatan fragmen baru sebelum membersihkan backlog.
• Memperlakukan ukuran target sebagai jaminan mutlak → Writer hanya dapat mengeluarkan baris yang diterimanya → Sesuaikan target, byte batch, distribusi, dan volume per partisi secara bersamaan.
• Menulis ulang seluruh tabel 20 TiB → Biaya dan cakupan konflik menjadi berlebihan → Proses partisi dingin dalam batch yang dibatasi oleh manfaat.
• Menggunakan sort atau Z-order secara default → Keduanya menambah shuffle dan penyimpanan sementara → Mulai dengan bin packing dan buktikan kebutuhan clustering dengan tolok ukur pemangkasan.
• Menghapus objek Parquet lama secara langsung → Snapshot yang dipertahankan dan kueri bersamaan mungkin merujuknya → Gunakan kedaluwarsa snapshot dan pembersihan file yatim secara terpisah dengan dry-run.
• Hanya memvalidasi total jumlah baris → Kehilangan baris dan duplikasi dapat saling meniadakan → Tambahkan agregat bisnis, jumlah key, checksum bertingkat, dan sampel.
• Memperkirakan waktu kerja tanpa throughput yang berkelanjutan → Pemrosesan harian di bawah input harian akan menumpuk backlog → Anggarkan pembacaan, penulisan, shuffle, percobaan ulang, dan lag pemadatan.
• Menggunakan coalesce(1) sebagai solusi universal → Satu writer menghancurkan paralelisme dan menciptakan bottleneck → Hitung jumlah writer dari volume partisi dan byte target.

Pertanyaan Lanjutan dan Tanggapan

Lanjutan 1: Mengapa menggunakan target 512 MiB alih-alih 128 MiB?

Target default Iceberg sebesar 512 MiB, atau 536.870.912 byte, adalah titik awal eksperimental untuk tabel besar dalam skenario ini, bukan nilai optimal universal. Lakukan benchmark pada kandidat 128, 256, dan 512 MiB atau lebih besar terhadap selektivitas kueri, biaya perencanaan, paralelisme task, kompresi, dan volume harian per partisi. Kueri yang sangat selektif mungkin lebih menyukai file yang lebih kecil, sementara pemindaian throughput dan partisi yang sangat besar mungkin lebih menyukai file yang lebih besar.

Lanjutan 2: Mengapa ukuran file masih hanya beberapa MiB setelah meningkatkan target?

Target memandu ukuran output yang coba dicapai oleh writer; target tidak menggabungkan data yang dipegang oleh task yang berbeda. Jika batch satu-menit dibagi ke puluhan writer, atau satu writer menyentuh banyak partisi bervolume rendah, file akan ditutup saat task melakukan commit. Ubah ukuran batch, distribusi penulisan, paralelisme, dan desain partisi alih-alih hanya menaikkan target.

Lanjutan 3: Bagaimana Anda memilih antara bin packing, sorting, dan Z-ordering?

Pilih bin packing jika tujuannya adalah memperkecil jumlah file dan menurunkan overhead pembukaan file. Uji sorting jika kueri sering memfilter pada satu kolom atau key hierarkis dan statistik file dapat memangkas rentang data. Evaluasi Z-ordering hanya jika filter umumnya mencakup kombinasi variabel dari beberapa dimensi. Sertakan shuffle tambahan, penyimpanan sementara, amplifikasi penulisan (write amplification), dan pemeliharaan berkelanjutan dalam benchmark kedua metode terakhir.

Lanjutan 4: Bagaimana jika pemadatan berkonflik dengan penulisan streaming?

Kecualikan partisi aktif terlebih dahulu. Jika tidak memungkinkan, gunakan grup file yang lebih kecil, batasi konkurensi, aktifkan progres parsial, dan terapkan percobaan ulang terbatas pada konflik commit. Penjadwal harus memberlakukan mutual exclusion untuk rentang tabel yang tumpang tindih. Progres parsial mencegah satu grup yang berkonflik memaksa eksekusi ulang penuh, tetapi ini menambah snapshot dan status keberhasilan parsial, jadi catat setiap hasil grup.

Lanjutan 5: Mengapa penggunaan object-store tidak langsung turun setelah pemadatan?

Pemadatan melakukan commit snapshot yang merujuk ke file baru. Snapshot historis, branch, atau tag masih merujuk ke file lama untuk pembacaan bersamaan dan time travel. Setelah retensi tujuh hari terpenuhi, masa berlaku snapshot dapat diakhiri untuk mereklamasi file yang tidak lagi dibutuhkan oleh snapshot yang disimpan. File yang tidak dirujuk oleh metadata tabel mana pun memerlukan proses pembersihan file yatim yang terpisah.

Lanjutan 6: Bagaimana Anda membuktikan bahwa peningkatan performa berasal dari berkurangnya file kecil, bukan dari cache atau sumber daya tambahan?

Gunakan pengaturan engine yang sama dan pastikan status cache konsisten (selalu dingin atau selalu hangat). Jalankan kueri yang dapat diulang pada rentang snapshot logis yang sama dan catat waktu perencanaan, jumlah task, pembukaan file, byte yang dipindai, dan waktu eksekusi sebelum dan sesudah pemadatan. Pertahankan partisi yang belum dipadatkan dengan beban serupa sebagai kontrol dan bandingkan persentil di beberapa kali pengujian. Bukti kausal lebih kuat hanya jika tata letak file berubah dan overhead perencanaan atau pembukaan file menurun secara konsisten seiring dengannya.