深さ分析HBaseのアーキテクチャ

オリジナルのリンク（HTTPS：// mapr.com/blog/in-depth- ルックHBaseのアーキテクチャー/）

HBaseのアーキテクチャ

物理的には、HBaseのシステムは、デーモンの3種類、すなわち、地域のサーバー、マスターサーバーと飼育係があります。

リージョンサーバーは、実際にデータを読み書きする責任がある。データにアクセスする場合、クライアントとのHBaseリージョンサーバが直接通信します。

マスターサーバーの管理場所の地域、DDL（テーブル構造の追加と削除）

メンテナンスを担当する飼育係と全体のHBaseクラスタの状態を記録します。

だから、この地域サーバは、データがコピーに保存されますHDFSのデータノード。すべてのHBaseのデータはHDFSに保存されている。各地域のサーバーがデータをHDFSに保存されている置く。サーバは両方のリージョンサーバである場合でありますローカルHDFS、加速アクセス速度。

しかし、地域サーバ、この地域サーバーとデータのローカルコピーに新しい移行場合。HBaseのは、コンパクションまで実行することは、上記ローカルデータノードへの移行のコピーを配置します。

すべてのブロックファイルHDFSこれに格納された名前のノードの位置情報

HBaseのリージョンサーバ

行キー領域を応じて複数の領域に分割HBaseのテーブルは、リージョンはこの領域内のすべてのデータが含まれています。サーバーは、複数のリージョンリージョンを管理し、地域サーバのこの領域内のすべての読み取りおよび書き込み操作を担当しています。地域アップサーバー1000年には、地域を管理することができます。

HBaseのマスターサーバー

HBaseのザ・マスターの領域等、（例えば、作成および削除テーブルなど）DDLの分布及び動作の主な原因であります

HBaseのマスター機能：

コーディネーションリージョンサーバー
データ復旧クラスタ内または動的にリージョンサーバーに地域に割り当てられた負荷を調整
クラスタの状態の制御、すべてのリージョンサーバーの監視
DDLは、関連するAPIを提供し、（作成）新しいは、削除（削除）およびアップデート（更新）テーブル構造。

ZooKeeperの：クラスタ「プロパティ」管理者

Zookeepperには中央のメタデータ・ストレージ・サービスを分散されていない。飼育係が検出し、HBaseのクラスタサーバのステータス情報を記録する。飼育係は、サーバーがダウンしているが見つかった場合、それはマスターノードは、本番環境の展開飼育係に少なくとも3を必要とするのHBaseを通知しますコアアルゴリズムのZooKeeper満たすために、サーバ、パクシ島最低限の要件を。

注釈：示されているように、そこに飼育係飼育係のステータスレポートの実施形態3台のサーバ、地域サーバーとハートビートによるマスターノード

ZooKeeperの、マスター地域サーバと連携して動作

セッションの接続を維持する飼育係の検出および管理することにより、サーバのダウンタイム。リージョンサーバー、スタンバイ・マスター・ノードのアクティブな接続飼育係、サーバーライン、メンバーのクラスタを、維持する責任Zookeepr、

このセッションでは、定期的にオンラインの飼育係、およびダウンタイムなしを説明するために、ハートビートを送信する必要があります。

ZooKeeper有一个Ephemeral Node(临时节点)的概念, session连接在zookeeper中建立一个临时节点(Ephemeral Node), 如果这个session断开, 临时节点被自动删除.

所有Region server都尝试连接Zookeeper, 并在这个session中建立一个临时节点(Ephemeral node). HBase的master节点监控这些临时节点的是否存在, 可以发现新加入region server和判断已经存在的region server宕机.

为了高可用需求, HBase的master也有多个, 这些master节点也同时向Zookeeper注册临时节点(Ephemeral Node). Zookeeper把第一个成功注册的master节点设置成active状态, 而其他master node处于inactive状态.

如果zookeeper规定时间内, 没有收到active的master节点的heartbeat, 连接session超时, 对应的临时节也自动删除. 之前处于Inactive的master节点得到通知, 马上变成active状态, 立即提供服务.

