【翻译自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 设置。
Direct memory sizing(直接内存大小调整)
在Broker中，所需的直接内存数量取决于配置了多少合并缓冲区（用于合并GroupBy）。Broker通常不需要处理线程或处理缓冲区，因为查询结果是在http连接线程的堆上合并的。
druid.processing.buffer.sizeBytes： 可以设置为500M
druid.processing.numThreads：设置为 1 （所允许的最小值）
druid.processing.numMergeBuffers：与历史节点设置为相同的值 或者略高一点
Note on the deprecated chunkPeriod
Broker 不需要处理线程和处理缓冲区 有一个例外：
如果在 query context 设置了已弃用的 chunkPeriod 属性，GroupBy V1 查询将会使用处理线程和处理缓冲区。
chunkPeriod 和 GroupBy V1（代替用GroupBy V2）目前已被弃用，将来将会被移除，不推荐再使用。chunkPeriod特性的存在也解释了为什么要配置处理线程最小为1，尽管未被使用。
Connection pool sizing (连接池大小调整)
需要确保所有Brokers中 druid.broker.http.numConnections 的总和 略低于 历史节点和Tasks中设置的 druid.server.http.numThreads值。
在同一个Broker节点，druid.server.http.numThreads 应该略高于 druid.broker.http.numConnections。
使得每个历史节点可以接受50个查询和10个非查询，进而相应的调整Broker是一个合理的集群调优的开端。
Broker backpress（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有较大的内存压力
Number of brokers
Broker 与历史节点的比率设置为1：15 是一个合理的开端。
如果需要Broker HA，需要先部署2个Broker，然后用1：15的比率来添加额外的Brokers
Total memory usage
按照下面的指导估计Broker总的内存使用量：
Heap： 分配的堆大小
Direct Memory：（druid.processing.numThreads + druid.processing.numMergeBuffers + 1） * druid.processing.buffer.sizeBytes
网友评论