Bagikan melalui

Hapus file data yang tidak terpakai dengan vakum

  • Artikel

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 Pengoptimalan prediktif untuk tabel terkelola Unity Catalog.

Anda dapat menghapus file data yang tidak lagi direferensikan oleh tabel Delta yang lebih lama dari ambang retensi dengan menjalankan VACUUM perintah pada tabel. Berjalan VACUUM secara teratur penting untuk biaya dan kepatuhan karena pertimbangan berikut:

  • 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 untuk 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 Delta secara otomatis. Lihat Pengoptimalan prediktif untuk tabel terkelola Unity Catalog.

Beberapa fitur Delta Lake menggunakan file metadata untuk menandai data sebagai dihapus daripada menulis ulang file data. Anda dapat menggunakan REORG TABLE ... APPLY (PURGE) untuk menerapkan penghapusan ini dan menulis ulang file data. Lihat Menghapus menyeluruh penghapusan khusus metadata 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 dari tabel Delta lainnya. Lihat Klon Vakum dan Unity Catalog dangkal.
  • VACUUM menghapus semua file dari direktori yang tidak dikelola oleh Delta Lake, mengabaikan direktori yang dimulai dengan _ atau .. Jika Anda menyimpan metadata tambahan seperti titik pemeriksaan Streaming Terstruktur dalam direktori tabel Delta, 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 penembolokan Delta diaktifkan, kluster mungkin berisi data dari file Parket 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 RETAIN 100 HOURS  -- vacuum files not required by versions more than 100 hours old

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

RETAIN Gunakan kata kunci untuk menentukan ambang batas yang digunakan untuk menentukan apakah file data harus dihapus. Perintah VACUUM menggunakan ambang ini untuk melihat ke belakang dalam waktu jumlah waktu yang ditentukan dan mengidentifikasi versi tabel terbaru pada saat itu. Delta mempertahankan semua file data yang diperlukan untuk mengkueri versi tabel tersebut dan semua versi tabel yang lebih baru. Pengaturan ini berinteraksi dengan properti tabel lainnya. Lihat Mengonfigurasi retensi data untuk kueri perjalanan waktu.

Hapus menyeluruh hanya metadata untuk memaksa penulisan ulang data

Perintah REORG TABLE menyediakan APPLY (PURGE) sintaks untuk 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 TABEL REORG.

Operasi yang membuat penghapusan sementara di Delta Lake meliputi yang berikut ini:

  • Menghilangkan kolom dengan pemetaan kolom diaktifkan.
  • Menghapus baris dengan vektor penghapusan diaktifkan.
  • Setiap modifikasi data pada kluster yang diaktifkan Photon saat 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 OPTIMIZE dengan perintah, di mana file data ditulis ulang meskipun 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 VACUUM retensi dapat dikurangi untuk mempersingkat waktu tunggu yang diperlukan, dengan biaya mengurangi riwayat maksimum yang dipertahankan.

Kluster ukuran apa yang dibutuhkan vakum?

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 Delta 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 khusus driver, yang berarti bahwa semua operasi terjadi dalam satu simpul sementara simpul pekerja tidak aktif.

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 di luar 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 simpul pekerja. Jika perlambatan terjadi saat perintah penghapusan sedang berjalan, coba tingkatkan ukuran driver.

Seberapa sering Anda harus menjalankan vakum?

Databricks merekomendasikan untuk berjalan VACUUM secara teratur di semua tabel untuk mengurangi kelebihan biaya penyimpanan data cloud. 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 Delta dengan ambang retensi rendah?

Peringatan

Direkomendasikan agar Anda menetapkan interval retensi menjadi setidaknya 7 hari, karena snapshot lama dan file yang tidak diterapkan masih dapat digunakan oleh pembaca atau penulis tabel secara bersamaan. Jika VACUUM menghapus file aktif, pembaca dapat mengalami kegagalan secara serentak atau, lebih buruk lagi, tabel dapat menjadi rusak saat VACUUM menghapus file yang belum diterapkan. Anda harus memilih interval yang lebih lama dari transaksi serentak yang berjalan dengan waktu terlama dan periode terlama di mana aliran apa pun dapat tertinggal dari pembaruan tabel terbaru.

Delta Lake memiliki 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, Anda dapat mematikan pemeriksaan keamanan ini dengan mengatur properti spark.databricks.delta.retentionDurationCheck.enabled ke false.

Informasi audit

VACUUM terapkan ke log transaksi Delta berisi informasi audit. Anda dapat mengkueri peristiwa audit menggunakan DESCRIBE HISTORY.