Advisori Apache HBase di Azure HDInsight
Artikel ini menjelaskan beberapa saran untuk membantu Anda mengoptimalkan kinerja Apache HBase di Azure HDInsight.
Optimalkan HBase untuk membaca data tertulis terbaru
Jika kasus penggunaan Anda melibatkan pembacaan data tertulis terbaru dari HBase, nasihat ini dapat membantu Anda. Untuk performa tinggi, optimal bahwa bacaan HBase harus dilayani dari memstore
, bukan penyimpanan jarak jauh.
Saran kueri menunjukkan bahwa untuk keluarga kolom tertentu dalam tabel > 75% bacaan yang dilayani dari memstore
. Indikator ini menunjukkan bahwa bahkan jika flush terjadi pada memstore
file terbaru perlu diakses dan yang perlu berada di cache. Data pertama kali ditulis ke memstore
sistem mengakses data terbaru di sana. Ada kemungkinan bahwa rangkaian flusher HBase internal mendeteksi bahwa wilayah tertentu telah mencapai ukuran 128M (default) dan dapat memicu flush. Skenario ini bahkan terjadi pada data terbaru yang ditulis ketika berukuran memstore
sekitar 128M. Oleh karena itu, bacaan selanjutnya dari rekaman terbaru tersebut mungkin memerlukan file yang dibaca daripada dari memstore
. Karenanya yang terbaik adalah mengoptimalkan bahwa bahkan data terbaru yang baru-baru ini dihapus dapat berada di cache.
Untuk mengoptimalkan data terbaru di cache, pertimbangkan pengaturan konfigurasi berikut:
Set
hbase.rs.cacheblocksonwrite
ketrue
. Konfigurasi default ini di HDInsight HBase adalahtrue
, jadi periksa apakah itu tidak diatur ulang kefalse
.Tingkatkan nilai
hbase.hstore.compactionThreshold
sehingga Anda dapat menghindari pemadatan dari menendang pada. Secara default nilai ini adalah3
. Anda dapat meningkatkannya ke nilai yang lebih tinggi seperti10
.Jika Anda mengikuti langkah 2 dan set ambang batas pemadatan, lalu ubah
hbase.hstore.compaction.max
ke nilai yang lebih tinggi misalnya100
, dan juga tingkatkan nilai untuk konfigurasi ke nilaihbase.hstore.blockingStoreFiles
yang lebih tinggi misalnya300
.Jika Anda yakin bahwa Anda hanya perlu membaca data terbaru, set konfigurasi
hbase.rs.cachecompactedblocksonwrite
ke ON. Konfigurasi ini memberi tahu sistem bahwa bahkan jika pemadatan terjadi, data tetap berada di cache. Konfigurasi dapat diatur di tingkat keluarga juga.Di HBase Shell, jalankan perintah berikut untuk
hbase.rs.cachecompactedblocksonwrite
mengatur konfigurasi:alter '<TableName>', {NAME => '<FamilyName>', CONFIGURATION => {'hbase.hstore.blockingStoreFiles' => '300'}}
Cache blokir dapat dinonaktifkan untuk keluarga tertentu dalam tabel. Pastikan dalam keadaan AKTIF untuk keluarga yang memiliki pembacaan data terbaru. Secara default, cache blokir diaktifkan untuk semua keluarga dalam tabel. Jika Anda telah menonaktifkan cache blok untuk keluarga dan perlu mengaktifkannya, gunakan perintah alter dari shell hbase.
Konfigurasi ini membantu memastikan bahwa data tersedia dalam cache dan bahwa data terbaru tidak mengalami pemadatan. Jika TTL dimungkinkan dalam skenario Anda, pertimbangkan untuk menggunakan pemadatan log tingkat tanggal. Untuk informasi selengkapnya, lihat Panduan Referensi Apache HBase: Pemadatan Tingkat Tanggal
Optimalkan antrean flush
Nasihat ini menunjukkan bahwa flush HBase mungkin perlu disetel. Konfigurasi saat ini untuk handler flush mungkin tidak cukup tinggi untuk ditangani dengan lalu lintas tulis yang dapat menyebabkan perlambatan flush.
Di UI server wilayah, perhatikan apakah antrean flush tumbuh di luar 100. Ambang batas ini menunjukkan bahwa pembilasan lambat dan Anda mungkin harus menyetel konfigurasi hbase.hstore.flusher.count
. Secara default, nilainya adalah 2. Pastikan bahwa rangkaian flusher maks tidak meningkat melebihi 6.
Selain itu, lihat apakah Anda memiliki rekomendasi untuk penyetelan jumlah wilayah. Jika ya, kami sarankan Anda untuk mencoba penyetelan wilayah untuk melihat apakah itu membantu dalam flush yang lebih cepat. Jika tidak, penyetelan rangkaian flusher dapat membantu Anda.
Penyetelan jumlah wilayah
Nasihat penyetelan jumlah wilayah menunjukkan bahwa HBase telah memblokir pembaruan, dan jumlah wilayah mungkin lebih dari ukuran tumpukan yang didukung secara optimal. Anda dapat menyempurnakan ukuran tumpuk, memstore
ukuran, dan jumlah wilayah.
Contoh skenario:
Asumsikan ukuran tumpukan untuk server wilayah adalah 10 GB. Secara default
hbase.hregion.memstore.flush.size
adalah128M
. Nilai defaultnya untukhbase.regionserver.global.memstore.size
adalah0.4
. Yang berarti bahwa dari 10 GB, 4 GB dialokasikan untukmemstore
(secara global).Asumsikan ada distribusi beban tulis yang merata di semua wilayah dan dengan asumsi setiap wilayah tumbuh hingga 128 MB hanya kemudian jumlah wilayah maksimum dalam pengaturan ini
32
adalah wilayah. Jika server wilayah tertentu dikonfigurasi untuk memiliki 32 wilayah, sistem lebih baik menghindari pemblokiran pembaruan.Dengan pengaturan ini di tempat, jumlah wilayah adalah 100. Global 4 GB
memstore
sekarang terbagi di 100 wilayah. Jadi secara efektif setiap wilayah hanya mendapatkan 40 MB untukmemstore
. Ketika penulisan seragam, sistem sering melakukan pembersihan dan ukuran lebih kecil dari urutan < 40 MB. Memiliki banyak rangkaian flusher mungkin meningkatkan kecepatanhbase.hstore.flusher.count
flush.
Saran berarti bahwa akan baik untuk mempertimbangkan kembali jumlah wilayah per server, ukuran timbunan, dan konfigurasi ukuran global memstore
bersama dengan penyetelan utas flush untuk menghindari pembaruan diblokir.
Penyetelan antrean pemadatan
Jika antrean pemadatan HBase tumbuh hingga lebih dari 2000 dan terjadi secara berkala, Anda dapat meningkatkan rangkaian pemadatan ke nilai yang lebih besar.
Ketika ada jumlah file yang berlebihan untuk pemadatan, itu dapat menyebabkan lebih banyak penggunaan tumpukan terkait dengan bagaimana file berinteraksi dengan sistem file Azure. Jadi lebih baik menyelesaikan pemadatan secepat mungkin. Beberapa kali di kluster yang lebih lama konfigurasi pemadatan yang terkait dengan pembatasan dapat menyebabkan laju pemadatan yang lebih lambat.
Periksa konfigurasi hbase.hstore.compaction.throughput.lower.bound
dan hbase.hstore.compaction.throughput.higher.bound
. Jika mereka sudah diatur ke 50M dan 100M, biarkan mereka apa adanya. Namun, jika Anda mengonfigurasi pengaturan tersebut ke nilai yang lebih rendah (yang demikian dengan kluster yang lebih lama), ubah batas masing-masing menjadi 50M dan 100M.
Konfigurasi tersebut adalah hbase.regionserver.thread.compaction.small
dan hbase.regionserver.thread.compaction.large
(defaultnya masing-masing 1).
Batasi nilai maksimal untuk konfigurasi ini menjadi kurang dari 3.
Pemindaian tabel penuh
Penasihat pemindaian tabel lengkap menunjukkan bahwa lebih dari 75% pemindaian yang dikeluarkan adalah pemindaian tabel/wilayah penuh. Anda dapat mengunjungi kembali cara kode Anda memanggil pemindaian untuk meningkatkan kinerja kueri. Pertimbangkan contoh berikut:
Set baris mulai dan hentikan yang tepat untuk setiap pemindaian.
Gunakan API MultiRowRangeFilter sehingga Anda dapat meminta rentang yang berbeda dalam satu panggilan pemindaian. Untuk informasi selengkapnya, lihat Dokumentasi API MultiRowRangeFilter.
Dalam kasus di mana Anda memerlukan pemindaian tabel atau wilayah penuh, periksa apakah ada kemungkinan untuk menghindari penggunaan cache untuk kueri tersebut, sehingga kueri lain yang menggunakan cache mungkin tidak mengusir blok yang panas. Untuk memastikan pemindaian tidak menggunakan cache, gunakan API pindai dengan opsi setCaching(false) di kode Anda:
scan#setCaching(false)