Hapus file data yang tidak terpakai dengan vakum

Pengoptimalan prediktif secara otomatis berjalan VACUUM pada tabel terkelola Unity Catalog. Databricks merekomendasikan untuk mengaktifkan pengoptimalan prediktif untuk semua tabel terkelola Unity Catalog untuk menyederhanakan pemeliharaan data dan mengurangi biaya penyimpanan. Lihat Optimasi prediktif untuk tabel yang dikelola oleh Unity Catalog.

Hapus file data yang tidak lagi direferensikan oleh tabel yang lebih lama dari ambang retensi dengan menjalankan VACUUM perintah pada tabel. Menjalankan VACUUM secara teratur penting untuk biaya operasional dan kepatuhan hukum berdasarkan pertimbangan-pertimbangan berikut ini:

  • Menghapus file data yang tidak digunakan mengurangi biaya penyimpanan cloud.
  • File data yang dihapus dengan VACUUM mungkin berisi rekaman yang telah dimodifikasi atau dihapus. Menghapus file-file ini secara permanen dari penyimpanan cloud memastikan rekaman ini tidak lagi dapat diakses.

Peringatan dan Pembatasan untuk Teknologi Vakum

Ambang retensi default untuk file data setelah berjalan VACUUM adalah 7 hari. Untuk mengubah perilaku ini, lihat Mengonfigurasi retensi data untuk kueri perjalanan waktu.

VACUUM mungkin meninggalkan direktori kosong setelah menghapus semua file dari dalamnya. Operasi berikutnya VACUUM menghapus direktori kosong ini.

Databricks merekomendasikan penggunaan pengoptimalan prediktif untuk menjalankan VACUUM tabel secara otomatis. Lihat Optimasi prediktif untuk tabel yang dikelola oleh Unity Catalog.

Beberapa fitur tabel menggunakan file metadata untuk menandai data sebagai dihapus daripada menulis ulang file data. Gunakan REORG TABLE ... APPLY (PURGE) untuk menerapkan penghapusan ini dan menulis ulang file data. Lihat Penghapusan metadata saja untuk memaksa penulisan ulang data.

Penting

  • Dalam Databricks Runtime 13.3 LTS ke atas, VACUUM semantik untuk kloning dangkal dengan tabel terkelola Unity Catalog berbeda dengan tabel lainnya. Lihat Menggunakan VACUUM dengan klon dangkal pada Unity Catalog.
  • VACUUM menghapus semua file dari direktori yang tidak dikelola oleh Azure Databricks, mengabaikan direktori yang dimulai dengan _ atau .. Jika Anda menyimpan metadata tambahan seperti titik pemeriksaan Streaming Terstruktur dalam direktori tabel, gunakan nama direktori seperti _checkpoints.
  • Kemampuan untuk mengkueri versi tabel yang lebih lama dari periode retensi hilang setelah menjalankan VACUUM.
  • File log dihapus secara otomatis dan asinkron setelah operasi titik pemeriksaan dan tidak diatur oleh VACUUM. Meskipun periode retensi default file log adalah 30 hari, berjalan VACUUM pada tabel akan menghapus file data yang diperlukan untuk perjalanan waktu.

Catatan

Saat penyimpanan cache disk diaktifkan, kluster mungkin berisi data dari file Parquet yang telah dihapus dengan VACUUM. Oleh karena itu, dimungkinkan untuk mengkueri data dari versi tabel sebelumnya yang filenya telah dihapus. Menghidupkan ulang kluster akan menghapus data cache. Harap lihat Mengonfigurasi tembolokan disk.

Contoh sintaks untuk vakum

VACUUM table_name   -- vacuum files not required by versions older than the default retention period

VACUUM table_name DRY RUN    -- do dry run to get the list of files to be deleted

Untuk detail sintaks Spark SQL, lihat VACUUM.

Lihat dokumentasi Delta Lake API untuk detail sintaks Scala, Java, dan Python.

Catatan

