Apache HBase adalah database Hadoop, dan didasarkan pada Hadoop Distributed File System (HDFS ). HBase memungkinkan untuk mengakses dan memperbarui data secara acak yang disimpan dalam HDFS, tetapi file dalam HDFS hanya dapat ditambahkan dan tidak dapat diubah setelah dibuat. Jadi, Anda mungkin bertanya, bagaimana HBase menyediakan baca dan tulis latensi rendah? Dalam posting blog ini, kami menjelaskannya dengan menjelaskan jalur penulisan HBase — bagaimana data diperbarui di HBase.
Jalur tulis adalah bagaimana HBase menyelesaikan operasi put atau delete. Jalur ini dimulai pada klien, pindah ke server wilayah, dan berakhir saat data akhirnya ditulis ke file data HBase yang disebut HFile . Termasuk dalam desain jalur tulis adalah fitur yang digunakan HBase untuk mencegah kehilangan data jika terjadi kegagalan server wilayah. Oleh karena itu, memahami jalur tulis dapat memberikan wawasan tentang mekanisme pencegahan kehilangan data asli HBase.
Setiap tabel HBase di-host dan dikelola oleh set server yang terbagi dalam tiga kategori:
- Satu server master aktif
- Satu atau beberapa server master cadangan
- Banyak server wilayah
Server wilayah berkontribusi untuk menangani tabel HBase. Karena tabel HBase bisa berukuran besar, tabel tersebut dipecah menjadi partisi yang disebut region. Setiap server wilayah menangani satu atau beberapa wilayah ini. Perhatikan bahwa karena server wilayah adalah satu-satunya server yang melayani data tabel HBase, server master mogok tidak dapat menyebabkan kehilangan data.
Data HBase diatur mirip dengan peta yang diurutkan, dengan ruang kunci yang diurutkan dipartisi menjadi pecahan atau wilayah yang berbeda. Klien HBase memperbarui tabel dengan menjalankan perintah put atau delete. Saat klien meminta perubahan, permintaan tersebut langsung dirutekan ke server wilayah secara default. Namun, secara terprogram, klien dapat men-cache perubahan di sisi klien, dan menyiram perubahan ini ke server wilayah dalam satu batch, dengan mematikan autoflush. Jika autoflush dimatikan, perubahan di-cache sampai flush-commits dipanggil, atau buffer penuh tergantung pada ukuran buffer yang diatur secara terprogram atau dikonfigurasi dengan parameter “hbase.client.write.buffer”.
Karena kunci baris diurutkan, mudah untuk menentukan server wilayah mana yang mengelola kunci mana. Permintaan perubahan adalah untuk baris tertentu. Setiap kunci baris milik wilayah tertentu yang dilayani oleh server wilayah. Jadi berdasarkan kunci put atau delete, klien HBase dapat menemukan server wilayah yang tepat. Pada awalnya, ia menempatkan alamat server wilayah yang menampung wilayah -ROOT- dari kuorum ZooKeeper. Dari server wilayah root, klien mengetahui lokasi server wilayah yang menghosting wilayah -META-. Dari server wilayah meta, akhirnya kami menemukan server wilayah aktual yang melayani wilayah yang diminta. Ini adalah proses tiga langkah, jadi lokasi region di-cache untuk menghindari rangkaian operasi yang mahal ini. Jika lokasi yang di-cache tidak valid (misalnya, kami mendapatkan beberapa pengecualian wilayah yang tidak dikenal), saatnya untuk menemukan kembali wilayah tersebut dan memperbarui cache.
Setelah permintaan diterima oleh server region yang tepat, perubahan tidak dapat langsung ditulis ke HFile karena data dalam HFile harus diurutkan berdasarkan kunci baris. Ini memungkinkan pencarian baris acak secara efisien saat membaca data. Data tidak dapat dimasukkan secara acak ke dalam HFile. Sebagai gantinya, perubahan harus ditulis ke file baru. Jika setiap pembaruan ditulis ke file, banyak file kecil akan dibuat. Solusi seperti itu tidak akan terukur atau tidak efisien untuk digabungkan atau dibaca di lain waktu. Oleh karena itu, perubahan tidak segera ditulis ke HFile baru.
Sebagai gantinya, setiap perubahan disimpan di tempat di memori yang disebut memstore , yang secara murah dan efisien mendukung penulisan acak. Data di memstore diurutkan dengan cara yang sama seperti data di HFile. Ketika memstore mengumpulkan data yang cukup, seluruh set yang diurutkan akan ditulis ke HFile baru dalam HDFS. Menyelesaikan satu tugas tulis besar itu efisien dan memanfaatkan kekuatan HDFS.
Meskipun menulis data ke memstore itu efisien, hal itu juga menimbulkan elemen risiko:Informasi yang disimpan di memstore disimpan dalam memori yang mudah menguap, jadi jika sistem gagal, semua informasi memstore hilang. Untuk membantu mengurangi risiko ini, HBase menyimpan pembaruan dalam log tulis (WAL ) sebelum menulis informasi ke memstore. Dengan cara ini, jika server wilayah gagal, informasi yang disimpan di memstore server tersebut dapat dipulihkan dari WAL-nya.
Catatan:Secara default, WAL diaktifkan, tetapi proses penulisan file WAL ke disk menghabiskan beberapa sumber daya. WAL mungkin dinonaktifkan, tetapi ini hanya boleh dilakukan jika risiko kehilangan data tidak menjadi perhatian. Jika Anda memilih untuk menonaktifkan WAL, pertimbangkan untuk menerapkan solusi pemulihan bencana Anda sendiri atau bersiaplah untuk kemungkinan kehilangan data.
Data dalam file WAL diatur secara berbeda dari HFile. File WAL berisi daftar suntingan, dengan satu suntingan mewakili satu put atau hapus. Pengeditan mencakup informasi tentang perubahan dan wilayah tempat perubahan diterapkan. Pengeditan ditulis secara kronologis, jadi, untuk ketekunan, penambahan ditambahkan ke akhir file WAL yang disimpan di disk. Karena file WAL diurutkan secara kronologis, tidak perlu menulis ke tempat acak di dalam file.
Saat WAL tumbuh, mereka akhirnya ditutup dan file WAL baru yang aktif dibuat untuk menerima pengeditan tambahan. Ini disebut "menggulung" file WAL. Setelah file WAL diputar, tidak ada perubahan tambahan yang dilakukan pada file lama.
Secara default, file WAL digulung ketika ukurannya sekitar 95% dari ukuran blok HDFS. Anda dapat mengkonfigurasi multiplier menggunakan parameter:“hbase.regionserver.logroll.multiplier”, dan ukuran blok menggunakan parameter:“hbase.regionserver.hlog.blocksize”. File WAL juga digulirkan secara berkala berdasarkan interval yang dikonfigurasi “hbase.regionserver.logroll.period”, satu jam secara default, bahkan ukuran file WAL lebih kecil dari batas yang dikonfigurasi.
Membatasi ukuran file WAL memfasilitasi pemutaran ulang file yang efisien jika pemulihan diperlukan. Ini sangat penting selama pemutaran ulang file WAL suatu wilayah karena saat file sedang diputar ulang, wilayah yang sesuai tidak tersedia. Tujuannya adalah untuk akhirnya menulis semua perubahan dari setiap file WAL ke disk dan mempertahankan konten itu dalam HFile. Setelah ini selesai, file WAL dapat diarsipkan dan akhirnya dihapus oleh utas daemon LogCleaner. Perhatikan bahwa file WAL berfungsi sebagai tindakan perlindungan. File WAL hanya perlu diputar ulang untuk memulihkan pembaruan yang seharusnya hilang setelah server wilayah mogok.
Server wilayah melayani banyak wilayah, tetapi tidak memiliki file WAL untuk setiap wilayah. Sebagai gantinya, satu file WAL aktif dibagikan di antara semua wilayah yang dilayani oleh server wilayah. Karena file WAL digulung secara berkala, satu server wilayah mungkin memiliki banyak file WAL. Perhatikan bahwa hanya ada satu WAL aktif per server wilayah pada waktu tertentu.
Dengan asumsi root HBase default “/ hbase”, semua file WAL untuk instance server wilayah disimpan di bawah folder root yang sama, yaitu sebagai berikut:
/hbase/.logs/<host>, <port>,<startcode>
Misalnya:
/hbase/.logs/srv.example.com,60020,1254173957298
File log WAL diberi nama sebagai berikut:
/hbase/.logs/<host>, <port>,<startcode>/<host>%2C <port>%2C<startcode>.<timestamp>
Misalnya:
/hbase/.logs/srv.example.com,60020,1254173957298/srv.example.com%2C60020%2C1254173957298.1254173957495
Setiap pengeditan dalam file WAL memiliki id urutan yang unik. Id ini meningkat untuk mempertahankan urutan pengeditan. Setiap kali file log digulung, id urutan berikutnya dan nama file lama dimasukkan ke dalam peta dalam memori. Informasi ini digunakan untuk melacak id urutan maksimum dari setiap file WAL sehingga kami dapat dengan mudah mengetahui apakah suatu file dapat diarsipkan di lain waktu ketika beberapa memstore di-flush ke disk.
Pengeditan dan id urutannya unik dalam suatu wilayah. Setiap kali edit ditambahkan ke log WAL, id urutan edit juga dicatat sebagai id urutan terakhir yang ditulis. Saat memstore di-flush ke disk, id urutan terakhir yang ditulis untuk wilayah ini dihapus. Jika id urutan terakhir yang ditulis ke disk sama dengan id urutan maksimum file WAL, dapat disimpulkan bahwa semua pengeditan dalam file WAL untuk wilayah ini telah ditulis ke disk. Jika semua pengeditan untuk semua wilayah dalam file WAL telah ditulis ke disk, jelas bahwa tidak diperlukan pemisahan atau pemutaran ulang, dan file WAL dapat diarsipkan.
Pengguliran file WAL dan memstore flush adalah dua tindakan terpisah, dan tidak harus terjadi bersamaan. Namun, kami tidak ingin menyimpan terlalu banyak file WAL per server wilayah untuk menghindari pemulihan yang memakan waktu jika terjadi kegagalan server wilayah. Oleh karena itu, ketika file WAL diputar, HBase memeriksa apakah ada terlalu banyak file WAL, dan memutuskan wilayah mana yang harus dihapus sehingga beberapa file WAL dapat diarsipkan.
Dalam posting ini, kami menjelaskan jalur penulisan HBase, yaitu bagaimana data dalam HBase dibuat dan/atau diperbarui. Beberapa bagian penting darinya adalah:
- Bagaimana klien menemukan server wilayah,
- Memstore yang mendukung penulisan acak cepat,
- File WAL sebagai cara untuk menghindari kehilangan data jika server wilayah gagal.
Kita akan berbicara tentang format HFile, pemisahan file WAL dan sebagainya di posting berikutnya.
