假设有一张表的数据特别大，一台服务器存不下来，就需要把这张表拆分成好几个部分(例如4个部分)。如果这张表再进行拆分的时候老早已经排好顺序，那拆分出来的数据应该是一段一段的，每一段就包含了这一段的所有数据。
那客户端现在来查询数据，过来扫描数据，那它到底扫描哪一台服务器呢？我们不确定，可能每台服务器都要扫描一遍，这样做导致效率很差！
我们可以先去找一个中间机构去确认要找的数据在这4段中的哪一段，创建一个元数据表meta存真正数据的Region位置，先去找meta表。当元数据表变得特别大，也会切分多个段放在RegionServer中，这个时候就会提供一个ROOT表来确定meta表的位置。
这就形成了一种层级关系，从ROOT表跳到meta表跳到具体RegionServer。
形成跳表Topo结构降低了扫描次数，原来需要n次或4次扫描，现在变为1次扫描，性能得到提高，并且可以管理非常多的数据。
如何理解可以管理非常多的数据？
hbase1.0之前，每个Region默认大小是128M，每条元数据为1KB，那它就能存储1千多个元数据，那3层结构就会存储几千万上亿的记录。hbase1.0之后，每个Region默认大小是10G，两层结构能够存储的数据也足够大，满足集群需求。
2.5 读缓存+写缓存内存分读缓存和写缓存，把经常查询的数据放在读缓存，可以提升效率。写缓存怎么扫描文件速率最高？就是利用内存+磁盘的方式，先把数据放在内存排序后，再把数据写入到磁盘中，这样磁盘里的文件就是有序的了，接着对磁盘文件二分查找，效率变高。
3 第二个问题解答为了确保在分布式架构中，数据的安全，HBase怎么做？
3.1 内存+磁盘HBase采用了内存+磁盘存储的方式，这样做的好处是在数据安全性和数据操作效率之间做了一个权衡，既追求数据安全，也追求数据操作效率。
3.2 WAL机制WAL意为Write Ahead Log，类似MySQL中的binlog，用来做灾难恢复之用。HBase为了防止数据写入缓存之后不会因RegionServer进程发生异常导致数据丢失，在写入缓存之前会首先将数据顺序写入到HLog(WAL)中。如果不幸一旦发生RegionServer宕机或者其他异常，这种设计可以从HLog中进行日志回放进行数据补救，保证数据不丢失。HBase故障恢复的最大看点就在于如何通过HLog回放补救丢失数据。
4 总结好啦，HBase的架构设计大致聊得差不多了，老刘主要给大家讲了讲为什么HBase的架构设计这么牛。尽管当前水平可能不及各位大佬，但老刘还是希望能够变得更加优秀，能够帮助更多自学编程的伙伴。
如果有相关问题，请联系公众号：努力的老刘。如果觉得帮到了您，不妨点赞关注支持一波！