Model pemadatan berubah drastis dengan CDH 5/HBase 0,96. Inilah yang perlu Anda ketahui.
Apache HBase adalah penyimpanan data terdistribusi berdasarkan pohon gabungan terstruktur-log, sehingga kinerja baca yang optimal akan datang dari hanya memiliki satu file per toko (Keluarga Kolom). Namun, cita-cita itu tidak mungkin selama periode penulisan masuk yang banyak. Sebagai gantinya, HBase akan mencoba menggabungkan HFiles untuk mengurangi jumlah maksimum pencarian disk yang diperlukan untuk membaca. Proses ini disebut pemadatan .
Pemadatan memilih beberapa file dari satu penyimpanan di suatu wilayah dan menggabungkannya. Proses ini melibatkan membaca Nilai Kunci dalam file input dan menulis Nilai Kunci yang tidak dihapus, berada di dalam time to live (TTL), dan tidak melanggar jumlah versi. File gabungan yang baru dibuat kemudian menggantikan file input di wilayah tersebut.
Sekarang, setiap kali klien meminta data, HBase mengetahui data dari file input disimpan dalam satu file yang berdekatan di disk — maka hanya satu pencarian yang diperlukan, sedangkan sebelumnya satu pencarian untuk setiap file mungkin diperlukan. Tetapi disk IO tidak gratis, dan tanpa perhatian yang cermat, menulis ulang data berulang kali dapat menyebabkan beberapa jaringan yang serius dan langganan disk yang berlebihan. Dengan kata lain, pemadatan adalah tentang memperdagangkan beberapa IO disk sekarang untuk pencarian yang lebih sedikit nanti.
Dalam postingan ini, Anda akan mempelajari lebih lanjut tentang penggunaan dan implikasi pemadatan di CDH 4, serta perubahan model pemadatan di CDH 5 (yang akan didasarkan ulang pada HBase 0.96).
Pemadatan dalam CDH 4
Pemadatan yang ideal akan memilih file yang akan mengurangi pencarian paling banyak dalam pembacaan yang akan datang sementara juga memilih file yang membutuhkan jumlah IO paling sedikit. Sayangnya, masalah itu tidak dapat diselesaikan tanpa pengetahuan tentang masa depan. Karena itu, HBase harus berjuang untuk mencapai cita-cita dan bukan sesuatu yang benar-benar dapat dicapai.
Alih-alih ideal yang tidak mungkin, HBase menggunakan heuristik untuk mencoba dan memilih file mana di toko yang mungkin menjadi kandidat yang baik. File dipilih berdasarkan intuisi bahwa file sejenis harus digabungkan dengan file sejenis – artinya, file yang berukuran hampir sama harus digabungkan.
Kebijakan default dalam HBase 0.94 (pengiriman dalam CDH 4) melihat daftar HFiles, mencoba menemukan file pertama yang memiliki ukuran kurang dari total semua file dikalikan dengan hbase.store.compaction.ratio. Setelah file itu ditemukan, HFile dan semua file dengan id urutan yang lebih kecil dipilih untuk dipadatkan.
Untuk kasus default dari file terbesar menjadi yang tertua, pendekatan ini bekerja dengan baik:
Namun, asumsi tentang korelasi antara usia dan ukuran file ini salah dalam beberapa kasus, menyebabkan algoritma saat ini memilih sub-optimal. Sebaliknya, file yang dimuat secara massal dapat dan kadang-kadang melakukan pengurutan yang sangat berbeda dari HFiles yang lebih normal, jadi mereka membuat contoh yang bagus:
Perubahan Pemadatan di CDH 5
Pemadatan telah berubah secara signifikan baru-baru ini. Untuk HBase 0.96 dan CDH 5, algoritme pemilihan file dibuat dapat dikonfigurasi melalui HBASE-7516— jadi sekarang dimungkinkan untuk memiliki kebijakan pemadatan yang disediakan pengguna. Perubahan ini memungkinkan pengguna yang lebih berpengalaman untuk menguji dan mengulangi bagaimana mereka ingin menjalankan pemadatan.
Algoritme pemilihan pemadatan default juga diubah menjadi ExploringCompactionPolicy. Kebijakan ini berbeda dari default lama karena memastikan bahwa setiap file dalam pemadatan yang diusulkan berada dalam rasio yang diberikan. Selain itu, ia tidak hanya memilih kumpulan file pertama yang memiliki ukuran dalam rasio pemadatan; alih-alih, ia melihat semua rangkaian yang mungkin yang tidak melanggar aturan apa pun, lalu memilih sesuatu yang terlihat paling berdampak untuk jumlah IO yang diharapkan paling sedikit. Untuk melakukannya, ExploringCompactionPolicy memilih pemadatan yang akan menghapus sebagian besar file dalam rasio, dan jika ada ikatan, preferensi diberikan pada kumpulan file yang berukuran lebih kecil:
Lebih banyak perubahan direncanakan untuk rilis mendatang, termasuk pemadatan berjenjang, pemadatan bergaris, dan pemadatan berbasis level.
Kesimpulan
Untuk beberapa kasus penggunaan, pekerjaan ini tidak akan berdampak sama sekali. Itu hal yang baik, karena pemadatan sudah dipelajari dengan cukup baik. Namun, bagi pengguna yang memiliki lonjakan lalu lintas yang besar atau yang menggunakan beban massal, pekerjaan ini dapat menghasilkan peningkatan besar dalam waktu tunggu IO dan dalam latensi permintaan. Untuk kasus penggunaan beban massal tertentu, kami telah melihat pengurangan 90% pada IO disk karena pemadatan.
Berikut adalah hasil dari kasus uji di PerfTestCompactionPolicies HBase:
Lihat karya ini di CDH 5 (dalam versi beta pada saat penulisan ini) tentang cluster di dekat Anda.
Bacaan Lebih Lanjut:
- Menjelajahi Kebijakan Pemadatan
- https://hbase.apache.org/book/regions.arch.html#compaction.file.selection
- https://issues.apache.org/jira/browse/HBASE-7516
- https://issues.apache.org/jira/browse/HBASE-7678
- https://issues.apache.org/jira/browse/HBASE-7667
- https://issues.apache.org/jira/browse/HBASE-7055
- http://www.hbasecon.com/sessions/compaction-improvements-in-apache-hbase/
