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全面》