首先说一下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中；
    Kudu的物理模型是master和tserver，其中table根据hash和range分区，分为多个tablet存储到tserver中，tablet分为leader和follower，leader负责写请求，follower负责读请求，总结来说，一个ts可以服务多个tablet，一个tablet可以被多个ts服务（基于tablet的分区，最低为2个分区）
    而Clickhouse的特点在于它号称最快的查询性能，虽然也能存储数据，但并不是他的强项，而且Clickhouse还不能update/delete数据。

    最后从下面几个维度来对比一下Hbase、Kudu和Clickhouse。

    Hbase Kudu Clickhouse
    数据存储 Zookeeper保存元数据，数据写入HDFS(非结构化数据) master保存元数据，数据及副本存储在tserver(强类型数据) Zookeeper保存元数据，数据存储在本地，且会压缩
    查询 查询比较麻烦，Phoenix集成之后比较好点 查询比较麻烦，集成Impala之后表现优秀 高效的查询能力
    数据读写 支持随机读写，删除。更新操作是插入一条新timestamp的数据 支持读写，删除，更新 支持读写，但不能删除和更新
    维护 需要同时维护HDFS、Zookeeper和Hbase(甚至于Phoenix) CDH版本维护简单，Apache版需要单独维护，额外还有Impala 额外维护Zookeeper

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