同样, 如果zookeeper没有及时收到region server的heartbeat, session过期, 临时节点删除. HBase master得知region server宕机, 启动数据恢复方案.

HBase的第一次读写流程

HBase把各个region的位置信息存储在一个特殊的表中, 这个表叫做Meta table.

Zookeeper里面存储了这个Meta table的位置信息.

HBase的访问流程:

1. 客户端访问Zookeep, 得到了具体Meta table的位置

2. 客户端再访问真正的Meta table, 从Meta table里面得到row key所在的region server

3. 访问rowkey所在的region server, 得到需要的真正数据.

客户端缓存meta table的位置和row key的位置信息, 这样就不用每次访问都读zookeeper.

如果region server由于宕机等原因迁移到其他服务器. Hbase客户端访问失败, 客户端缓存过期, 再重新访问zookeeper, 得到最新的meta table位置, 更新缓存.

HBase Meta Table

Meta table存储所有region的列表

Meta table用类似于Btree的方式存储

Meta table的结构如下:

- Key: region的开始row key, region id

- Values: Region server

译注: 在google的bigtable论文中, bigtable采用了多级meta table, Hbase的Meta table只有2级

Region Server的结构

Region Server运行在HDFS的data node上面, 它有下面4个部分组成:

WAL: 预写日志(Write Ahead Log)是一HDFS上的一个文件, 如果region server崩溃后, 日志文件用来恢复新写入的的, 但是还没有存储在硬盘上的数据.
BlockCache: 读取缓存, 在内存里缓存频繁读取的数据, 如果BlockCache满了, 会根据LRU算法(Least Recently Used)选出最不活跃的数据, 然后释放掉
MemStore: 写入缓存, 在数据真正被写入硬盘前, Memstore在内存中缓存新写入的数据. 每个region的每个列簇(column family)都有一个memstore. memstore的数据在写入硬盘前, 会先根据key排序, 然后写入硬盘.
HFiles: HDFS上的数据文件, 里面存储KeyValue对.

HBase的写入流程(1)

当hbase客户端发起Put请求, 第一步是将数据写入预写日志(WAL):

将修改的操作记录在预写日志(WAL)的末尾
先行書き込みログ（WAL）を使用した場合にリージョン・サーバーがクラッシュし、データmemstoreの回復

書き込みファイルの末尾にWAL合計の書き込みは、より高速なシーケンシャル書き込み速度であります

HBaseの書き込み処理（2）

データは、書き込み先のログ（WAL）に書かれた、とmemstore後に保存され、ユーザーが正常に書き戻します。

HBaseのMemStore

MemStoreメモリは、ストレージのための順序キー、キー値によると、Memstoreクラスタは、キーと値のすべては、キーストアに応じて発注され、また、内部HFILEに。列（列ファミリー）に対応しています。

HBaseの地域フラッシュ

注釈：データは水と比較されるフラッシュ意識内部オリジナルは、（トイレをフラッシュ）トイレをフラッシュに似ているハードディスクからのデータのバッファメモリダンプで、水の蓄積が下水道になりますしたいですデータがハードディスクキャッシュに書き込まれたとき。フラッシュや、ウォーターバスなど、非常に英語に似ただけでなく、非プラグ限り、非プラグ浴槽の栓を、お風呂の水が下水道に流入し始めたが、また、類推キャッシュとしてデータがハードディスクに書き込まれます

Memstore十分なデータを蓄積したときに、リージョン・サーバーデータは、各データが実際に格納されHFILE、HFILEの複数のHFILEとして格納Memstore HDFS、各クラスタのカラム（列ファミリー）に書き込まれます。

各カラム（列ファミリー）のためのクラスタ数がMemstore [...に対応するのでMemstoreが後、通知HBaseのクラスタにフラッシュHDFSファイルはカラム（列ファミリー）を制限する場合、これらのHFILEは、完全であるすぎる：翻訳よりmemstoreあまりにも多くのメモリを取ります ]。

