在说任务配置策略之前，先给大家看一下druid任务处理的大概架构图

如上图可以看出overlord节点如何将任务分配到middlemanager节点进行处理，如果在架构中有多个middlemanager节点，那任务将怎么分配呢，分配的测试是什么？
 
默认策略是fillCapacity, 意思是当一个MiddleManager的worker capacity满了的时候,再有任务到来时,才会分配给另外的MiddleManager节点。
 
补充: middlemanager的capacity意思是,能容纳任务的数量,通过修改middleManager节点下的 runtime.properties配置文件里的druid.worker.capacity属性配置。 

那么,除了这个策略,还有其他策略吗?另外,这个策略如何修改呢? 除了这个策略,还有fillCapacityWithAffinity, equalDistribution and javascript策略,那么策略如何修改呢? 
 
通过向Overlord节点发送个一个HTTP请求来修改,实质上是修改保存druid元数据的数据库,即 MetadataStorage,修改步骤如下: 

http://10.1.3.9:8090/druid/indexer/v1/worker(http://: /druid/indexer/v1/worke

X-Druid-Author sdx(修改配置的作者,可以随意写) X-Druid-Comment equal policy(修改配置的注释,可以随意写) Content-Type application/json

http://10.1.3.9:8090/druid/indexer/v1/worker(http://: /druid/indexer/v1/worker)

{

"selectStrategy": {

"type": "equalDistribution" }

}

通过访问http://10.1.3.9:8090/druid/indexer/v1/worker/history查看配置是否成功 

或者通过查看MetadataStorage的druid_conifg和druid_audit表查看是否配置成功 
 
注意: linux上通过如下指令配置:

curl -XPOST -H 'X-Druid-Author: lucky' -H 'X-Druid-Comment: lucky' -H 'Content-Type: application/json' http://10.1.3.9:8090/druid/indexer/v1/worker -d '{ "selectStrategy": { "type": "equalDistribution" } }'

更多内容请参考官网:http://druid.io/docs/0.9.1.1/configuration/indexing-service.html。

经测试发现: 
DeepStorage里所有的segements都需要在Historical节点中有一份。其实这样说是不严格的，有时候我们需要DeepStorage里所有的segements(或者某类datasource)在Historical节点中有一份或者n份。这样做的好处是，提高数据查询效率，那么这个n在哪里配置呢?
 
原来是在druid_rules表里面配置，默认情况下，druid_rules表里面只有一条数据，其中payload字段默认值如下:

[{"tieredReplicants":{"_default_tier":2},"type":"loadForever"}]

意思是 保证deepstorage里面的数据，在Historical节点集群存在两份，即副本为2，这两份数据一定保存在不同的Historical服务器。
 
如果只有一台Historical服务器，那么则只会有一份数据，如果你添加一台Historical服务器，则就会在新的节点复制一份数据。
 
如果想修改默认的副本数，不需要数据备份，进行如下操作就好：

update druid_rules set payload='[{"tieredReplicants":{"_default_tier":1},"type":"loadForever"}]' where id="_default_2016-09-23T08:50:09.457Z";

只需把_default_tier的值改为1即可，id得看druid_rules表中的具体值。
 
segment执行过程如下：

1. 聚合任务生成segment
2. 将segment push到Deep Storage 
3. Historical节点从 DeepStorage加载segment
4. segment加载成功后,调用回调方法结束任务 

 
所以,如果Historical节点硬盘上缓存的segment占满磁盘空间,任务会一直挂起, 最后任务数量达到MiddleManager节点的容量,导致任务排队。 
 
那么现实业务中,如果DeepStorage里所有的segments 都需要在Historical节点中有一份,会非常 浪费空间,浪费空间就是浪费金钱。 
 
很不能理解这种方式,并且我们对DeepStorage节点和Historical节点之间的关系一直都是这样理解的，当查询的数据不在Historical节点的时候,才会从DeepStorage加载。但是,现实是残酷的,现实不是这样的。 
 
如何解决这个问题呢?这时我们就需要用到druid的数据保留和自动删除规则配置。 通过这个配置,我们可以为每个datasource配置一个据保留和自动删除规则。 
 
这个配置可以通过druid提供的HTTP接口配置,也可以通过Coordinator界面配置,如下: 

此配置的意思是: 我们为agentToic-1m设置了两个rule,第一个rule的意思是(Load-Period-P30D)保 留最近30天的数据。第二个rule的意思是(Drop-Forever)删除所有的数据。另外还需要填写,修改 配置的作者和注释。最后Save all rules。 通过如下界面查看,配置是否成功,或者通过查看MetadataStorage的druid_rules表查看配置是否成功。

最后,结合下图,观察左侧segment列表是否会发生变化(shareds的数量和intergvals的数量)。 

经过验证,左侧列表只会展示最近30天的数据,通过查看MetadataStorage的druid_segments表, 发现30天以前的数据都被假删了,即used字段设置为了0,表示配置成功。 
 
注意: 
如果druid_segments表中的某条数据used字段为0,即此条数据对应的segment不再支持可查,同 时会再Historical节点删除。 如果上面的P30D改为P1M,意思是1个月,这个月不是自然月,而是最近30天的意思。 如果按照如上的方式设置了,再修改第一条配置规则,改为P50D,那么数据是不能恢复的,即还 是只会保留最近30天的数据。 一个笨的恢复数据方法是,可以通过修改MetadataStorage的druid_segments表中的used字段来恢复数据。 
 
论坛:

If you configure a per datasource rule that drops data for the current month, and there i

s a default rule where everything is loaded, then yes, data for the current month is dropp ed and all older data is loaded. If you instead configure a load rule for the current month followed by a drop rule for everything else, then the current month of data is kept, and

all older data is dropped.

具体内容,参考官网:http://druid.io/docs/latest/operations/rule-configuration.html
任务分配策略，会让Geek小A  明天写！