包括重做文件系统，磁盘挂载等。
有如下配置
--fs_wal_dir=/data_a/kuduWAL
--fs_data_dirs=/data_a/kudu /data_b/kudu ... /data_g/kudu
1.删除WAL目录
`rm -r -f /data_a/kuduWAL/*`
2.删除数据目录
`for i in {a..g}do rm -r -f /data_$i/kudu/*done`
三.启动 Kudu tablet servers
在cloudera manager上启动kudu-tbserver即可
一、项目背景清洗的结果中有两张比较大的表：
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）只有主键中的第二列出现在查询条件中时，查询速度很差，实测数据量在十亿级别时耗时在几十秒甚至查不出。
官网中也提到过该问题，见下图：
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核
集群支持情况 支持，但对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、不同条件下的查询时间记录
3、数据量为28亿时的查询记录
总数：
将dn作为条件查询：
将ip作为条件查询：
4、数据量为63亿时的查询记录
总数：
将dn作为条件查询：
将ip作为条件查询：
在某些时候查询速度一般（第一次查询慢，再次查会快），
5、数据量为110亿时的查询记录
总数：
将dn作为条件查询：
将ip作为条件查询：
附录： 一些其他对比
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）