Hbase、Kudu 和 ClickHouse 全面对比（万字、张图）.docxVIP

Hbase、Kudu 和 ClickHouse 全面对比（万字、16张图） ???????? Hadoop生态圈的技术繁多。HDFS一直用来保存底层数据，地位坚固。Hbase作为一款Nosql也是Hadoop生态圈的核心组件，它海量的存储力量，优秀的随机读写力量，能够处理一些HDFS不足的地方。Clickhouse是一个用于联机分析(OLAP)的列式数据库管理系统(DBMS)。能够使用SQL查询实时生成分析数据报告。它同样拥有优秀的数据存储力量。 Apache Kudu是Cloudera Manager公司16年发布的新型分布式存储系统，结合CDH和Impala使用可以同时处理随机读写和sql化数据分析的问题。分别弥补HDFS静态存储和Hbase Nosql的不足。 既然可选的技术路线有这么多，本文将从安装部署、架构组成、基本操作等方面横向对比一下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值）；而Clickhouse的update、delete是通过异步方式实现的，当执行update语句时，服务端马上反回，但是实际上此时数据还没变，而是排队等着。 Mutation具体过程 首先，使用where条件找到需要修改的分区；然后，重建每个分区，用新的分区替换旧的，分区一旦被替换，就不行回退；对于每个分区，可以认为是原子性的；但对于整个mutation，假如涉及多个分区，则不是原子性的。 ?更新功能不支持更新有关主键或分区键的列； ?更新操作没有原子性，即在更新过程中select结果很可能是一部分变了，一部分没变，从上边的具体过程就可以晓得； ?更新是按提交的挨次执行的； ?更新一旦提交，不能撤销，即便重启Clickhouse服务，也会连续依据system.mutations的挨次连续执行； ?已完成更新的条目不会马上删除，保留条目的数量由finished_mutations_to_keep存储引擎参数确定。超过数据量时旧的条目会被删除； ?更新可能会卡住，比如update intvalue=abc’这品种型错误的更新语句执行不过去，那么会一直卡在这里，此时，可以使用KILL MUTATION来取消。 综上所示，Hbase随机读写，但是Hbase的update操作不是真的update，它的实际操作是insert一条新的数据，打上不同的timestamp，而老的数据会在有效期之后自动删除。而Clickhouse干脆就不支持update和delete。 数据查询操作 ?Hbase 不支持标准sql，需要集成Phoenix插件。Hbase本身有Scan操作，但是不建议执行，一般会全量扫描导致集群崩溃。 ?Kudu 与Impala集成实现查询。 ?Clickhouse 本身有优良的查询功能。 HBASE在滴滴出行的应用场景和最佳实践 HBase在滴滴次要存放了以下四种数据类型： ?统计结果、报表