Temu Duga Kejuruteraan Data: Bagaimana Anda Mendiagnosis dan Membetulkan Masalah Fail Kecil dalam Lakehouse?

Gesaan dan Konteks yang Berkenaan

Satu jadual peristiwa Apache Iceberg pada storan objek mempunyai 20 TiB data aktif. Satu kerja penstriman melakukan komit mikrokumpulan satu minit. Ia menambah kira-kira 200 GiB sehari tetapi mencipta kira-kira 80,000 fail data Parquet yang saiz mediannya hanya 3 MiB. p95 pertanyaan baru-baru ini meningkat daripada 20 saat kepada 95 saat, manakala fasa perancangan meningkat daripada 4 saat kepada 32 saat. Perniagaan mesti mengekalkan penyerapan hampir masa nyata, mengekalkan perjalanan masa selama tujuh hari dan tidak sekali-kali memadam objek jadual secara langsung daripada storan.

Terangkan cara anda akan membuktikan bahawa fail kecil mendominasi kemerosotan prestasi, mencari punca penulisan dan pembahagian (partitioning), menghentikan pertumbuhannya serta memadatkan fail sedia ada secara selamat. Sertakan kawalan keserempakan, belanjawan sumber, pemulihan (rollback) dan kriteria penerimaan.

Semua kapasiti, bilangan fail, kependaman dan nilai daya pemprosesan merupakan andaian temu duga, bukan penanda aras sejagat. Soalan ini sesuai untuk peranan kejuruteraan data, platform analitik, infrastruktur lakehouse dan SRE platform data. Kecekapan terasnya ialah susun atur data dan penyelenggaraan jadual, jadi kategorinya ialah data; ia bukan sekadar soalan konfigurasi Spark atau operasi storan objek.

Perkara yang Dinilai oleh Penemu Duga

Pertama, bolehkah calon membina rantaian bukti? Bilangan fail yang tinggi sahaja tidak membuktikan sebab dan akibat. Bilangan fail aktif, taburan saiz, kecondongan (skew) partisi, masa pembacaan manifes, permulaan tugas dan overhed pembukaan fail mesti dihubungkaitkan secara berasingan dengan perancangan dan pengimbasan pertanyaan.

Kedua, bolehkah calon membezakan pembetulan tunggakan daripada pencegahan? Pemadatan (compaction) mengendalikan fail sedia ada. Jika kekerapan mikrokumpulan, bilangan penulis, taburan data dan pembahagian partisi yang terlalu terperinci kekal tidak berubah, jadual akan berpecah-belah (fragment) semula.

Ketiga, adakah calon menghormati sempadan transaksi format jadual? Pemadatan Iceberg menulis semula fail data dan melakukan komit snapshot baharu. Snapshot lama masih boleh merujuk fail lama, jadi memadam objek di belakang metadata adalah tidak selamat.

Keempat, bolehkah calon membuat pertukaran (trade-offs) yang terikat? Pembungkusan bin (bin packing) pada dasarnya mengubah saiz fail. Pengisihan atau Z-ordering juga mengubah pengelompokan dan boleh menambah baik pemangkasan (pruning), tetapi memerlukan kos shuffle, pengisihan dan storan sementara yang lebih tinggi.

Kelima, bolehkah calon mengukur rancangan operasi secara kuantitatif? Jawapan yang kukuh menganggarkan bait yang ditulis semula setiap hari, sasaran bilangan fail, tetingkap kerja dan risiko konflik, kemudian menggunakan metrik ketepatan dan prestasi untuk memutuskan sama ada mahu meluaskan pelancaran.

Soalan Penjelasan Sebelum Menjawab

