简介
战斗民族开发的 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 客户端
对比
| 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 使用
数据库稠密索引与稀疏索引
