一、背景说明
环境说明
  • 机器配置：32core 64GB 共4台 外挂2个T磁盘（由64core128G的物理机虚拟出来2台）
  • DataX3.0 集成clickhouse
CK版本说明
  • ClickHouse client version 20.3.12.112
数据量
  • Hive表单分区（31个字段，数据条：78889453）
目的
  • 测试大数据量下的datax channel数和batchSize的的合理参数设置
二、测试结果
1. 测试 数据量：78889453  channel=2  batchSize=100000

任务启动时刻                    : 2020-08-31 18:05:49
任务结束时刻                    : 2020-08-31 18:23:36
任务总计耗时                    :               1067s
任务平均流量                    :            9.05MB/s
记录写入速度                    :          74424rec/s
读出记录总数                    :            78889453
读写失败总数                    :                   0


2. 测试 数据量：78889453  channel=5  batchSize=2048
任务启动时刻                    : 2020-08-31 18:57:07
任务结束时刻                    : 2020-08-31 19:12:02
任务总计耗时                    :                895s
任务平均流量                    :           10.77MB/s
记录写入速度                    :          88639rec/s
读出记录总数                    :            78889453
读写失败总数                    :                   0


3. 测试 数据量：78889453  channel=5  batchSize=100000
任务启动时刻                    : 2020-08-31 18:35:41
任务结束时刻                    : 2020-08-31 18:44:36
任务总计耗时                    :                535s
任务平均流量                    :           18.09MB/s
记录写入速度                    :         148848rec/s
读出记录总数                    :            78889453
读写失败总数                    :                   0

4. 测试 数据量：78889453  channel=5  batchSize=200000
任务启动时刻                    : 2020-08-31 19:41:18
任务结束时刻                    : 2020-08-31 19:50:24
任务总计耗时                    :                545s
任务平均流量                    :           17.76MB/s
记录写入速度                    :         146091rec/s
读出记录总数                    :            78889453
读写失败总数                    :                   0
三、结果说明
结论：
  1. Hive表推数到clickhouse 适当提什channel数能显著提升性能（考虑文件数设置合适的channel）
  2. 当channel=5时候，提升批写由10w到20w大小无性能增加，可能IO已到极值,写入速度14w+每秒)
  3. 同channel数情况下，批越大写入的速度相对越快，但是到了一定的值就不会再增加
不足之处：
  1. 缺乏ck集群的监控，只能看到简单的qps和读写延迟，无法看具体机器的负载情况
  2. 未做小数据量如百万级别的推数对照测试（真的很快）
  3. 没有ck的异步后台合并监控（很关键）
计划
  1. 必须增加监控收集更多的数据信息（运维同学目前在努力）
  2. 千万级别一下不建议写分布式表，一律统一使用本地表
  3. ck查询要负载均衡设置（可以使用Nginx做软件负载均衡）
  4. ck的上层需要封装用以路由查询和事务、并发相关的控制

最后， 不足之处、欢迎批评指正！