• Apakah sasaran yang mentakrifkan "kecil"? Baca write.target-file-size-bytes, kemudian pilih ambang menggunakan kepilihan pertanyaan (query selectivity), volum harian setiap partisi dan ujian enjin. Satu saiz tetap tidak tepat untuk setiap jadual.
• Adakah 80,000 fail tersebut aktif dalam snapshot semasa atau dikira merentasi snapshot sejarah? Mulakan dengan files untuk laluan pertanyaan; gunakan all_files dan rujukan snapshot untuk pengekalan dan kos storan.
• Adakah kependaman berlaku dalam perancangan atau pengimbasan? Bahagian perancangan yang meningkat menunjukkan masalah pada manifes dan tugas fail. Daya pemprosesan imbasan yang menurun juga memerlukan pemeriksaan kecondongan, fail pemadaman (delete files), pemampatan, statistik lajur dan sumber hiliran.
• Apakah spesifikasi partisi dan taburan penulisan? Kardinaliti tinggi atau partisi masa yang terlalu terperinci mungkin tidak pernah mengumpul fail bersaiz sasaran. Penulis selari yang berlebihan mungkin masing-masing melakukan komit fail yang terisi sebahagian sahaja.
• Adakah jadual menggunakan salin-semasa-tulis (copy-on-write) atau gabung-semasa-baca (merge-on-read)? Gabung-semasa-baca mungkin mengumpul fail pemadaman kedudukan atau kesamarataan, jadi memadatkan fail data sahaja mungkin tidak mencukupi.
• Partisi manakah yang masih menerima data lewat? Utamakan partisi sejuk yang telah ditutup. Partisi panas memerlukan kumpulan fail yang lebih kecil, keserempakan terkawal dan percubaan semula konflik.
• Apakah yang dimaksudkan dengan pengekalan tujuh hari? Sahkan kebolehpertanyaan snapshot, pengekalan cabang atau tag dan kitaran hayat storan objek secara berasingan. Pemadaman direktori tidak boleh menggantikan ketiga-tiganya.

Rangka Kerja Jawapan 30 Saat

"Saya akan memprofilkan fail aktif, persentil saiz dan partisi daripada snapshot Iceberg semasa, kemudian memisahkan perancangan daripada pengimbasan. Pada 200 GiB sehari, 80,000 fail berbanding kira-kira 400 fail ideal bersaiz 512 MiB menjadikan mikrokumpulan, penulis dan keperincian partisi sebagai suspek utama.

Saya akan menghentikan pemecahan baharu dengan membesarkan kumpulan data, mengagihkan mengikut kunci partisi dan mengawal bilangan penulis. Kemudian saya akan melakukan bin packing pada satu partisi sejuk dengan keserempakan terikat, mengisih hanya apabila ujian pemangkasan mewajarkannya. Pemadatan melakukan komit snapshot baharu; fail lama mematuhi pengekalan tujuh hari dan tidak sekali-kali dipadamkan secara langsung. Penyelarasan data, persentil fail, p95 perancangan dan pertanyaan, kelengahan (lag) serta konflik menentukan sama ada pelancaran perlu diperluaskan."

Pendalaman Langkah demi Langkah

Langkah 1: Profilkan Fail daripada Snapshot Semasa

Pertanyakan metadata Iceberg daripada menyenaraikan direktori storan objek secara rekursif. Direktori tersebut boleh mengandungi fail yang dirujuk hanya oleh snapshot sejarah atau objek yatim, jadi ia tidak mewakili perkara yang dirancang oleh pertanyaan semasa. SQL berikut menggambarkan katalog Spark dan Iceberg; sesuaikan nama katalog dan fungsi persentil dengan enjin sebenar:

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;

Rekodkan ID snapshot semasa, bilangan fail data dan fail pemadaman, bilangan manifes, persentil saiz fail mengikut partisi dan peratusan fail di bawah ambang calon. Purata (mean) menyembunyikan ekor panjang (long tail): sesuatu partisi boleh mempunyai beberapa fail besar dan puluhan ribu fail bersaiz 1 hingga 3 MiB. Sekurang-kurangnya, periksa p50, p90, p99 dan histogram.

Pecahkan p95 pertanyaan kepada penyelesaian katalog dan manifes, perancangan fail, penjadualan tugas, masa untuk bait pertama dan pengimbasan. Kes penyebab menjadi lebih kukuh apabila bilangan fail dan masa perancangan meningkat bersama-sama dan partisi ujian dengan jumlah bait yang sama dirancang dengan jauh lebih pantas selepas pemadatan. Jika perancangan stabil tetapi pengimbasan menjadi perlahan, selidiki kepilihan, statistik lajur, fail pemadaman, kecondongan dan sumber pengiraan sebagai ganti.

Langkah 2: Cari Punca Penjanaan Semula dalam Laluan Penulisan

Senario ini menghasilkan 1,440 kumpulan satu minit setiap hari. Lapan puluh ribu fail adalah kira-kira 56 fail bagi setiap kumpulan secara purata. Apabila setiap penulis atau gabungan penulis-partisi menerima terlalu sedikit data, menetapkan sasaran 512 MiB tidak dapat mengubah output 3 MiB menjadi fail penuh. write.target-file-size-bytes ialah sasaran, bukan jaminan bahawa setiap fail akan mencapainya.

