Apache Druid的性能优化
作者：互联网
简单从6个方面列举一下druid在生产实践中的一些优化
1. Segments大小控制
按照官方说明，段文件的大小应在建议的300MB-700MB范围内，当超过700M时才建议通过减小 Max rows per segment 来控制大小，如果默认500w行生成的segments只有太低，需要将 Max rows per segment 增大。
由于Segments里面的数据是经过索引压缩的，由为4个固定的文件组成，且segments的相关信息存在MySQL中，很难手动合并Druid小文件。所以除了对整个数据源开启compact任务的同时，建议并发开启多个compact任务，对过去的每一天的segments进行批量合并，同时开启定时任务，每天1点以后对昨天的segements执行compact合并任务。合并参数Max rows per segment 默认是500w行，这里也需要修改以控制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小时形成1个segments左右，如果只有较少的segments是达到500w上限的，可以2小时结束一个task
批量输入：增大maxRowsPerSegment，尽量用正则匹配多个文件，合理设置任务的并行度。
3. 合理设置数据源
尽量按不同需求拆分数据源，避免一个数据源的segments太多，维度数据可以单独数据源存放，druid现在已经直接jion查询。
4. 预计算
开启rollup减少数据量，或者通过spark hive预先聚合数据
5.减少LookUP的使用
已经固定的数据清洗，需要转移到预计算中，尽量减少loop_up的使用，减少Druid cpu负担，毕竟Druid不是一个分布式计算引擎。
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机制，通过它们能很好的将数据进行分离，从而达到灵活的分布数据的目的。
参考资料
- 基于 Apache Druid 的实时分析平台在爱奇艺的实践 https://www.sohu.com/a/398880575_315839
- 知乎 Druid 集群优化实践https://zhuanlan.zhihu.com/p/82038648
- 实时OLAP引擎之Apache Druid：架构、原理和应用实践 https://zhuanlan.zhihu.com/p/17857217
- 网飞公司是如何使用Druid进行实时观测以确保高质量体验的？ https://baijiahao.baidu.com/s?id=1663595034362515556&wfr=spider&for=pc
[WARN]本文发自csdn,未经授权禁止复制转载
标签：compact,数据源,segments,Druid,com,https,Apache,优化 来源： https://blog.csdn.net/qq_19933029/article/details/116499720