OLAP分析引擎Druid配置文件詳解（三）：coordinator配置文件

摘要：
  本文是Druid配置文件系列博文的第三篇，之前的文章已經介紹了Druid配置文件整體的組織結構以及公共配置文件，接下來將逐個介紹Druid的五大組件，本文是第一個組件Coordinator的介紹。

---

以下配置都在coordinator/runtime.properties文件中。

Coordinator Process Config

屬性	含義	備註	是否需要修改
druid.host	組件所在的主機	默認InetAddress.getLocalHost().getCanonicalHostName()	一般不需要修改
druid.bindOnHost	組件的內部jetty服務是否和druid.host綁定	默認false	一般不需要修改
druid.plaintextPort	實際監聽端口	默認8081	一般不需要修改
druid.tlsPort	TLS端口號	默認8281	一般不修改
druid.service	用於服務發現的名字	默認druid/coordinator	一般不修改

這些配置在其他組件中也都有，含義與這裏相同，接下來將不再逐個介紹

Coordinator Operation

屬性	含義	備註	是否需要修改
druid.coordinator.period	coordinator每隔一段時間會運行去查看可用的segment和處於服務中的segment，這個屬性表示這個時間間隔	默認PT60S	按需修改
druid.coordinator.period.indexingPeriod	每隔多久去發送壓縮/合併/轉換任務	默認PT1800S，推薦要大於druid.manager.segments.pollDuration	一般不需要
druid.coordinator.startDelay	Coordinator運行時假設自己知道最新的所有狀態，但是ZK不允許Coordinator知道它是否已經得到全部最新狀態，所以需要一個時間間隔給足夠的時間讓Coordinator可以假設自己已經得到全部最新狀態	默認PT300S	一般不修改
druid.coordinator.load.timeout	分配一個segment到historical的超時時間	默認PT15M	一般不修改
druid.coordinator.kill.pendingSegments.on	是否清理元數據中的pendingSegments表的老條目，清理的時間間隔是druid.coordinator.period，killPendingSegmentsSkipList裏的數據源不會被清理	默認false	按需修改
druid.coordinator.kill.on	Coordinator是否提交kill任務去刪除元數據和深存儲中的無用數據清理的時間間隔是druid.coordinator.kill.period，durationToRetain是保留時間，在這個時間內的segment不會被刪除，白名單可以通過killAllDataSources和killDataSourceWhitelist設置	默認false	按需修改
druid.coordinator.kill.period	發送kill任務的時間間隔	默認P1D	按需修改
druid.coordinator.kill.durationToRetain	在最近這個時間內的segment不會被刪除	默認PT-1S	默認值無效，如果kill打開必須設置
druid.coordinator.kill.maxSegments	每個kill任務最多刪除的segment數量	默認0	默認值無效，如果kill打開必須設置
druid.coordinator.balancer.strategy	segment平衡策略	默認cost，可選值是cachingCost、diskNormalized、random，cachingCost是cost的優化版將取代cost，diskNormalized儘量保證磁盤使用均勻，random隨機分配segment	按需修改
druid.coordinator.balancer.cachingCost.awaitInitialization	使用cachingCost策略時，是否在創建cachingCost策略之前等待segment視圖初始化	默認false	按需修改
druid.coordinator.loadqueuepeon.repeatDelay	管理segment加載和刪除的loadqueue的開始和重複延遲時間	默認PT0.050S (50 ms)	按需修改
druid.coordinator.asOverlord.enabled	是否Coordinator也充當Overlord的角色，這個用來簡化集羣，沒有部署overlord時使用	默認false	一般不修改
druid.coordinator.asOverlord.overlordService	如果druid.coordinator.asOverlord.enabled爲true，用於服務發現	默認null，應該和overlord組件的druid.service屬性和middle manager組件的druid.selectors.indexing.serviceName屬性相同	如果druid.coordinator.asOverlord.enabled爲true，需要修改

Segment Management

屬性	含義	備註	是否需要修改
druid.serverview.type	segment發現的方法	默認batch，可選值http，batch使用zk方式	按需修改
druid.coordinator.loadqueuepeon.type	分配segment的方式	默認curator，可選值http	按需修改
druid.coordinator.segment.awaitInitializationOnStart	Coordinator是否在開始之前等待segment視圖完全初始化	默認true	按需修改