Punca utamanya selalunya merupakan gabungan: mikrokumpulan terlalu kerap; keselarian huluan adalah berlebihan untuk setiap kumpulan; baris tidak dikelompokkan mengikut kunci partisi jadual sebelum menulis; dimensi setiap jam, penyewa atau pengguna membahagikan jadual secara berlebihan; kunci panas menyebabkan kecondongan; percubaan semula menambah komit; atau kemas kini gabung-semasa-baca mencipta hutang fail pemadaman.

Tafsirkan "kecil" mengikut partisi. Partisi bervolum rendah yang sah yang hanya menerima 40 MiB sehari tidak akan dapat mengisi fail 512 MiB. Terima sasaran yang lebih kecil, jadikan spesifikasi partisi lebih kasar atau gunakan baldi (buckets) atau pembahagian tersembunyi daripada meningkatkan kekerapan pemadatan selama-lamanya.

Langkah 3: Berhenti Menghasilkan Pemecahan yang Sama

Lakukan perubahan bahagian penulisan yang paling kecil dalam kenari (canary). Dalam SLA kesegaran, gabungkan komit satu minit ke dalam kumpulan pencetus yang lebih besar. Agihkan baris secara hash atau julat mengikut kunci partisi Iceberg. Pilih bilangan penulis daripada bait bagi setiap kumpulan dan bukannya keselarian kluster maksimum. Elakkan pembahagian secara langsung pada lajur berkardinaliti tinggi.

Uji saiz fail sasaran terhadap nisbah pemampatan sebenar, lebar baris, kepilihan pertanyaan dan volum harian setiap partisi. Senario ini menggunakan 512 MiB, atau 536,870,912 bait, sebagai calon kerana lalai Iceberg menyediakan titik permulaan yang munasabah. Ia tidak menolak 128 MiB, 256 MiB atau nilai yang lebih besar. Jika sesuatu partisi jauh lebih kecil daripada sasaran, kembangkan spesifikasi partisi. Jika data yang mencukupi wujud tetapi setiap penulis menerima sedikit baris, betulkan pengagihan dan keselarian.

Jalankan perbandingan A/B pada dua partisi yang mempunyai beban yang sama. Bandingkan bilangan fail, taburan saiz, kependaman komit, kelengahan pemprosesan strim dan pemulihan kegagalan pada volum data yang sama. Pemadatan tunggakan menjadi mampan hanya selepas kadar penjanaan fail baharu menurun secara ketara.

Langkah 4: Hadkan Pemadatan Mengikut Manfaat dan Risiko Konflik

Untuk pas pertama, pilih satu partisi sejuk yang tetingkap data lewat dan pembetulan perniagaannya telah ditutup, dan sekurang-kurangnya kecualikan jam yang sedang ditulis. Sama ada partisi masih boleh berubah dan sama ada snapshot dikekalkan selama tujuh hari adalah garis masa yang berasingan. Mulakan dengan bin packing kerana matlamat serta-merta adalah overhed metadata dan pembukaan fail yang lebih rendah. Tingkatkan kepada pengisihan atau Z-ordering hanya apabila lajur penapis biasa bertindih secara ketara merentasi fail dan penanda aras mewajarkan 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 fail yang mungkin mengandungi baris yang sepadan. Selaraskannya dengan sempadan partisi dan periksa bait calon sebelum pelaksanaan. Kumpulan fail mengehadkan setiap unit kerja. Keserempakan terkawal menghalang storan objek, shuffle dan kluster pertanyaan daripada tepu bersama-sama. Kemajuan separa (partial progress) melakukan komit kumpulan secara berasingan, mengurangkan kos mencuba semula konflik, tetapi ia mencipta berbilang snapshot dan memerlukan pemantauan serta rollback pada peringkat kumpulan.

Jika partisi panas tidak dapat dielakkan, kecilkan julat masa dan kumpulan fail, jadikan penjadualan idempoten dan bezakan konflik fail data daripada konflik komit metadata yang boleh dicuba semula. Jangan sekali-kali menjalankan dua kerja pemadatan dengan julat jadual yang bertindih.

Langkah 5: Anggarkan Sasaran Bilangan Fail, I/O dan Tetingkap

Membahagikan 200 GiB dengan 512 MiB memberikan bilangan ideal kira-kira 400 fail sasaran. Sempadan partisi, pemampatan dan baki yang tertinggal menjadikan bilangan sebenar lebih tinggi sedikit. Anggaran tersebut mengesan ralat tahap magnitud; ia bukan janji tepat 400 output.

