OLAP分析引擎Druid配置文件详解（四）：Overlord配置文件

师建德

2023-12-01

摘要：
本文是Druid配置文件系列博文的第四篇，我们将继续逐个介绍Druid的五大组件，前文已经介绍了Coordinator组件的配置文件，本文是第二个组件Overlord的介绍。

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

Overlord Process Configs

这些配置在其他组件中也都有，这里不太详细介绍，如需了解请查看前一篇博文Coordinator配置文件

Overlord Operations

属性	含义	备注	是否需要修改
druid.indexer.runner.type	任务是运行在本地还是一个分布式环境中	可选值有local（运行在本地）、remote（通过zk运行在分布式环境）、httpRemote（通过Http运行在分布式环境），默认是local	一般正式环境下需要修改
druid.indexer.storage.type	任务元信息存储位置	可选值有local（本地内存中）、metadata（元数据表中，overlord挂掉后任务可恢复），默认是local	一般正式环境需要修改
druid.indexer.storage.recentlyFinishedThreshold	任务结果的保留时间	默认PT24H，24小时	按需配置
druid.indexer.tasklock.forceTimeChunkLock	是否强制使用time chunk锁	默认true	一般不修改
druid.indexer.queue.maxSize	活跃任务的最大数量	默认Integer.MAX_VALUE	一般不修改
druid.indexer.queue.startDelay	打开overlord队列管理器之前等待这么多时间以给集群时间去重新定位自己	默认PT1M，一分钟	按需修改，一般不需要修改
druid.indexer.queue.restartDelay	在overlord队列管理器遇到异常重启之前等待这么久时间	默认PT30S	按需修改，一般不需要修改
druid.indexer.queue.storageSyncRate	同步overlord状态的时间	默认PT1M	按需修改，一般不需要修改

以下属性只在druid.indexer.runner.type为remote模式下有效。

属性	含义	备注	是否需要修改
druid.indexer.runner.taskAssignmentTimeout	任务分配超时时间，过了这个时间后，会跑出任务分配错误的异常	默认PT5M	按需修改，一般不需要修改
druid.indexer.runner.minWorkerVersion	最小的middle manager版本	默认0	一般不需要修改
druid.indexer.runner.compressZnodes	是否期待middle manager去压缩Znode	默认true	按需修改，一般不修改
druid.indexer.runner.maxZnodeBytes	最大的Znode字节大小	默认524288	按需修改，一般不修改
druid.indexer.runner.taskCleanupTimeout	middle manager和zk失联多久后，一个任务超时失败	默认PT15M	按需修改，一般不修改
druid.indexer.runner.taskShutdownLinkTimeout	给middle manager发送请求多久没响应后超时失败	默认PT1M	按需修改，一般不修改
druid.indexer.runner.pendingTasksRunnerNumThreads	分配pending任务到worker的线程数量	默认1，至少设置为1	按需修改
druid.indexer.runner.maxRetriesBeforeBlacklist	最大连续的失败次数，超过这个次数后worker将被加入黑名单	默认5，最小设置1	按需修改
druid.indexer.runner.workerBlackListBackoffTime	多久之后worker被重新加入到白名单	默认PT15M，必须大于workerBlackListCleanupPeriod	按需修改
druid.indexer.runner.workerBlackListCleanupPeriod	清理线程过这么久后将去清理黑名单里的worker	默认PT5M	按需修改
druid.indexer.runner.maxPercentageBlacklistWorkers	加入黑名单的worker的最大百分比	默认20	按需修改

此外，有一些用于自动扩容的配置：

属性	含义	备注	是否需要修改
druid.indexer.autoscale.strategy	自动扩容策略	可选值有noop和ec2（amazon的一个自动扩容器，是目前唯一支持的自动扩容器，之后会详细介绍），默认noop	如果设置自动扩容需要修改为ec2
druid.indexer.autoscale.doAutoscale	是否自动扩容	默认false	如果设置自动扩容需要修改为true
druid.indexer.autoscale.provisionPeriod	每隔多久去检查是否应该增加middle manager	默认1分钟	按需修改，一般不需要
druid.indexer.autoscale.terminatePeriod	每隔多久去检查是否应该移除middle manager	默认5分钟	按需修改，一般不需要
druid.indexer.autoscale.originTime	terminate period增加的开始参考时间戳	默认2012-01-01T00:55:00.000Z	按需修改，一般不需要
druid.indexer.autoscale.workerIdleTimeout	一个worker不运行任务多久后会被终止	默认90分钟	按需修改，一般不需要
druid.indexer.autoscale.maxScalingDuration	overlord会等待middle manager多久不响应才会放弃	默认15分钟	按需修改，一般不需要
druid.indexer.autoscale.numEventsToTrack	要追踪的自动扩容相关event的数量	默认10	按需修改，一般不需要
druid.indexer.autoscale.pendingTaskTimeout	一个任务处于pending状态多久后overlord会考虑扩容	默认30秒	按需修改
druid.indexer.autoscale.workerVersion	如果设置，在自动扩容时将仅仅创造设置版本的节点	默认null	按需修改
druid.indexer.autoscale.workerPort	自动扩容的middle manager的端口号	默认8080	按需修改

Supervisors

属性	含义	备注	是否需要修改
druid.supervisor.healthinessThreshold	对于一个不健康的Supervisor，当它成功运行多少次后将它作为一个健康的	默认3	按需修改，一般不需要
druid.supervisor.unhealthinessThreshold	对于一个健康的Supervisor，当它失败运行多少次后将它作为一个不健康的	默认3	按需修改，一般不需要
druid.supervisor.taskHealthinessThreshold	对于一个不健康的Supervisor，当它连续成功运行多少次后将它作为一个健康的	默认3	按需修改，一般不需要
druid.supervisor.taskUnhealthinessThreshold	对于一个健康的Supervisor，当它连续失败运行多少次后将它作为一个不健康的	默认3	按需修改，一般不需要
druid.supervisor.storeStackTrace	是否Supervisor异常的全部stack traces应该被保存和被/status返回	默认false	按需修改
druid.supervisor.maxStoredExceptionEvents	能被/status返回的最大异常事件数量	默认max(healthinessThreshold, unhealthinessThreshold)	需修改，一般不需要

