hbase 权威指南翻译：第一章介绍

gaolu1234 · 发表于 2012-10-22 16:03

本帖最后由 gaolu1234 于 2012-10-23 15:13 编辑

implementation 实现
数据放在数据文件里面叫 HFILE 。 HFILE 内部是将 block 连续存放，并使用 block index 块索引。就是这些block 里面放了什么内容，都是有索引文件的。 HFIle打开的时候，块索引会被读入内存常驻,缺省 block大小是 64K，但是也可以根据需要配置。  可以通过API来扫描，给定了开始值和结束值后，可以根据范围扫描特定的值。
既然每个HFIle都有 block index 块索引.查询可以通过单个磁盘查找提高性能。首先，对可能包含需要查询值的block 的查询可以在内存的 block index （内存中的块索引）进行二进制格式查询来进行。然后进行读磁盘来获得真正的数据.(先在内存中的块索引block index 查索引，后在磁盘上查真实值).
HFIle 会存放在 HDFS上。有若干优点。。。
在数据被更新前，会写入 commit log ，叫 write-ahead log (WAL) ，（类似 oracle的 redo log ），然后保存在内存中的 memstore 。当内存中的数据超过一个设定值，就会被刷新到磁盘上的一个HFile （flush）。 flush 以后， commit log 会被丢弃  到最后未被刷新的部分。当系统刷新memstore到磁盘里面后，这部分内存就可以继续服务给读进程和写进程而不会阻塞这2个进程。  这就是将 memstore 在内存中滚动  来进行归档，当新的 / 空的内存被（使用来）更新时，而老的，满的内存被转换到文件。
注意：memstore 里面的数据已经按照 key排序过了，也跟hfile在磁盘上的排序精确的一致，就不需要排序和其他动作了。
内容相同的 key/value 数据对保存在一起，有利于数据压缩。原来的适用场景是存储网页，那么相似的页面地址放在一起有利压缩。例如： org.hbase.com / www.hbase.com 这样的网址.
因为存储文件是连续的，索引不能直接删除一个值来删除 key/value 对数据。  要用删除标记 delete marker 来作为里程碑标记写入记录来指示该记录已经被删除。在检索过程中，  删除标记掩盖了实际值，从client 端读取数据的操作中隐藏。
读数据涉及到memstore中保存数据的 merge ，就是这些数据还没有写到磁盘上，磁盘上的存储文件。 wal 是不用来作为数据检索的，只用来服务器当机的恢复。
flush memstore 的数据到磁盘上，越来越多的HFile 被创建出来。hbase 有了一种管家机制，把这些hfile merge 到大文件，叫压缩 compaction . 有2种类型的压缩： minor 小压缩和 marjor 主压缩。
（minor？？？）以前的压缩是将小文件写成大文件，执行一个多路merge n-way merge 。既然所有的数据都保存在每个HFile里面， merge 是很快和分界的由磁盘IO性能.
marjor 压缩是重写一个region里面的一个 cf里面的所有文件到一个新的文件。这样还有另外一个单独的特性：扫描所有的 key/value 数据对，可以丢弃有 delete marker 删除标记的记录（就是被删除的）. 谓词删除很好的处理：例如，超时的数据和超过配置时间的数据，有太多版本的数据.
这个结构来自于LSM-tree索引，区别是LSM-tree是一种在多个数据块类似 B-tree方式存储数据。hbase 是 update /merge / 在一个旋转的 fashion？？？，整个memstore 保存在一个新的存储文件里面，而不是立刻merge . 你可以称为 HBase的 log-structured sort and merge maps . 后台压缩依照LSM-tree ，但是发生在存储文件级别的部分 tree 更新。

Zookeeper :类似 google的chubby 项目。zookeeper 提供了文件系统的目录访问和文件。分布系统，所有权，注册服务，更新watch。每个region server 建立它自己的发生node 在 zookeeper里面。master 会查找所有的可用的 server 。也用来跟踪服务器当机或者网络失败。
短暂的节点 ephemral node 绑定在 zookeeper 和client 端的线程上，线程有个心跳机制来保持节点存活，当线程报告当机，被zookeeper 宣告当机，相关的短暂节点就被删除。

hbase使用 zookeeper 来保证只有一个 master 节点，来保存启动文件，这些启动文件保存了 region server的注册信息。ZOOKEEPER是个关键部件，如果没有，hbase就无法运行。 zookeeper的分布设计使用了服务器组合来环境， zab 协议保证了状态一致。

CiSong · 发表于 2012-10-23 10:45

mark

gaolu1234 · 发表于 2012-10-23 15:24

本帖最后由 gaolu1234 于 2012-10-23 16:41 编辑

hbase 构成 :
api + master + region server( hfile + memstore+writer-ahead-log)
hdfs +  zookeeper .

主节点负载处理跨region server 的 region的负载平衡。从负载压力大的 server 上把region 移动到压力小的server上。主节点不是数据存储的一部分，也不是搜索路径。主节点协调负载平衡，管理 cluster 的状态，不提供数据，因此压力是很轻的。附带的，也管理 schema 改变和其他的元数据操作，如果表建立，cf管理等。
region server 负责  在其上的所有的 region（真正保存数据的）所有的读/ 写要求 .  也在region 超过配置大小阈值的时候，负责分割 region 。  客户端直接与 region server  通讯，处理所有数据相关的操作  .

总结:
数十亿行 , 数百万的列, 数千的 version  = tb 或者pb的数据
我们已经知道google的Bigtable 存储架构是如何使用很多服务器来，通过 key  来将记录行分布，达到负载平衡和扩展到 pb  的数据，在数千台服务器上。使用的存储格式  是理想的用来读临近的 key /value 数据对，和优化的 IO block操作，能够饱和的使用磁盘的IO能力。
表扫描在线性的时间， rowkey 查询，转换能在对数级性能良好的运行。在极端的例子，在常量顺序，使用 bloom filter  ，设计 schema 用这样的方法，避免明确锁定，使用行级别原子操作组合，给了系统扩展能力，而不影响读写性能。
列导向结构，大的宽的，稀疏的表， null存储没有代价。因为每行记录都由确定的一个服务器管理， hbase是一个强一致性，使用多版本的，避免冲突的，使用并发去耦过程，获得历史变化。
实际上Bigtable 已经在google里面上线  在2005开始了，可以在不同的应用情况下使用，从批导向的处理，到实时数据处理。保存的数据从很小  例如 url 到很大，例如网页内容和卫星地图，已经成功地提供了灵活的高性能的解决方案，例如 google earth  ， google reader ， google finance ， google analytics 。