All Products
Search

This Product

    Data Lake Formation:Optimisasi penyimpanan

    Document Center

    Data Lake Formation:Optimisasi penyimpanan

    Last Updated:Jul 16, 2026

    Optimisasi penyimpanan DLF menyederhanakan pemeliharaan tabel Paimon melalui kompaksi adaptif, pembersihan snapshot kedaluwarsa, manajemen siklus hidup partisi, dan pembersihan file yatim. Panduan ini mencakup strategi optimisasi yang tersedia serta cara DLF mengeksekusinya.

    Penting

    Tabel Iceberg tidak memiliki reklamasi penyimpanan otomatis. Untuk mencegah lonjakan biaya penyimpanan, bersihkan secara berkala snapshot kedaluwarsa dan file yatim sebagaimana dijelaskan dalam Tata kelola penyimpanan tabel Iceberg.

    Strategi optimisasi penyimpanan

    Jenis strategi

    Deskripsi

    Mekanisme eksekusi DLF

    Compaction

    Menggabungkan file kecil menjadi file yang lebih besar untuk mengurangi jumlah file, overhead metadata, dan biaya pencarian file selama kueri, sehingga meningkatkan performa kueri tabel Paimon.

    DLF secara otomatis memicu compaction saat penulisan data dikomit.

    Expired snapshot cleanup

    Snapshot melindungi file data yang direferensikan dari penghapusan sehingga mempertahankan status historis. Seiring akumulasi snapshot, konsumsi penyimpanan meningkat. Menghapus snapshot yang tidak diperlukan membebaskan ruang penyimpanan.

    DLF memicu pembersihan snapshot kedaluwarsa secara otomatis selama pekerjaan optimisasi penyimpanan. Waktu kedaluwarsa default adalah satu jam dan dapat disesuaikan melalui parameter tabel Paimon. Untuk informasi lebih lanjut, lihat Bersihkan data kedaluwarsa.

    Partition lifecycle management

    Banyak skenario hanya memerlukan data terbaru. Partisi data berdasarkan waktu dan atur aturan kedaluwarsa untuk secara otomatis menghapus partisi lama guna membebaskan penyimpanan. Konfigurasikan tiering penyimpanan cerdas untuk memindahkan data yang jarang diakses dari Standard ke kelas penyimpanan berbiaya lebih rendah (Infrequent Access, Archive, atau Cold Archive).

    Konfigurasikan waktu kedaluwarsa melalui parameter tabel Paimon di Atur waktu kedaluwarsa partisi. Setelah dikonfigurasi, pembersihan dipicu secara otomatis selama pekerjaan optimisasi penyimpanan DLF. Gunakan intelligent storage tiering untuk memindahkan data partisi yang memenuhi syarat ke kelas penyimpanan berbiaya lebih rendah, atau ubah kelas penyimpanan secara manual pada halaman Table Details. Halaman Storage Overview menampilkan distribusi tiering di seluruh katalog, database, dan tabel.

    Orphan file cleanup

    File yatim adalah file yang ada di bawah path penyimpanan tabel tetapi tidak direferensikan oleh snapshot mana pun. File tersebut biasanya dihasilkan dari pekerjaan penulisan yang terganggu, commit gagal, atau sisa proses pembersihan abnormal. Karena tidak direferensikan oleh snapshot apa pun, kedaluwarsa snapshot tidak dapat menghapusnya, sehingga memerlukan pembersihan berkala.

    Anda dapat memicu pembersihan file yatim secara manual dari console atau mengaktifkan pembersihan otomatis. File yatim yang dibersihkan dipindahkan sementara ke recycle bin (system.trash) dan dihapus setelah periode retensi berakhir.

    Aktifkan atau nonaktifkan optimisasi penyimpanan cerdas

    Catatan

    Tab Storage Optimization hanya muncul untuk tabel Paimon.

    1. Masuk ke DLF console

    2. Pada halaman Catalogs, klik nama katalog.

    3. Pada tab Database, klik nama database target untuk melihat tabelnya.

    4. Dalam daftar Tables, klik nama tabel target untuk melihat informasi skemanya.

    5. Klik tab Storage Optimization. Sakelar optimisasi penyimpanan cerdas diaktifkan secara default. Untuk menonaktifkannya, klik sakelar image.

    Lihat dan konfigurasi strategi optimisasi penyimpanan

    Compaction

    Pada tab Storage Optimization, klik Compaction untuk melihat status eksekusi, catatan rescale, dan riwayat eksekusi.

    Edit mode kebijakan sesuai kebutuhan Anda:

    Mode resource dinamis (direkomendasikan)

    Sistem secara otomatis menskalakan resource komputasi berdasarkan workload real-time, sehingga menghilangkan perencanaan kapasitas manual. Cocok untuk traffic yang fluktuatif.
    Tersedia tiga preferensi konfigurasi:

    • Balanced: Menyeimbangkan kecepatan compaction dan konsumsi resource (default).

    • Low latency: Mengalokasikan lebih banyak resource untuk compaction lebih cepat, sehingga mengurangi delay visibilitas data.

    • Low resource usage: Membatasi penggunaan resource untuk mengurangi biaya komputasi dengan mengorbankan waktu compaction yang lebih lama.

      Alokasi dan penskalaan resource dinamis

      Dalam mode resource dinamis, sistem mengalokasikan resource komputasi berdasarkan workload real-time dan karakteristik data. Faktor-faktor berikut mendorong alokasi resource dan penskalaan otomatis.

      Write throughput
      Traffic penulisan merupakan pendorong utama. Traffic penulisan yang lebih tinggi memicu lebih banyak resource komputasi untuk ingesti data yang stabil.

      Active concurrency
      Jumlah partisi aktif dan bucket menentukan kebutuhan resource. Lebih banyak partisi aktif dan bucket menghasilkan lebih banyak resource pemrosesan paralel.

      Skala data untuk fitur lanjutan
      Tabel dengan fitur lanjutan seperti deletion vectors atau lookup changelog producer meningkatkan kompleksitas komputasi. Ukuran file total yang lebih besar dalam partisi aktif memerlukan lebih banyak resource.

      Karakteristik baris data
      Ukuran baris ekstrem meningkatkan overhead pemrosesan. Baik baris terlalu kecil (banyak nilai null) maupun terlalu besar (bidang string panjang), sistem meningkatkan alokasi resource untuk menjaga performa.

      Optimisasi resource untuk tabel kecil

      Untuk tabel kecil, sistem menggunakan mekanisme berbagi untuk mengurangi overhead resource:

      Saat tabel menggunakan postponed bucketing (bucket = -2) dan mode "Prioritize Latency" tidak diaktifkan, sistem menggabungkan tugas optimisasi dari beberapa tabel kecil ke dalam satu pekerjaan, sehingga mengurangi konsumsi resource secara keseluruhan.

      Pemantauan dan troubleshooting resource

      Untuk menganalisis konsumsi resource, navigasi ke Catalogs > Resource Overview > Resource Requests dan lihat daftar Top Tables by CU-Hours .

      Catatan

      Penggunaan resource yang sangat tinggi untuk satu tabel sering kali disebabkan oleh strategi partisi yang terlalu detail halus, yang meningkatkan jumlah partisi aktif secara konkuren dan memaksa alokasi resource berlebihan. Tinjau dan optimalkan strategi partisi Anda.

    Mode sumber daya tetap

    Tentukan secara manual resource komputasi untuk compaction. Cocok untuk traffic stabil atau kontrol biaya ketat.

    • Persyaratan konfigurasi: Minimum 2 CU.

    • Pengaturan parameter: Sesuaikan interval pemicu compaction dan jumlah bucket.

    Lihat status eksekusi

    Lihat status eksekusi optimisasi untuk tabel saat ini dan konfigurasikan langganan alert CloudMonitor melalui Monitor lakehouse optimization.

    Lihat catatan rescale

    Mencatat event rescaling bucket untuk tabel atau partisi tertentu, mencerminkan perubahan struktur penyimpanan fisik. Rescaling mengatasi masalah performa akibat perubahan volume data. Gunakan catatan ini untuk memeriksa apakah tabel sedang menjalani rescale, yang mencegah compaction.

    Lihat riwayat eksekusi

    Lihat riwayat eksekusi compaction untuk tabel saat ini. Gunakan catatan ini untuk:

    1. Konfirmasi eksekusi tugas: Verifikasi bahwa tugas compaction latar belakang berjalan dengan benar dan mencegah akumulasi file kecil.

    2. Evaluasi efisiensi compaction: Bandingkan jumlah dan ukuran file sebelum dan sesudah compaction untuk menilai efektivitas strategi.

    Expired snapshot cleanup

    Pada tab Storage Optimization, klik Expired Snapshot Cleanup untuk mengonfigurasi aturan pembersihan dan melihat hasilnya.

    • Konfigurasikan aturan pembersihan snapshot

      Klik Modify, atur Snapshot Retention Period (default 1 jam), lalu klik Save.

    • Lihat hasil pembersihan snapshot

      • Jumlah snapshot saat ini: Jumlah snapshot yang tersisa.

      • Informasi snapshot paling awal: Detail snapshot paling awal, termasuk ID snapshot, waktu commit, jenis commit, jumlah baris total, dan baris yang ditambahkan dalam commit tersebut.

    Partition lifecycle management

    Pada tab Storage Optimization, klik Partition Lifecycle untuk mengonfigurasi aturan pembersihan, melihat hasil, dan menyiapkan tiering penyimpanan.

    Aturan pembersihan partisi

    1. Klik sakelar image di samping Expired Partition Cleanup untuk mengaktifkannya.

    2. Konfigurasikan aturan pembersihan berikut, lalu klik Save.

      Anda juga dapat mengonfigurasi pengaturan ini melalui pasangan kunci-nilai opsi tabel.

      Parameter

      Deskripsi

      Expiration Policy

      (partition.expiration-strategy)

      Anda dapat memilih salah satu strategi kedaluwarsa berikut:

      • Berdasarkan waktu akses terakhir (access-time): Menghapus partisi berdasarkan waktu akses terakhirnya.

      • Berdasarkan nilai partisi (values-time): Anda dapat mengonfigurasi format dan pola timestamp partisi.

        • Format timestamp (partition.timestamp-formatter): Anda dapat mengonfigurasi format seperti yyyy-MM-dd, yyyyMdd, dd/MM/yyyy, dan dd.MM.yyyy.

        • Pola timestamp (partition.timestamp-pattern): Secara default, bidang partisi pertama digunakan. Anda dapat mengonfigurasi pola seperti $dt atau $year-$month-$day.

      • Berdasarkan waktu pembaruan terakhir (update-time): Menghapus partisi berdasarkan waktu pembaruan terakhirnya.

      Partition Retention Period

      (partition.expiration-time)

      Unit: hari. Contoh: 30d. Nilai maksimum adalah 999.999 hari. Periode retensi dimulai berdasarkan strategi kedaluwarsa yang dipilih.

    3. (Opsional) Setelah menyimpan, klik Cleanup Rule Settings di samping Modify untuk memodifikasi pengaturan.

    Catatan

    Untuk menyimpan partisi secara permanen, jangan konfigurasi aturan kedaluwarsa. Sistem tidak membersihkan data partisi secara default.

    Hasil pembersihan partisi

    Klik View Partitions untuk melihat daftar partisi, termasuk nama partisi, jumlah baris, file yang direferensikan, ukuran file, pembuat, kelas penyimpanan, terakhir diubah oleh, timestamp, dan aksi.

    Storage tiering

    Parameter

    Deskripsi

    Intelligent Tiering

    imageSaat diaktifkan, sistem secara otomatis melakukan tiering penyimpanan untuk semua tabel dalam katalog berdasarkan aturan siklus hidup yang dikonfigurasi. Tentukan strategi dan aturan sesuai kebutuhan.

    Catatan

    • Jika diaktifkan di tingkat katalog, tabel mewarisi pengaturan tersebut secara default. Modifikasi di tingkat tabel menggantikan pengaturan katalog dan menghapus indikator pewarisan.

    • Jika tidak diaktifkan di tingkat katalog, Anda tetap dapat mengaktifkannya di tingkat tabel.

    Tiering Strategy

    • Last access time: Mengevaluasi aturan berdasarkan waktu akses terakhir data tabel atau partisi.

    • Last update time: Mengevaluasi aturan berdasarkan waktu pembaruan terakhir data tabel atau partisi.

    Tiering Rule

    Persyaratan durasi penyimpanan minimum bervariasi berdasarkan kelas penyimpanan.

    Konfigurasikan aturan tiering:

    • Transisi ke Infrequent Access

      • Ambang batas ketidakaktifan: Kustom. Default adalah 30 hari.

        Data beralih ke penyimpanan Infrequent Access setelah periode ketidakaktifan ini. Mesin komputasi masih dapat mengakses data, tetapi dengan performa yang berkurang.

      • Otomatis ubah kembali ke penyimpanan Standard saat diakses: Mengubah tabel atau partisi kembali ke penyimpanan Standard saat diakses.

        Catatan

        Fitur ini hanya didukung saat strategi tiering diatur ke "Last access time".

    • Transisi ke Archive

      • Ambang batas ketidakaktifan: Kustom. Default adalah 60 hari.

        Data beralih ke penyimpanan Archive setelah periode ketidakaktifan ini. Mesin komputasi tidak dapat mengakses data yang diarsipkan.

      • Otomatis ubah kembali ke penyimpanan Standard saat diakses: Mengubah tabel atau partisi kembali ke penyimpanan Standard saat diakses.

        Catatan

        Fitur ini hanya didukung saat strategi tiering diatur ke "Last access time".

    • Transisi ke Cold Archive

      • Ambang batas ketidakaktifan: Kustom. Default adalah 180 hari.

        Data beralih ke penyimpanan Cold Archive setelah periode ketidakaktifan ini. Mesin komputasi tidak dapat mengakses data yang diarsipkan dingin.

    Catatan

    Selain intelligent storage tiering, Anda dapat mengubah kelas penyimpanan secara manual pada halaman detail tabel. Halaman Storage Overview menampilkan distribusi tiering di seluruh katalog, database, dan tabel.

    Orphan file cleanup

    Pada tab Storage Optimization, klik Orphan file cleanup untuk memicu pembersihan file orphan secara manual.

    Untuk mengaktifkan pembersihan otomatis, tambahkan auto-orphan-files-clean.enabled = true ke konfigurasi katalog. File yatim yang dibersihkan dipindahkan sementara ke recycle bin (system.trash). Sesuaikan berapa lama file tetap berada di recycle bin dengan konfigurasi katalog dlf.trashed-file-retained-days.

    Mengubah kelas penyimpanan secara manual

    1. Dalam daftar Database, klik nama database untuk melihat daftar tabel.

    2. Dalam daftar Tables, klik nama tabel untuk melihat skemanya.

    3. Klik tab Table Details untuk mengubah kelas penyimpanan secara manual untuk tabel partisi dan non-partisi.

      Tabel partisi

      Pada tab Partitions, Anda dapat mengubah kelas penyimpanan untuk partisi.

      • Untuk partisi dalam kelas penyimpanan Standard, Infrequent Access, atau Archive:

        Pada kolom Actions, klik Modify Storage Class untuk mengubah ke kelas penyimpanan lainnya.

      • Untuk partisi dalam kelas penyimpanan Cold Archive:

        Pulihkan data terlebih dahulu, lalu ubah kelas penyimpanan:

        1. Klik Restore dan konfigurasikan Restored Copy Availability Duration. Anda dapat memilih beberapa partisi untuk batch restore.

          • Rentang nilai: Bilangan bulat dari 1 hingga 365 (satuan: hari).

          • Nilai default: 1 hari.

        2. Saat data memasuki restored state, klik Modify Storage Class pada kolom Actions untuk mengubah kelas penyimpanan.

      Tabel non-partisi

      Pada bagian Basic Information tabel, Anda dapat memodifikasi Storage Class.

      • Untuk kelas penyimpanan Standard, Infrequent Access, atau Archive:

        Klik Edit di samping Storage Class untuk mengubah ke kelas penyimpanan lainnya.

      • Untuk kelas penyimpanan Cold Archive:

        Pulihkan data terlebih dahulu, lalu ubah kelas penyimpanan:

        1. Klik Restore di samping Storage Class dan konfigurasikan Restored Copy Availability Duration.

          • Rentang nilai: Bilangan bulat dari 1 hingga 365 (satuan: hari).

          • Nilai default: 1 hari.

        2. Saat Storage Class berubah menjadi Cold Archive (Restored), klik Edit di samping Storage Class. Anda kemudian dapat mengubahnya ke kelas penyimpanan lainnya.

      Catatan

      • Waktu pemulihan: Cold Archive hanya mendukung prioritas pemulihan standar, yang memerlukan waktu 2 hingga 5 jam.

      • Waktu mulai restored state: Saat objek Cold Archive pertama dalam partisi memasuki restored state setelah pemulihan selesai.

      • Restored copy availability duration: Durasi data tetap dapat diakses setelah dipulihkan dari Cold Archive. Setelah kedaluwarsa, partisi kembali ke status beku. Kirim permintaan pemulihan baru untuk mengaksesnya lagi.

      Prosedur pemulihan

      1. Objek dimulai dalam status beku.

      2. Setelah mengirim permintaan pemulihan, objek memasuki status restoring. Waktu pemulihan bervariasi.

      3. Setelah pemulihan selesai, objek memasuki restored state. Untuk tiering penyimpanan di tingkat tabel, partisi menjadi dapat diakses setelah semua objek dipulihkan.

        Perpanjang restored state dengan menyesuaikan restored copy availability duration, hingga batas maksimum yang diizinkan untuk kelas penyimpanan tersebut.

      4. Setelah restored copy availability duration kedaluwarsa, objek kembali ke status beku. Kirim permintaan pemulihan baru untuk mengaksesnya lagi.