Di Databricks Runtime 18.0 dan ke atas, gunakan properti tabel untuk mengontrol penyimpanan. Untuk tabel terkelola Unity Catalog, ini berlaku untuk Databricks Runtime 12.2 ke atas.

Lihat Mengonfigurasi retensi data untuk kueri perjalanan waktu.

Mode penuh versus mode ringan

Penting

Fitur ini ada di Pratinjau Umum di Databricks Runtime 16.1 atau versi yang lebih baru.

Anda dapat menentukan LITE kata kunci dalam pernyataan vakum Anda untuk memicu mode VACUUM alternatif yang menghindari daftar semua file dalam direktori tabel.

LITE mode menggunakan log transaksi untuk mengidentifikasi file data yang tidak lagi berada dalam VACUUM ambang retensi dan menghapus file data ini dari tabel. LITE mode sangat berguna untuk tabel besar yang sering memerlukan operasi VACUUM, karena menghindari kebutuhan mencantumkan semua file untuk mengidentifikasi mana file data yang harus dihapus.

Catatan

Berjalan VACUUM dalam LITE mode tidak akan menghapus file apa pun yang tidak dirujuk dalam log transaksi. Misalnya, file yang dibuat oleh transaksi yang dibatalkan.

Gunakan sintaks berikut untuk VACUUM dalam LITE mode:

VACUUM table_name LITE

LITE mode memiliki persyaratan berikut:

  • Anda harus menjalankan setidaknya satu operasi yang berhasil VACUUM dalam ambang retensi log transaksi yang dikonfigurasi (30 hari secara default).

Jika persyaratan ini tidak terpenuhi, saat Anda mencoba menjalankan VACUUM dalam LITE mode, pesan kesalahan berikut akan ditampilkan. Untuk melanjutkan, Anda harus menjalankan VACUUM dalam mode FULL.

VACUUM <tableName> LITE cannot delete all eligible files as some files are not referenced by the log. Please run VACUUM FULL.

FULL mode adalah pengaturan default untuk mode vakum. Anda dapat secara eksplisit menjalankan mode penuh dengan perintah berikut:

VACUUM table_name FULL

Lihat VACUUM.

Hapus hanya metadata untuk memaksa penulisan ulang data

Perintah REORG TABLE dengan APPLY (PURGE) sintaks memungkinkan Anda menulis ulang data untuk menerapkan penghapusan sementara. Penghapusan sementara tidak menulis ulang data atau menghapus file data, melainkan menggunakan file metadata untuk menunjukkan bahwa beberapa nilai data telah berubah. Lihat REORG TABLE.

Operasi yang membuat penghapusan lunak mencakup yang berikut ini:

  • Menghapus kolom dengan pemetaan kolom diaktifkan.
  • Setiap modifikasi data dengan vektor penghapusan diaktifkan.

Dengan penghapusan sementara diaktifkan, data lama mungkin tetap ada secara fisik dalam file tabel saat ini bahkan setelah data dihapus atau diperbarui. Untuk menghapus data ini secara fisik dari tabel, selesaikan langkah-langkah berikut:

  1. Jalankan REORG TABLE ... APPLY (PURGE). Setelah melakukan ini, data lama tidak lagi ada dalam file tabel saat ini , tetapi masih ada dalam file lama yang digunakan untuk perjalanan waktu.
  2. Jalankan VACUUM untuk menghapus file lama ini.

REORG TABLE membuat versi baru tabel saat operasi selesai. Semua versi tabel dalam riwayat sebelum transaksi ini merujuk ke file data yang lebih lama. Secara konseptual, ini mirip dengan perintah OPTIMIZE, di mana file data ditulis kembali bahkan ketika data dalam versi tabel saat ini tetap konsisten.

Penting

File data hanya dihapus ketika file telah kedaluwarsa sesuai dengan VACUUM periode retensi. Ini berarti bahwa VACUUM harus dilakukan dengan penundaan setelah REORG sehingga file yang lebih lama telah kedaluwarsa. Periode retensi VACUUM dapat dikurangi untuk mempersingkat waktu tunggu yang diperlukan, dengan konsekuensi mengurangi riwayat maksimum yang dipertahankan.