当Memstore的数据Flush到硬盘时, 系统额外保存了最后写入操作的序列号(last written squence number), 所以HBase知道有多少数据已经成功写入硬盘. 每个HFile都记录这个序号, 表明这个HFile记录了多少数据和从哪里继续写入数据.

在region server启动后, 读取所有HFile中最高的序列号, 新的写入序列号从这个最高序列号继续向上累加.

HBase HFile

HFile中存储有序的Key-Value对. 当Memstore满了之后, Memstore中的所有数据写入HDFS中,形成一个新的HFile. 这种大文件写入是顺序写, 因为避免了机械硬盘的磁头移动, 所以写入速度非常快.

HBase HFile Structure

HFile存储了一个多级索引(multi-layered index), 查询请求不需要遍历整个HFile查询数据, 通过多级索引就可以快速得到数据(工作机制类似于b+tree)

Key-Value按照升序排列
Key-Value存储在以64KB为单位的Block里
每个Block有一个叶索引(leaf-index), 记录Block的位置
每个Block的最后一个Key(译注: 最后一个key也是最大的key), 放入中间索引(intermediate index)
根索引(root index)指向中间索引

尾部指针(trailer pointer)在HFile的最末尾, 它指向元数据块区(meta block), 布隆过滤器区域和时间范围区域. 查询布隆过滤器可以很快得确定row key是否在HFile内, 时间范围区域也可以帮助查询跳过不在时间区域的读请求.

译注: 布隆过滤器在搜索和文件存储中有广泛用途, 具体算法请参考https://china.googleblog.com/2007/07/bloom-filter_7469.html

HFile索引

当打开HFile后, 系统自动缓存HFile的索引在Block Cache里, 这样后续查找操作只需要一次硬盘的寻道.

HBase的混合读(Read Merge)

我们发现HBase中的一个row里面的数据, 分配在多个地方. 已经持久化存储的Cell在HFile, 最近写入的Cell在Memstore里, 最近读取的Cell在Block cache里. 所以当你读HBase的一行时, 混合了Block cache, memstore和Hfiles的读操作

首先, 在Block cache(读cache)里面查找cell, 因为最近的读取操作都会缓存在这里. 如果找到就返回, 没有找到就执行下一步
其次, 在memstore(写cache)里查找cell, memstore里面存储里最近的新写入, 如果找到就返回, 没有找到就执行下一步
最后, 在读写cache中都查找失败的情况下, HBase查询Block cache里面的Hfile索引和布隆过滤器, 查询有可能存在这个cell的HFile, 最后在HFile中找到数据.

HBase Minor Compaction

HBase自动选择较小的HFile, 将它们合并成更大的HFile. 这个过程叫做minor compaction. Minor compaction通过合并小HFile, 减少HFile的数量.

HFile的合并采用归并排序的算法.

译注: 较少的HFile可以提高HBase的读性能

HBase Major Compaction

Major compaction指一个region下的所有HFile做归并排序, 最后形成一个大的HFile. 这可以提高读性能. 但是, major compaction重写所有的Hfile, 占用大量硬盘IO和网络带宽. 这也被称为写放大现象(write amplification)

Major compaction可以被调度成自动运行的模式, 但是由于写放大的问题(write amplification), major compaction通常在一周执行一次或者只在凌晨运行. 此外, major compaction的过程中, 如果发现region server负责的数据不在本地的HDFS datanode上, major compaction除了合并文件外, 还会把其中一份数据转存到本地的data node上.

Region = 一组连续key

快速的复习region的概念:

一张表垂直分割成一个或多个region, 一个region包括一组连续并且有序的row key, 每一个row key对应一行的数据.
每个region最大1GB(默认)
region由region server管理
一个region server可以管理多个region, 最多大约1000个region(这些region可以属于相同的表,也可以属于不同的表)

Region的拆分

最初, 每张表只有一个region, 当一个region变得太大时, 它就分裂成2个子region. 2个子region, 各占原始region的一半数据, 仍然被相同的region server管理. Region server向HBase master节点汇报拆分完成.