Memadatkan satu partisi harian penuh membaca kira-kira 200 GiB dan menulis kira-kira 200 GiB, atau kira-kira 400 GiB I/O data, ditambah shuffle, storan sementara, metadata dan percubaan semula. Jika penanda aras mengukur daya pemprosesan hujung ke hujung mampan sebanyak 100 MiB/s mengikut bait input, tempoh ideal ialah:

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

Tambah margin untuk kecondongan, pertanyaan serentak dan percubaan semula. Tetingkap 60 hingga 90 minit ialah belanjawan senario yang munasabah, bersama-sama dengan had pada bait calon, kumpulan fail serentak, kadar permintaan storan objek dan cakera sementara. Jika pemadatan hanya boleh memproses 150 GiB sehari manakala 200 GiB tiba, tunggakan pasti akan berkembang. Tingkatkan daya pemprosesan yang mampan atau kurangkan penciptaan fail baharu terlebih dahulu.

Langkah 6: Asingkan Pengekalan Snapshot daripada Pembersihan Fizikal

Selepas pemadatan, snapshot baharu merujuk fail yang besar. Pertanyaan yang sudah membaca snapshot yang lebih lama masih boleh selesai, dan perjalanan masa tujuh hari masih memerlukan fail lama. Memadam objek Parquet asal secara langsung akan merosakkan kedua-dua tingkah laku ini.

Sahkan snapshot baharu dan perhatikan kitaran perniagaan penuh sebelum menjalankan expire_snapshots. Kekalkan tetingkap tujuh hari, cabang atau tag yang diperlukan dan bilangan snapshot minimum. Tempoh luput snapshot hanya mengalih keluar fail yang tidak lagi diperlukan oleh mana-mana snapshot yang dikekalkan. Fail yatim adalah kelas yang berbeza: tiada metadata jadual yang merujuknya. Jalankan remove_orphan_files secara berasingan, mulakan dengan dry_run, pilih older_than yang konservatif dan sahkan skema laluan, autoriti dan penulisan terpanjang yang sedang berjalan sebelum memadam.

Tempoh luput snapshot bukan pemadatan, dan pembersihan fail yatim bukan pengganti untuk meluputkan rujukan snapshot lama. Berikan ketiga-tiganya jadual, kebenaran dan rekod audit yang bebas.

Langkah 7: Jalankan Kenari, Sahkan dan Tentukan Syarat Berhenti

Sematkan snapshot pra-pemadatan dan partisi calon. Rekodkan bilangan baris, bilangan kunci perniagaan yang berbeza, agregat jumlah atau peristiwa kritikal, masa peristiwa minimum dan maksimum serta bilangan null. Kira semula julat logik yang sama selepas itu. Jumlah bilangan baris sahaja boleh menyembunyikan satu baris yang hilang yang diimbangi oleh satu pendua, jadi jadual kritikal harus menambah checksum berbaldi atau sampel kunci perniagaan.

Untuk prestasi, bandingkan bilangan fail aktif, saiz p50/p90/p99, bilangan manifes, p50/p95 perancangan, p95 pertanyaan hujung ke hujung, bait yang diimbas, bait yang ditulis semula dan kos sumber. Metrik operasi termasuk kadar penjanaan fail kecil, kelengahan pemadatan, kumpulan fail yang gagal, konflik komit, bilangan snapshot dan bait yang boleh dituntut semula.

Hentikan peluasan jika ketepatan berbeza, masa perancangan tidak bertambah baik, kos memasuki SLA penyerapan atau daya pemprosesan pemadatan kekal di bawah kadar pemecahan baharu. Snapshot jadual boleh mengembalikan penunjuk metadata, tetapi ia tidak boleh membalikkan luput snapshot yang telah selesai dan pemadaman fizikal dengan sendirinya.

Contoh Jawapan Berkualiti Tinggi

"Saya tidak akan bermula dengan menjalankan pemadatan. Saya akan membuktikan punca kekangan terlebih dahulu. Direktori storan objek mencampurkan fail sejarah dan yatim, jadi saya akan menggunakan jadual metadata files snapshot Iceberg semasa untuk mengukur fail aktif, jumlah bait dan saiz p50/p90/p99 mengikut partisi. Saya kemudiannya akan memisahkan penyelesaian katalog dan manifes, perancangan tugas, pembukaan fail dan pengimbasan. Dalam senario ini, 200 GiB sehari mencipta 80,000 fail dengan median 3 MiB. Sasaran calon 512 MiB membayangkan kira-kira 400 fail ideal, jadi susun atur penulisan ialah petunjuk yang kuat, tetapi saya masih akan mengesahkan bahawa partisi yang dipadatkan dengan bait yang sama dirancang dengan lebih pantas.

