Mengatasi masalah retensi data (TTL) terkait dengan data kedaluwarsa yang tidak terhapus dari penyimpanan di Azure HDInsight

2025-04-02

Di kluster HBase, Anda dapat memutuskan bahwa Anda ingin menghapus data setelah tersimpan lama untuk mengosongkan penyimpanan dan menghemat biaya karena data yang lebih lama tidak lagi diperlukan, atau untuk mematuhi peraturan. Saat diperlukan, Anda perlu mengatur TTL dalam tabel di tingkat ColumnFamily untuk kedaluwarsa dan menghapus data yang lebih lama secara otomatis. Meskipun TTL juga dapat diatur pada tingkat sel, mengaturnya di tingkat ColumnFamily biasanya merupakan opsi yang lebih nyaman karena kemudahan administrasi dan karena TTL sel (dinyatakan dalam ms) tidak dapat memperpanjang masa pakai efektif sel di luar pengaturan TTL tingkat ColumnFamily (dinyatakan dalam detik), sehingga hanya diperlukan waktu retensi yang lebih singkat pada tingkat sel yang dapat memanfaatkan pengaturan tingkat sel TTL.

Meskipun mengatur TTL, Terkadang Anda mungkin melihat bahwa Anda tidak mendapatkan efek yang diinginkan, yaitu, beberapa data belum kedaluwarsa dan/atau ukuran penyimpanan belum berkurang.

Prasyarat

Ikuti langkah-langkah dan perintah yang diberikan, buka dua koneksi ssh ke kluster HBase:

Pada salah satu sesi ssh, tetap menggunakan shell bash default.
Dalam sesi ssh kedua luncurkan shell HBase dengan menjalankan, perintah berikut.
```
hbase shell
```

Periksa apakah TTL yang diinginkan dikonfigurasi dan apakah data kedaluwarsa dihapus dari hasil kueri

Ikuti langkah-langkah yang diberikan untuk memahami di mana masalahnya. Mulailah dengan memeriksa apakah perilaku terjadi untuk tabel tertentu atau untuk semua tabel. Jika Anda tidak yakin apakah masalah berdampak pada semua tabel atau hanya tabel tertentu, pertimbangkan nama tabel tertentu untuk permulaan sebagai contoh.

Periksa terlebih dahulu apakah TTL telah dikonfigurasi untuk ColumnFamily untuk tabel target. Jalankan perintah berikut dalam sesi ssh tempat Anda meluncurkan shell HBase dan mengamati output. Satu keluarga kolom memiliki TTL yang diatur ke 50 detik, ColumnFamily lainnya tidak memiliki nilai yang dikonfigurasi untuk TTL, sehingga muncul sebagai "FOREVER" (data dalam keluarga kolom ini tidak dikonfigurasi untuk kedaluwarsa).
```
describe 'table_name'
```
Jika tidak dikonfigurasi, TTL default diatur ke 'FOREVER.' Ada dua kemungkinan alasan data tidak kedaluwarsa seperti yang diharapkan dan dihapus dari hasil kueri.
1. Jika TTL memiliki nilai selain 'FOREVER', amati nilai untuk keluarga kolom dan catat nilainya dalam hitungan detik (berikan perhatian khusus pada nilai yang berkaitan dengan satuan ukuran karena TTL sel berada dalam ms, tetapi TTL keluarga kolom dalam detik) untuk memastikan apakah itu adalah nilai yang diharapkan. Jika nilai yang diamati tidak benar, perbaiki terlebih dahulu.
2. Jika nilai TTL adalah 'FOREVER' untuk semua keluarga kolom, konfigurasikan TTL sebagai langkah pertama dan setelahnya pantau apakah data kedaluwarsa seperti yang diharapkan.
Jika Anda menetapkan bahwa TTL dikonfigurasi dan memiliki nilai yang benar untuk ColumnFamily, langkah selanjutnya adalah mengonfirmasi bahwa data yang kedaluwarsa tidak lagi muncul saat melakukan pemindaian tabel. Ketika kedaluwarsa, data seharusnya dihapus dan tidak muncul dalam hasil tabel pemindaian. Jalankan perintah di bawah ini di shell HBase untuk memeriksa.
```
scan 'table_name'
```

