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:

  1. Set hbase.rs.cacheblocksonwrite ke true. Konfigurasi default ini di HDInsight HBase adalah true, jadi periksa apakah itu tidak diatur ulang ke false.

  2. Tingkatkan nilai hbase.hstore.compactionThreshold sehingga Anda dapat menghindari pemadatan dari menendang pada. Secara default nilai ini adalah 3. Anda dapat meningkatkannya ke nilai yang lebih tinggi seperti 10.

  3. Jika Anda mengikuti langkah 2 dan set ambang batas pemadatan, lalu ubah hbase.hstore.compaction.max ke nilai yang lebih tinggi misalnya 100, dan juga tingkatkan nilai untuk konfigurasi ke nilai hbase.hstore.blockingStoreFiles yang lebih tinggi misalnya 300.

  4. 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'}}
    
  5. 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 adalah 128M. Nilai defaultnya untuk hbase.regionserver.global.memstore.size adalah 0.4. Yang berarti bahwa dari 10 GB, 4 GB dialokasikan untuk memstore (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 untuk memstore. Ketika penulisan seragam, sistem sering melakukan pembersihan dan ukuran lebih kecil dari urutan < 40 MB. Memiliki banyak rangkaian flusher mungkin meningkatkan kecepatan hbase.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)
    

Langkah berikutnya

Optimalkan Apache HBase menggunakan Ambari