性能测试在大数据平台产品研发中的实践

1.

2.

3. O1 大数据平台产品概述 O2 OLAP性能测试指标 O3 OLAP性能测试实践 O4 问题与展望

4. 大数据平台产品概述

5. 行业趋势物联网市场不断增长物联网数据包含多种类型互联网连接数量增长零售边缘设备 GSMA预计，2025年全球物联网连接数量将达246亿，中国占比将达到30% IoT设备工业物联网数据量增长 IDC预计，2025年全球物联网生成的数据量将达到每年73.1ZB 数据中心应用及服务规模增长交通 GSMA预计，到2025年，物联网上层的平台、应用和服务带城市社区、楼宇、家庭来的收入占比将高达物联网收入的67%，成为价值增速最快的环节 5

6. 大数据平台产品

7. OLAP性能测试指标

8. OLTP vs OLAP 8

9. OLAP场景的关键特性绝大多数是读请求数据以相当大的批次(> 1000行)更新，而不是单行更新已添加到数据库的数据不能修改对于读取，从数据库中提取相当多的行，但只提取列的一小部分宽表，即每个表包含着大量的列查询相对较少 (查询数百次或更少/秒) 处理单个查询时需要高吞吐量(可达数十亿行/秒) 每个查询有一个大表。除了他以外，其他的都很小查询结果明显小于源数据

10. 性能测试的定义及目标性能测试Definition (from 维基百科) performance testing is in general a testing practice performed to determine how a system performs in terms of responsiveness and stability under a particular workload. 性能测试目标我们的性能价值观：用户场景对比业界主流OLAP数据库的性能，为引擎选型提供技术支撑正确性评估核心数据引擎的性能对目标业务场景的适配能力业务指标为核心数据引擎的性能优化提供方向和数据支撑资源指标 10

11. OLAP性能测试指标数据插入性能指标：行/秒 (rows/seconds) 吞吐量 (throughput) 数据查询性能指标：查询响应时间 (Response Time) 每秒查询率 (QPS) 资源使用指标： CPU Memory Disk I/O Network I/O 存储性能指标：存储压缩比 11

12. 性能测试实践

13. 时间序列场景测试数据集：Time Series Benchmark Suite (TSBS) https://github.com/timescale/tsbs 场景: TSBS DevOps CPU-Only：4000 device, 10秒采样一次，数据规模：10亿测试数据生成： tsbs_generate_data --use-case="cpu-only" --seed=123 --scale=4000 --timestamp-start="2021-05-01T00:00:00Z" --timestamp-end="2021-05- 04T00:00:00Z" --log-interval="10s" --format="clickhouse" | gzip > /tmp/clickhouse-data.gz 查询SQL生成： FORMATS="clickhouse" SCALE=4000 SEED=123 TS_START="2021-05-01T00:00:00Z" TS_END="2021-05-04T00:00:01Z" QUERIES=100 QUERY_TYPES="single-groupby-1-1-1 single-groupby-1-1-12 single-groupby-1-8-1 single-groupby-5-1-1 single-groupby-5-1-12 single-groupby-5- 8-1 cpu-max-all-1 cpu-max-all-8 double-groupby-1 double-groupby-5 double-groupby-all high-cpu-all high-cpu-1 lastpoint groupby-orderby-limit" BULK_DATA_DIR="/tmp/bulk_clickhouse_queries" scripts/generate_queries.sh 13

14. 时序指标数据写入性能测试数据集：Time Series Benchmark Suite (TSBS) Influx DB Data Loader Data Ingestion TimeScale DB 写入数据为采用Time Series Benchmark Suite (TSBS) 生成的时序数据，模拟4000台设备，每10秒采样一次，1月的数据量，总计10亿条数据，约53GB。 ClickHouse “样本数据 - cpu” DAE "2021-04-26 02:59:50",7866,79,10,44,76,69,54,12,91,50,53 “样本数据 - tags” "2021-05-27 09:54:46",1,"host_0","eu-central-1","eu-central-1a","6","Ubuntu15.10","x86","SF","19","1","test" 测试环境数据写入场景处理器 Intel(R) Xeon(R) CPU E5-2620 v4 @ 2.10GHz 32Cores 内存 192 GB 磁盘 7200 RPM 8T SATA * 22 网络万兆网络写入批量每次写入10000行TSBS数据写入worker数目 32 worker 单行数据平均size 56字节

15. 时序指标数据写入性能 (Cont.) Demo TSBS Data Ingestion Performance (rows/seconds, 32 workers) 1878805 2000000 - InfluxDB 的 15.5 倍 1500000 1000000 - TimeScaleDB 的 5.47 倍 636074 500000 0 插入性能对比： 17063 DorisDB - 社区版 ClickHouse 的 1.85 倍 224550 InfluxDB TimescaleDB ClickHouse

16. 时序指标数据查询性能查询数据集为采用Time Series Benchmark Suite (TSBS) 生成的时序数据，模拟4000台设备，每10秒采样一次，1月的数据量，总计10亿条数据，约53GB。 Influx DB Query Client Query Request 对比查询使用2张表：“cpu”表和“tags”表 TimeScale DB ClickHouse DAE 时序指标数据查询场景测试环境处理器内存 Intel(R) Xeon(R) CPU E5-2620 v4 @ 2.10GHz 32Cores 对比查询采用 Light Query是TSBS查询集合中非 192 GB TSBS的时序指计算密集型查询，不含多个group 标的15个标准 by, join操作 single-groupby-5-1-12，single-groupby-5-8-1 Heavy Query是TSBS查询集合中计 double-groupby-1，double-groupby-5，double- 磁盘 7200 RPM 8T SATA * 22 网络万兆网络查询算密集型查询，含多个group by， join等操作 cpu-max-all-1，cpu-max-all-8，high-cpu-1， single-groupby-1-1-1，single-groupby-1-1-12， single-groupby-1-8-1，single-groupby-5-1-1， groupby-all，groupby-orderby-limit，high-cpu-all ，lastpoint