Overlord Dynamic Configuration

Overlord能动态修改配置。
动态修改配置需要POST发送配置Json到以下url：

http://<OVERLORD_IP>:/druid/indexer/v1/worker

也可以通过GET方式请求以上url得到现有的配置。
header中可以添加两个参数用于审计配置的修改（也可以不指定）。X-Druid-Author指示做这个修改的用户。X-Druid-Comment指示做这个修改的一个备注。
以下是要发送的json body的一个例子：

{
  "selectStrategy": {
    "type": "fillCapacity",
    "affinityConfig": {
      "affinity": {
        "datasource1": ["host1:port", "host2:port"],
        "datasource2": ["host3:port"]
      }
    }
  },
  "autoScaler": {
    "type": "ec2",
    "minNumWorkers": 2,
    "maxNumWorkers": 12,
    "envConfig": {
      "availabilityZone": "us-east-1a",
      "nodeData": {
        "amiId": "${AMI}",
        "instanceType": "c3.8xlarge",
        "minInstances": 1,
        "maxInstances": 1,
        "securityGroupIds": ["${IDs}"],
        "keyName": "${KEY_NAME}"
      },
      "userData": {
        "impl": "string",
        "data": "${SCRIPT_COMMAND}",
        "versionReplacementString": ":VERSION:",
        "version": null
      }
    }
  }
}

下面详细介绍以下这些参数。

属性	含义	备注	是否需要修改
selectStrategy	如何去分配任务到middle manager	可选值有fillCapacity, equalDistribution和javascript，具体含义下面介绍	默认equalDistribution
按需修改
autoScaler	如果设置自动扩容时使用，接下来详细介绍	默认null	按需修改

接下来首先介绍selectStrategy的几种类型：

equalDistribution：当任务开始运行时，任务会分配到有最多空闲slot的middle manager。如果想平均分布task，可以使用这个策略。
equalDistributionWithCategorySpec：是equalDistribution的变种。支持workerCategorySpec而不是affinityConfig（workerCategorySpec、affinityConfig下面将具体介绍）。通过指定workerCategorySpec，能基于任务类型和数据源将任务分配到不同目录的middle manager上。这个策略不能使用自动扩容。
fillCapacity：当任务开始运行时，任务会分配到现在运行任务最多的worker。当自动扩容时使用这个是有用的，因为你可以把任务尽量放在一些worker上直到放满，保持其他worker空闲能被终止。注意如果druid.indexer.runner.pendingTasksRunnerNumThreads的值N大于1，则这个策略会同时填充N个middle manager。
fillCapacityWithCategorySpec：是fillCapacity的变体。支持workerCategorySpec而不是affinityConfig。同equalDistributionWithCategorySpec。
javascript：使用JavaScript函数自定义分配逻辑。

接下来介绍affinityConfig：
以下是一个例子，表示datasource1优先分配到host1:port表示的middle manager和host2:port表示的middle manager，datasource2优先分配到host3:port表示的middle manager：

"affinityConfig": {
      "affinity": {
        "datasource1": ["host1:port", "host2:port"],
        "datasource2": ["host3:port"]
      }
}

属性	含义	备注	是否需要修改
affinity	一个JSON对象，映射数据源名字到一个middle manager的列表（middle manager用host:port的形式表示）	默认{}	按需配置
strong	布尔值，表示是否强制分配指定middle manager，即使指定middle manager不能运行全部pending任务	默认false	按需配置，一般不修改

接下来介绍WorkerCategorySpec：
以下是一个例子，表示对于index_kafka类型的任务，如果数据源是ds1，则分配到c2目录里的middle manager，如果数据源不是ds1，则按照默认目录分配到c1目录：

"workerCategorySpec": {
      "strong": false,
      "categoryMap": {
        "index_kafka": {
           "defaultCategory": "c1",
           "categoryAffinity": {
              "ds1": "c2"
           }
        }
      }
 }

属性	含义	备注	是否需要修改
categoryMap	映射任务类型到CategoryConfig对象（CategoryConfig下面详细介绍），你能为不同的类型指定CategoryConfig	默认{}	按需配置
strong	是否强制按照CategoryConfig分配middle manager	默认false	按需配置，一般不修改

CategoryConfig介绍：

属性	含义	备注	是否需要修改
defaultCategory	默认目录，如果一个数据源没有指定目录就会运行在默认目录	默认null	需要设置
categoryAffinity	JSON对象，映射数据源到middle manager的目录	默认null	按需设置

Autoscaler介绍：

属性	含义	备注	是否需要修改
minNumWorkers	集群中某一时间最小的worker数量	默认0	按需修改
maxNumWorkers	集群中某一时间最大的worker数量	默认0	按需修改
availabilityZone	要在哪个可用区中运行	默认none	按需设置
nodeData	一个描述如何启动新节点的JSON对象	默认none	按需设置
userData	一个描述如何配置新节点的JSON对象。如果设置了druid.indexer.autoscale.workerVersion，则必须具有versionReplacementString	默认none	按需设置

OLAP分析引擎Druid配置文件详解（四）：Overlord配置文件

Overlord Process Configs

Overlord Operations

Supervisors

Overlord Dynamic Configuration

相关阅读

相关文章

相关问答

相关文档