Seterusnya saya akan membetulkan penjanaan semula. Terdapat 1,440 kumpulan satu minit setiap hari dan kira-kira 56 fail bagi setiap kumpulan. Saya akan memeriksa keselarian penulis, kardinaliti partisi, pengagihan pra-penulisan, kecondongan, percubaan semula dan fail pemadaman gabung-semasa-baca. Dalam SLA kesegaran, saya akan membesarkan kumpulan komit, mengagihkan secara hash atau julat mengikut kunci partisi dan menentukan saiz bilangan penulis daripada bait kumpulan. Nilai 512 MiB hanyalah titik permulaan. Partisi bervolum rendah yang tidak dapat mengisinya memerlukan partisi yang lebih kasar atau sasaran yang lebih kecil.

Untuk tunggakan, saya akan menguji kenari pada satu partisi sejuk dengan bin packing rewrite_data_files, predikat partisi, keserempakan kumpulan fail terikat dan had bait calon. Saya akan menggunakan pengisihan atau Z-ordering hanya jika ujian penapis biasa menunjukkan nilai yang jelas kerana pengisihan menambah shuffle dan storan sementara. Jika partisi panas mesti diproses, saya akan menggunakan kumpulan fail yang lebih kecil, kemajuan separa dan percubaan semula konflik terikat. Saya akan menghalang pemadatan yang bertindih.

Pada 200 GiB dan 512 MiB, output ideal adalah kira-kira 400 fail. Satu pas membaca kira-kira 200 GiB dan menulis 200 GiB. Pada kadar hujung ke hujung yang diukur sebanyak 100 MiB/s mengikut bait input, masa jalanan ideal ialah 34.1 minit; saya akan memperuntukkan 60 hingga 90 minit dan membuktikan bahawa kapasiti harian melebihi input harian.

Pemadatan melakukan komit snapshot baharu secara atomik. Pertanyaan sedia ada dan perjalanan masa tujuh hari terus merujuk fail lama, jadi saya tidak akan sekali-kali memadam objek secara langsung. Selepas mengesahkan bilangan baris, agregat perniagaan, checksum berbaldi dan p95 pertanyaan pada snapshot baharu, saya akan meluputkan snapshot di bawah dasar tujuh hari. Pembersihan fail yatim kekal sebagai kerja berasingan yang mengutamakan dry-run dan ditangguhkan secara konservatif. Papan pemuka pelancaran akan menjejaki ketepatan, kadar fail kecil baharu, persentil fail, p95 perancangan, kelengahan pemadatan, konflik dan manfaat bagi setiap GiB. Sebarang kemerosotan teras akan menghentikan peluasan."

Kesilapan Biasa

• Menganggap bilangan fail yang tinggi membuktikan puncanya → Fail sejarah bukan fail pertanyaan semasa → Profilkan snapshot semasa dan pisahkan perancangan daripada pengimbasan.
• Menjalankan satu pemadatan dan berhenti → Mikrokumpulan, penulis dan partisi halus terus menghasilkan serpihan → Kurangkan kadar serpihan baharu sebelum membersihkan tunggakan.
• Memperlakukan saiz sasaran sebagai jaminan mutlak → Penulis hanya boleh mengeluarkan baris yang diterimanya → Sesuaikan sasaran, bait kumpulan, pengagihan dan volum setiap partisi bersama-sama.
• Menulis semula keseluruhan jadual 20 TiB → Kos dan skop konflik menjadi berlebihan → Proses partisi sejuk dalam kumpulan yang terikat dengan manfaat.
• Menggunakan pengisihan atau Z-order secara lalai → Kedua-duanya menambah shuffle dan storan sementara → Mulakan dengan bin packing dan wajarkan pengelompokan dengan penanda aras pemangkasan.
• Memadam objek Parquet lama secara langsung → Snapshot yang dikekalkan dan pertanyaan serentak mungkin merujuknya → Gunakan tempoh luput snapshot dan pembersihan fail yatim dry-run yang berasingan.
• Mengesahkan jumlah bilangan baris sahaja → Kehilangan dan pendua boleh saling membatalkan → Tambah agregat perniagaan, bilangan kunci, checksum berbaldi dan sampel.
• Menganggarkan masa jalanan tanpa daya pemprosesan yang mampan → Pemprosesan harian di bawah input harian mengembangkan tunggakan → Belanjawankan pembacaan, penulisan, shuffle, percubaan semula dan kelengahan pemadatan.
• Menggunakan coalesce(1) sebagai penyelesaian sejagat → Satu penulis memusnahkan keselarian dan mencipta kesesakan (bottleneck) → Kira bilangan penulis daripada volum partisi dan bait sasaran.

