标签：color 文件 分享图片 hdf 维度 key 查找 写入 content
一、HBase数据模型
HBase是一个类似于BigTable的分布式数据库，它是一个稀疏的长期存储的（存在HDFS上）、多维度的、排序的映射表。这张表的索引是行关键字、列关键字和时间戳。HBase的数据都是字符串，没有类型。
例：
可以将一个表想象成一个大的映射关系，通过行键、行键+时间戳或行键+列（列族：列修饰符），就可以定位特定数据。由于HBase是稀疏存储数据的，所以某些列可以是空白的。上表给出了 com.cnn.www 网站的数据存放逻辑视图，表中仅有一行数据，行的唯一标识为“com.cnn.www”，对这行数据的每一次逻辑修改都有一个时间戳关联对应。表中共有四列：contents:html、anchor:cnnsi.com、anchor:my.look.ca、mime:type，每一列以前缀的方式给出其所属的列族。
行键（RowKey）是数据行在表中的唯一标识，并作为检索记录的主键。在HBase中访问表中的行只有三种方式：通过某个行键访问、给定行键的范围访问、全表扫描。行键可以是任意字符串（最大长度64KB）并按照字典序进行存储。对于那些经常一起读取的行，需要对键值精心设计，以便它们能放在一起存储。
二、HBase读写流程
上图是HRegionServer数据存储关系图。上文提到，HBase使用MemStore和StoreFile存储对表的更新。数据在更新时首先写入HLog和MemStore。MemStore中的数据是排序的，当MemStore累计到一定阈值时，就会创建一个新的MemStore，并且将老的MemStore添加到Flush队列，由单独的线程Flush到磁盘上，成为一个StoreFile。与此同时，系统会在Zookeeper中记录一个CheckPoint，表示这个时刻之前的数据变更已经持久化了。当系统出现意外时，可能导致MemStore中的数据丢失，此时使用HLog来恢复CheckPoint之后的数据。
StoreFile是只读的，一旦创建后就不可以再修改。因此Hbase的更新其实是不断追加的操作。当一个Store中的StoreFile达到一定阈值后，就会进行一次合并操作,将对同一个key的修改合并到一起，形成一个大的StoreFile。当StoreFile的大小达到一定阈值后，又会对 StoreFile进行切分操作，等分为两个StoreFile。
1、写操作流程
步骤1：Client通过Zookeeper的调度，向HRegionServer发出写数据请求，在HRegion中写数据。
步骤2：数据被写入HRegion的MemStore，直到MemStore达到预设阈值。
步骤3：MemStore中的数据被Flush成一个StoreFile。
步骤4：随着StoreFile文件的不断增多，当其数量增长到一定阈值后，触发Compact合并操作，将多个StoreFile合并成一个StoreFile，同时进行版本合并和数据删除。
步骤5：StoreFiles通过不断的Compact合并操作，逐步形成越来越大的StoreFile。
步骤6：单个StoreFile大小超过一定阈值后，触发Split操作，把当前HRegion Split成2个新的HRegion。父HRegion会下线，新Split出的2个子HRegion会被HMaster分配到相应的HRegionServer 上，使得原先1个HRegion的压力得以分流到2个HRegion上。
2、读操作流程
步骤1：client访问Zookeeper，查找-ROOT-表，获取.META.表信息。
步骤2：从.META.表查找，获取存放目标数据的HRegion信息，从而找到对应的HRegionServer。
步骤3：通过HRegionServer获取需要查找的数据。
步骤4：HRegionserver的内存分为MemStore和BlockCache两部分，MemStore主要用于写数据，BlockCache主要用于读数据。读请求先到MemStore中查数据，查不到就到BlockCache中查，再查不到就会到StoreFile上读，并把读的结果放入BlockCache。
标签：color 文件 分享图片 hdf 维度 key 查找 写入 content
原文地址：https://www.cnblogs.com/sunziying/p/9178655.html
