说说HBase读、写流程

分析&回答

---

HBase读流程

1. 首先，客户端需要获知其想要读取的信息的Region的位置，这个时候，Client访问hbase上数据时并不需要Hmaster参与（HMaster仅仅维护着table和Region的元数据信息，负载很低），只需要访问zookeeper，从meta表获取相应region信息(地址和端口等)。【Client请求ZK获取.META.所在的RegionServer的地址。】
2. 客户端会将该保存着RegionServer的位置信息的元数据表.META.进行缓存。然后在表中确定待检索rowkey所在的RegionServer信息（得到持有对应行键的.META表的服务器名）。【获取访问数据所在的RegionServer地址】
3. 根据数据所在RegionServer的访问信息，客户端会向该RegionServer发送真正的数据读取请求。服务器端接收到该请求之后需要进行复杂的处理。
4. 先从MemStore找数据，如果没有，再到StoreFile上读(为了读取的效率)。

HBase写流程

前三点和读类似:

1. Client先访问zookeeper，从.META.表获取相应region信息，然后从meta表获取相应region信息
2. 根据namespace、表名和rowkey根据meta表的数据找到写入数据对应的region信息
3. 找到对应的regionserver把数据先写到WAL中，即HLog，然后写到MemStore上
4. MemStore达到设置的阈值后则把数据刷成一个磁盘上的StoreFile文件。
5. 当多个StoreFile文件达到一定的大小后(这个可以称之为小合并，合并数据可以进行设置，必须大于等于2，小于10——hbase.hstore.compaction.max和hbase.hstore.compactionThreshold)，默认为10和3)，会触发Compact合并操作，合并为一个StoreFile，（这里同时进行版本的合并和数据删除。）
6. 当Storefile大小超过一定阈值后，会把当前的Region分割为两个（Split）【可称之为大合并，该阈值通过hbase.hregion.max.filesize设置，默认为10G】，并由Hmaster分配到相应的HRegionServer，实现负载均衡

反思&扩展

---

HBase的缺点

• 单一RowKey固有的局限性决定了它不可能有效地支持多条件查询
• 不适合于大范围扫描查询
• 不直接支持 SQL 的语句查询

---

为了大家更加方便的刷题，我们对文章进行了分类和整理，免费为大家提供刷题服务。程序员不欺骗程序员，赶紧扫码小程序刷起来！

为了一站式解决面者刷题问题，部分内容可能存在摘录情况，如有侵权辛苦您留言联系我们，我们会删除文章或添加引用文案，Thanks！