HBASE起源于Google BigTable，几乎遵从了BigTable论文的大多数架构设计。Cassandra则是采纳了BigTable的数据模型，同时吸收了Amazon Dynamo的分布式设计。

因此从存储结构模型的微观上看，HBASE和Cassandra在单点存储数据的机理是类似的，但是从分布式架构的宏观上看，两者则大相径庭。

因为两者参考和遵从的分布式架构产品不同，前者BigTable，后者Dynamo，所以最终性格导向也就不同了，前者是中心化架构并满足分布式CAP定理中的CP(分布式一致性)，强调数据写入的强一致性；后者去中心化架构并满足分布式CAP定理中的AP(分布式高可用)，适应数据在读取过程中完成最终一致性。

由内看结构： 在查询方面Cassandra还支持二级索引，内置CQL(MySQL的SQL语法接近)，SSTable分层结构也侧重定位与查找；但HBase没有二级索引，只强调列簇的行键scan，Region中的Store与HDFS密切配合，StoreFile中KV以顺序排列，存储强调整体的时间写入顺序。因此Cassandra就非常适合通过列字段为条件来查找，而HBase更擅长通过行扫描做列集分析。

本质原因在于Cassandra的数据是基于一致性哈希算法，按照HASH范围划分，实现记录根据哈希值在整个集群节点的随机分布以及复本冗余，那么查找起来更适合在整个集群中对任何记录进行大范围的定位和查询，充分利用集群的整体算力；

但是HBase是顺序的写入同一个Region，在数据量足够大后再分裂，那么HBase就不适合频繁大范围的对数据定位与查找，更适合按行键做顺序扫描的集合分析。查询主要体现在就近和热点数据上的高性能。

由外看分布式： Cassandra的集群去中心化主要利用一致性哈希环机制实现数据的分布和扩容缩容的数据迁移，利用gossip协议在对等节点的网络传播下保存集群状态一致性，利用anti-entropy(反熵)机制实现数据读取过程中节点之间的比对，保证数据一致性，这些都是集群在对等条件下基于机制而达成状态上的共识，那么Cassandra的这些特性，就使得集群不能太大，太大就不好管理，也容易导致网络通讯过于密集。

不过Cassandra这种去中心化架构表现出来的优点就是集群无单点故障隐患，集群健壮性高，可用性极高，运维很省事。

HBASE以及所依赖的Hadoop HDFS都是基于中心化集中式管理，存在HMaster的集群单点故障风险，因此一般HBASE的HMaster可以有一个或多个HA热备，引入HA后的HBASE集群依然很健壮，只是必然引入更高的部署复杂度，底层依赖的HDFS NameNode HA在服务部署复杂性方面则更甚之。

不过无论是HBase的Region Server，还是HDFS DataNode作为被管理的数据节点，要比Cassandra的对等节点承载的功能要简单得多，复杂的协调指挥问题都是由主节点服务来完成，数据节点通讯关系都是朝向主节点的被动处理，节点功能越简单，风险会越小。

而不是Cassandra那样，必须通过gossip协议的全网络病毒式传播状态来保证集群一致性，还要通过anti-entropy(反熵)机制，进行节点副本数据的一致性比对，每个节点承载的内容太多了，自然故障风险也会变得更大。因此，Hadoop HBase更适合去管理大规模的数据节点。

HBASE基于HMaster和ZooKeeper协调，实现表->列簇->Region在单点HRegionserver上做行级事务写入，当Region切分与合并后，才会在多个HRegionserver节点上形成数据分布，因此HBase强调了写入过程的一致性，而且集群中任何状态变更过程，都会以保证一致性为前提，(例如：region切分与合并过程缓慢的话，面向该Region的客户端会感受到短暂的中断)；

另外底层HFile文件的存储是建立在Hadoop HDFS之上，文件的高可靠全部由HDFS代管，HBase所谓的Region迁移，并不存在实质上的文件移动，仅仅是HDFS元数据的变化。因此HBASE更适合大规模数据形成的文件在分布式环境中的管理，集群可以做的足够大。

但是Cassandra强调的是高可用，任何时候都要先照顾客户端的感受，例如：hinted handoff机制会让兄弟节点把面向故障节点的写请求先接过来，总之以不能堵塞客户端为优先，但这里存在兄弟节点的单点故障风险。

这些特征就特别适合中国这个特别容易产生超大规模数据的地方，更适合大厂所面对的大规模用户在关键性业务上产生的结构化数据，通过HBASE来支撑大吞吐的写入，实时的在线分析以及数据可靠性方面的需求，并且大厂的工程师团队也具备消化Hadoop平台复杂性的能力。

Cassandra架构是最终一致性，去中心化，节点对等，组件更精简，非常适合一个分布式数据库的小型集群的快速搭建，非常灵活，并不像HBASE搭建那么复杂，但我认为在国内不好找到需求点，为什么呢？

因为Cassandra的定位是在线事务应用的大规模数据支撑，无缝对接SQL语法，满足大范围的海量数据的快速查询，同样也适合实时性的流库连接，但前提是在写入数据方面，应该是弱一致性的业务环境要求(尽管一致性可调配置支持强一致性ALL，但代价太高)。

这就比较尴尬，刚性业务不合适，日志型业务国内Elasticsearch才是热门，MongoDB一样提供了可调的分布式一致性，支持的查询语义更丰富，还支持关键性业务的分布式事务，而且在国内也更流行。

但是我相信随着大数据技术的不断发展，国内工程师的不断普及，Cassandra是有非常多的优点，面向分布式海量数据的查询优化架构，尤其是去中心化带来的集群健壮性，对于一个运维团队会非常省事，尤其是越来越多的物联网项目和海量数据的搜索需求，必将在中小型团队中流行起来。

至于国外为什么Cassandra更流行，没太涉及过国外项目和团队，不能贸然下结论。但我能看到和想到的客观推理包括两方面：