Click house 初体验

简介

战斗民族开发的 olap 数据库，适用于渠道漏斗分析、app 点击行为路径分析等业务场景

关键特性

优点

#	描述	备注
多引擎支持	支持多引擎 engine，生产环境主要是 merge tree，有点类似 LSM 但是不写内存，直接写磁盘，每次摄入数据都会生成一个目录，并会生成相关的 idx、mrk、bin 文件，所以适合批量摄入，实时摄入最好能够进行时间与 batch 批量摄入，server 端会异步进行数据 merge，单条摄入一定要杜绝，将会对服务端造成极大压力
向量化（SIMD）	向量化计算充分利用 cpu 资源
code gen	code gen 生成优化后的物理执行计划
列式存储	每个列都有单独的 mrk、bin 文件存储，对于压缩友好
TTL	支持字段级和表级别的 TTL
MVCC	查询时支持多版本，不会进行加锁
SQL 支持良好，分析函数丰富	提供了很多方便漏斗分析，路径分析的函数方便进行 olap 分析，如：sequenceMatch,groupArray等,还支持高阶函数，如 arrayFilter ，arrayFirstIndex 等

缺点

#	描述	备注
不支持事务	OLAP 引擎，无可厚非
仅支持 batch 摄入	由于 merge tree 本身的设计（类似 lsm，但是无 log 和 memory store，不写内存，直接写入磁盘），仅对 batch 写入支持友好，单条频繁摄入将对 server 端性能造成极大影响，server 端会频繁 merge 造成 load 升高	实时数据摄入时需要注意
不支持二级索引
写放大	merge tree 会定期进行 merge，导致写入放大，当前类 lsm 结构的通病
主键可重复	比较诡异的地方，不一定算劣势，部分场景需要考虑业务层面做去重
稀疏索引不适合点查	稀疏索引导致其不适合点查，kv 查询更适合使用 hbase redis 等

JDBC 客户端

github链接	描述
clickhouse-jdbc	官方提供，基于 http 实现，与 server 的 8123 端口进行通信
ClickHouse-Native-JDBC	第三方lib，基于 tcp 实现，与 server 的 9000 端口进行通讯 性能相对更优，推荐使用

对比

OLAP数据库	数据摄入	存储方式	查询性能	用户友好程度	场景
Druid	支持离线 Hdfs 数据摄入和实时 Kafka 数据摄入	LSM 变种，采用一层全维度的 roll up 进行预计算，不存储明细	查询时在 broker 层面进行更加深层的聚合计算，毫秒级到秒级	组件繁多，包含 coordinator、 overlord、broker、historical、middle manager 等多种组件和进程，依赖 ZK 和 mysql，运维相对复杂，维度度量修改支持在线修改，对用户友好，需要时间字段	iot、实时监控指标产出、实时渠道聚合分析等
Kylin	支持 Hive 和 Kafka 摄入，由于使用基于 mr 和 spark 的计算引擎进行 cube 构建，难以达到分钟级延迟，延迟至少在十分钟至半小时级别	全维度预计算构建 cube，支持一些策略的剪枝，减少无用计算量，开源版本依赖 HBase 作为 Storage	基于全量预计算产出、亚秒级	依赖 Hadoop 生态，适合维度、度量相对稳定的 cube 分析，一旦需要修改维度、度量需要重新配置，重新构建，不一定需要时间字段	维度、度量明确的场景、偏离线 T+1 或 H+1、分析聚合维度多样化，维度尽量不要超过 20 维，否则将产生维度爆炸
ClickHouse	支持离线在线数据录入，但是由于存储设计实时数据摄入千万不能单条频繁摄入，一定要做 batch 汇总，秒级摄入 qps 不要超过 1	与 kylin、druid 不同，不做预计算，完全是通过索引、列式存储、压缩、向量化、code gen 等充分压榨 cpu 等计算资源达到快速计算的目的	毫秒级至秒级不等	单一组件、sql 支持良好、分析函数丰富，易上手，需要时间字段	渠道漏斗分析、app 点击路径事件分析

参考文档

怎么用ClickHouse做漏斗分析？

转化漏斗的基本实现

ClickHouse主键探讨[译文+补充]

使用ClickHouse一键接管MySQL数据分析

How to realize funnel analysis by ClickHouse (with our illustrating example) ?

https://clickhouse.yandex/docs/en/single/

ClickHouse 使用

数据库稠密索引与稀疏索引