【翻译自https://druid.apache.org/docs/latest/operations/basic-cluster-tuning.html】

Broker

Heap sizing（堆大小调整）

Broker上的堆主要使用集中在：

来自历史节点以及Tasks（一般值peons）未合并的查询

segment时间线：包括当前所有可用的segments的位置信息（哪个历史节点或者task正在提供segment查询服务）

缓存segment元数据：包括当前所有可用的segments元数据（如每个segment的schema信息）

Broker堆基于集群中segment的数量以及segments的总数据大小进行扩展。

堆大小将基于数据大小和使用模式有所不同，但4G到8G是中小集群（大约15台服务器或者更小）的良好起点。

对内存需求粗略估计，节点数约为100个节点的超大集群需要broker堆的大小为30G~60G

如果使Broker中的缓存生效，缓存存储在堆中，大小由 druid.cache.sizeInBytes 设置。

在Broker中，所需的直接内存数量取决于配置了多少合并缓冲区（用于合并GroupBy）。Broker通常不需要处理线程或处理缓冲区，因为查询结果是在http连接线程的堆上合并的。

druid.processing.buffer.sizeBytes：可以设置为500M

druid.processing.numThreads：设置为 1 （所允许的最小值）

druid.processing.numMergeBuffers：与历史节点设置为相同的值或者略高一点

Broker 不需要处理线程和处理缓冲区有一个例外：

如果在 query context 设置了已弃用的 chunkPeriod 属性，GroupBy V1 查询将会使用处理线程和处理缓冲区。

chunkPeriod 和 GroupBy V1（代替用GroupBy V2）目前已被弃用，将来将会被移除，不推荐再使用。chunkPeriod特性的存在也解释了为什么要配置处理线程最小为1，尽管未被使用。

需要确保所有Brokers中 druid.broker.http.numConnections 的总和略低于历史节点和Tasks中设置的 druid.server.http.numThreads值。

在同一个Broker节点，druid.server.http.numThreads 应该略高于 druid.broker.http.numConnections。

使得每个历史节点可以接受50个查询和10个非查询，进而相应的调整Broker是一个合理的集群调优的开端。

当从历史节点和Tasks提取查询结果时，Broker能够选择性的指定队列以及未读数据的最大缓冲区大小，并且在达到上限时，对历史节点和Tasks的通道施加反压力（导致在历史节点/Task端阻塞对通道的写入，直到Broker能够从通道中消耗一些数据）

缓冲区大小通过 druid.broker.http.maxQueueBytes来设置

这个大小限制被查询命中的历史节点/Tasks的数量分摊：假如设置 druid.broker.http.maxQueuedBytes 为5MB，Broke收到一个查询，该查询需要分摊到2个历史节点，每个历史节点通道将得到2.5MB的缓冲区。

通常将该值设置为 2MB * number of Historicals。

当集群规模随着历史节点和Tasks增多而扩展时，需要相应的增加缓冲区大小和Broker堆大小。

如果缓冲区太小，会因为缓冲区快速填满并拖住通道而使得查询效率低下

如果缓冲区太大，会因为http通道中有较多的排队结果数据而使得Broker有较大的内存压力

Broker 与历史节点的比率设置为1：15 是一个合理的开端。

如果需要Broker HA，需要先部署2个Broker，然后用1：15的比率来添加额外的Brokers

按照下面的指导估计Broker总的内存使用量：

Heap：分配的堆大小

Direct Memory：（druid.processing.numThreads + druid.processing.numMergeBuffers + 1） * druid.processing.buffer.sizeBytes

Druid调优指南（三）- MiddleManager