0、前言

Hadoop生态圈的技术繁多，HDFS一直用来保存底层数据，地位牢固。

Hbase作为一款Nosql也是Hadoop生态圈的核心组件，它海量的存储能力，优秀的随机读写能力，能够处理一些HDFS不足的地方。

Apache Kudu是Cloudera Manager公司16年发布的新型分布式存储系统，结合CDH和Impala使用可以同时解决随机读写和sql化数据分析的问题。分别弥补HDFS静态存储和Hbase Nosql的不足。

Clickhouse是一个用于联机分析(OLAP)的列式数据库管理系统(DBMS)，能够使用SQL查询实时生成分析数据报告。它同样拥有优秀的数据存储能力。

既然可选的技术路线有这么多，本文将从安装部署、架构组成、基本操作等方面横向对比一下Hbase、Kudu和Clickhouse。

一、安装部署方式对比

具体的安装步骤不过多赘述，这里只简要比较安装过程中需要依赖的外部组件。

Habse 安装：依赖HDFS作为底层存储插件 依赖Zookeeper作为元数据存储插件Kudu 安装：依赖Impala作为辅助分析插件 依赖CDH集群作为管理插件，但是不是必选的，也可以单独安装。ClickHouse 安装：依赖Zookeeper作为元数据存储插件和Log Service以及表的 catalog service 二、组成架构对比 2.1 Hbase架构

?2.2?Kudu架构

?2.3?Clickhouse架构

2.4 总结? Hbase和Kudu都是类似于Master-slave的架构而Clickhouse不存在Master结构，Clickhouse的每台Server的地位都是等价的，是multi-master模式。Hbase和Clickhouse额外增加了一个Zookeeper作为辅助的元数据存储或者是log server等，而Kudu的元数据是Master管理的，为了避免server频繁从Master读取元数据，server会从Master获取一份元数据到本地，但是会有元数据丢失的风险。 三、基本操作对比 ?3.1 HBASE

读流程

?写流程

3.2 Kudu?

3.3??Clickhouse

Clickhouse是个分析型数据库，这种场景下，数据一般是不变的，因此Clickhouse对update、delete的支持是比较弱的，实际上并不支持标准的update、delete操作。

Clickhouse通过alter方式实现更新、删除，它把update、delete操作叫做mutation(突变)。

标准SQL的更新、删除操作是同步的，即客户端要等服务端反回执行结果（通常是int值）；而Clickhouse的update、delete是通过异步方式实现的，当执行update语句时，服务端立即反回，但是实际上此时数据还没变，而是排队等着。

Mutation具体过程

首先，使用where条件找到需要修改的分区；然后，重建每个分区，用新的分区替换旧的，分区一旦被替换，就不可回退；对于每个分区，可以认为是原子性的；但对于整个mutation，如果涉及多个分区，则不是原子性的。

?更新功能不支持更新有关主键或分区键的列；

?更新操作没有原子性，即在更新过程中select结果很可能是一部分变了，一部分没变，从上边的具体过程就可以知道；

?更新是按提交的顺序执行的；

?更新一旦提交，不能撤销，即使重启Clickhouse服务，也会继续按照system.mutations的顺序继续执行；

?已完成更新的条目不会立即删除，保留条目的数量由finished_mutations_to_keep存储引擎参数确定。超过数据量时旧的条目会被删除；

?更新可能会卡住，比如update intvalue='abc’这种类型错误的更新语句执行不过去，那么会一直卡在这里，此时，可以使用KILL MUTATION来取消。

3.4 总结

Hbase随机读写，但是Hbase的update操作不是真的update，它的实际操作是insert一条新的数据，打上不同的timestamp，而老的数据会在有效期之后自动删除。而Clickhouse干脆就不支持update和delete。

四、数据查询操作 Hbase：不支持标准sql，需要集成Phoenix插件。Hbase自身有Scan操作，但是不建议执行，一般会全量扫描导致集群崩溃。Kudu：与Impala集成实现查询Clickhouse：自身有优良的查询性能 五、总结 5.1?Hbase与Kudu

Kudu师承Hbase，架构是类似的master-slave结构。Hbase的物理模型是master和regionserver，regionserver存储的是region，region里边很有很多store，一个store对应一个列簇，一个store中有一个memstore和多个storefile，store的底层是hfile，hfile是hadoop的二进制文件，其中HFile和HLog是Hbase两大文件存储格式，HFile用于存储数据，HLog保证可以写入到HFile中。

5.2 Kudu

Kudu的物理模型是master和tserver，其中table根据hash和range分区，分为多个tablet存储到tserver中，tablet分为leader和follower，leader负责写请求，follower负责读请求，总结来说，一个ts可以服务多个tablet，一个tablet可以被多个ts服务（基于tablet的分区，最低为2个分区）。

5.3 Clickhouse

Clickhouse的特点在于它号称最快的查询性能，虽然也能存储数据，但并不是他的强项，而且Clickhouse还不能update/delete数据。

5.4 各维度对比

?Hbase更适合非结构化的数据存储；在既要求随机读写又要求实时更新的场景，Kudu+Impala可以很好的胜任，当然再结合CDH就更好了，瓶颈并不在Kudu，而在Impala的Apache部署。如果只要求静态数据的极速查询能力，Clickhouse则更好。

参考资料：

微信公众号（数据仓库与Python大数据）-《万字对比ClickHouse、Kudu和Hbase全面》

---

1.本站遵循行业规范，任何转载的稿件都会明确标注作者和来源；2.本站的原创文章，会注明原创字样,如未注明都非原创，如有侵权请联系删除！；3.作者投稿可能会经我们编辑修改或补充；4.本站不提供任何储存功能只提供收集或者投稿人的网盘链接。