E-MapReduce:FAQ

Mengapa saya tidak dapat membuat tabel?

Delta Lake memerlukan parameter LOCATION saat membuat tabel. Parameter ini menentukan direktori tempat data tabel disimpan, dan tabel yang dihasilkan merupakan tabel eksternal di Apache Spark.

Perilaku tersebut bergantung pada apakah direktori tersebut sudah ada atau belum:

• Direktori belum ada: Delta Lake membuat tabel baru dengan skema yang Anda definisikan.

• Direktori sudah ada: Skema yang Anda tentukan harus persis sesuai dengan skema yang tercatat dalam file log Delta di direktori tersebut. Ketidaksesuaian apa pun menyebabkan pembuatan tabel gagal.

Periksa file log Delta di direktori tersebut dan sesuaikan skema CREATE TABLE Anda agar sesuai dengannya.

Mengapa Spark Streaming menghasilkan begitu banyak file kecil di Delta Lake?

Spark Streaming menulis data sebagai serangkaian mini batch, dan setiap mini batch menghasilkan satu atau beberapa file. Dengan ukuran batch kecil dan eksekusi berkelanjutan, jumlah file akan cepat bertambah.

Pilih strategi berdasarkan kebutuhan latensi Anda:

Kedua strategi dapat dikombinasikan: atur ukuran batch yang lebih besar untuk memperlambat akumulasi file, lalu jalankan OPTIMIZE secara berkala untuk mengompaksi sisa file tersebut.

Mengapa OPTIMIZE membutuhkan waktu lama untuk dijalankan?

Saat OPTIMIZE belum dijalankan dalam waktu lama, sejumlah besar file kecil menumpuk di Delta Lake. OPTIMIZE harus membaca dan menulis ulang semua file tersebut, sehingga memerlukan waktu yang jauh lebih lama.

Buat tugas terjadwal untuk menjalankan OPTIMIZE secara rutin. Frekuensi yang tepat bergantung pada beban kerja Anda:

• Kinerja kueri lebih baik: jalankan OPTIMIZE lebih sering (harian atau lebih sering lagi).

• Biaya lebih rendah: jalankan lebih jarang.

Menjalankan OPTIMIZE setiap hari merupakan titik awal yang baik, idealnya dilakukan pada jam sepi ketika biaya komputasi lebih rendah. Sesuaikan frekuensi berdasarkan kinerja kueri dan biaya yang Anda amati.

Mengapa OPTIMIZE gagal?

Delta Lake menggunakan mekanisme kunci optimis: ketika beberapa transaksi tulis dikomit secara bersamaan, salah satunya akan gagal. OPTIMIZE sendiri merupakan transaksi tulis, sehingga dapat bentrok dengan operasi tulis konkuren lainnya.

OPTIMIZE paling mungkin gagal ketika sebuah job streaming terus-menerus menghapus atau memperbarui data — pola yang umum dalam alur kerja Change Data Capture (CDC). Jika job streaming hanya menambahkan data tanpa penghapusan atau pembaruan, OPTIMIZE tidak akan gagal.

Untuk mengurangi konflik, partisi tabel berdasarkan waktu dan jalankan OPTIMIZE pada setiap partisi setelah data sepenuhnya ditulis ke dalamnya. Pendekatan ini menghindari persaingan antara OPTIMIZE dengan jendela penulisan aktif.

Mengapa file kecil tetap ada setelah menjalankan OPTIMIZE?

OPTIMIZE mengompaksi file kecil menjadi file yang lebih besar tetapi tidak menghapus file aslinya. Delta Lake menyimpan file-file tersebut untuk mendukung isolasi snapshot — kueri yang dimulai sebelum kompaksi tetap dapat membaca file asli guna mengakses snapshot konsisten dari tabel.

Untuk menghapus file yang telah dikompaksi, jalankan VACUUM setelah OPTIMIZE. VACUUM menghapus file yang telah digantikan dan telah melewati periode retensi (secara default 7 hari).

Mengapa file kecil tetap ada setelah menjalankan VACUUM?

VACUUM hanya menghapus file yang memenuhi dua kondisi: telah digabung oleh OPTIMIZE dan telah melewati periode retensi. Periode retensi default adalah 7 hari.

Jika file masih berada dalam periode retensi atau belum digabung, VACUUM akan membiarkannya tetap ada. Jalankan OPTIMIZE terlebih dahulu, lalu tunggu hingga periode retensi berlalu sebelum menjalankan VACUUM agar file tersebut memenuhi syarat untuk dihapus.

Bagaimana cara menghapus file kecil yang baru saja digabung?

File yang baru saja digabung masih berada dalam periode retensi 7 hari, sehingga VACUUM tidak akan menghapusnya secara default. Jendela retensi ini melindungi akses snapshot historis — menghapus file terlalu dini dapat mengganggu kueri yang mengandalkan perjalanan waktu (time travel).

Jika Anda yakin aman, gunakan salah satu metode berikut:

• Nonaktifkan pemeriksaan periode retensi: Atur properti konfigurasi Spark spark.databricks.delta.retentionDurationCheck.enabled ke false dan sertakan sebagai parameter saat memulai job Spark Anda. Lalu jalankan VACUUM dengan interval retensi yang singkat.

• Persingkat periode retensi global: Di spark-defaults.conf, atur spark.databricks.delta.properties.defaults.deletedFileRetentionDuration ke interval 1 hour. Pengaturan ini berlaku global untuk semua tabel Delta di kluster.

Mengapa file log Delta tetap ada setelah menjalankan VACUUM?

VACUUM mengelola file data, bukan file log Delta. Delta Lake menangani siklus hidup file log secara otomatis:

• Setiap 10 commit, Delta Lake menggabungkan file log.

• Setelah penggabungan, Delta Lake mengidentifikasi dan menghapus file log yang kedaluwarsa.

• Periode retensi default untuk file log Delta adalah 30 hari.

Tidak diperlukan intervensi manual. Jika Anda melihat banyak file log, kemungkinan besar file-file tersebut masih berada dalam jendela retensi 30 hari atau belum mencapai ambang batas 10 commit.

Apakah Delta Lake mendukung penjadwalan OPTIMIZE atau VACUUM secara otomatis?

Tidak. Delta Lake adalah library, bukan runtime, sehingga tidak memiliki penjadwal bawaan. OPTIMIZE dan VACUUM harus dipicu dari luar.

Konfigurasikan tugas terjadwal di sistem orkestrasi alur kerja Anda — seperti Apache Airflow atau cron job — untuk menjalankan perintah-perintah ini secara berkala pada tabel Delta Anda.