全部产品
Search
文档中心

Data Lake Formation:Optimasi penyimpanan

更新时间:Feb 11, 2026

Data Lake Formation (DLF) menyediakan fitur optimasi penyimpanan seperti kompaksi adaptif tingkat tabel, pembersihan snapshot kedaluwarsa, manajemen siklus hidup partisi, dan pembersihan file yatim. Fitur-fitur ini menyederhanakan penggunaan dan pemeliharaan tabel Paimon serta meningkatkan efisiensi komputasi dan penyimpanan. Topik ini menjelaskan kebijakan optimasi penyimpanan cerdas yang dijalankan DLF di latar belakang beserta mekanisme eksekusinya.

Penting

Tabel Iceberg tidak secara otomatis mereklaim storage. Untuk mencegah biaya penyimpanan meningkat, Anda harus membersihkan snapshot kedaluwarsa dan file yatim secara manual. Untuk informasi selengkapnya, lihat Iceberg Table Storage Administration.

Strategi optimasi penyimpanan

Jenis kebijakan

Deskripsi

Mekanisme eksekusi DLF

Compaction

Fitur compaction menggabungkan file-file kecil menjadi file yang lebih besar. Hal ini mengurangi jumlah file, sehingga menurunkan overhead manajemen metadata dan biaya pencarian file saat kueri. Ini meningkatkan performa dan efisiensi kueri pada tabel Paimon.

DLF secara otomatis memicu compaction ketika Anda melakukan commit penulisan data.

Expired snapshot cleanup

Selama snapshot masih ada, file data yang direferensikannya tidak dapat dihapus. Hal ini memastikan bahwa status historis data tetap dapat dibaca. Seiring pembuatan snapshot baru, ruang penyimpanan yang dikonsumsi oleh data historis meningkat. Anda harus menghapus snapshot lama untuk melepaskan ruang yang ditempati oleh data historis yang tidak aktif. Ini membantu Anda mengelola dan membebaskan resource penyimpanan.

DLF secara otomatis memicu pembersihan snapshot saat pekerjaan optimasi penyimpanan DLF berjalan. Waktu kedaluwarsa default untuk snapshot adalah 1 jam. Anda dapat menyesuaikan waktu kedaluwarsa tersebut menggunakan parameter tabel Paimon. Untuk informasi selengkapnya, lihat Clean up expired data.

Partition lifecycle management

Banyak skenario bisnis hanya memerlukan akses ke data terbaru. Dalam kasus ini, Anda dapat mempartisi data berdasarkan waktu dan menetapkan waktu kedaluwarsa partisi untuk menghapus partisi historis lama secara otomatis. Hal ini 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. Ini mengurangi biaya penyimpanan sekaligus memenuhi kebutuhan bisnis.

Anda dapat mengonfigurasi waktu kedaluwarsa menggunakan parameter tabel Paimon. Untuk informasi selengkapnya, lihat Set partition expiration time. Setelah Anda mengonfigurasi parameter tersebut, proses ini akan dipicu secara otomatis saat pekerjaan optimasi penyimpanan DLF berjalan. Anda juga dapat menggunakan fitur Intelligent storage tiering untuk secara otomatis memindahkan data partisi yang memenuhi kriteria tertentu ke kelas penyimpanan seperti Standard, Infrequent Access, Archive, atau Cold Archive. Anda juga dapat mengubah kelas penyimpanan secara manual pada halaman detail tabel. Pada halaman Storage overview, Anda dapat melihat distribusi tiering penyimpanan untuk katalog data, database, dan tabel.

Orphan file cleanup

Karena error job, restart, atau masalah lainnya, beberapa file temporary yang belum dikomit mungkin tersisa di direktori tabel Paimon. File yatim ini tidak direferensikan oleh snapshot mana pun dan tidak dapat dihapus oleh mekanisme kedaluwarsa snapshot. File-file ini perlu dibersihkan secara berkala.

Periode retensi default untuk file yatim adalah 7 hari. File yatim yang lebih tua dari periode ini dianggap kedaluwarsa dan secara otomatis dibersihkan. DLF memicu tugas pembersihan setiap 7 hari.

Aktifkan atau nonaktifkan optimasi penyimpanan cerdas

Catatan

