HBase、Kudu 和 ClickHouse 全视角对比
前言
Hadoop生态圈的技术繁多。HDFS一直用来保存底层数据，地位牢固。Hbase作为一款Nosql也是Hadoop生态圈的核心组件，它海量的存储能力，优秀的随机读写能力，能够处理一些HDFS不足的地方。Clickhouse是一个用于联机分析(OLAP)的列式数据库管理系统(DBMS)。能够使用SQL查询实时生成分析数据报告。它同样拥有优秀的数据存储能力。
Apache Kudu是Cloudera Manager公司16年发布的新型分布式存储系统，结合CDH和Impala使用可以同时解决随机读写和sql化数据分析的问题。分别弥补HDFS静态存储和Hbase Nosql的不足。
hbase应用案例既然可选的技术路线有这么多，本文将从安装部署、架构组成、基本操作等方面横向对比一下Hbase、Kudu和Clickhouse。另外这里还引入了几个大厂的实践作为例子予以参考。
安装部署方式对比
具体的安装步骤不过多赘述，这里只简要比较安装过程中需要依赖的外部组件。
Habse安装
依赖HDFS作为底层存储插件 依赖Zookeeper作为元数据存储插件 Kudu安装
依赖Impala作为辅助分析插件 依赖CDH集作为管理插件，但是不是必选的，也可以单独安装
Clickhouse安装
依赖Zookeeper作为元数据存储插件和Log Service以及表的 catalog service
组成架构对比
Hbase架构
Kudu架构
Clickhouse架构
综上所示，Hbase和Kudu都是类似于Master-slave的架构而Clickhouse不存在Master结构，Clickhouse的每台Server的地位都是等价的，是multi-master模式。不过Hbase和Clickhouse额外增加了一个Zookeeper作为辅助的元数据存储或者是log server等，而Kudu的元数据是Master管理的，为了避免server频繁从Master读取元数据，server会从Master获取一份元数据到本地，但是会有元数据丢失的风险。
基本操作对比 数据读写操作 •Hbase读流程
Hbase写流程
Kudu
Clickhouse
Clickhouse是个分析型数据库。这种场景下，数据一般是不变的，因此Clickhouse对update、delete的支持是比较弱的，实际上并不支持标准的update、delete操作。
Clickhouse通过alter方式实现更新、删除，它把update、delete操作叫做mutation(突变)。
标准SQL的更新、删除操作是同步的，即客户端要等服务端反回执行结果（通常是int值）；而Clickhous
e的update、delete是通过异步方式实现的，当执行update语句时，服务端立即反回，但是实际上此时数据还没变，而是排队等着。
Mutation具体过程
首先，使用w here条件到需要修改的分区；然后，重建每个分区，用新的分区替换旧的，分区一旦被替换，就不可回退；对于每个分区，可以认为是原子性的；但对于整个mutation，如果涉及多个分区，则不是原子性的。
•更新功能不支持更新有关主键或分区键的列•更新操作没有原子性，即在更新过程中select结果很可能是一部分变了，一部分没变，从上边的具体过程就可以知道•更新是按提交的顺序执行的•更新一旦提交，不能撤销，即使重启Clickhouse服务，也会继续按照s y stem.mutations的顺序继续执行•已完成更新的条目不会立即删除，保留条目的数量由
f inished_mutations_to_keep存储引擎参数确定。超过数据量时旧的条目会被删除•更新可能会卡住，比如update intvalue='abc’这种类型错误的更新语句执行不过去，那么会一直卡在这里，此时，可以使用KILL M UT A T ION来取消
综上所示，Hbase随机读写，但是Hbase的update操作不是真的update，它的实际操作是insert一条新的数据，打上不同的

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。