Druid压测和数据摄入优化

Druid压测结论：

  1.“枚举型”和“连续数值型”在当前业务数据量级（500G左右）下摄入和查询功能可轻松支撑，摄入时长可保证30分钟以内，查询用时可保证200ms以内。

  2.10倍于当前业务数据量级下，枚举型摄入时长可优化至2小时，连续数值型可优化至40分钟，查询用时可保证200ms以内。

Druid数据摄入优化经验

1. 对HDFS文件开启gz压缩，测试gz格式比lzo格式入库要省30%的时间，因为数据压缩率变大。

2. 对tuningConfig里的  "targetPartitionSize" : 1750000,（每个分片的文件大小，单位kb）

                                     "maxPartitionSize" : 2000000（每个分片最大行数）

Druid对这俩参数会自动取较小的生效，可以对targetPartitionSize降低一些，这样分片数变多，reduce端个数变多，运行时间变少

暂定改到128M

3. 对于数据量过大运行过慢的情况

HDFS数据入库Druid的时候，会有两组MRjob，第一组MRjob会从完整数据中抽样15%入库Druid，且入库时间为完整数据的15%，这15%的数据入库完后Druid会按照比例计算出完整数据需要设定多少个分片；然后走第二个MRjob，将完整数据入库Druid。

这样，如果数据量过大，可以在ioConfig中手动指定分片数，这样第一步的MRjob就不会运行，直接走第二步的MRjob，省下15%的时间

 

ps：分片数的个数最大不能超过集群机器的核数

分片数越多，入库速度越快，因为reducer端个数越多，但是分片数过多会导致查询时间变长，比如一次查询只能读取5000个分片，集群机器总核数5000，如果分片数设置为2w，那读取就需要读取四次，加大读取时间。

 

摄入效率最终优化成果：

  1.枚举型，原lzo压缩6.3T数据摄入用时6小时+，优化后2小时03分完成，缩减70%

  2.连续数值型，原lzo压缩1.8T数据摄入用时1小时20分钟+，优化后40分钟完成，缩减50%