Tab Storage Optimization hanya ditampilkan saat Anda membuat tabel Paimon.

  1. Masuk ke Konsol Data Lake Formation.

  2. Pada halaman daftar Data Catalog, klik nama katalog.

  3. Pada tab Databases, klik nama database tujuan untuk melihat tabel data.

  4. Pada Table List, klik sebuah tabel untuk melihat informasi kolomnya.

  5. Klik tab Storage Optimization. Sakelar optimasi penyimpanan cerdas diaktifkan secara default. Klik sakelar image untuk menonaktifkannya.

Lihat dan konfigurasi strategi optimasi penyimpanan

Compaction

Pada tab Storage Optimization, klik Compaction. Anda dapat melihat status eksekusi penggabungan file kecil, catatan Rescale, dan riwayat eksekusi.

Edit pola kebijakan sesuai kebutuhan:

Pola resource dinamis (Direkomendasikan)

Sistem secara otomatis menskalakan resource komputasi berdasarkan beban real-time. Pola ini tidak memerlukan perencanaan kapasitas manual dan cocok untuk skenario dengan trafik yang fluktuatif.
Tiga preferensi konfigurasi didukung:

  • Balanced resource and latency: Menyeimbangkan antara kecepatan merge dan konsumsi resource (default).

  • Latency first: Mengalokasikan lebih banyak resource untuk menyelesaikan merge lebih cepat dan mengurangi latensi visibilitas data.

  • Resource first: Membatasi penggunaan resource untuk mengurangi biaya komputasi, yang dapat mengakibatkan waktu merge lebih lama.

    Kebijakan alokasi dan skalabilitas resource dinamis

    Pada pola resource dinamis, sistem secara otomatis mengalokasikan resource komputasi untuk tabel primary key berdasarkan beban real-time dan karakteristik data. Jumlah resource yang dialokasikan ditentukan oleh faktor inti berikut dan memicu skalabilitas otomatis bila diperlukan.

    Write throughput
    Trafik penulisan merupakan pendorong utama alokasi resource. Trafik penulisan yang lebih tinggi menghasilkan alokasi resource komputasi yang lebih banyak untuk memastikan ingesti data yang stabil.

    Active concurrency
    Jumlah partisi aktif dan bucket secara langsung menentukan kebutuhan resource. Semakin banyak partisi aktif dan bucket, semakin banyak resource pemrosesan paralel yang dialokasikan sistem.

    Data volume for advanced features
    Ketika sebuah tabel memiliki deletion vectors atau lookup changelog producer yang diaktifkan, kompleksitas komputasi meningkat. Dalam kasus ini, semakin besar ukuran total file dalam partisi aktif, semakin banyak resource yang dialokasikan sistem.

    Data row features
    Ukuran ekstrem pada baris tunggal meningkatkan overhead pemrosesan. Baik baris yang terlalu kecil (berisi banyak nilai null) maupun terlalu besar (berisi field string sangat panjang), sistem meningkatkan alokasi resource untuk mempertahankan performa pemrosesan.

    Kebijakan optimasi resource untuk tabel kecil

    Untuk tabel data berskala kecil, sistem menggunakan mekanisme sharing untuk mengurangi overhead resource:

    Ketika sebuah tabel dikonfigurasi untuk adaptive bucketing (bucket = -2) dan mode "Latency first" tidak diaktifkan, sistem menggabungkan tugas optimasi dari beberapa tabel kecil ke dalam satu job. Mekanisme sharing multi-tabel ini secara signifikan mengurangi penggunaan resource keseluruhan.

    Pemantauan dan troubleshooting resource

    Untuk menganalisis konsumsi resource, buka Data Catalog > Resource Overview > Resource Request Metric Details dan lihat daftar CU * Hours Top Tables.

    Catatan

    Jika satu tabel menunjukkan penggunaan resource yang tidak biasa tinggi, sering kali disebabkan oleh granularitas partisi yang terlalu detail. Kebijakan partisi detail halus dapat menyebabkan lonjakan jumlah partisi aktif konkuren, memaksa sistem mengalokasikan banyak resource. Periksa dan optimalkan kebijakan partisi tersebut.

Pola sumber daya tetap

