druid.io实践1---查询速度优化

当数据维度比较多，存储时间比较长时，数据量会增加到到T级别。如果historical节点只是单机版，查询会特别慢。在生产过程中，主要做了以下几点优化：

增加缓存

当集群机器较少时(官方文档推荐<20台)，在broker节点配置缓存，可以适当增加缓存大小，或者从local替换成memcached。

当集群机器较多时，应当只配置historical节点缓存，减轻broker节点压力。

附：broker部分配置

# Query cache
druid.broker.cache.useCache=true
druid.broker.cache.populateCache=true
druid.cache.type=local
druid.cache.sizeInBytes=2000000000

historical节点集群化

查询为CPU密集型，通过合理的数据分配策略，使数据尽量分散在不同的历史节点。

集群分片

可以根据查询频率的高低分为冷热数据，公司经常查40天内的数据，40天内的数据显然是hot数据。

这里涉及到coordinate节点的Load Rules配置，druid 0.9版本有coordinator的UI界面，可以设置每个dataSource的Load Rules。如下：

这里设置了两个Load Rules，loadByPeriod部分表示40天内的数据在hot和_default_tier分片各保存一份副本。loadForever部分表示所有数据在_default_tier保存一份。

增加分片的节点数

增加_default_tier和hot分片的节点数，并且节点存储空间尽量一致，使segment均匀分散在节点间，降低查询时每个historical节点的CPU负载。

例如：_default_tier分片增加到2-3台，hot分片增加到5-10台机器，热数据分散到更多台。

调整历史节点配置参数

druid.server.priority

默认为0。

broker节点中，druid.broker.select.tier的配置默认为highestPriority，表示如果有重复的数据样本，优先查询优先级高的历史节点。

例如：将hot分片的机器druid.server.priority设置为100，_default_tier分片的默认0，则查询热数据时，不会查询_default_tier，只会去查询hot，而hot集群机器比较多，查询速度快。

druid.processing.numThreads

可以根据自己机器的情况进行调节，如果机器只用于历史节点，可以设置为（核心数-1），32核机器可以设置为31，或者默认值就是31。

druid.segmentCache.locations

可以将数据存储分散在不同的磁盘上，可以减轻磁盘的读写压力。

附：history节点部分配置

hot集群中调优查询速度的相关配置

#集群分片，不写默认_default_tier
druid.server.tier=hot  
#查询优先级，不写默认0，_default_tier分片的两个节点为0，hot节点的都改为100。这样，热数据只会查hot节点的机器。
druid.server.priority=100

#processing.buff，可以注释掉，默认是1G
#processing.numThreads:默认是繁忙时core-1做process，剩余的1个进程做与zk通信和拉取seg等。
druid.processing.buffer.sizeBytes=1073741824
druid.processing.numThreads=31

#segment路径和各路径的空间，例如：在disk1、2、3各配了200G
druid.segmentCache.locations=[{"path": "/disk1/druid-0.9.1.1-historical-data/persistent", "maxSize": 200000000000},{"path": "/disk2/druid-0.9.1.1-historical-data/persistent", "maxSize": 200000000000},{"path": "/disk3/druid-0.9.1.1-historical-data/persistent", "maxSize": 200000000000}]
#segment总空间（字节）=上述空间之和
druid.server.maxSize=600000000000

老数据roll up

进行实时和批量indexing的时候，一般配置的按小时的粒度进行roll up，最后存储的就是按小时聚合的数据。

"granularitySpec": {
    "type": "uniform",
    "segmentGranularity": "HOUR",
    "queryGranularity": "HOUR"
}

当数据积累较长时间后，按小时聚合必然数据量巨大，可以将不常用或者不太重要的数据，按天存储，数据量会大大减小，必然可以提高查询速度。

例如：将40天之后的数据提交batch indexing任务按天roll up。

最后的效果

以7台机器为例，配置5台hot分片的机器，2台default分片的机器。hot分片存储的是以小时为粒度的数据，_default_tier分片存的是按天为粒度的数据。

40天之内的热数据根据之前配置的规则，会在hot分片存一份，_default_tier分片存一份

40天之前的数据只会在_default_tier分片存一份

查询40天内的数据时，由于hot分片的机器优先级高。只会从hot分片的5台机器读取数据，40天之前的数据只会从default分片读取数据。