17. 时序指标数据查询性能 (cont.) Demo TSBS Query Benchmark - Heavy Queries (1 worker, ms) 100000 80000 60000 40000 20000 0 查询性能对比： 78783 41760 30132 263 590 2240 3467 15399 804 960 3302 double-groupby-1 double-groupby-5 DAE 1442 1420 4870 1385 1292 152 double-groupby-all ClickHouse 66.7%(4/6) 的 Heavy 查询， DAE 比 InfluxDB 和 groupby-orderby-limit TimeScaleDB InfluxDB 10259 8039 12248 high-cpu-all TimeScaleDB快，最快可达30.15倍。 55.6%(5/9)的 1426 1443 174 lastpoint 8462 Light查询，DAE比InfluxDB和TimeScaleDB快或者持平，最快可达4倍

18. 日志分析场景测试数据某安全产品集群数据规模某安全产品1周(7天)的数据量数据量 18亿条记录, 原始数据空间占用 4.007 TB “样本数据：1000+ 字段” ElastiscSearch Query Client Query Request "null_n_a","null_n_a","null_n_a",-1,-1,- 1,”xxxxxxx(Alert)","::10.16.195.4","info.lenovo.com.cn","null_n_a","::43.255.226.106","null_n_a",80,"null_n_a","null_n_a",”xxxx告警 ","/MA4KYFIR001b","null_n_a","null_n_a","null_n_a","356780381453156352","2021-02-01 00:00:40.000","null_n_a",-1,- 1,"null_n_a","null_n_a",”xxx_alert_V2.0.6.20",-1,"null_n_a","null_n_a",-1,"::10.18.127.153",-8564,- 1,"null_n_a","null_n_a",”XXXX","null_n_a","null_n_a",-1, ……, "2021-02-01 00:00:40.000","2021-03-18 16:40:40.000" 日志分析查询场景 DAE集群对比查询采用 DAE BI报表查询某安全产品内部测试环境的查询分布构造测试环境处理器 Intel(R) Xeon(R) CPU E5-2630 v3 @ 2.40GHz 32 Cores 内存 64 GB 磁盘 10 T SATA 网络万兆网络 HQ Lite查询

19. 日志分析场景 (Cont.) Demo 查询性能对比： BI Query查询中(Cold Cache)，DAE 85.33%(64/75)的查询比ES快， 70.67%(53/75)的查询比ES快1倍， 49.33%(37/75)的查询比ES快2倍， 22.67%(17/75)的查询比ES快5倍

20. 决策分析场景测试数据集：Star Schema Benchmark (SSB) 场景: 商业决策分析，Scale Factor：100, 数据规模：10亿 (600037902) 测试数据生成： $ git clone git@github.com:vadimtk/ssb-dbgen.git $ cd ssb-dbgen $ make $ ./dbgen -s 100 -T a 20

21. 决策分析场景查询性能对比： - SSB宽表查询性能对比，StarRocks比ClickHouse占优，但基本在同一个量级，13 SSB个查询中，StarRocks有7个查询较CK快。所有的查询都在1秒以内 - 多表Join查询，StarRocks所有的SSB查询都有较大的性能优势

22. 性能监控监控工具：node exporter + Prometheus + grafana

23. 问题与展望

24. 日志分析性能测试 (DAE vs ES) • 预期结果：DAE 优于ES • 实际结果：ES优于DAE

25. 日志分析性能测试 (DAE vs ES) • 观察一： • ES大量使用内存，有Query Cache, Request Cache, Data Cache, Index Cache, DAE使用的内存空间较少 • 更符合业务场景的查询测试方案： • 查询中伴随着数据的插入 • 对比首次查询(Cold Cache)的Query Response Time • Action: • 为ClickHouse查询添加缓存功能

26. 日志分析性能测试 (DAE vs ES) • 原因二： • DAE未创建合适的索引 • 解决方案： • 根据SQL中的filter建立合理的索引

27. 日志分析性能测试 (DAE vs ES) • 原因三 • DAE SQL未优化 • 解决方案 • 用count(1)代替count(id) • 用prewhere代替where

28. 日志分析性能测试 (DAE vs ES) • 原因四 • DAE分布式查询bug: 分布式查询的查询计划不正确

29. 时序指标数据写入性能测试 TSBS 问题： data generation data generation .gz/txt csv data ingestion Memory data query data ingestion • TSBS对每种数据库的源数据要单独生成，格式和内容有差异 • TSBS不支持TDengine、MatrixDB • 用TSBS原生的写入程序初步测试ClickHouse的写入性能达不到期望的写入性能 data query

30. 性能问题排查Tips Your best friend：ClickHouse Query Log Enable ClickHouse Query Log Clickhouse-client –-send_logs_level=trace -m 30

31. 性能问题排查Tips View ClickHouse Query Log sudo less /var/log/clickhouse-server/clickhouse-server.log Quick Identify related Query Log grep <query_id> from clickhouse-server.log

32. Others 开始性能测试之前，明确业务的性能需求以及场景小规模充分验证，保证方法正确后，再上规模测试数据交叉验证, 找到性能瓶颈在哪里详细记录每一次性能测试的配置及指标性能指标监控很重要保持好奇心，性能测试是一个不断学习的过程

33.

34. 360技术 THANKS 360质量效能

35.