一、架构思路
Hbase是一个分布式的数据库，使用Zookeeper来管理集群。
在Hbase的概念中，RegionServer对应于集群中的一个节点，而一个RegionServer负责管理多个Region。一个Region代 表一张表的一部分数据，所以在Hbase中的一张表可能会需要很多个Region来存储其数据，但是每个Region中的数据并不是杂乱无章 的，Hbase在管理Region的时候会给每个Region定义一个Rowkey的范围，落在特定范围内的数据将交给特定的Region，从而将负载分 摊到多个节点上，充分利用分布式的优点。另外，Hbase会自动的调节Region处在的位置，如果一个RegionServer变得Hot（大量的请求 落在这个Server管理的Region上），Hbase就会把Region移动到相对空闲的节点，依次保证集群环境被充分利用。
二、存储模型
有了架构层面的保证，接下来的事情就只是关注于数据的具体存储了。这里就是每个Region所承担的工作了。我们知道一个Region代表的是一张 Hbase表中特定Rowkey范围内的数据，而Hbase是面向列存储的数据库，所以在一个Region中，有多个文件来存储这些列。Hbase中数据 列是由列簇来组织的，所以每一个列簇都会有对应的一个数据结构，Hbase将列簇的存储数据结构抽象为Store，一个Store代表一个列簇。
在Hbase底层的Store数据结构中，每个StoreFile内的数据是有序的，但是StoreFile之间不一定是有序的，Store只 需要管理StoreFile的索引就可以了。这里也可以看出为什么指定版本和Rowkey可以加强查询的效率，因为指定版本和Rowkey的查询可以利用 StoreFile的索引跳过一些肯定不包含目标数据的数据。
Cassandra是一种用于数据存储和管理的“自给自足”技术，而HBase则不是。后者旨在用作HDFS随机数据输入/输出的工具，这就是为什么将其所有数据存储在此处的原因。此外，HBase使用Zookeeper作为服务器状态管理器，并使用“大师”来知道所有元数据在哪里（以避免在包含元数据的主服务器出现故障时立即出现群集故障）。因此，HBase复杂的相互依存系统更加难以配置，保护和维护。
Cassandra擅长写入，而HBase擅长密集读取。 Cassandra的弱点是数据一致性，而HBase的痛苦是数据可用性，尽管两者都试图减轻这些问题的不利后果。而且，两者都不会频繁删除和更新数据。