如果集群内还有其他region server, master节点倾向于做负载均衡, 所以master节点有可能调度新的region到其他region server, 由其他region管理新的分裂出的region.

负载均衡

最初, 一个Region server上的region一分为二, 但是考虑到负载均衡, master node会把新region调度到其他服务器上. 然而, 新region所在的region server在本地data node上没有数据, 所有操作都是操作远程HDFS上面的数据. 直到这个Region server运行了major compaction之后, 才有一份副本落在本地datanode中.

译注: HFile和WAL都是存储在HDFS中, 这里说的把副本存储在本地是指: 由于HDFS是一种聪明的FS, 如果他发现要求写入文件的客户端恰好也是HDFS的data node, 那么在分配哪三台服务器存储副本时, 会优先在发请求的客户端存储数据, 这样就可以让Region server管理的数据虽然是3份, 但是其中一份就在本地服务器上, 优化了访问路径.

具体可以参考这篇文章http://www.larsgeorge.com/2010/05/hbase-file-locality-in-hdfs.html, 里面详述了HDFS如何实现这种本地化的存储. 换句话说, 如果region server没有和HDFS的data node部署在同一台服务器, 就无法实现上面说的本地存储

HDFS的数据复制(1)

所有读写都是操作primary node. HDFS自动复制所有WAL和HFile的数据块到其他节点. HBase依赖HDFS保证数据安全. 当在HDFS里面写入一个文件时, 一份存储在本地节点, 另两份存储到其他节点

HDFS的数据复制(2)

预写日志(WAL) 和 HFile都存在HDFS里面, 可以保证数据的可靠性, 但是HBase memstore里的数据都在内存中, 如果系统崩溃后重启, Hbase如何恢复Memstore里面的数据?

注釈：図のメモリ内のデータから見memstoreは、何の複数のコピーが存在しません

HBaseのディザスタリカバリ

リージョン・サーバーがダウンした場合には、地域のサーバ管理領域の崩壊はもはやHBaseのは、異常監視回復プロセスを開始し、地域を復元するために、サービスを提供することはできません。

飼育係領域サーバは、領域サーバのダウンタイムを判断し、心拍が停止見つかり、マスタノードに通知する。HBaseのマスターノードの割り当て、その領域の領域サーバのダウンタイム、他の領域サーバーに領域サーバ管理の崩壊後。HBaseのプリライトファイルから（WAL ）データでmemstore回復インチ

HBaseのマスターは、リージョンサーバーのクラッシュをマスター。新しいリージョン・サーバーに再割り当てされている古い地域を知っている書き込みログの各領域サーバー障害回復リプレイを事前に複数の参加への先行書き込みログ（WAL）スプリットを持っています（WAL）は、失われたmemstoreを再構築します。

データ復旧

先行書き込みログ（WAL）各操作の記録HBaseの、それぞれのPutに代わって操作するか、操作を削除します。年代順、最も古いオペレーティングヘッダレコード、最新に配置された先行書き込みログ内のすべての操作（WAL）ファイルの最後での動作。

memstore年を復元するが、HFILEデータ？再実行することができ、先行書き込みログ（WAL）を順次memstoreデータを再構築し、前後からの操作で先行書き込みログ（WAL）を実行する。最後に、フラッシュmemstoreデータを書いていない方法HFILEに、回復を完了します。

ApacheのHBaseのアーキテクチャの利点

強い一貫性モデル

- 読むと、すべてが同じ値を読み込むことを保証するために、戻るに書き込むとき

自動拡張

- データの増加が大きすぎると、自動的に分割地域

- 分散やバックアップデータの使用HFDS

内蔵の自動返信

- 先行書き込みログ（WAL）

エコ統合Hadoopの

- HBaseのマップ上で実行すると、削減します

ApacheのHBaseの問題...

事業継続の信頼性：
重放预写日志慢
故障恢复既慢又复杂
Major compaction容易引起IO风暴(写放大)

[再印刷]深さ分析HBaseのアーキテクチャ