Kyligence VS ClickHouse (单表13亿数据)

导言

公司的大数据平台基于 Kyligence 搭建,集群运行了大概一年的时间,比较稳定,没出过啥问题。由于对大数据领域很有兴趣,所以平时会研究一些相关的产品。

初识ClickHouse的时候,我曾产生这样的感觉:它仿佛违背了物理定律,没有任何缺点,是一个不真实的存在。一款高性能、高可用OLAP数据库的一切诉求,ClickHouse似乎都能满足,这股神秘的气息引起了我极大的好奇。

Clickhouse采用了很多先进的算法、还有列式存储与数据压缩、向量化执行引擎(寄存器硬件层面的特性),我认为这款OLAP 数据库能打败 Kyligence(商业版的Kylin),为了证明心中的猜想,我花了一两周的空闲时间对这两款数据库做了性能对比。

结论

  1. 低并发数据扫描范围小的情况下,ClickHouse 比 Kyligence 查询速度快
  2. 高并发数据扫描范围大的情况下,Kyligence 比 ClickHouse 查询速度快,而且响应时间更加平稳

测试准备

1. 数据集:采用真实业务数据。

  • 数据总量:422 GB
  • 1个事实表:13 亿数据(17列)
  • 3个纬度表:
    • 纬度表A:150 万数据(9列)
    • 纬度表B:8000 数据(62列)
    • 纬度表C:500 数据(96列)
  • 为了充分发挥数据库的特性,数据模型在不同的数据库上会有不同的设计,业务逻辑不变
    • ClickHouse 擅长单表查询,于是我会在原始表的基础上,创建一个新表(宽表)基于MergeTree引擎,通过 materialized view 实时同步数据到新表
    • Kyligence 擅长预计算,于是我会基于原始表,设计CUBE纬度,并加速查询

2. 机器配置

  • Kyligence
    • 主节点:8C、28G、400GB HDD
    • 工作节点:16C、56G、400GB HDD
  • ClickHouse
    • 主节点:8C、28G、400GB HDD + 500GB HDD

3. 查询条件

  • Q1: 动态时间区间 < 30 天;动态店铺ID;动态Limit Offset;
  • Q2: 动态时间区间 < 30 天;动态店铺ID;更多动态Where条件;动态Limit Offset;
  • Q3: 动态时间区间 > 30 天、< 180天;动态店铺ID;动态Limit Offset;
  • Q4: 动态时间区间 > 30 天、< 180天;动态店铺ID;更多动态Where条件;动态Limit Offset;

4. 压测步骤

  • 使用 Golang 语言开发程序,生成查询SQL、请求数据库、提供统一的 API 接口
  • 使用 Jmeter 调用 Golang 提供的 Rest API 接口
  • 压测前,使用 Jmeter 单线程模式,循环调用10次 x 4组查询API ,预热系统
  • 压测中,使用 Jmeter 1并发、10并发、30并发、50并发、100并发、200并发 模式测试,每种并发,循环 5 次
  • 压测后,收集监控到的请求响应数据
    • 平均响应时间
    • 95% Line

5. 结果可视化

  • 使用 Python + plotly + pandas 生成图表

测试结果

1并发

10并发

30并发

50并发

100并发

200并发

服务器监控

ClickHouse

Kyligence

Show Comments