All Products
Search

This Product

    Data Lake Formation:Optimasi penyimpanan otomatis tabel Paimon

    Document Center

    Data Lake Formation:Optimasi penyimpanan otomatis tabel Paimon

    Last Updated:Jul 18, 2026

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

    Strategi optimasi 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 job optimasi penyimpanan. Waktu kedaluwarsa default adalah satu jam dan dapat disesuaikan melalui parameter tabel Paimon. Untuk informasi lebih lanjut, lihat Clean up expired data.

    Partition lifecycle management

    Banyak skenario hanya memerlukan data terbaru. Partisi data berdasarkan waktu dan tetapkan aturan kedaluwarsa untuk menghapus partisi lama secara otomatis 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 Set partition expiration time. Setelah dikonfigurasi, pembersihan dipicu secara otomatis selama job optimasi penyimpanan DLF. Gunakan intelligent storage tiering untuk memindahkan data partisi yang memenuhi syarat ke kelas penyimpanan berbiaya lebih rendah, atau manually change the storage class 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 ini biasanya dihasilkan dari job penulisan yang terganggu, commit yang gagal, atau sisa proses pembersihan abnormal. Karena tidak direferensikan oleh snapshot, kedaluwarsa snapshot tidak dapat menghapusnya sehingga memerlukan pembersihan berkala.

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

    Aktifkan atau nonaktifkan optimasi 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 optimasi penyimpanan cerdas diaktifkan secara default. Untuk menonaktifkannya, klik sakelar image tersebut.

    Lihat dan konfigurasi strategi optimasi 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, 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 (field string panjang), sistem meningkatkan alokasi resource untuk menjaga performa.



      Optimasi 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 optimasi dari beberapa tabel kecil ke dalam satu job sehingga mengurangi konsumsi resource secara keseluruhan.

      Pemantauan dan troubleshooting resource

      Untuk menganalisis konsumsi resource, navigasikan 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 resource 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 optimasi 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.

    • Konfigurasi 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, field 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, yang terakhir memodifikasi, 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:

    • Transition to Infrequent Access

      • Inactivity threshold: Kustom. Default adalah 30 hari.

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

      • Automatically convert to Standard storage upon access: Mengonversi tabel atau partisi kembali ke penyimpanan Standard saat diakses.

        Catatan

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

    • Transition to Archive

      • Inactivity threshold: Kustom. Default adalah 60 hari.

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

      • Automatically Convert to Standard Storage upon Access: Mengonversi tabel atau partisi kembali ke penyimpanan Standard saat diakses.

        Catatan

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

    • Transition to Cold Archive

      • Inactivity threshold: Kustom. Default adalah 180 hari.

        Data berpindah ke penyimpanan Cold Archive setelah periode inaktivitas ini. Mesin komputasi tidak dapat mengakses data arsip dingin.
    Catatan

    Selain intelligent storage tiering, Anda dapat manually change the storage class 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 yatim 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). Atur berapa lama file tetap berada di recycle bin dengan konfigurasi katalog dlf.trashed-file-retained-days.

    Ubah 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.

      • Durasi ketersediaan salinan yang dipulihkan: Berapa lama 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 durasi ketersediaan salinan yang dipulihkan, hingga batas maksimum yang diizinkan untuk kelas penyimpanan tersebut.

      4. Setelah durasi ketersediaan salinan yang dipulihkan berakhir, objek kembali ke status beku. Kirim permintaan pemulihan baru untuk mengaksesnya lagi.