Pengantar
Apache HBase adalah Hadoop open-source, terdistribusi, manajer penyimpanan berversi cocok untuk acak , baca/tulis waktu nyata akses.
Tunggu tunggu? acak, akses baca/tulis waktu nyata?
Bagaimana mungkin? Bukankah Hadoop hanya sistem pemrosesan batch baca/tulis berurutan?
Ya, kita membicarakan hal yang sama, dan dalam beberapa paragraf berikutnya, saya akan menjelaskan kepada Anda bagaimana HBase mencapai I/O acak, cara menyimpan data, dan evolusi format HFile HBase.
Format file Apache Hadoop I/O
Hadoop hadir dengan format file SequenceFile[1] yang dapat Anda gunakan untuk menambahkan pasangan kunci/nilai Anda tetapi karena kemampuan hanya menambahkan hdfs, format file tidak dapat mengizinkan modifikasi atau penghapusan nilai yang dimasukkan. Satu-satunya operasi yang diizinkan adalah menambahkan, dan jika Anda ingin mencari kunci tertentu, Anda harus membaca file hingga menemukan kunci Anda.
Seperti yang Anda lihat, Anda dipaksa untuk mengikuti pola baca/tulis berurutan… tetapi bagaimana mungkin untuk membangun sistem akses baca/tulis acak dengan latensi rendah seperti HBase di atas ini?
Untuk membantu Anda mengatasi masalah ini Hadoop memiliki format file lain, yang disebut MapFile[1], ekstensi dari SequenceFile. MapFile, pada kenyataannya, adalah direktori yang berisi dua SequenceFiles:file data "/ data" dan file indeks "/ indeks". MapFile memungkinkan Anda untuk menambahkan pasangan kunci/nilai yang diurutkan dan setiap kunci N (di mana N adalah interval yang dapat dikonfigurasi) menyimpan kunci dan offset dalam indeks. Ini memungkinkan pencarian yang cukup cepat, karena alih-alih memindai semua catatan, Anda memindai indeks yang memiliki lebih sedikit entri. Setelah Anda menemukan blok Anda, Anda dapat melompat ke file data sebenarnya.
MapFile bagus karena Anda dapat mencari pasangan kunci/nilai dengan cepat tetapi masih ada dua masalah:
- Bagaimana cara menghapus atau mengganti kunci/nilai?
- Jika input saya tidak diurutkan, saya tidak dapat menggunakan MapFile.
HBase &MapFile
Kunci HBase terdiri dari:kunci baris, kelompok kolom, kualifikasi kolom, stempel waktu, dan tipe.
Untuk mengatasi masalah menghapus pasangan kunci/nilai, idenya adalah menggunakan bidang "ketik" untuk menandai kunci sebagai dihapus (penanda batu nisan). Memecahkan masalah penggantian pasangan kunci/nilai hanyalah masalah memilih stempel waktu berikutnya (nilai yang benar berada di dekat akhir file, hanya menambahkan berarti yang terakhir dimasukkan mendekati akhir).
Untuk memecahkan masalah kunci "tidak berurutan", kami menyimpan nilai kunci terakhir yang ditambahkan dalam memori. Ketika Anda telah mencapai ambang batas, HBase menyiramnya ke MapFile. Dengan cara ini, Anda akhirnya menambahkan kunci/nilai yang diurutkan ke MapFile.
HBase melakukan hal ini [2]:ketika Anda menambahkan nilai dengan table.put(), kunci/nilai Anda ditambahkan ke MemStore (di bawah tenda MemStore adalah ConcurrentSkipListMap yang diurutkan). Ketika ambang batas per-memstore (hbase.hregion.memstore.flush.size) tercapai atau RegionServer menggunakan terlalu banyak memori untuk memstore (hbase.regionserver.global.memstore.upperLimit), data di-flush pada disk sebagai MapFile baru .
Hasil dari setiap flush adalah MapFile baru, dan ini berarti bahwa untuk menemukan kunci Anda harus mencari di lebih dari satu file. Ini membutuhkan lebih banyak sumber daya dan berpotensi lebih lambat.
Setiap kali get atau scan dikeluarkan, HBase memindai setiap file untuk menemukan hasilnya, untuk menghindari melompat-lompat terlalu banyak file, ada utas yang akan mendeteksi ketika Anda telah mencapai jumlah file tertentu (hbase.hstore.compaction .maks). Kemudian mencoba menggabungkannya bersama dalam proses yang disebut pemadatan, yang pada dasarnya membuat file besar baru sebagai hasil penggabungan file.
HBase memiliki dua jenis pemadatan:satu disebut "pemadatan kecil" yang hanya menggabungkan dua atau lebih file kecil menjadi satu, dan yang lain disebut "pemadatan besar" yang mengambil semua file di wilayah tersebut, menggabungkannya dan melakukan beberapa pembersihan. Dalam pemadatan utama, kunci/nilai yang dihapus dihapus, file baru ini tidak berisi penanda batu nisan dan semua kunci/nilai duplikat (operasi nilai pengganti) dihapus.
Sampai dengan versi 0.20, HBase telah menggunakan format MapFile untuk menyimpan data tetapi di 0.20 MapFile khusus HBase baru diperkenalkan (HBASE-61).
HFile v1
Di HBase 0.20, MapFile digantikan oleh HFile:implementasi file peta khusus untuk HBase. Idenya sangat mirip dengan MapFile, tetapi menambahkan lebih banyak fitur daripada hanya file kunci/nilai biasa. Fitur seperti dukungan untuk metadata dan indeks sekarang disimpan dalam file yang sama.
Blok data berisi kunci/nilai aktual sebagai MapFile. Untuk setiap “operasi penutupan blok”, kunci pertama ditambahkan ke indeks, dan indeks ditulis pada penutupan HFile.
Format HFile juga menambahkan dua jenis blok "metadata" tambahan:Meta dan FileInfo. Kedua blok kunci/nilai ini ditulis saat file ditutup.
Blok Meta dirancang untuk menyimpan sejumlah besar data dengan kuncinya sebagai String, sementara FileInfo adalah Peta sederhana yang lebih disukai untuk informasi kecil dengan kunci dan nilai yang keduanya byte-array. StoreFile Regionserver menggunakan Meta-Blocks untuk menyimpan Filter Bloom, dan FileInfo untuk Max SequenceId, kunci pemadatan utama dan info Timerange. Informasi ini berguna untuk menghindari membaca file jika tidak ada kemungkinan kuncinya ada (Bloom Filter), jika file terlalu lama (Max SequenceId) atau jika file terlalu baru (Timerange) untuk memuat apa yang kita cari untuk.
HFile v2
Dalam HBase 0.92, format HFile diubah sedikit (HBASE-3857) untuk meningkatkan kinerja ketika sejumlah besar data disimpan. Salah satu masalah utama dengan HFile v1 adalah bahwa Anda perlu memuat semua indeks monolitik dan Filter Bloom besar dalam memori, dan untuk memecahkan masalah ini v2 memperkenalkan indeks multi-level dan Filter Bloom tingkat blok. Hasilnya, HFile v2 meningkatkan kecepatan, memori, dan penggunaan cache.
Fitur utama dari v2 ini adalah "blok inline", idenya adalah untuk memecah indeks dan Filter Bloom per blok, daripada memiliki seluruh indeks dan Filter Bloom dari seluruh file dalam memori. Dengan cara ini Anda dapat menyimpan ram sesuai kebutuhan.
Karena indeks dipindahkan ke level blok, Anda kemudian memiliki indeks multi-level, artinya setiap blok memiliki indeks sendiri (indeks daun). Kunci terakhir dari setiap blok disimpan untuk membuat perantara/indeks yang membuat indeks multilevel b+tree seperti.
Header blok sekarang berisi beberapa informasi:Bidang "Block Magic" digantikan oleh bidang "Block Type" yang menjelaskan konten blok "Data", Leaf-Index, Bloom, Metadata, Root-Index, dll. Juga tiga bidang (ukuran terkompresi/tidak terkompresi dan blok sebelumnya offset) ditambahkan untuk memungkinkan pencarian mundur dan maju dengan cepat.
Pengkodean Blok Data
Karena kunci diurutkan dan biasanya sangat mirip, dimungkinkan untuk merancang kompresi yang lebih baik daripada yang dapat dilakukan oleh algoritme tujuan umum.
HBASE-4218 mencoba memecahkan masalah ini, dan di HBase 0.94 Anda dapat memilih di antara beberapa algoritme yang berbeda:Prefix dan Diff Encoding.
Ide utama Pengkodean Awalan adalah untuk menyimpan awalan umum hanya sekali, karena baris diurutkan dan awalnya biasanya sama.
Diff Encoding mendorong konsep ini lebih jauh. Alih-alih mempertimbangkan kunci sebagai urutan byte buram, Diff Encoder membagi setiap bidang kunci untuk mengompresi setiap bagian dengan cara yang lebih baik. Ini adalah bahwa keluarga kolom disimpan sekali. Jika panjang kunci, panjang nilai, dan jenisnya sama dengan baris sebelumnya, bidang dihilangkan. Selain itu, untuk peningkatan kompresi, stempel waktu yang disimpan disimpan sebagai Diff dari yang sebelumnya.
Perhatikan bahwa fitur ini dinonaktifkan secara default karena penulisan dan pemindaian lebih lambat tetapi lebih banyak data di-cache. Untuk mengaktifkan fitur ini, Anda dapat mengatur DATA_BLOCK_ENCODING =PREFIX | DIFF | FAST_DIFF dalam info tabel.
HFile v3
HBASE-5313 berisi proposal untuk merestrukturisasi tata letak HFile untuk meningkatkan kompresi:
- Kemas semua kunci bersama-sama di awal blok dan semua nilai di akhir blok. Dengan cara ini Anda dapat menggunakan dua algoritme berbeda untuk mengompresi kunci dan nilai.
- Kompres stempel waktu menggunakan XOR dengan nilai pertama dan gunakan VInt sebagai ganti panjang.
Juga, format kolom atau pengkodean kolom sedang diselidiki, lihat AVRO-806 untuk format file kolom oleh Doug Cutting.
Seperti yang mungkin Anda lihat, tren dalam evolusi adalah menjadi lebih sadar tentang isi file, untuk mendapatkan kompresi yang lebih baik atau kesadaran lokasi yang lebih baik yang diterjemahkan menjadi lebih sedikit data untuk ditulis/dibaca dari disk. Lebih sedikit I/O berarti lebih cepat!
[1] https://clouderatemp.wpengine.com/blog/2011/01/hadoop-io-sequence-map-set-array-bloommap-files/
[2] https://clouderatemp.wpengine. com/blog/2012/06/hbase-write-path/
