Dalam posting hari ini mari kita bincangkan mengenai HBase Architecture. Mari selami asas HBase kami sebelum kita mempelajari lebih mendalam mengenai seni bina HBase.
HBase - Asas:
HBase adalah kedai terbuka, NoSQL, diedarkan, tidak berkaitan, versi, multi-dimensi, berorientasikan lajur yang telah dimodelkan selepas Google BigTable yang berjalan di atas HDFS. 'NoSQL' adalah istilah luas yang bermaksud bahawa pangkalan data bukan RDBMS yang menyokong SQL sebagai bahasa akses utamanya. Tetapi terdapat banyak jenis pangkalan data NoSQL dan Berkeley DB adalah contoh yang baik dari pangkalan data NoSQL tempatan, sedangkan HBase adalah sangat banyak pangkalan data yang diedarkan.
HBase menyediakan semua ciri Google BigTable. Ia bermula sebagai projek oleh Powerset untuk memproses sejumlah besar data untuk pencarian bahasa semula jadi. Ia dibangunkan sebagai sebahagian daripada projek Hadoop Apache dan berjalan di atas HDFS (Hadoop Distused File System). Ia menyediakan kaedah toleransi kesalahan menyimpan sejumlah besar data yang jarang. HBase sebenarnya lebih merupakan 'Penyimpanan Data' daripada 'Pangkalan Data' kerana kekurangan banyak fitur yang tersedia dalam RDBMS, seperti lajur yang diketik, indeks sekunder, pencetus, dan bahasa pertanyaan lanjutan, dll.
Dalam pangkalan data Berorientasikan Kolom, jadual data disimpan sebagai bahagian lajur data dan bukan sebagai baris data. Model data pangkalan data berorientasikan lajur terdiri daripada nama Jadual, kunci baris, keluarga lajur, lajur, cap waktu. Semasa membuat jadual di HBase, baris akan dikenal pasti secara unik dengan bantuan kekunci baris dan cap waktu. Dalam model data ini keluarga lajur statik sedangkan lajur dinamik. Sekarang mari kita lihat HBase Architecture.
Bilakah untuk pergi ke HBase?
HBase adalah pilihan yang baik hanya apabila terdapat ratusan juta atau berbilion baris. HBase juga dapat digunakan di tempat-tempat ketika mempertimbangkan untuk berpindah dari RDBMS ke HBase sebagai reka bentuk semula yang lengkap berbanding dengan port. Dengan kata lain, HBase tidak dioptimumkan untuk aplikasi transaksi klasik atau bahkan analisis relasional. Ia juga bukan pengganti HDFS sepenuhnya ketika melakukan MapReduce batch besar. Jadi mengapa anda mesti pergi ke HBase ?? Sekiranya aplikasi anda mempunyai skema pemboleh ubah di mana setiap baris sedikit berbeza, maka anda harus melihat HBase.
Senibina HBase:
Gambar berikut menerangkan dengan jelas HBase Architecture.
Di HBase, terdapat tiga komponen utama: Tuan, pelayan Wilayah dan penjaga Zoo . Komponen lain adalah Memstore, HFile dan WAL.
Oleh kerana HBase berjalan di atas HDFS, ia menggunakan seni bina Master-Slave di mana HMaster akan menjadi simpul induk dan Pelayan Wilayah adalah node hamba. Apabila pelanggan menghantar permintaan tulis, HMaster mendapat permintaan itu dan meneruskannya ke Pelayan Wilayah masing-masing.
Pelayan Wilayah:
Ini adalah sistem yang bertindak serupa dengan simpul data. Apabila Server Wilayah (RS) menerima permintaan tulis, ia mengarahkan permintaan tersebut ke Wilayah tertentu. Setiap Wilayah menyimpan set baris. Data baris dapat dipisahkan dalam beberapa keluarga lajur (CF). Data CF tertentu disimpan di HStore yang terdiri daripada Memstore dan satu set HFiles.
Apa yang dilakukan oleh Memstore?
Memstore melacak semua log untuk operasi membaca dan menulis yang telah dilakukan dalam pelayan wilayah tertentu. Dari sini kita dapat mengatakan bahawa bertindak serupa dengan simpul nama di Hadoop. Memstore adalah simpanan dalam memori, oleh itu Memstore menggunakan penyimpanan dalam memori setiap nod data untuk menyimpan log. Apabila ambang tertentu dipenuhi, data Memstore dialirkan ke HFile.
Tujuan utama untuk menggunakan Memstore adalah keperluan untuk menyimpan data pada DFS yang dipesan dengan kunci baris. Oleh kerana HDFS dirancang untuk membaca / menulis secara berurutan, tanpa modifikasi fail yang diizinkan, HBase tidak dapat menulis data ke disk dengan cekap seperti yang diterima: data yang ditulis tidak akan diurutkan (ketika input tidak diurutkan) yang berarti tidak dioptimumkan untuk masa depan pengambilan. Untuk menyelesaikan masalah ini, penyangga HBase terakhir menerima data dalam memori (di Memstore), 'menyusun' sebelum memerah, dan kemudian menulis ke HDFS menggunakan penulisan berurutan yang cepat. Oleh itu, HFile mengandungi senarai baris yang disusun.
Setiap kali Memstore flush berlaku satu HFile dibuat untuk setiap CF dan flush yang kerap boleh menghasilkan banyak HFiles. Oleh kerana semasa membaca HBase harus melihat banyak HFiles, kelajuan membaca dapat menderita. Untuk mengelakkan pembukaan HFiles terlalu banyak dan mengelakkan kemerosotan prestasi membaca, proses pemadatan HFiles digunakan. HBase secara berkala (apabila ambang tertentu yang dapat dikonfigurasi dipenuhi) menggabungkan HFiles yang lebih kecil menjadi yang besar. Jelas, semakin banyak fail yang dibuat oleh Memstore flushes, semakin banyak kerja (beban tambahan) untuk sistem. Selain itu, sementara proses pemadatan biasanya dilakukan selari dengan melayani permintaan lain dan ketika HBase tidak dapat mengikuti pemadatan HFiles (ya, ada ambang konfigurasi untuk itu juga), ia akan menyekat penulisan di RS lagi. Seperti yang telah kita bincangkan di atas, ini sangat tidak diingini.
Kami tidak pasti bahawa data akan berterusan di Memstore. Anggaplah bahawa datanod tertentu tergendala. Kemudian data yang berada di memori simpul data tersebut akan hilang.
Untuk mengatasi masalah ini, apabila permintaan itu datang dari tuan, ia juga ditulis kepada WAL. WAL tidak lain dan tidak bukan Tulis Log Depan yang berada di HDFS, simpanan tetap. Sekarang kita dapat memastikan bahawa walaupun ketika simpul data turun, data tidak akan hilang. kami mempunyai salinan semua tindakan yang sepatutnya anda lakukan di WAL. Apabila simpul data habis, ia akan melakukan semua aktiviti lagi. Setelah operasi selesai, semuanya dikeluarkan dari Memstore dan WAL dan ditulis dalam HFile untuk memastikan bahawa kita tidak kehabisan memori.
Mari kita ambil contoh mudah yang saya mahu tambahkan baris 10, kemudian permintaan menulis masuk, ia mengatakan bahawa ia memberikan semua data meta ke Memstore dan WAL. Sebaik sahaja baris tertentu ditulis ke dalam HFile segala-galanya di Memstore dan WAL dikeluarkan.
Penjaga zoo:
HBase disatukan dengan penjaga Zoo. Semasa saya memulakan HBase, contoh penjaga Zoo juga dimulakan. Sebabnya adalah bahawa penjaga Zoo membantu kami dalam mengawasi semua pelayan wilayah yang ada di HBase. Penjaga kebun binatang mengawasi berapa banyak pelayan wilayah yang ada, pelayan wilayah mana yang menahan dari simpul data ke simpul data mana. Ia melacak set data yang lebih kecil di mana Hadoop hilang. Ini mengurangkan overhead di atas Hadoop yang mengawasi sebahagian besar data Meta anda. Oleh itu HMaster mendapat perincian pelayan wilayah dengan benar-benar menghubungi penjaga Zoo.
Ada soalan untuk kami? Sebutkannya di bahagian komen dan kami akan menghubungi anda.
Catatan berkaitan:
cara menggabungkan data dalam tableau