亚洲六月丁香婷婷综合,亚洲国产精品嫩草影院在线观看 ,亚洲欧洲国产成人精品

SSTable详解

DLevin — Thu, 24 Sep 2015 17:35:00 GMT

前记

几年前在读Google的BigTable论文的时候，当时�q�没有理解论文里面表辄��思想�Q�因而囫囵吞枣，�q�没有注意到SSTable的概��c��再后来开始关注HBase的设计和源码后，开始对BigTable传递的思想慢慢的清晰�v来，但是因�ؓ事情太多�Q�没有安排出旉��重读BigTable的论文。在��目里，我因��己在学HBase�Q�开始主推HBase�Q�而另一个同事则因�ؓ对Cassandra比较感冒�Q�因而他主要��x��Cassandra的设计，不过我们两个人偶��都会讨��Z��下技术、设计的各种观点和心得，然后他偶然的说了一句：Cassandra和HBase都采用SSTable格式存储�Q�然后我本能的问了一句：什么是SSTable�Q�他�q�没有回�{�，可能也不是那么几句能说清楚的�Q�或者他自己也没有尝试的去问�q�自��p��个问题。然而这个问题本�w�却一直困扰着我，因而趁着现在有一些时间深入学习HBase和Cassandra相关设计的时候先把这个问题弄清楚了�?br />

SSTable的定�?/h2>要解释这个术语的真正含义�Q�最好的�Ҏ��是从它的出处找�{�案�Q�所以重新翻开BigTable的论文。在�q�篇论文中，最初对SSTable是这么描�q�的�Q�第三页末和�W�四��初�Q�：
SSTable

The Google SSTable file format is used internally to store Bigtable data. An SSTable provides a persistent, ordered immutable map from keys to values, where both keys and values are arbitrary byte strings. Operations are provided to look up the value associated with a specified key, and to iterate over all key/value pairs in a specified key range. Internally, each SSTable contains a sequence of blocks (typically each block is 64KB in size, but this is configurable). A block index (stored at the end of the SSTable) is used to locate blocks; the index is loaded into memory when the SSTable is opened. A lookup can be performed with a single disk seek: we first find the appropriate block by performing a binary search in the in-memory index, and then reading the appropriate block from disk. Optionally, an SSTable can be completely mapped into memory, which allows us to perform lookups and scans without touching disk.

��单的非直译：
SSTable是Bigtable内部用于数据的文件格式，它的格式为文件本�w�就是一个排序的、不可变的、持久的Key/Value对Map�Q�其中Key和value都可以是��L��的byte字符丌Ӏ��用Key来查找Value�Q�或通过�l�定Key范围遍历所有的Key/Value寏V��每个SSTable包含一�p�d��的Block�Q�一般Block大小�?4KB�Q�但是它是可配置的）�Q�在SSTable的末��是Block索引�Q�用于定位Block�Q�这些烦引在SSTable打开时被加蝲到内存中�Q�在查找旉��先从内存中的索引二分查找扑ֈ�Block�Q�然后一�ơ磁盘寻道即可读取到相应的Block。还有一�U�方案是��这个SSTable加蝲到内存中�Q�从而在查找和扫描中不需要读取磁盘�?/span>

�q�个貌似��是HFile�W�一个版本的格式么，贴张图感受一下：

在HBase使用�q�程中，对这个版本的HFile遇到以下一些问题（参�?a >�q�里�Q�：
1. 解析时内存��用量比较高�?br />2. Bloom Filter和Block索引会变的很大，而媄响启动性能。具体的�Q�Bloom Filter可以增长�?00MB每个HFile�Q�而Block索引可以增长�?00MB�Q�如果一个HRegionServer中有20个HRegion�Q�则他们分别能增长到2GB�?GB的大��。HRegion需要在打开�Ӟ��需要加载所有的Block索引到内存中�Q�因而媄响启动性能�Q�而在�W�一�ơRequest�Ӟ��需要将整个Bloom Filter加蝲到内存中�Q�再开始查找，因而Bloom Filter太大会媄响第一�ơ请求的延迟�?br />而HFile在版�?中对�q�些问题做了一些优化，具体会在HFile解析时详�l�说明�?br />
SSTable作�ؓ存储使用
�l�箋BigTable的论文往下走�Q�在5.3 Tablet Serving��节中这样写道（�W?��）�Q?br />
Tablet Serving

Updates are committed to a commit log that stores redo records. Of these updates, the recently committed ones are stored in memory in a sorted buffer called a memtable; the older updates are stored in a sequence of SSTables. To recover a tablet, a tablet server reads its metadata from the METADATA table. This metadata contains the list of SSTables that comprise a tablet and a set of a redo points, which are pointers into any commit logs that may contain data for the tablet. The server reads the indices of the SSTables into memory and reconstructs the memtable by applying all of the updates that have committed since the redo points.
When a write operation arrives at a tablet server, the server checks that it is well-formed, and that the sender is authorized to perform the mutation. Authorization is performed by reading the list of permitted writers from a Chubby file (which is almost always a hit in the Chubby client cache). A valid mutation is written to the commit log. Group commit is used to improve the throughput of lots of small mutations [13, 16]. After the write has been committed, its contents are inserted into the memtable.

When a read operation arrives at a tablet server, it is similarly checked for well-formedness and proper authorization. A valid read operation is executed on a merged view of the sequence of SSTables and the memtable. Since the SSTables and the memtable are lexicographically sorted data structures, the merged view can be formed efficiently.

Incoming read and write operations can continue while tablets are split and merged.

�W�一�D�和�W�三�D늮�单描�q�ͼ�非翻译：
在新数据写入�Ӟ��q�个操作首先提交到日志中作�ؓredo�U�录�Q�最�q�的数据存储在内存的排序�~�存memtable中；旧的数据存储在一�p�d��的SSTable 中。在recover中，tablet server从METADATA表中��d��metadata�Q�metadata包含了组成Tablet的所有SSTable�Q�纪录了�q�些SSTable的元数据信息�Q�如SSTable的位�|�、StartKey、EndKey�{�）以及一�p�d��日志中的redo炏V��Tablet Server��d��SSTable的烦引到内存�Q��ƈreplay�q�些redo点之后的更新来重构memtable�?br />在读�Ӟ��完成格式、授权等��查后�Q�读会同时读取SSTable、memtable�Q�HBase中还包含了BlockCache中的数据�Q��ƈ合�ƈ他们的结果，�׃��SSTable和memtable都是字典序排列，因而合�q�操作可以很高效完成�?br />
SSTable在Compaction�q�程中的使用
在BigTable论文5.4 Compaction��节中是�q�样说的�Q?br />
Compaction

As write operations execute, the size of the memtable increases. When the memtable size reaches a threshold, the memtable is frozen, a new memtable is created, and the frozen memtable is converted to an SSTable and written to GFS. This minor compaction process has two goals: it shrinks the memory usage of the tablet server, and it reduces the amount of data that has to be read from the commit log during recovery if this server dies. Incoming read and write operations can continue while compactions occur.

Every minor compaction creates a new SSTable. If this behavior continued unchecked, read operations might need to merge updates from an arbitrary number of SSTables. Instead, we bound the number of such files by periodically executing a merging compaction in the background. A merging compaction reads the contents of a few SSTables and the memtable, and writes out a new SSTable. The input SSTables and memtable can be discarded as soon as the compaction has finished.

A merging compaction that rewrites all SSTables into exactly one SSTable is called a major compaction. SSTables produced by non-major compactions can contain special deletion entries that suppress deleted data in older SSTables that are still live. A major compaction, on the other hand, produces an SSTable that contains no deletion information or deleted data. Bigtable cycles through all of its tablets and regularly applies major compactions to them. These major compactions allow Bigtable to reclaim resources used by deleted data, and also allow it to ensure that deleted data disappears from the system in a timely fashion, which is important for services that store sensitive data.

随着memtable大小增加��C��个阀��|��q�个memtable会被��M��而创��Z��个新的memtable以供使用�Q�而旧的memtable会�{换成一个SSTable而写道GFS中，�q�个�q�程叫做minor compaction。这个minor compaction可以减少内存使用量，�q�可以减��日志大��，因�ؓ持久化后的数据可以从日志中删除�?/span>在minor compaction�q�程中，可以�l�箋处理��d��h��?br />每次minor compaction会生成新的SSTable文�g�Q�如果SSTable文�g数量增加�Q�则会媄响读的性能�Q�因而每�ơ读都需要读取所有SSTable文�g�Q�然后合�q�结果，因而对SSTable文�g个数需要有上限�Q��ƈ且时不时的需要在后台做merging compaction�Q�这个merging compaction��d��一些SSTable文�g和memtable的内容，�q�将他们合�ƈ写入一个新的SSTable中。当�q�个�q�程完成后，�q�些源SSTable和memtable��可以被删除了�?br />如果一个merging compaction是合�q�所有SSTable��C��个SSTable�Q�则�q�个�q�程�U�做major compaction。一�ơmajor compaction会将mark成删除的信息、数据删除，而其他两�ơcompaction则会保留�q�些信息、数据（mark的�Ş式）。Bigtable会时不时的扫描所有的Tablet�Q��ƈ对它们做major compaction。这个major compaction可以��需要删除的数据真正的删除从而节省空��_��q�保持系�l�一致性�?/span>
SSTable的locality和In Memory
在Bigtable中，它的本地性是由Locality group来定义的�Q�即多个column family可以�l�合��C��个locality group中，在同一个Tablet中，使用单独的SSTable存储�q�些在同一个locality group的column family。HBase把这个模型简化了�Q�即每个column family在每个HRegion都��用单独的HFile存储�Q�HFile没有locality group的概念，或者一个column family��是一个locality group�?/span>

在Bigtable中，�q�可以支持在locality group�U�别讄��是否��所有这个locality group的数据加载到内存中，在HBase中通过column family定义时设�|�。这个内存加载采用�g时加载，主要应用于一些小的column family�Q��ƈ且经常被用到的，从而提升读的性能�Q�因而这样就不需要再从磁盘中��d��了�?/span>
SSTable压羃
Bigtable的压�~�是��Z��locality group�U�别�Q?br />
Compression

Clients can control whether or not the SSTables for a locality group are compressed, and if so, which compression format is used. The user-specified compression format is applied to each SSTable block (whose size is controllable via a locality group specific tuning parameter). Although we lose some space by compressing each block separately, we benefit in that small portions of an SSTable can be read without decompressing the entire file. Many clients use a two-pass custom compression scheme. The first pass uses Bentley and McIlroy’s scheme [6], which compresses long common strings across a large window. The second pass uses a fast compression algorithm that looks for repetitions in a small 16 KB window of the data. Both compression passes are very fast—they encode at 100–200 MB/s, and decode at 400–1000 MB/s on modern machines.
Bigtable的压�~�以SSTable中的一个Block为单位，虽然每个Block为压�~�单位损�׃��些空��_��但是采用�q�种方式�Q�我们可以以Block为单位读取、解压、分析，而不是每�ơ以一�?#8220;�?#8221;的SSTable为单位读取、解压、分析�?/span>
SSTable的读�~�存
��Z��提升�ȝ��性能�Q�Bigtable采用两层�~�存机制�Q?br />
Caching for read performance

To improve read performance, tablet servers use two levels of caching. The Scan Cache is a higher-level cache that caches the key-value pairs returned by the SSTable interface to the tablet server code. The Block Cache is a lower-level cache that caches SSTables blocks that were read from GFS. The Scan Cache is most useful for applications that tend to read the same data repeatedly. The Block Cache is useful for applications that tend to read data that is close to the data they recently read (e.g., sequential reads, or random reads of different columns in the same locality group within a hot row).
两层�~�存分别是：
1. High Level�Q�缓存从SSTable��d��的Key/Value寏V��提升那些們֐�重复的读取相同的数据的操作（引用局部性原理）�?br />2. Low Level�Q�BlockCache�Q�缓存SSTable中的Block。提升那些們֐�于读取相�q�数据的操作�?br />
Bloom Filter
前文有提到Bigtable采用合�ƈ读，即需要读取每个SSTable中的相关数据�Q��ƈ合�ƈ成一个结果返回，然而每�ơ读都需要读取所有SSTable�Q�自然会耗费性能�Q�因而引入了Bloom Filter�Q�它可以很快速的扑ֈ�一个RowKey不在某个SSTable中的事实�Q�注�Q�反�q�来则不成立�Q��?br />
Bloom Filter

As described in Section 5.3, a read operation has to read from all SSTables that make up the state of a tablet. If these SSTables are not in memory, we may end up doing many disk accesses. We reduce the number of accesses by allowing clients to specify that Bloom fil- ters [7] should be created for SSTables in a particu- lar locality group. A Bloom filter allows us to ask whether an SSTable might contain any data for a spec- ified row/column pair. For certain applications, a small amount of tablet server memory used for storing Bloom filters drastically reduces the number of disk seeks re- quired for read operations. Our use of Bloom filters also implies that most lookups for non-existent rows or columns do not need to touch disk.

SSTable设计成Immutable的好�?/h2>在SSTable定义中就有提到SSTable是一个Immutable的order map�Q�这个Immutable的设计可以让�pȝ��单很多：
Exploiting Immutability

Besides the SSTable caches, various other parts of the Bigtable system have been simplified by the fact that all of the SSTables that we generate are immutable. For example, we do not need any synchronization of accesses to the file system when reading from SSTables. As a result, concurrency control over rows can be implemented very efficiently. The only mutable data structure that is accessed by both reads and writes is the memtable. To reduce contention during reads of the memtable, we make each memtable row copy-on-write and allow reads and writes to proceed in parallel.
Since SSTables are immutable, the problem of permanently removing deleted data is transformed to garbage collecting obsolete SSTables. Each tablet’s SSTables are registered in the METADATA table. The master removes obsolete SSTables as a mark-and-sweep garbage collection [25] over the set of SSTables, where the METADATA table contains the set of roots.

Finally, the immutability of SSTables enables us to split tablets quickly. Instead of generating a new set of SSTables for each child tablet, we let the child tablets share the SSTables of the parent tablet.

关于Immutable的优�Ҏ��以下几点�Q?/span>
1. 在读SSTable是不需要同步。读写同步只需要在memtable中处理，��Z��减少memtable的读写竞争，Bigtable��memtable的row设计成copy-on-write�Q�从而读写可以同时进行�?/span>
2. �怹�的移除数据�{变�ؓSSTable的Garbage Collect。每个Tablet中的SSTable在METADATA表中有注册，master使用mark-and-sweep��法��SSTable在GC�q�程中移除�?/span>
3. 可以让Tablet Split�q�程变的高效�Q�我们不需要�ؓ每个子Tablet创徏新的SSTable�Q�而是可以�׃�n�?/span>Tablet的SSTable�?/span>

DLevin 2015-09-25 01:35 发表评论

DLevin — Sat, 22 Aug 2015 11:40:00 GMT

前言

�q�是《深入HBase架构解析�Q�一�Q��?/a>的箋�Q�不多废话，�l�箋。。。�?br />

HBase�ȝ��实现

通过前文的描�q�ͼ�我们知道在HBase写时�Q�相同Cell(RowKey/ColumnFamily/Column相同)�q�不保证在一��P��甚至删除一个Cell也只是写入一个新的Cell�Q�它含有Delete标记�Q�而不一定将一个Cell真正删除了，因而这��引起了一个问题，如何实现�ȝ��问题�Q�要解决�q�个问题�Q�我们先来分析一下相同的Cell可能存在的位�|�：首先�Ҏ��写入的Cell�Q�它会存在于MemStore中；然后对之前已�l�Flush到HDFS中的Cell�Q�它会存在于某个或某些StoreFile(HFile)中；最后，对刚��d��q�的Cell�Q�它可能存在于BlockCache中。既然相同的Cell可能存储在三个地方，在读取的时候只需要扫瞄这三个地方�Q�然后将�l�果合�ƈ卛_��(Merge Read)�Q�在HBase中扫瞄的��序依次是：BlockCache、MemStore、StoreFile(HFile)。其中StoreFile的扫瞄先会��用Bloom Filter�q��o那些不可能符合条件的HFile�Q�然后��用Block Index快速定位Cell�Q��ƈ��其加蝲到BlockCache中，然后从BlockCache中读取。我们知道一个HStore可能存在多个StoreFile(HFile)�Q�此旉��要扫瞄多个HFile�Q�如果HFile�q�多又是会引��h��能问题�?br />

Compaction

MemStore每次Flush会创建新的HFile�Q�而过多的HFile会引赯��的性能问题�Q�那么如何解册��个问题呢�Q�HBase采用Compaction机制来解册��个问题，有点�c�M��Java中的GC机制�Q��v初Java不停的申请内存而不释放�Q�增加性能�Q�然而天下没有免费的午餐�Q�最�l�我们还是要在某个条件下��L��集垃圾，很多时候需要Stop-The-World�Q�这�U�Stop-The-World有些时候也会引起很大的问题�Q�比如参考本人写�?a href="http://m.tkk7.com/DLevin/archive/2015/08/01/426418.html">�q�篇文章�Q�因而设计是一�U�权衡，没有完美的。还是类似Java中的GC�Q�在HBase中Compaction分�ؓ两种�Q�Minor Compaction和Major Compaction�?br />

Minor Compaction是指选取一些小的、相�ȝ��StoreFile��他们合�q�成一个更大的StoreFile�Q�在�q�个�q�程中不会处理已�l�Deleted或Expired的Cell。一�ơMinor Compaction的结果是更少�q�且更大的StoreFile。（�q�个是对的吗�Q�BigTable中是�q�样描述Minor Compaction�?span style="font-size: 10.000000pt; font-family: 'Times'">�Q�As write operations execute, the size of the memtable in- creases. When the memtable size reaches a threshold, the memtable is frozen, a new memtable is created, and the frozen memtable is converted to an SSTable and written to GFS. This minor compaction process has two goals: it shrinks the memory usage of the tablet server, and it reduces the amount of data that has to be read from the commit log during recovery if this server dies. Incom- ing read and write operations can continue while com- pactions occur. 也就是说它将memtable的数据flush的一个HFile/SSTable�U�Cؓ一�ơMinor Compaction�Q?/li>
Major Compaction是指��所有的StoreFile合�ƈ成一个StoreFile�Q�在�q�个�q�程中，标记为Deleted的Cell会被删除�Q�而那些已�l�Expired的Cell会被丢弃�Q�那些已�l�超�q�最多版本数的Cell会被丢弃。一�ơMajor Compaction的结果是一个HStore只有一个StoreFile存在。Major Compaction可以手动或自动触发，然而由于它会引起很多的IO操作而引��h��能问题�Q�因而它一般会被安排在周末、凌晨等集群比较闲的旉��?br />

更�Ş象一点，如下面两张图分别表示Minor Compaction和Major Compaction�?br />

HRegion Split

最初，一个Table只有一个HRegion�Q�随着数据写入增加�Q�如果一个HRegion到达一定的大小�Q�就需要Split成两个HRegion�Q�这个大��由hbase.hregion.max.filesize指定�Q�默认�ؓ10GB。当split�Ӟ��两个新的HRegion会在同一个HRegionServer中创建，它们各自包含父HRegion一半的数据�Q�当Split完成后，父HRegion会下�U�，而新的两个子HRegion会向HMaster注册上线�Q�处于负载均衡的考虑�Q�这两个新的HRegion可能会被HMaster分配到其他的HRegionServer中。关于Split的详�l�信息，可以参考这��文章：《Apache HBase Region Splitting and Merging�?/a>�?br />

HRegion负蝲均衡

在HRegion Split后，两个新的HRegion最初会和之前的父HRegion在相同的HRegionServer上，��Z��负蝲均衡的考虑�Q�HMaster可能会将其中的一个甚至两个重新分配的其他的HRegionServer中，此时会引��h��些HRegionServer处理的数据在其他节点上，直到下一�ơMajor Compaction��数据从�q�端的节点移动到本地节点�?br />

HRegionServer Recovery

当一台HRegionServer宕机�Ӟ��׃��它不再发送Heartbeat�l�ZooKeeper而被监测刎ͼ�此时ZooKeeper会通知HMaster�Q�HMaster会检��到哪台HRegionServer宕机�Q�它��宕机的HRegionServer中的HRegion重新分配�l�其他的HRegionServer�Q�同时HMaster会把宕机的HRegionServer相关的WAL拆分分配�l�相应的HRegionServer(��拆分出的WAL文�g写入对应的目的HRegionServer的WAL目录中，�q��ƈ写入对应的DataNode中）�Q�从而这些HRegionServer可以Replay分到的WAL来重建MemStore�?br />

HBase架构��单�ȝ��

在NoSQL中，存在著名的CAP理论�Q�即Consistency、Availability、Partition Tolerance不可全得�Q�目前市��Z��基本上的NoSQL都采用Partition Tolerance以实现数据得水��^扩展�Q�来处理Relational DataBase遇到的无法处理数据量太大的问题，或引��L��性能问题。因而只有剩下C和A可以选择。HBase在两者之间选择了Consistency�Q�然后��用多个HMaster以及支持HRegionServer的failure监控、ZooKeeper引入作�ؓ协调者等各种手段来解决Availability问题�Q�然而当�|�络的Split-Brain(Network Partition)发生�Ӟ��它还是无法完全解决Availability的问题。从�q�个角度上，Cassandra选择了A�Q�即它在�|�络Split-Brain时还是能正常写，而��用其他技术来解决Consistency的问题，如读的时候触发Consistency判断和处理。这是设计上的限制�?br />
从实��C��的优点：

HBase采用��Z��致性模型，在一个写�q�回后，保证所有的读都��d��相同的数据�?/li>
通过HRegion动态Split和Merge实现自动扩展�Q��ƈ使用HDFS提供的多个数据备份功能，实现高可用性�?/li>
采用HRegionServer和DataNode�q�行在相同的服务器上实现数据的本地化�Q�提升读写性能�Q��ƈ减少�|�络压力�?/li>
内徏HRegionServer的宕��动恢复。采用WAL来Replay�q�未持久化到HDFS的数据�?/li>
可以无缝的和Hadoop/MapReduce集成�?br />

实现上的�~�点�Q?br />

WAL的Replay�q�程可能会很慢�?/li>
��N��恢复比较复杂�Q�也会比较慢�?/li>
Major Compaction会引起IO Storm�?/li>
。。。�?br />

参考：

https://www.mapr.com/blog/in-depth-look-hbase-architecture#.VdNSN6Yp3qx
http://jimbojw.com/wiki/index.php?title=Understanding_Hbase_and_BigTable
http://hbase.apache.org/book.html
http://www.searchtb.com/2011/01/understanding-hbase.html
http://research.google.com/archive/bigtable-osdi06.pdf

DLevin 2015-08-22 19:40 发表评论

DLevin — Sat, 22 Aug 2015 09:44:00 GMT

前记

公司内部使用的是MapR版本的Hadoop生态系�l�，因而从MapR的官�|�看��C��q�篇文文章：An In-Depth Look at the HBase Architecture�Q�原本想��译全文�Q�然而如果翻译就需要各�U�咬文嚼字，太麻烦，因而本文大部分使用了自��q��语言�Q��ƈ且加入了其他资源的参考理解以及本��p��源码时对其的理解�Q�属于半��译、半原创吧�?br />

HBase架构�l�成

HBase采用Master/Slave架构搭徏集群�Q�它隶属于Hadoop生态系�l�，�׃��下类型节点组成：HMaster节点、HRegionServer节点、ZooKeeper集群�Q�而在底层�Q�它��数据存储于HDFS中，因而涉及到HDFS的NameNode、DataNode�{�，��M��l�构如下�Q?br />
其中HMaster节点用于�Q?br />

��理HRegionServer�Q�实现其负蝲均衡�?/li>
��理和分配HRegion�Q�比如在HRegion split时分配新的HRegion�Q�在HRegionServer退出时�q�移其内的HRegion到其他HRegionServer上�?/li>
实现DDL操作�Q�Data Definition Language�Q�namespace和table的增删改�Q�column familiy的增删改�{�）�?/li>
��理namespace和table的元数据�Q�实际存储在HDFS上）�?/li>
权限控制�Q�ACL�Q��?/li>

HRegionServer节点用于�Q?br />

存放和管理本地HRegion�?/li>
��d��HDFS�Q�管理Table中的数据�?/li>
Client直接通过HRegionServer��d��数据�Q�从HMaster中获取元数据�Q�找到RowKey所在的HRegion/HRegionServer后）�?/li>

ZooKeeper集群是协调系�l?/strong>�Q�用于：

存放整个 HBase集群的元数据以及集群的状态信息�?/li>
实现HMaster��M��节点的failover�?/li>
HBase Client通过RPC方式和HMaster、HRegionServer通信�Q�一个HRegionServer可以存放1000个HRegion�Q�底层Table数据存储于HDFS中，而HRegion所处理的数据尽量和数据所在的DataNode在一��P��实现数据的本地化�Q�数据本地化�q�不是总能实现�Q�比如在HRegion�U�d��(如因Split)�Ӟ��需要等下一�ơCompact才能�l�箋回到本地化�?br />
本着半翻译的原则�Q�再贴一个《An In-Depth Look At The HBase Architecture》的架构图：

�q�个架构图比较清晰的表达了HMaster和NameNode都支持多个热备䆾�Q��用ZooKeeper来做协调�Q�ZooKeeper�q�不是云般神�U�，它一般由三台机器�l�成一个集��，内部使用PAXOS��法支持三台Server中的一台宕机，也有使用五台机器的，此时则可以支持同时两台宕机，既少于半数的宕机�Q�然而随着机器的增加，它的性能也会下降�Q�RegionServer和DataNode一般会攑֜�相同的Server上实现数据的本地化�?br />
HRegion
HBase使用RowKey��表水��^切割成多个HRegion�Q�从HMaster的角度，每个HRegion都纪录了它的StartKey和EndKey�Q�第一个HRegion的StartKey为空�Q�最后一个HRegion的EndKey为空�Q�，�׃��RowKey是排序的�Q�因而Client可以通过HMaster快速的定位每个RowKey在哪个HRegion中。HRegion由HMaster分配到相应的HRegionServer中，然后由HRegionServer负责HRegion的启动和��理�Q�和Client的通信�Q�负责数据的�?使用HDFS)。每个HRegionServer可以同时��理1000个左右的HRegion�Q�这个数字怎么来的�Q�没有从代码中看到限�Ӟ��N��是出于经验？��过1000个会引�v性能问题�Q?strong>来回�{�这个问�?/strong>�Q�感觉这�?000的数字是从BigTable的论文中来的�Q? Implementation节）�Q�Each tablet server manages a set of tablets(typically we have somewhere between ten to a thousand tablets per tablet server)�Q��?br />

HMaster
HMaster没有单点故障问题�Q�可以启动多个HMaster�Q�通过ZooKeeper的Master Election机制保证同时只有一个HMaster��Z��Active状态，其他的HMaster则处于热备䆾状态。一般情况下会启动两个HMaster�Q�非Active的HMaster会定期的和Active HMaster通信以获取其最新状态，从而保证它是实时更新的�Q�因而如果启动了多个HMaster反而增加了Active HMaster的负担。前文已�l�介�l�过了HMaster的主要用于HRegion的分配和��理�Q�DDL(Data Definition Language�Q�既Table的新建、删除、修改等)的实现等�Q�既它主要有两方面的职责�Q?br />

协调HRegionServer

启动时HRegion的分配，以及负蝲均衡和修复时HRegion的重新分配�?/li>
监控集群中所有HRegionServer的状�?通过Heartbeat和监听ZooKeeper中的状�?�?br />

Admin职能

创徏、删除、修改Table的定义�?br />

ZooKeeper�Q�协调�?/h2> ZooKeeper为HBase集群提供协调服务�Q�它��理着HMaster和HRegionServer的状�?available/alive�{?�Q��ƈ且会在它们宕机时通知�l�HMaster�Q�从而HMaster可以实现HMaster之间的failover�Q�或对宕机的HRegionServer中的HRegion集合的修�?��它们分配给其他的HRegionServer)。ZooKeeper集群本��n使用一致性协�?PAXOS协议)保证每个节点状态的一致性�?br />

How The Components Work Together
ZooKeeper协调集群所有节点的�׃�n信息�Q�在HMaster和HRegionServer�q�接到ZooKeeper后创建Ephemeral节点�Q��ƈ使用Heartbeat机制�l�持�q�个节点的存�zȝ��态，如果某个Ephemeral节点实效�Q�则HMaster会收到通知�Q��ƈ做相应的处理�?br />
另外�Q�HMaster通过监听ZooKeeper中的Ephemeral节点(默认�Q?hbase/rs/*)来监控HRegionServer的加入和宕机。在�W�一个HMaster�q�接到ZooKeeper时会创徏Ephemeral节点(默认�Q?hbasae/master)来表�C�Active的HMaster�Q�其后加�q�来的HMaster则监听该Ephemeral节点�Q�如果当前Active的HMaster宕机�Q�则该节�Ҏ��失，因而其他HMaster得到通知�Q�而将自��n转换成Active的HMaster�Q�在变�ؓActive的HMaster之前�Q�它会创建在/hbase/back-masters/下创��q��Ephemeral节点�?br />
HBase的第一�ơ读�?/h3> 在HBase 0.96以前�Q�HBase有两个特�D�的Table�Q?ROOT-�?META.�Q�如BigTable中的设计�Q�，其中-ROOT- Table的位�|�存储在ZooKeeper�Q�它存储�?META. Table的RegionInfo信息�Q��ƈ且它只能存在一个HRegion�Q��?META. Table则存储了用户Table的RegionInfo信息�Q�它可以被切分成多个HRegion�Q�因而对�W�一�ơ访问用户Table�Ӟ��首先从ZooKeeper中读�?ROOT- Table所在HRegionServer�Q�然后从该HRegionServer中根据请求的TableName�Q�RowKey��d��.META. Table所在HRegionServer�Q�最后从该HRegionServer中读�?META. Table的内容而获取此�ơ请求需要访问的HRegion所在的位置�Q�然后访问该HRegionSever获取��h��的数据，�q�需要三�ơ请求才能找到用户Table所在的位置�Q�然后第四次��h��开始获取真正的数据。当然�ؓ了提升性能�Q�客��L��会缓�?ROOT- Table位置以及-ROOT-/.META. Table的内宏V��如下图所�C�：

可是即��客户端有�~�存�Q�在初始阶段需要三�ơ请求才能直到用户Table真正所在的位置也是性能低下的，而且真的有必要支持那么多的HRegion吗？或许对Google�q�样的公司来说是需要的�Q�但是对一般的集群来说好像�q�没有这个必要。在BigTable的论文中��_��每行METADATA存储1KB左右数据�Q�中�{�大��的Tablet(HRegion)�?28MB左右�Q?层位�|�的Schema设计可以支持2^34个Tablet(HRegion)。即使去�?ROOT- Table�Q�也�q�可以支�?^17(131072)个HRegion�Q?如果每个HRegion�q�是128MB�Q�那��是16TB�Q�这个貌��g��够大�Q�但是现在的HRegion的最大大��都会设�|�的比较大，比如我们讄��?GB�Q�此时支持的大小则变成了4PB�Q�对一般的集群来说已经够了�Q�因而在HBase 0.96以后��L��?ROOT- Table�Q�只剩下�q�个�Ҏ��的目录表叫做Meta Table(hbase:meta)�Q�它存储了集��中所有用户HRegion的位�|�信息，而ZooKeeper的节点中(/hbase/meta-region-server)存储的则直接是这个Meta Table的位�|�，�q�且�q�个Meta Table如以前的-ROOT- Table一��h��不可split的。这��P��客户端在�W�一�ơ访问用户Table的流�E�就变成了：

从ZooKeeper(/hbase/meta-region-server)中获取hbase:meta的位�|�（HRegionServer的位�|�）�Q�缓存该位置信息�?/li>
从HRegionServer中查询用户Table对应��h��的RowKey所在的HRegionServer�Q�缓存该位置信息�?/li>
从查询到HRegionServer中读取Row�?/li>
从这个过�E�中�Q�我们发现客户会�~�存�q�些位置信息�Q�然而第二步它只是缓存当前RowKey对应的HRegion的位�|�，因而如果下一个要查的RowKey不在同一个HRegion中，则需要��l�查询hbase:meta所在的HRegion�Q�然而随着旉��的推�U�，客户端缓存的位置信息��来��多�Q�以至于不需要再�ơ查找hbase:meta Table的信息，除非某个HRegion因�ؓ宕机或Split被移动，此时需要重新查询�ƈ且更新缓存�?br />

hbase:meta�?/h3> hbase:meta表存储了所有用户HRegion的位�|�信息，它的RowKey是：tableName,regionStartKey,regionId,replicaId�{�，它只有info列族�Q�这个列族包含三个列�Q�他们分别是�Q�info:regioninfo列是RegionInfo的proto格式�Q�regionId,tableName,startKey,endKey,offline,split,replicaId�Q�info:server格式�Q�HRegionServer对应的server:port�Q�info:serverstartcode格式是HRegionServer的启动时间戳�?br />

HRegionServer详解
HRegionServer一般和DataNode在同一台机器上�q�行�Q�实现数据的本地性。HRegionServer包含多个HRegion�Q�由WAL(HLog)、BlockCache、MemStore、HFile�l�成�?br />

WAL即Write Ahead Log�Q�在早期版本中称为HLog�Q�它是HDFS上的一个文�Ӟ��如其名字所表示的，所有写操作都会先保证将数据写入�q�个Log文�g后，才会真正更新MemStore�Q�最后写入HFile中。采用这�U�模式，可以保证HRegionServer宕机后，我们依然可以从该Log文�g中读取数据，Replay所有的操作�Q�而不至于数据丢失。这个Log文�g会定期Roll出新的文件而删除旧的文�?那些已持久化到HFile中的Log可以删除)。WAL文�g存储�?hbase/WALs/${HRegionServer_Name}的目录中(�?.94之前�Q�存储在/hbase/.logs/目录�?�Q�一般一个HRegionServer只有一个WAL实例�Q�也��是说一个HRegionServer的所有WAL写都是串行的(��像log4j的日志写也是串行�?�Q�这当然会引��h��能问题�Q�因而在HBase 1.0之后�Q�通过HBASE-5699实现了多个WAL�q�行�?MultiWAL)�Q�该实现采用HDFS的多个管道写�Q�以单个HRegion为单位。关于WAL可以参考Wikipedia�?a >Write-Ahead Logging。顺便吐槽一句，英文版的�l�基癄��竟然能毫无压力的正常讉K��了，�q�是某个GFW的疏忽还是以后的常态？

BlockCache是一个读�~�存�Q�即“引用局部�?#8221;原理�Q�也应用于CPU�Q?a >分空间局部性和旉��局部�?/a>�Q�空间局部性是指CPU在某一时刻需要某个数据，那么有很大的概率在一下时��d��需要的数据在其附近�Q�时间局部性是指某个数据在被访问过一�ơ后�Q�它有很大的概率在不久的��来会被再次的访问）�Q�将数据预读取到内存中，以提升读的性能。HBase中提供两�U�BlockCache的实玎ͼ�默认on-heap LruBlockCache和BucketCache(通常是off-heap)。通常BucketCache的性能要差于LruBlockCache�Q�然而由于GC的媄响，LruBlockCache的�g�q�会变的不稳定，而BucketCache�׃��是自��q��理BlockCache�Q�而不需要GC�Q�因而它的�g�q�通常比较�E�_��Q�这也是有些时候需要选用BucketCache的原因。这��文�?a >BlockCache101对on-heap和off-heap的BlockCache做了详细的比较�?/li>
HRegion是一个Table中的一个Region在一个HRegionServer中的表达。一个Table可以有一个或多个Region�Q�他们可以在一个相同的HRegionServer上，也可以分布在不同的HRegionServer上，一个HRegionServer可以有多个HRegion�Q�他们分别属于不同的Table。HRegion由多个Store(HStore)构成�Q�每个HStore对应了一个Table在这个HRegion中的一个Column Family�Q�即每个Column Family��是一个集中的存储单元�Q�因而最好将��h��相近IO�Ҏ��的Column存储在一个Column Family�Q�以实现高效��d��(数据局部性原理，可以提高�~�存的命中率)。HStore是HBase中存储的核心�Q�它实现了读写HDFS功能�Q�一个HStore�׃��个MemStore �?个或多个StoreFile�l�成�?br />

MemStore是一个写�~�存(In Memory Sorted Buffer)�Q�所有数据的写在完成WAL日志写后�Q�会写入MemStore中，由MemStore�Ҏ��一定的��法��数据Flush到地层HDFS文�g�?HFile)�Q�通常每个HRegion中的每个 Column Family有一个自��q��MemStore�?/li>
HFile(StoreFile) 用于存储HBase的数�?Cell/KeyValue)。在HFile中的数据是按RowKey、Column Family、Column排序�Q�对相同的Cell(卌��三个值都一�?�Q�则按timestamp倒序排列�?/li>

虽然上面�q�张囑ֱ�现的是最新的HRegionServer的架�?但是�q�不是那么的�_��)�Q�但是我一直比较喜�Ƣ看以下�q�张图，即��它展现的应该�?.94以前的架构�?br />

HRegionServer中数据写��程图解
当客��L��发�v一个Put��h��Ӟ��首先它从hbase:meta表中查出该Put数据最�l�需要去的HRegionServer。然后客��L��Put��h��发送给相应的HRegionServer�Q�在HRegionServer中它首先会将该Put操作写入WAL日志文�g�?Flush到磁盘中)�?br />
写完WAL日志文�g后，HRegionServer�Ҏ��Put中的TableName和RowKey扑ֈ�对应的HRegion�Q��ƈ�Ҏ��Column Family扑ֈ�对应的HStore�Q��ƈ��Put写入到该HStore的MemStore中。此时写成功�Q��ƈ�q�回通知客户端�?br />
MemStore Flush
MemStore是一个In Memory Sorted Buffer�Q�在每个HStore中都有一个MemStore�Q�即它是一个HRegion的一个Column Family对应一个实例。它的排列顺序以RowKey、Column Family、Column的顺序以及Timestamp的倒序�Q�如下所�C�：

每一�ơPut/Delete��h��都是先写入到MemStore中，当MemStore满后会Flush成一个新的StoreFile(底层实现是HFile)�Q�即一个HStore(Column Family)可以�?个或多个StoreFile(HFile)。有以下三种情况可以触发MemStore的Flush动作�Q?strong>需要注意的是MemStore的最��Flush单元是HRegion而不是单个MemStore。据说这是Column Family有个数限制的其中一个原因，估计是因为太多的Column Family一起Flush会引��h��能问题�Q�具体原因有待考证�?br />

当一个HRegion中的所有MemStore的大��d��过了hbase.hregion.memstore.flush.size的大��，默认128MB。此时当前的HRegion中所有的MemStore会Flush到HDFS中�?/li>
当全局MemStore的大��超�q�了hbase.regionserver.global.memstore.upperLimit的大��，默认40�Q�的内存使用量。此时当前HRegionServer中所有HRegion中的MemStore都会Flush到HDFS中，Flush��序是MemStore大小的倒序�Q�一个HRegion中所有MemStore��d��作�ؓ该HRegion的MemStore的大��还是选取最大的MemStore作�ؓ参考？有待考证�Q�，直到��M��的MemStore使用量低于hbase.regionserver.global.memstore.lowerLimit�Q�默�?8%的内存��用量�?/li>
当前HRegionServer中WAL的大��超�q�了hbase.regionserver.hlog.blocksize * hbase.regionserver.max.logs的数量，当前HRegionServer中所有HRegion中的MemStore都会Flush到HDFS中，Flush使用旉��序�Q�最早的MemStore先Flush直到WAL的数量少于hbase.regionserver.hlog.blocksize * hbase.regionserver.max.logs�?a >�q�里说这两个�怹�的默认大��是2GB�Q�查代码�Q�hbase.regionserver.max.logs默认值是32�Q�而hbase.regionserver.hlog.blocksize是HDFS的默认blocksize�Q?2MB。但不管怎么��P��因�ؓ�q�个大小��过限制引�v的Flush不是一件好事，可能引�v长时间的延迟�Q�因而这��文章给的徏议：“Hint: keep hbase.regionserver.hlog.blocksize * hbase.regionserver.maxlogs just a bit above hbase.regionserver.global.memstore.lowerLimit * HBASE_HEAPSIZE.”。�ƈ且需要注意，�q�里�l�的描述是有错的(虽然它是官方的文�?�?br />

在MemStore Flush�q�程中，�q�会在尾部追加一些meta数据�Q�其中就包括Flush时最大的WAL sequence��|��以告诉HBase�q�个StoreFile写入的最新数据的序列�Q�那么在Recover时就直到从哪里开始。在HRegion启动�Ӟ��q�个sequence会被��d��Q��ƈ取最大的作�ؓ下一�ơ更新时的�v始sequence�?br />

HFile格式

HBase的数据以KeyValue(Cell)的�Ş式顺序的存储在HFile中，在MemStore的Flush�q�程中生成HFile�Q�由于MemStore中存储的Cell遵��@相同的排列顺序，因而Flush�q�程是顺序写�Q�我们直到磁盘的��序写性能很高�Q�因��Z��需要不停的�U�d��盘指针�?br />
HFile参考BigTable的SSTable和Hadoop�?a >TFile实现�Q�从HBase开始到现在�Q�HFile�l�历了三个版本，其中V2�?.92引入�Q�V3�?.98引入。首先我们来看一下V1的格式：

V1的HFile由多个Data Block、Meta Block、FileInfo、Data Index、Meta Index、Trailer�l�成�Q�其中Data Block是HBase的最��存储单元，在前文中提到的BlockCache��是��Z��Data Block的缓存的。一个Data Block�׃��个魔数和一�p�d��的KeyValue(Cell)�l�成�Q�魔数是一个随机的数字�Q�用于表�C��是一个Data Block�c�d��Q�以快速监��这个Data Block的格式，防止数据的破坏。Data Block的大��可以在创徏Column Family时设�|?HColumnDescriptor.setBlockSize())�Q�默认值是64KB�Q�大��L��Block有利于顺序Scan�Q�小号Block利于随机查询�Q�因而需要权衡。Meta块是可选的�Q�FileInfo是固定长度的块，它纪录了文�g的一些Meta信息�Q�例如：AVG_KEY_LEN, AVG_VALUE_LEN, LAST_KEY, COMPARATOR, MAX_SEQ_ID_KEY�{�。Data Index和Meta Index�U�录了每个Data块和Meta块的其实炏V��未压羃时大��、Key(起始RowKey�Q?�{�。Trailer�U�录了FileInfo、Data Index、Meta Index块的起始位置�Q�Data Index和Meta Index索引的数量等。其中FileInfo和Trailer是固定长度的�?br />
HFile里面的每个KeyValue对就是一个简单的byte数组。但是这个byte数组里面包含了很多项�Q��ƈ且有固定的结构。我们来看看里面的具体结构：

开始是两个固定长度的数��|��分别表示Key的长度和Value的长度。紧接着是Key�Q�开始是固定长度的数��|��表示RowKey的长度，紧接着�? RowKey�Q�然后是固定长度的数��|��表示Family的长度，然后是Family�Q�接着是Qualifier�Q�然后是两个固定长度的数��|��表示Time Stamp和Key Type�Q�Put/Delete�Q�。Value部分没有�q�么复杂的结构，��是�U��a的二�q�制数据了�?strong>随着HFile版本�q�移�Q�KeyValue(Cell)的格式�ƈ未发生太多变化，只是在V3版本�Q�尾部添加了一个可选的Tag数组�?br />
HFileV1版本的在实际使用�q�程中发现它占用内存多，�q�且Bloom File和Block Index会变的很大，而引起启动时间变�ѝ��其中每个HFile的Bloom Filter可以增长�?00MB�Q�这在查询时会引��h��能问题�Q�因为每�ơ查询时需要加载�ƈ查询Bloom Filter�Q?00MB的Bloom Filer会引起很大的延迟�Q�另一个，Block Index在一个HRegionServer可能会增长到��d��6GB�Q�HRegionServer在启动时需要先加蝲所有这些Block Index�Q�因而增加了启动旉��。�ؓ了解册��些问题，�?.92版本中引入HFileV2版本�Q?br />
在这个版本中�Q�Block Index和Bloom Filter��d��C��Data Block中间�Q�而这�U�设计同时也减少了写的内存��用量�Q�另外，��Z��提升启动速度�Q�在�q�个版本中还引入了�g�q�读的功能，卛_��HFile真正被��用时才对其进行解析�?br />
FileV3版本基本和V2版本相比�Q��ƈ没有太大的改变，它在KeyValue(Cell)层面上添加了Tag数组的支持；�q�在FileInfo�l�构中添加了和Tag相关的两个字�D�c��关于具体HFile格式演化介绍�Q�可以参�?a >�q�里�?br />
对HFileV2格式具体分析�Q�它是一个多层的�c�B+树烦引，采用�q�种设计�Q�可以实现查找不需要读取整个文�Ӟ��

Data Block中的Cell都是升序排列�Q�每个block都有它自��q��Leaf-Index�Q�每个Block的最后一个Key被放入Intermediate-Index中，Root-Index指向Intermediate-Index。在HFile的末��还有Bloom Filter用于快速定位那么没有在某个Data Block中的Row�Q�TimeRange信息用于�l�那些��用时间查询的参考。在HFile打开�Ӟ��q�些索引信息都被加蝲�q�保存在内存中，以增加以后的��d��性能�?br />
�q�篇��先写到�q�里�Q�未完待�l�。。。�?br />

参考：

https://www.mapr.com/blog/in-depth-look-hbase-architecture#.VdNSN6Yp3qx
http://jimbojw.com/wiki/index.php?title=Understanding_Hbase_and_BigTable
http://hbase.apache.org/book.html
http://www.searchtb.com/2011/01/understanding-hbase.html
http://research.google.com/archive/bigtable-osdi06.pdf

DLevin 2015-08-22 17:44 发表评论