Periksa jumlah dan ukuran StoreFiles per tabel per wilayah untuk mengamati apakah ada perubahan yang terlihat setelah operasi pemadatan

Sebelum melanjutkan ke tahap selanjutnya, dari sesi SSH di shell bash, jalankan perintah berikut untuk memeriksa jumlah StoreFiles dan ukuran saat ini untuk setiap StoreFile yang saat ini muncul untuk ColumnFamily dimana TTL telah dikonfigurasi. Perhatikan terlebih dahulu tabel dan ColumnFamily tempat Anda melakukan pemeriksaan, lalu jalankan perintah berikut dalam sesi ssh (bash).
```
hdfs dfs -ls -R /hbase/data/default/table_name/ | grep "column_family_name"
```
Kemungkinan, ada lebih banyak hasil yang ditampilkan dalam output, satu hasil untuk setiap ID wilayah yang merupakan bagian dari tabel dan antara 0 dan lebih hasil untuk StoreFiles yang ada di bawah setiap nama wilayah, untuk ColumnFamily yang dipilih. Untuk menghitung jumlah keseluruhan baris dalam output hasil di atas, jalankan perintah berikut.
```
hdfs dfs -ls -R /hbase/data/default/table_name/ | grep "column_family_name" | wc -l
```

Periksa jumlah dan ukuran StoreFiles per tabel per wilayah setelah flush

Berdasarkan TTL yang dikonfigurasi untuk setiap ColumnFamily dan seberapa banyak data yang ditulis ke dalam tabel untuk target ColumnFamily, sebagian data mungkin masih ada di MemStore dan belum ditulis sebagai StoreFile ke penyimpanan. Dengan demikian, untuk memastikan bahwa data ditulis ke penyimpanan sebagai StoreFile, sebelum ukuran MemStore maksimum yang dikonfigurasi tercapai, Anda dapat menjalankan perintah berikut di shell HBase untuk segera menulis data dari MemStore ke StoreFile.
```
flush 'table_name'
```

Amati hasilnya dengan menjalankan lagi di shell bash perintah.

hdfs dfs -ls -R /hbase/data/default/table_name/ | grep "column_family_name"

File penyimpanan tambahan dibuat dibandingkan dengan output hasil sebelumnya untuk setiap wilayah tempat data dimodifikasi, StoreFile menyertakan konten MemStore saat ini untuk wilayah tersebut.

Periksa jumlah dan ukuran StoreFiles per tabel per wilayah setelah pemadatan besar

Pada titik ini, data dari MemStore telah ditulis ke StoreFile, dalam penyimpanan, tetapi data kedaluwarsa mungkin masih ada di satu atau beberapa StoreFiles saat ini. Meskipun pemadatan kecil dapat membantu menghapus beberapa entri yang kedaluwarsa, tidak dijamin bahwa itu menghapus semuanya sebagai pemadatan kecil. Ini tidak memilih semua StoreFiles untuk pemadatan, sedangkan pemadatan besar memilih semua StoreFiles untuk pemadatan di wilayah tersebut.