Tentukan secara manual jumlah resource komputasi untuk compaction. Pola ini cocok untuk skenario dengan trafik stabil atau persyaratan kontrol biaya yang ketat.

  • Persyaratan konfigurasi: 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 tabel saat ini dan mengonfigurasi langganan alert kustom di Cloud Monitor. Untuk informasi lebih lanjut tentang metrik dan langkah konfigurasi, lihat Lakehouse table optimization monitoring.

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. Anda dapat menggunakan catatan Rescale untuk menentukan apakah suatu tabel tidak memasuki proses compaction karena sedang dalam proses rescale.

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. Gunakan catatan ini untuk:

  1. Konfirmasi eksekusi tugas: Pastikan tugas merge latar belakang berjalan dengan benar untuk mencegah akumulasi tak terbatas file kecil.

  2. Evaluasi efisiensi kompresi: Bandingkan jumlah file dan ukurannya sebelum dan sesudah penggabungan untuk menentukan apakah strategi compaction saat ini sesuai.

Expired snapshot cleanup

Pada 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 untuk menyelesaikan konfigurasi.

  • Lihat hasil pembersihan snapshot

    • Jumlah Snapshot Saat Ini: Menampilkan jumlah snapshot yang tersisa secara real-time.

    • Informasi Snapshot Terlama: Menampilkan detail snapshot tabel terlama, termasuk ID snapshot, waktu commit, jenis commit, total baris tabel, dan baris yang ditambahkan dalam commit ini.

Partition lifecycle management

Pada tab Storage Optimization, klik Partition LifeCycle. Anda dapat mengonfigurasi aturan pembersihan partisi, melihat hasil pembersihan partisi, dan mengonfigurasi tiering penyimpanan.

Konfigurasi aturan pembersihan partisi

  1. Anda dapat mengklik sakelar image di sisi kanan Enable Partition Cleanup untuk mengaktifkan pembersihan partisi.

  2. Setelah mengaktifkan pembersihan partisi, konfigurasikan aturan berikut sesuai kebutuhan. Klik Save untuk menyelesaikan konfigurasi.

    Anda dapat menyelesaikan konfigurasi dengan mengatur pasangan kunci-nilai opsi tabel yang sesuai.

    Item konfigurasi

    Deskripsi

    Expiration Policy

    (partition.expiration-strategy)

    Anda dapat memilih salah satu kebijakan kedaluwarsa berikut:

    • Last access time (access-time): Menentukan kedaluwarsa berdasarkan waktu akses terakhir data partisi.

    • Partition value (values-time): Anda dapat mengonfigurasi format timestamp partisi dan pola field partisi.

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

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

    • Last update time (update-time): Menentukan kedaluwarsa berdasarkan waktu pembaruan terakhir data partisi pada granularitas terkecil.

    Partition Retention Period

    (partition.expiration-time)

    Unit: hari. Anda dapat mengonfigurasi nilai seperti 30d. Nilai maksimum adalah 999.999 hari. Waktu mulai periode retensi ditentukan oleh kebijakan kedaluwarsa yang dipilih.

  3. (Opsional) Setelah menyimpan, Anda juga dapat mengklik Edit di samping Rule Configuration untuk melakukan perubahan.

Catatan

Jika Anda ingin menyimpan partisi secara permanen, jangan konfigurasi aturan kedaluwarsa partisi. Secara default, sistem tidak secara otomatis membersihkan data partisi.

Lihat hasil pembersihan partisi

Klik View Partitions untuk melihat daftar partisi tabel saat ini. Daftar ini mencakup nama partisi, jumlah baris (fisik), jumlah file yang direferensikan, ukuran total file, pembuat, kelas penyimpanan, pembaruan terakhir, waktu pembuatan, waktu pembaruan terakhir, dan operasi.

Konfigurasi tiering penyimpanan

Item konfigurasi

Deskripsi

Intelligent Tiering

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

Catatan
  • Jika 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 memodifikasi 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 Strategy

  • 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:

  • Transition to Infrequent Access

    • Inactivity Threshold: Kustom. Default adalah 30 hari.

      Data secara otomatis dipindahkan ke penyimpanan IA jika waktu akses terakhirnya melebihi jumlah hari ini. Penyimpanan IA masih dapat diakses oleh mesin komputasi, tetapi dengan performa yang berkurang.

    • Convert to Standard Storage Upon Access: Jika Anda memilih opsi ini, sistem secara otomatis memindahkan partisi atau tabel non-partisi ke kelas penyimpanan Standard saat diakses.

      Catatan

      Fitur ini hanya didukung ketika strategi tiering berdasarkan "Last Access Time".

  • Transition to Archive

    • Number of Days: Dapat dikustomisasi. Nilai default adalah 60 hari.

      Data secara otomatis dipindahkan ke Archive Storage jika waktu akses terakhirnya melebihi jumlah hari ini. Data dalam Archive Storage tidak dapat diakses oleh mesin komputasi.

    • Convert to Standard Storage Upon Access: Jika Anda memilih opsi ini, sistem secara otomatis memindahkan partisi atau tabel non-partisi ke kelas penyimpanan Standard saat diakses.

      Catatan

      Fitur ini hanya didukung ketika kebijakan tiering berdasarkan "Last Access Time".

  • Transition to Cold Archive

    • Inactivity Threshold: Kustom. Default adalah 180 hari.

      Data secara otomatis dipindahkan ke penyimpanan Cold Archive jika waktu akses terakhirnya melebihi jumlah hari ini. Data dalam penyimpanan Cold Archive tidak dapat diakses oleh mesin komputasi.

