clickhouse vs kudu

一、项目背景
清洗的结果中有两张比较大的表：
1）ip域名关系首次发现统计表，日增约0.5亿；
2）ip域名关系历史变化轨迹统计表，日增约1.4亿；

前端查询方式包括以下两种方式：
1）查询某个ip的信息，例如：select * from xxx where ip='xxxx'
2）查询某个域名的信息，例如： select * from xxx where dn = 'xxx'

二、clickhouse
优势：
1）数据压缩率高、写入性能高；
2）主键最左侧列出现在查询条件中时查询耗时在1秒内。（实测数据44亿，公司wiki其他项目组测试数据在百亿级别）

存在问题：
1）只有主键中的第二列出现在查询条件中时，查询速度很差，实测数据量在十亿级别时耗时在几十秒甚至查不出。
官网中也提到过该问题，见下图：

1.png

(来源：https://blog.csdn.net/bluetjs/article/details/80322497)

2）不能保证数据全局唯一，clickhouse的主键并不能约束数据唯一性，即使使用ReplacedMergeTree，也只能保证分区内数据唯一。

3）跳数索引作用不大，实测过set、ngrambf_v1、tokenbf_v1。（后两者均为布隆过滤器）

三、impala+kudu
由于clickhouse存在类似主键“最左原则”问题，导致无法同时满足dns反查的应用场景，变通的解决方案是同时存储两份数据，一份使用ip作为主键，另一份使用域名作为主键，前端不同查询场景分别转换为对这两份数据的查询，但这种解决方案存在数据不一致的隐患，一旦出现两份数据不一致时对数据的比对、修复等都是件麻烦的事情，此外还增加了数据同步任务维护的负担。
思考是否存在一种存储方式能够同时满足两个主键的索引（或分区）。
kudu可以支持同时按hash和范围分区，例如：
PARTITION BY HASH (id) PARTITIONS 4,
RANGE (sku)
(
PARTITION VALUES < ‘g’,
PARTITION ‘g’ <= VALUES < ‘o’,
PARTITION ‘o’ <= VALUES < ‘u’,
PARTITION ‘u’ <= VALUES
)
这样在原理上是能够支持分别按单列作为查询条件的应用场景。

四、clickhouse与kudu对比

clickhouse impala+kudu
服务器情况 单机128G 24核 4台 128G 24核

2.png

集群支持情况 支持，但对zk的依赖过重 支持，不依赖zk，内部使用raft算法；可在CDH中管理impala和kudu
数据一致性支持情况 不能保证数据一致性，即使使用ReplacedMergeTree，也只能保证分区内数据唯一 支持upsert操作，能够保证唯一性
占用磁盘空间 44亿69g 31亿163G
写入速度 10万/s 23万/s
查询速度 10亿数据量时：只有主键中最左侧列作为查询条件时耗时在1秒内；当主键中最左侧列不在查询条件中时耗时在几十秒 29亿时分别将ip和域名作为条件查询耗时均在1秒内；63亿时ip作为条件（range分区）时，耗时大部分在1~2秒，部分查询时间在几十秒（原因待查）域名作为条（hash分区），耗时基本在1秒内
并发 不支持大并发查询 不支持大并发查询

kudu查询性能记录
1、集群描述
3个master 3个tabletserver
128G内存（设置kudu和impala可用内存上限均为80G） 24核

2、不同条件下的查询时间记录

数量	dn作为条件查询	ip作为条件
29亿	select * from kd.t_ip_dn_first_test2 where dn= 'lovelit.org' limit 10; 0.24 0.13 0.13	select * from kd.t_ip_dn_first_test2 where ip_num='1806320426' limit 10; 0.85 0.84 0.73
63亿	select * from kd.t_ip_dn_first_test2 where dn= 'lovelit.org' 1.99 0.12 0.12	select * from kd.t_ip_dn_first_test2 where ip_num='1806320426'; 1.28 1.33 1.30
110亿	select * from kd.t_ip_dn_first_test2 where dn= 'lovelit.org' 2.21 0.11 0.13	select * from kd.t_ip_dn_first_test2 where ip_num='1806320426'; 111.12 4.78 2.59

3、数据量为28亿时的查询记录
总数：

3.png

将dn作为条件查询：

4.png 5.png

将ip作为条件查询：

6.png

4、数据量为63亿时的查询记录
总数：

7.png

将dn作为条件查询：

8.png

将ip作为条件查询：

9.png

在某些时候查询速度一般（第一次查询慢，再次查会快），

10.png

5、数据量为110亿时的查询记录
总数：

11.png

将dn作为条件查询：

12.png

将ip作为条件查询：

13.png

附录： 一些其他对比

	clickhouse	kudu
并发qps	100qps/s	100w/s
join支持	join写法比较特殊；最新版已支持类似SQL的join，但性能不好；无论是Left Join 、Right Join还是Inner Join永远都是拿着右表中的每一条记录到左表中查找该记录是否存在，所以右表必须是小表	与impala或sparksql集成后支持标准sql
小批量写入对性能影响	尽量做1000条以上批量的写入，避免逐行insert或小批量的insert，update，delete操作，因为ClickHouse底层会不断的做异步的数据合并，会影响查询性能，这个在做实时数据写入的时候要尽量避开	无影响
cpu	Clickhouse快是因为采用了并行处理机制，即使一个查询，也会用服务器一半的CPU去执行，所以ClickHouse不能支持高并发的使用场景，默认单查询使用CPU核数为服务器核数的一半，安装时会自动识别服务器核数，可以通过配置文件修改该参数	低
查询性能	count: 千万级别，500毫秒，1亿 800毫秒 2亿 900毫秒 3亿 1.1秒 group: 百万级别 200毫米，千万 1秒，1亿 10秒，2亿 20秒，3亿 30秒join：千万-10万 600 毫秒， 千万 -百万：10秒，千万-千万 150秒	高
使用场景	不适合分析场景，聚合排序	既有随机（hbase擅长）又有批量扫描（hdfs顺序读写）
优点	1、高效使用cpu2、顺序IO，因此对磁盘没有要求3、索引不使用B树，不受最左原则限制，只要字段在索引中就可以4、写入速度非常快，50-200M/s，对于大量的数据更新非常适用。	1、可以解决流式计算结果的更新；2、
缺点	1、不支持事务2、不支持高并发，官方建议100qps/s3、耗cpu	1、只有主键可以设置range分区，且只能有一个主键；2、pyspark连接kudu时不支持调用kudu本地库，scala spark支持，支持kudu的各种语法（哪些语法？）3、shell不能查询到表的schema，可通过impala和spark的dataframe获取4、时间格式是utc格式的，差8个小时
总结	可作为dws宽表层使用，减少join查询	tserver不要超过100台，单个tserver支持100个tablet，单个tablet支持10G数据，单表最多使用100个tablet；因此：1、不适用pb级数据；2、每台tserver支持1T数据3、单表最大1T数据