Data Lake Formation (DLF) menyediakan fitur optimasi penyimpanan seperti compaction adaptif tingkat tabel, pembersihan snapshot kedaluwarsa, manajemen siklus hidup partisi, dan pembersihan file yatim. Fitur-fitur ini menyederhanakan penggunaan serta operasi dan pemeliharaan (O&M) tabel Paimon serta meningkatkan efisiensi komputasi dan penyimpanan. Topik ini menjelaskan kebijakan optimasi penyimpanan cerdas yang dijalankan DLF di latar belakang beserta mekanisme eksekusinya.
Tabel Iceberg tidak memiliki mekanisme reklamasi penyimpanan otomatis. Untuk mencegah lonjakan biaya penyimpanan, lihat Administrasi Penyimpanan Tabel Iceberg untuk petunjuk cara membersihkan snapshot kedaluwarsa dan file yatim secara berkala dan manual.
Kebijakan optimasi penyimpanan
Jenis kebijakan | Deskripsi | Mekanisme eksekusi DLF |
Fitur compaction menggabungkan file-file kecil menjadi file yang lebih besar untuk mengurangi jumlah total file. Pengurangan jumlah file ini menurunkan overhead manajemen metadata dan biaya pencarian file selama kueri, sehingga meningkatkan performa dan efisiensi kueri pada tabel Paimon. | DLF secara otomatis memicu compaction saat Anda melakukan commit penulisan data. | |
Selama snapshot masih ada, file data yang direferensikannya tidak dapat dihapus. Hal ini memastikan bahwa status data historis tetap dapat dibaca. Namun, pembuatan snapshot baru meningkatkan ruang penyimpanan yang dikonsumsi oleh data historis. Anda harus menghapus snapshot lama untuk melepaskan ruang yang ditempati oleh data tidak aktif tersebut dan membebaskan sumber daya penyimpanan. | DLF secara otomatis memicu pembersihan snapshot saat pekerjaan optimasi penyimpanan DLF berjalan. Periode retensi default untuk snapshot adalah 1 jam. Anda dapat menyesuaikan periode retensi ini menggunakan parameter tabel Paimon. Untuk informasi selengkapnya, lihat Bersihkan data kedaluwarsa. | |
Banyak skenario bisnis hanya memerlukan akses ke data terbaru. Dalam kasus ini, Anda dapat mempartisi data berdasarkan waktu dan menetapkan aturan kedaluwarsa partisi untuk secara otomatis menghapus partisi lama dan membebaskan ruang penyimpanan. Anda juga dapat mengonfigurasi tiering penyimpanan untuk memindahkan data partisi yang jarang diakses dari penyimpanan berkinerja tinggi seperti Standard ke penyimpanan berbiaya rendah seperti Infrequent Access, Archive, atau Cold Archive. Praktik ini mengurangi biaya penyimpanan sekaligus memenuhi kebutuhan bisnis. | Anda dapat mengonfigurasi waktu kedaluwarsa partisi menggunakan parameter tabel Paimon. Untuk informasi selengkapnya, lihat Atur waktu kedaluwarsa partisi. Setelah Anda mengonfigurasi parameter tersebut, proses ini akan dipicu secara otomatis saat pekerjaan optimasi penyimpanan DLF berjalan. Anda juga dapat menggunakan tiering cerdas untuk secara otomatis memindahkan data partisi yang memenuhi kriteria tertentu ke kelas penyimpanan berbeda, seperti Standard, Infrequent Access, Archive, atau Cold Archive. Selain itu, Anda dapat mengubah kelas penyimpanan secara manual pada halaman detail tabel. Di halaman Ikhtisar Penyimpanan, Anda dapat melihat distribusi tiering penyimpanan untuk katalog data, database, dan tabel. | |
Error pekerjaan, restart, atau masalah lain dapat menyebabkan file temporary yang belum dikomit tetap berada di direktori tabel Paimon. File yatim ini tidak direferensikan oleh snapshot mana pun dan tidak dapat dihapus oleh mekanisme kedaluwarsa snapshot. Oleh karena itu, Anda harus membersihkan file-file ini secara berkala. | Periode retensi default untuk file yatim adalah 7 hari. DLF secara otomatis membersihkan file yatim yang lebih tua dari periode ini. Tugas pembersihan ini dipicu setiap 7 hari. |
Aktifkan atau nonaktifkan optimasi penyimpanan cerdas
Tab Optimasi Penyimpanan hanya ditampilkan saat Anda membuat tabel Paimon.
Masuk ke Konsol DLF.
Di halaman Data Catalog, klik nama katalog tersebut.
Di tab Databases, klik nama database target untuk melihat tabel-tabelnya.
Di Table List, klik nama tabel target untuk melihat informasi field-nya.
Klik tab Storage Optimization. Secara default, optimasi penyimpanan cerdas diaktifkan. Untuk menonaktifkan fitur ini, klik sakelar
.
Lihat dan konfigurasi kebijakan optimasi penyimpanan
Compaction
Di tab Storage Optimization, klik Compaction. Anda dapat melihat status eksekusi penggabungan file kecil, catatan Rescale, dan riwayat eksekusi.
Anda dapat mengedit mode kebijakan sesuai kebutuhan:
Mode sumber daya dinamis (Direkomendasikan)
Sistem menggunakan skalabilitas elastis otomatis untuk menyesuaikan sumber daya komputasi berdasarkan beban real-time. Mode ini tidak memerlukan perencanaan kapasitas manual dan cocok untuk skenario dengan trafik yang sangat fluktuatif.
Tiga preferensi konfigurasi didukung:
Resource dan latency seimbang: Menyeimbangkan optimal antara kecepatan merge dan konsumsi sumber daya (opsi default).
Latency-first: Mengalokasikan lebih banyak sumber daya untuk menyelesaikan penggabungan secepat mungkin guna mengurangi latensi visibilitas data.
Prioritas resource: Membatasi penggunaan sumber daya untuk mengurangi biaya komputasi, sehingga memungkinkan waktu merge sedikit lebih lama.
Mode sumber daya tetap
Anda dapat menentukan secara manual jumlah sumber daya komputasi untuk compaction. Mode ini cocok untuk skenario dengan trafik stabil atau persyaratan kontrol biaya yang ketat.
Persyaratan: Konfigurasi unit komputasi (CU) minimal harus 2 CU.
Pengaturan parameter: Anda dapat menyesuaikan interval pemicu compaction dan jumlah bucket.
Lihat status eksekusi
Anda dapat melihat status eksekusi optimasi untuk tabel saat ini dan mengonfigurasi langganan alert kustom di Cloud Monitor. Untuk informasi lebih lanjut tentang metrik dan langkah-langkah konfigurasi, lihat Pemantauan optimasi Lakehouse.
Lihat catatan Rescale
Bagian ini mencatat event historis rescaling bucket untuk tabel data atau partisi tertentu. Catatan ini mencerminkan perubahan struktur penyimpanan fisik dasar tabel. Mekanisme rescale terutama digunakan untuk mengatasi masalah performa akibat perubahan volume data. Catatan rescale memungkinkan Anda menentukan apakah tabel saat ini sedang menjalani proses rescale dan karenanya tidak memasuki proses compaction.
Lihat riwayat eksekusi
Anda dapat melihat riwayat eksekusi penggabungan file kecil untuk tabel saat ini. Riwayat ini menunjukkan bagaimana sistem memproses file terfragmentasi untuk mengoptimalkan performa baca dan ruang penyimpanan. Anda dapat menggunakan catatan ini untuk:
Konfirmasi eksekusi tugas: Memastikan tugas merge latar belakang berjalan dengan benar untuk mencegah akumulasi tak terbatas file kecil.
Evaluasi efisiensi kompresi: Membandingkan jumlah dan ukuran file sebelum dan sesudah merge untuk mengevaluasi apakah strategi compaction saat ini efektif.
Pembersihan snapshot kedaluwarsa
Di tab Storage Optimization, klik Snapshot Expire. Anda dapat mengonfigurasi aturan pembersihan snapshot dan melihat hasilnya.
Konfigurasi aturan pembersihan snapshot
Klik Edit, atur Snapshot Retention Period (default 1 jam), lalu klik Save.
Lihat hasil pembersihan snapshot
Jumlah snapshot saat ini: Menampilkan jumlah snapshot yang tersisa secara real time.
Informasi snapshot paling awal: Menampilkan detail snapshot tabel paling awal, termasuk ID snapshot, waktu commit, jenis commit, total baris dalam tabel, dan baris yang ditambahkan dalam commit ini.
Manajemen siklus hidup partisi
Di tab Storage Optimization, klik Partition Lifecycle. Anda dapat mengonfigurasi aturan pembersihan partisi, melihat hasil pembersihan partisi, dan mengonfigurasi tiering penyimpanan.
Konfigurasi aturan pembersihan partisi
Klik sakelar Expired Partition Cleanup
untuk mengaktifkan pembersihan partisi.Setelah mengaktifkan pembersihan partisi, konfigurasikan aturan berikut sesuai kebutuhan. Klik Save untuk menyelesaikan konfigurasi.
Item konfigurasi
Deskripsi
Expiration Policy
Anda dapat memilih salah satu kebijakan kedaluwarsa berikut:
Last access time: Menentukan kedaluwarsa berdasarkan waktu akses terakhir data partisi.
Partition value: Menentukan kedaluwarsa berdasarkan nilai partisi (values-time). Anda dapat mengonfigurasi format timestamp partisi dan pola field partisi.
Timestamp Format: Sesuai dengan item konfigurasi tabel
partition.timestamp-formatter. Anda dapat mengonfigurasi format sepertiyyyy-MM-dd,yyyyMMdd,dd/MM/yyyy, dandd.MM.yyyy.Timestamp Pattern: Sesuai dengan item konfigurasi tabel
partition.timestamp-pattern. Secara default, field partisi pertama digunakan. Anda dapat mengonfigurasi pola seperti$dtatau$year-$month-$day.
Last update time: Menentukan kedaluwarsa berdasarkan waktu pembaruan terakhir data partisi pada granularitas terkecil.
Partition Retention Period
Nilai maksimum adalah 999.999 hari. Waktu mulai periode retensi ditentukan oleh kebijakan kedaluwarsa yang dipilih.
(Opsional) Setelah menyimpan, Anda juga dapat mengklik Edit di sebelah kanan Rule Configuration untuk mengubah pengaturan lagi.
CatatanJika Anda ingin menyimpan partisi secara permanen, jangan mengonfigurasi aturan kedaluwarsa partisi. Secara default, sistem tidak secara otomatis membersihkan data partisi.
Lihat hasil pembersihan partisi
Klik View Partition List untuk melihat daftar partisi tabel data saat ini. Daftar ini mencakup nama partisi, jumlah baris (fisik), jumlah file yang direferensikan, ukuran total file, pembuat, kelas penyimpanan, terakhir diperbarui oleh, waktu pembuatan, waktu pembaruan terakhir, dan operasi.
Konfigurasi tiering penyimpanan
Item konfigurasi
Deskripsi
Intelligent Tiering
Saat diaktifkan, sistem secara otomatis melakukan tiering penyimpanan untuk semua tabel dalam katalog berdasarkan aturan siklus hidup yang Anda konfigurasi. Tentukan kebijakan dan aturan tiering sesuai kebutuhan.CatatanJika intelligent tiering diaktifkan di tingkat katalog, fitur ini juga diaktifkan secara default untuk tabel (diwariskan dari katalog). Anda dapat memodifikasi konfigurasi di tingkat tabel. Jika Anda mengubah aturan di tingkat tabel, status "inherited from Catalog" tidak lagi ditampilkan.
Jika intelligent tiering tidak diaktifkan di tingkat katalog, Anda tetap dapat mengaktifkan dan memodifikasinya di tingkat tabel.
Tiering Policy
Last access time: Aturan dievaluasi berdasarkan waktu akses terakhir data tabel atau partisi.
Last update time: Aturan dievaluasi berdasarkan waktu pembaruan terakhir data tabel atau partisi.
Tiering Rule
Persyaratan durasi penyimpanan minimum berbeda-beda untuk kelas penyimpanan yang berbeda.
Anda dapat mengonfigurasi aturan tiering berikut:
Transisi ke penyimpanan Infrequent Access
Hari: Kustom. Default 30 hari.
Data secara otomatis ditransisikan ke penyimpanan IA jika waktu akses terakhirnya melebihi jumlah hari ini. Penyimpanan IA masih dapat diakses oleh mesin komputasi, tetapi dengan performa yang berkurang.
Otomatis ubah ke penyimpanan Standard saat diakses: Jika Anda memilih opsi ini, sistem secara otomatis mentransisikan partisi atau tabel non-partisi ke kelas penyimpanan Standard saat diakses.
CatatanFitur ini hanya didukung saat kebijakan tiering diatur ke "Last access time".
Transisi ke Archive Storage
Hari: Kustom. Default 60 hari.
Data secara otomatis ditransisikan ke Archive Storage jika waktu akses terakhirnya melebihi jumlah hari ini. Data dalam Archive Storage tidak dapat diakses oleh mesin komputasi.
Otomatis ubah ke penyimpanan Standard saat diakses: Jika Anda memilih opsi ini, sistem secara otomatis mentransisikan partisi atau tabel non-partisi ke kelas penyimpanan Standard saat diakses.
CatatanFitur ini hanya didukung saat kebijakan tiering diatur ke "Last access time".
Transisi ke penyimpanan Cold Archive
Hari: Kustom. Default 180 hari.
Data secara otomatis ditransisikan ke penyimpanan Cold Archive jika waktu akses terakhirnya melebihi jumlah hari ini. Data dalam penyimpanan Cold Archive tidak dapat diakses oleh mesin komputasi.
CatatanSelain menggunakan fitur intelligent tiering, Anda dapat mengubah kelas penyimpanan secara manual di halaman detail tabel. Distribusi tiering penyimpanan untuk katalog data, database, dan tabel tersedia di halaman Ikhtisar Penyimpanan.
Pembersihan file yatim
Di tab Storage Optimization, klik Orphan File Remove. Anda dapat melihat aturan pembersihan file yatim. Misalnya, periode retensi default untuk file yatim adalah 7 hari, berdasarkan waktu penulisan file. Sistem secara otomatis membersihkan file yatim yang lebih tua dari periode ini.
Mengubah kelas penyimpanan secara manual
Di halaman Databases, klik nama database untuk melihat daftar tabel.
Di Table List, klik nama tabel untuk melihat field-field tabel.
Klik tab Table Details. Anda dapat mengubah kelas penyimpanan secara manual untuk tabel partisi maupun non-partisi.
Tabel partisi
Di tab Partition List, Anda dapat mengubah kelas penyimpanan untuk partisi.
Partisi dalam kelas penyimpanan Standard, Infrequent Access, atau Archive:
Di kolom Operation, klik Modify Storage Type. Anda dapat mengubah kelas penyimpanan ke kelas apa pun selain kelas saat ini.
Partisi dalam kelas penyimpanan Cold Archive:
Objek harus berada dalam keadaan dipulihkan sebelum Anda dapat mengubah kelas penyimpanannya. Langkah-langkahnya sebagai berikut:
Klik Restore. Konfigurasi Restored state duration. Anda dapat memilih partisi untuk batch restore.
Rentang nilai: Bilangan bulat dari 1 hingga 365. Satuannya hari.
Nilai default: 1 hari.
Saat data berada dalam status restored, klik Modify Storage Type di kolom Operation untuk mengubah kelas penyimpanan.
Tabel non-partisi
Di bagian Basic Information tabel, Anda dapat memodifikasi Storage Type.
Kelas penyimpanan Standard, Infrequent Access, atau Archive
Klik Modify di sebelah kanan Storage Type. Anda dapat mengubah kelas penyimpanan ke kelas apa pun selain kelas saat ini.
Kelas penyimpanan Cold Archive
Anda harus terlebih dahulu memulihkan objek tersebut. Setelah objek berada dalam keadaan dipulihkan, Anda dapat mengubah kelas penyimpanannya. Ikuti langkah-langkah berikut:
Klik Restore di sebelah kanan Storage Type. Konfigurasi Restored state duration.
Rentang nilai: Bilangan bulat dari 1 hingga 365. Satuannya hari.
Nilai default: 1 hari.
Saat Storage Type berubah menjadi Cold Archive (Restored), klik Modify di sebelah kanan Storage Type. Anda kemudian dapat mengubahnya ke kelas penyimpanan lainnya.
CatatanWaktu pemulihan: Waktu yang diperlukan untuk memulihkan objek. Untuk kelas penyimpanan Cold Archive, hanya prioritas pemulihan Standard yang didukung. Pemulihan selesai dalam 2 hingga 5 jam.
Waktu mulai keadaan dipulihkan: Waktu saat objek Cold Archive pertama dalam partisi memasuki keadaan dipulihkan setelah pemulihan selesai.
Durasi keadaan dipulihkan: Periode selama data tetap dalam keadaan dipulihkan setelah objek Cold Archive pertama dalam partisi dipulihkan. Setelah semua objek dalam partisi dipulihkan, Anda dapat membaca, menulis, atau mengubah kelas penyimpanan partisi tersebut. Saat durasi keadaan dipulihkan berakhir, data dalam partisi kembali ke status beku. Anda tidak dapat mengakses data secara langsung dan harus memulihkannya lagi untuk mendapatkan akses.
Prosedur pemulihan
Awalnya, objek berada dalam status beku.
Setelah Anda mengirim permintaan pemulihan, objek memasuki status restoring. Waktu pemulihan aktual dapat bervariasi.
Setelah tugas pemulihan di sisi server selesai, objek memasuki keadaan dipulihkan. Untuk tiering penyimpanan tingkat tabel, partisi dapat diakses setelah semua objek di dalamnya dipulihkan.
Anda dapat memperpanjang durasi total keadaan dipulihkan dengan menyesuaikan durasi keadaan dipulihkan partisi. Namun, durasi total tidak boleh melebihi batas maksimum yang diizinkan untuk kelas penyimpanan tersebut.
Setelah durasi keadaan dipulihkan berakhir, objek kembali ke status beku. Kelas penyimpanan aslinya tidak berubah. Untuk mengakses data lagi, Anda harus mengirim permintaan pemulihan baru dan menunggu pemulihan selesai.