Vakum membutuhkan kluster ukuran berapa?

Untuk memilih ukuran kluster yang benar untuk VACUUM, ini membantu memahami bahwa operasi terjadi dalam dua fase:

  1. Pekerjaan dimulai dengan menggunakan semua simpul eksekutor yang tersedia untuk mencantumkan file di direktori sumber secara paralel. Daftar ini dibandingkan dengan semua file yang saat ini dirujuk dalam log transaksi untuk mengidentifikasi file yang akan dihapus. Driver duduk diam selama waktu ini.
  2. Driver kemudian mengeluarkan perintah penghapusan untuk setiap file yang akan dihapus. Penghapusan file adalah operasi yang hanya melibatkan driver, yang berarti bahwa semua operasi terjadi dalam satu simpul sementara simpul pekerja dalam keadaan diam.

Untuk mengoptimalkan biaya dan performa, Databricks merekomendasikan hal berikut, terutama untuk pekerjaan vakum yang berjalan lama:

  • Jalankan vakum pada kluster dengan penskalaan otomatis yang ditetapkan untuk 1-4 pekerja, di mana setiap pekerja memiliki 8 core.
  • Pilih driver dengan antara 8 dan 32 core. Tingkatkan ukuran driver untuk menghindari kesalahan kehabisan memori (OOM).

Jika VACUUM operasi secara teratur menghapus lebih dari 10 ribu file atau mengambil lebih dari 30 menit waktu pemrosesan, Anda mungkin ingin meningkatkan ukuran driver atau jumlah pekerja.

Jika Anda menemukan bahwa perlambatan terjadi saat mengidentifikasi file yang akan dihapus, tambahkan lebih banyak node pekerja. Jika perlambatan terjadi saat perintah penghapusan sedang berjalan, coba tingkatkan ukuran driver.

Seberapa sering Anda harus menggunakan penyedot debu?

Databricks merekomendasikan menjalankan VACUUM secara teratur di semua tabel untuk mengurangi biaya penyimpanan data cloud berlebih. Ambang retensi default untuk vakum adalah 7 hari. Mengatur ambang yang lebih tinggi memberi Anda akses ke riwayat yang lebih besar untuk tabel Anda, tetapi meningkatkan jumlah file data yang disimpan dan, akibatnya, menimbulkan biaya penyimpanan yang lebih besar dari penyedia cloud Anda.

Mengapa Anda tidak dapat menyedot debu tabel dengan ambang retensi rendah?

Peringatan

Databricks sangat merekomendasikan pengaturan interval retensi setidaknya 7 hari. Jika Anda memiliki pekerjaan yang berjalan selama beberapa hari, pekerjaan jangka panjang mungkin menulis file yang belum dikonfirmasi. Jika periode retensi Anda terlalu pendek, VACUUM dapat menghapus file yang tidak dikomit ini sebelum pekerjaan selesai.

Ada pemeriksaan keamanan untuk mencegah Anda menjalankan perintah berbahaya VACUUM . Jika Anda yakin bahwa tidak ada operasi yang dilakukan pada tabel ini yang memakan waktu lebih lama dari interval retensi yang Anda rencanakan untuk ditentukan, nonaktifkan pemeriksaan keamanan ini dengan mengatur properti spark.databricks.delta.retentionDurationCheck.enabled konfigurasi Spark (Delta) atau spark.databricks.iceberg.retentionDurationCheck.enabled (Iceberg) ke false.

Informasi audit

VACUUM menerapkan informasi audit ke log transaksi. Kueri peristiwa audit menggunakan DESCRIBE HISTORY.

Pengelogan audit vakum dikontrol oleh konfigurasi spark.databricks.delta.vacuum.logging.enabled tingkat ruang kerja (Delta) atau spark.databricks.iceberg.vacuum.logging.enabled (Iceberg). Secara default, pengelogan audit diaktifkan di semua platform untuk tabel terkelola Unity Catalog.

Catatan

Pengelogan audit juga diaktifkan secara default untuk tabel eksternal.

  • Last updated on