Druid的性能优化

列举一下druid在生产实践中的一些调优

1. Segments大小数量控制

按照官方说明，段文件的大小应在建议的300MB-700MB范围内，当超过700M时才建议通过减小 Max rows per segment 来控制大小，如果默认500w行生成的segments太低，需要将 Max rows per segment 增大。

如果segments太小，建议开启数据源自动compact任务，对过去的segments进行批量合并，同时开启定时任务，每天1点以后对昨天的segements执行compact合并。合并参数Max rows per segment 这里也需要修改以控制segments 大小。

合并任务参数：

{"type":"compact","dataSource":"XXXX","interval":"2020-01-01/2020-01-02","tuningConfig":{"type":"index_parallel","maxRowsPerSegment":20000000,"maxRowsInMemory":2000000}}

2.Segments数量、分布:

决定因素：划分的时间段内数据量大小和task数量，task周期

流式输入：每天默认1小时结束一个task，如果不是按小时切分segments且只有较少的segments是达到500w上限的，可以2小时结束一个task，不影响查询。

批量输入：增大maxRowsPerSegment，合理设置任务的并行度，合理设置分区规则，可以指定数据摄入的Time intervals，使用hadoop-index的方式代替默认的index_parallel。

3. 合理设置数据源

尽量按不同需求拆分数据源，避免一个数据源的segments太多，维度数据可以在单独的数据源存放，druid现在已经支持join查询，相同schema的数据源可以在需要的时候一起查询。

指定union和datasource列表可查询多个schema相同的数据源

"type":"union",
"dataSources":[
    "<datasource_1>",
    "<datasource_2>",
    "...",
    "<datasource_n>"
]

4. 预计算

开启rollup减少数据量，或者通过spark hive预先聚合数据。

5.减少LookUP的使用

​ 已经固定的数据清洗，需要转移到预计算中，尽量减少loop_up的使用，减少Druid cpu负担。

6.Hisory节点相关

• ​ 参考Airbnb 4 Brokers, 2 Overlords, 2 Coordinators, 8 Middle Managers, and 40 Historical nodes的设计 分配更多的 Historical nodes会显著提高性能。
• 推荐使用ssd作为cache硬盘
• 冷热分离：Druid索引好的数据放在Historical中，随着数据规模的扩大，分离数据的需求逐渐变得迫切。Druid提供了Tier机制与数据加载Rule机制，通过它们能很好的将数据进行分离，从而达到灵活的分布数据的目的。

  [INFO]转载请注明作者和出处