Catatan

Selain menggunakan fitur Intelligent storage tiering, Anda juga dapat mengubah kelas penyimpanan secara manual pada halaman detail tabel. Anda juga dapat melihat distribusi tiering penyimpanan untuk katalog data, database, dan tabel pada halaman Storage overview.

Orphan file cleanup

Pada 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. File yatim kedaluwarsa yang lebih tua dari periode ini secara otomatis dibersihkan oleh sistem.

Mengubah kelas penyimpanan secara manual

  1. Pada daftar Databases, klik nama database untuk melihat daftar tabel.

  2. Pada daftar Tables, klik nama tabel untuk melihat kolom tabel.

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

    Tabel partisi

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

    • Partisi dalam kelas penyimpanan Standard, Infrequent Access, atau Archive:

      Pada kolom Actions, klik Modify Storage Class. Anda dapat mengubah kelas penyimpanan ke kelas apa pun selain yang saat ini digunakan.

    • Partisi dalam kelas penyimpanan Cold Archive:

      Anda harus terlebih dahulu memulihkan data. Setelah pemulihan selesai dan status berubah menjadi restored, Anda dapat mengubah kelas penyimpanan. Lakukan langkah-langkah berikut:

      1. Klik Restore. Konfigurasikan Restored state duration. Anda dapat memilih partisi untuk batch restoration.

        • Rentang nilai: 1 hingga 365. Satuan: hari.

        • Nilai default: 1 hari.

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

    Tabel non-partisi

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

    • Kelas penyimpanan Standard, Infrequent Access, atau Archive

      Klik Edit di samping Storage Class. Anda dapat mengubah kelas penyimpanan ke kelas apa pun selain yang saat ini digunakan.

    • Kelas penyimpanan Cold Archive

      Anda harus terlebih dahulu memulihkan data. Setelah pemulihan selesai dan status berubah menjadi restored, Anda dapat mengubah kelas penyimpanan. Lakukan langkah-langkah berikut:

      1. Klik Restore di samping Storage Class. Konfigurasikan Restored state duration.

        • Rentang nilai: 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: Waktu yang diperlukan untuk memulihkan objek. Kelas penyimpanan Cold Archive hanya mendukung prioritas pemulihan Standard, dan proses pemulihan memerlukan waktu 2 hingga 5 jam.

    • Waktu mulai status restored: Waktu saat objek Cold Archive pertama dalam partisi memasuki status restored setelah operasi pemulihan selesai.

    • Durasi status restored: Periode validitas data tetap dalam status restored setelah objek Cold Archive pertama dalam partisi dipulihkan. Setelah semua objek dalam partisi dipulihkan, Anda dapat membaca, menulis, atau mengubah kelas penyimpanan partisi tersebut. Ketika durasi status restored berakhir, data dalam partisi kembali ke status Cold Archive dan tidak dapat diakses secara langsung. Untuk melakukan operasi pada data tersebut, Anda harus memulihkannya lagi.

    Prosedur pemulihan

    1. Awalnya, objek berada dalam status beku.

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

    3. Setelah server menyelesaikan tugas pemulihan, objek memasuki status restored. Untuk tiering penyimpanan tingkat tabel, partisi dapat diakses secara normal setelah semua objek di dalamnya dipulihkan.

      Anda dapat memperpanjang durasi status restored dengan menyesuaikan durasi status restored partisi. Namun, durasi total tidak boleh melebihi batas maksimum untuk kelas penyimpanan tersebut.

    4. Setelah durasi status restored berakhir, objek kembali ke status beku tanpa mengubah kelas penyimpanan aslinya. Untuk mengakses data lagi, Anda harus mengirim permintaan pemulihan baru dan menunggu pemulihan selesai.