Soalan Susulan dan Maklum Balas

Susulan 1: Mengapa menggunakan sasaran 512 MiB dan bukannya 128 MiB?

Sasaran lalai Iceberg sebanyak 512 MiB, atau 536,870,912 bait, ialah titik permulaan eksperimen untuk jadual besar dalam senario ini, bukan optimum sejagat. Buat penanda aras bagi calon 128, 256 dan 512 MiB atau lebih besar terhadap kepilihan pertanyaan, kos perancangan, keselarian tugas, pemampatan dan volum harian setiap partisi. Pertanyaan yang sangat memilih mungkin lebih menggemari fail yang lebih kecil, manakala imbasan daya pemprosesan dan partisi yang sangat besar mungkin lebih menggemari fail yang lebih besar.

Susulan 2: Mengapa fail masih hanya beberapa MiB selepas meningkatkan sasaran?

Sasaran membimbing saiz output yang cuba dicapai oleh penulis; ia tidak menggabungkan data yang dipegang oleh tugas yang berbeza. Jika kumpulan satu minit dipecahkan merentasi puluhan penulis, atau seorang penulis menyentuh banyak partisi bervolum rendah, fail ditutup apabila tugas melakukan komit. Ubah saiz kumpulan, pengagihan penulisan, keselarian dan reka bentuk partisi daripada hanya meningkatkan sasaran.

Susulan 3: Bagaimanakah anda memilih antara bin packing, pengisihan dan Z-ordering?

Pilih bin packing apabila matlamatnya adalah fail yang lebih sedikit dan overhed pembukaan yang lebih rendah. Uji pengisihan apabila pertanyaan kerap menapis pada satu lajur atau kunci berhierarki dan statistik fail boleh memangkas julat. Nilaikan Z-ordering hanya apabila penapis biasanya merangkumi gabungan berbilang dimensi yang berubah-ubah. Sertakan shuffle tambahan, storan sementara, amplifikasi penulisan dan penyelenggaraan berterusan dalam kedua-dua penanda aras yang terakhir.

Susulan 4: Bagaimana jika pemadatan bercanggah dengan penulisan penstriman?

Kecualikan partisi aktif terlebih dahulu. Apabila perkara itu mustahil, gunakan kumpulan fail yang lebih kecil, hadkan keserempakan, dayakan kemajuan separa dan gunakan percubaan semula terikat pada konflik komit. Penjadual harus menguatkuasakan saling eksklusif (mutual exclusion) untuk julat jadual yang bertindih. Kemajuan separa menghalang satu kumpulan yang berkonflik daripada memaksa larian semula penuh, tetapi ia menambah snapshot dan keadaan kejayaan separa, jadi rekodkan setiap hasil kumpulan.

Susulan 5: Mengapakah penggunaan storan objek tidak menurun serta-merta selepas pemadatan?

Pemadatan melakukan komit snapshot yang merujuk fail baharu. Snapshot sejarah, cabang atau tag masih merujuk fail lama untuk pembacaan serentak dan perjalanan masa. Selepas pengekalan tujuh hari dipenuhi, tempoh luput snapshot boleh menuntut semula fail yang tidak diperlukan oleh snapshot yang dikekalkan. Fail yang tidak dirujuk oleh mana-mana metadata jadual sama sekali memerlukan proses pembersihan fail yatim yang berasingan.

Susulan 6: Bagaimanakah anda membuktikan perolehan itu datang daripada fail kecil yang lebih sedikit dan bukannya cache atau sumber tambahan?

Gunakan tetapan enjin yang sama dan jadikan keadaan cache sejuk secara konsisten atau dipanaskan secara konsisten. Jalankan pertanyaan yang boleh diulang ke atas julat snapshot logik yang sama dan rekodkan masa perancangan, bilangan tugas, pembukaan fail, bait yang diimbas dan masa pelaksanaan sebelum dan selepas. Simpan partisi yang tidak dipadatkan dengan beban yang sama sebagai kawalan dan bandingkan persentil merentasi pelbagai larian. Bukti sebab dan akibat adalah lebih kukuh hanya apabila susun atur fail berubah dan overhed perancangan atau pembukaan menurun secara konsisten dengannya.