druid.coordinator.loadqueuepeon.type設置爲http時需要配置以下屬性

屬性	含義	備註	是否需要修改
druid.coordinator.loadqueuepeon.http.batchSize	在一個http請求里加載或刪除的segment數量	默認1，需要小於druid.segmentCache.numLoadingThreads	按需配置

Metadata Retrieval

屬性	含義	備註	是否需要修改
druid.manager.config.pollDuration	manager多久拉一次配置表用於更新	默認PT1M	按需修改
druid.manager.rules.pollDuration	manager多久拉一次用於更新活躍segment	默認PT1M	按需修改
druid.manager.rules.defaultTier	默認tier，默認的規則將從tier中加載	默認_default	按需修改
druid.manager.rules.alertThreshold	失敗的拉多久後會報警	默認PT10M	按需修改

Dynamic Configuration

Coordinator有一個通過HTTP的動態配置方式，具體如下：
url：POST http://<COORDINATOR_IP>:/druid/coordinator/v1/config

可選的Header：

屬性	含義
X-Druid-Author	改變配置的用戶名
X-Druid-Comment	描述配置修改內容的註釋

一個Body的例子：

{
  "millisToWaitBeforeDeleting": 900000,
  "mergeBytesLimit": 100000000,
  "mergeSegmentsLimit" : 1000,
  "maxSegmentsToMove": 5,
  "replicantLifetime": 15,
  "replicationThrottleLimit": 10,
  "emitBalancingStats": false,
  "killDataSourceWhitelist": ["wikipedia", "testDatasource"],
  "decommissioningNodes": ["localhost:8182", "localhost:8282"],
  "decommissioningMaxPercentOfMaxSegmentsToMove": 70,
  "pauseCoordinator": false
}

一個GET請求相同的url會得到當前這些配置屬性的值

下面分別介紹這些屬性的含義：

屬性	含義	備註	是否需要修改
millisToWaitBeforeDeleting	Coordinator在刪除元數據中的segment之前需要活躍多久	默認900000（15分鐘）	按需配置
mergeBytesLimit	合併segment的最大未壓縮字節大小	默認524288000L	按需修改
mergeSegmentsLimit	合併的最大segment數量	默認100	按需修改
maxSegmentsToMove	最大的能被移動的segment數量	默認5	按需修改
replicantLifetime	對於要複製的segment，在報警之前Coordiantor運行的最大次數	默認15	按需修改
replicationThrottleLimit	一次複製的最大segment數量	默認10	按需修改
balancerComputeThreads	在segment平衡是，計算移動cost的線程池大小	默認1	按需修改
emitBalancingStats	是否emit平衡相關統計	默認false，這是一個昂貴的操作	按需修改
killDataSourceWhitelist	發送kill任務的數據源白名單（白名單中的dataSource會被kill）	默認none	按需使用
killAllDataSources	是否對所有dataSource發送kill任務，與killDataSourceWhitelist只能使用其中一個	默認false	按需使用
killPendingSegmentsSkipList	kill pending狀態segment時跳過的數據源列表	默認none	按需使用
maxSegmentsInNodeLoadingQueue	最大的segment排毒數量	默認0，這個值可以在有慢節點或segment調度不均勻時加速segment加載過程，可以設置爲1000然後根據情況調節	按需使用
decommissioningNodes	退役historical列表，將不分配新的segment到退役節點上	默認none	按需使用
decommissioningMaxPercentOfMaxSegmentsToMove	再一次Coordinator運行時，從退役節點上移動到非退役節點上的segment數量	默認70	按需使用

Lookups Dynamic Configuration

略

Compaction Dynamic Configuration

通過API來設置Compaction任務

屬性	含義	備註	是否需要修改
dataSource	要Compaction的數據源名字		需要設置
taskPriority	任務優先級	默認25	不需要設置
inputSegmentSizeBytes	最大的總的segment的字節數	默認419430400	不需要設置
maxRowsPerSegment	每個segment的最大行數		不需要設置
skipOffsetFromLatest	搜索要壓縮的segment的offset	默認P1D	不需要設置，對於實時數據源推薦去設置
tuningConfig	裏面的參數之後在詳細介紹		不需要配置
taskContext	環境參數		不需要設置