Selain itu, ada situasi lain ketika pemadatan kecil mungkin tidak menghapus sel dengan TTL yang kedaluwarsa. Ada properti bernama MIN_VERSIONS dan defaultnya hanya 0 (lihat pada output di atas dari jelaskan 'table_name' properti MIN_VERSIONS=>'0'). Jika properti ini diatur ke 0, pemadatan kecil akan menghapus sel dengan TTL kedaluwarsa. Jika nilai ini lebih besar dari 0, pemadatan minor mungkin tidak menghapus sel dengan TTL yang kedaluwarsa bahkan jika menyentuh file yang bersangkutan selama pemadatan. Properti ini mengonfigurasi jumlah minimum versi sel yang akan disimpan, meskipun versi tersebut memiliki TTL yang kedaluwarsa.
Untuk memastikan data yang kedaluwarsa juga dihapus dari penyimpanan, kita perlu menjalankan operasi pemadatan besar. Ketika operasi pemadatan utama selesai, operasi tersebut meninggalkan satu StoreFile per wilayah. Di shell HBase, jalankan perintah untuk menjalankan operasi pemadatan besar pada tabel:
```
major_compact 'table_name'
```
Tergantung pada ukuran tabel, operasi pemadatan utama dapat memakan waktu. Gunakan perintah berikut di shell HBase untuk memantau kemajuan. Jika pemadatan masih berjalan saat Anda menjalankan perintah berikut, Anda mendapatkan output sebagai "MAJOR", tetapi jika pemadatan selesai, Anda mendapatkan output sebagai "NONE."
```
compaction_state 'table_name'
```
Saat status pemadatan muncul sebagai "NONE" di hbase shell, segera beralih ke bash dan jalankan perintah.
```
hdfs dfs -ls -R /hbase/data/default/table_name/ | grep "column_family_name"
```
Perhatikan bahwa StoreFile tambahan telah dibuat selain yang sebelumnya per wilayah per ColumnFamily, dan setelah beberapa saat, hanya StoreFile terakhir yang dibuat yang disimpan per wilayah per ColumnFamily.

Untuk contoh wilayah di atas, setelah momen tambahan berlalu, kita dapat melihat bahwa satu StoreFile tunggal tetap ada. Selain itu, ukuran yang ditempati oleh file ini pada penyimpanan berkurang karena pemadatan signifikan. Pada titik ini, data kedaluwarsa apa pun yang belum dihapus sebelumnya (oleh pemadatan utama lainnya), segera dihapus setelah operasi pemadatan utama saat ini berjalan.

Cuplikan layar memperlihatkan data kedaluwarsa tidak dihapus.

Catatan

Untuk latihan pemecahan masalah ini, Anda memicu pemadatan utama secara manual. Tetapi dalam praktiknya, melakukan itu secara manual untuk banyak tabel memakan waktu. Secara bawaan, kompaktasi utama dinonaktifkan pada kluster HDInsight. Alasan utama menjaga pemadatan utama dinonaktifkan secara default adalah karena kinerja operasi tabel terdampak saat pemadatan utama berlangsung. Namun, Anda dapat mengaktifkan pemadatan utama dengan mengonfigurasi nilai untuk properti hbase.hregion.majorcompaction dalam ms atau dapat menggunakan pekerjaan tab cron atau sistem eksternal lain untuk menjadwalkan pemadatan pada waktu yang nyaman bagi Anda, dengan beban kerja yang lebih rendah.

Langkah berikutnya

Jika Anda tidak melihat masalah atau tidak dapat memecahkan masalah, kunjungi salah satu saluran berikut untuk mendapatkan dukungan lebih lanjut:

Dapatkan jawaban dari para ahli Azure melalui Dukungan Komunitas Azure.
Hubungi @AzureSupport - akun Microsoft Azure resmi untuk meningkatkan pengalaman pelanggan. Menghubungkan komunitas Azure ke sumber daya yang tepat: answers, , supportdan experts.
Jika Anda memerlukan bantuan lainnya, Anda dapat mengirimkan permintaan dukungan dari portal Microsoft Azure. Pilih Dukungan dari bilah menu atau buka hub Bantuan + Dukungan. Untuk informasi selengkapnya, tinjau Cara membuat permintaan dukungan Microsoft Azure. Akses ke Manajemen Langganan dan dukungan tagihan disertakan dengan langganan Microsoft Azure, dan Dukungan Teknis disediakan melalui salah satu Paket Dukungan Azure.