大家好，我是考100分的小小码 ，祝大家学习进步，加薪顺利呀。今天说一说HBase 与 Cassandra 架构对比分析的经验分享[亲测有效],希望您对编程的造诣更进一步.
架构对比
HBase和Cassandra几乎是一个年份发起，又都是在2010年成为Apache的顶级项目，不过如果我们去细品其内部机制，我们会发现其实两者是完全不同的架构风格。
HBASE起源于Google BigTable，几乎遵从了BigTable论文的大多数架构设计。Cassandra则是采纳了BigTable的数据模型，同时吸收了Amazon Dynamo的分布式设计。
因此从存储结构模型的微观上看，HBASE和Cassandra在单点存储数据的机理是类似的，但是从分布式架构的宏观上看，两者则大相径庭。
因为两者参考和遵从的分布式架构产品不同，前者BigTable，后者Dynamo，所以最终性格导向也就不同了，前者是中心化架构并满足分布式CAP定理中的CP(分布式一致性)，强调数据写入的强一致性；后者去中心化架构并满足分布式CAP定理中的AP(分布式高可用)，适应数据在读取过程中完成最终一致性。
我们看到此处就首先会明白这两个伙计从分布式架构上压根走的不是一路，只不过都从单点存储模型上看起来很像，有日志追加(WAL VS CommitLog)，有内存写入缓冲区(MemStore VS MemTable)，也都刷盘(flush)到LSM-Tree结构的持久化文件(StoreFile VS SSTable File)，都用Bloomfilter和Row Index的组合模式进行行键的索引，它们也都是利用BigTable的数据模型结构实现高速的写入和热点数据的查找。
关键特性对比
有两个关键特性区分了它们：
由内看结构： 在查询方面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机制会让兄弟节点把面向故障节点的写请求先接过来，总之以不能堵塞客户端为优先，但这里存在兄弟节点的单点故障风险。
另外，去中心化架构几乎默认都是利用HASH算法实现数据分布的共识机制，但麻烦的问题在于数据管理，例如：迁移过程，必须诚实地进行物理层面的数据移动，这点是无法匹敌HBASE与HDFS的中心化架构组合，其底层机制是通过元数据对集群数据文件的逻辑操作，带来数据管理的灵活性优势。这也是中心化集中管理架构相对于去中心化共识架构最大的优势所在。
适应场景对比
通过上面的描述，实际上我们可以分析出来，Cassandra更适合在数据大吞吐的情况下，借助数据分布优势，高速写入，并通过二级索引实现SQL语法丰富的字段级查找，以及支持在线应用实时产生的超大规模数据的存储，可以在大规模数据写入与查询的都比较适合的场景下替代MySQL，在事务和一致性要求不严格的环境下，为每天并发与写入量惊人的在线业务系统，提供数据库支撑。因此其面向服务的领域偏重oltp。
HBASE更适合管理着大规模集群，并在超大规模数据之上进行实时的，结构化的海量数据支撑，而且满足强一致性要求，达到行级事务要求，可以使其对接一些关键性业务在可靠性要求高的环境下支撑在线实时分析，例如电子商务交易，金融交易等等。但并不适合随机性很强的查询，更适合大吞吐的数据写入，热点数据的行级查找以及大规模的扫描分析。并且具有Hadoop生态的数仓工具支撑。因此HBASE更面向olap。
流行度分析
我们说完它们的大体架构对比分析，我们再回到问题上来，首先HBASE基于Hadoop，自然名声响，但是其本质特征适合关键性数据的高可靠支撑，大规模集群数据管理，以及Hadoop生态的结合，自然在大规模的结构化数据的实时与离线分析上数一数二的优势，同时HBASE也在进化，对诟病已久的RIT(导致region迁移缓慢问题)进行了根除，精简zookeeper依赖，加强master中心管理，解决了过去很多导致缓慢的根子问题，也更适合面向实时性分析业务。
这些特征就特别适合中国这个特别容易产生超大规模数据的地方，更适合大厂所面对的大规模用户在关键性业务上产生的结构化数据，通过HBASE来支撑大吞吐的写入，实时的在线分析以及数据可靠性方面的需求，并且大厂的工程师团队也具备消化Hadoop平台复杂性的能力。
Cassandra架构是最终一致性，去中心化，节点对等，组件更精简，非常适合一个分布式数据库的小型集群的快速搭建，非常灵活，并不像HBASE搭建那么复杂，但我认为在国内不好找到需求点，为什么呢？
因为Cassandra的定位是在线事务应用的大规模数据支撑，无缝对接SQL语法，满足大范围的海量数据的快速查询，同样也适合实时性的流库连接，但前提是在写入数据方面，应该是弱一致性的业务环境要求(尽管一致性可调配置支持强一致性ALL，但代价太高)。
这就比较尴尬，刚性业务不合适，日志型业务国内Elasticsearch才是热门，MongoDB一样提供了可调的分布式一致性，支持的查询语义更丰富，还支持关键性业务的分布式事务，而且在国内也更流行。
但是我相信随着大数据技术的不断发展，国内工程师的不断普及，Cassandra是有非常多的优点，面向分布式海量数据的查询优化架构，尤其是去中心化带来的集群健壮性，对于一个运维团队会非常省事，尤其是越来越多的物联网项目和海量数据的搜索需求，必将在中小型团队中流行起来。
至于国外为什么Cassandra更流行，没太涉及过国外项目和团队，不能贸然下结论。但我能看到和想到的客观推理包括两方面：
- 中英文关于Cassandra技术资料的新鲜度差距很大，可研读资料稀缺，我对Cassandra的技术研究也主要是基于英文。
- 在强调分布式数据库面向结构化海量数据的承载能力之外，HBASE更侧重分析，Cassandra则胜于查询，项目中往往数据查询需求是远高于数据分析需求，因此国外的热度对比很正常，只不过Cassandra在国内工程师的认识上尚未普及而已！
本文由西安守护石信息科技的 CTO 老方发表，转载请注明来源和作者。
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 举报，一经查实，本站将立刻删除。
转载请注明出处: https://daima100.com/5801.html
