摘要:
本文是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 | 环境参数 | 不需要设置 |