• 基于apache-druid-0.17

概述

• 本文是基于官網(wǎng)的一些建議進(jìn)行的

與進(jìn)程類相關(guān)的配置建議

Historical 進(jìn)程

Heap 大?。ǘ汛笮。?/h4>

• Historicals進(jìn)程中heap的主要貢獻(xiàn)為：
  • 來自Segment的部分未合并查詢結(jié)果；
  • 存儲(chǔ)Lookup的值；
• 調(diào)整Historicals進(jìn)程的heap大小的一般經(jīng)驗(yàn)法則是(0.5GB * CPU內(nèi)核的數(shù)量)，上限為~24GB。
• 這個(gè)經(jīng)驗(yàn)法則使用CPU內(nèi)核的數(shù)量作為硬件大小和并發(fā)級(jí)別的方便代理(注意:這個(gè)公式并不是確定歷史堆大小的硬性規(guī)則)。
• heap太大可能會(huì)導(dǎo)致GC收集暫停過長，為了避免這種情況，設(shè)置了~24GB上限。
• Historicals進(jìn)程如果允許緩存，緩存是存儲(chǔ)在heap上。大小有參數(shù)druid.cache.sizeInBytes決定。
• 在Historicals進(jìn)程上耗盡堆可能表明配置錯(cuò)誤或使用模式導(dǎo)致集群超載。

lookups功能

• 如果正在使用lookup功能，請(qǐng)計(jì)算正在加載的lookup映射的總大小。
• Druid在更新lookup映射時(shí)執(zhí)行原子交換(在交換期間舊映射和新映射都存在于堆中)，所以lookup映射的最大潛在堆使用量將是(2 *所有加載查找的總大小)。
• 除了(0.5GB * CPU核心數(shù)量)準(zhǔn)則外，請(qǐng)確保將(2 *所有加載查找的總大小)添加到堆大小中。

處理線程和緩沖區(qū)

• Historicals進(jìn)程中：
  • druid.processing.numThreads:通常應(yīng)設(shè)置為(內(nèi)核數(shù)量- 1):較小的值會(huì)導(dǎo)致CPU利用率不足，而超過內(nèi)核數(shù)量則會(huì)導(dǎo)致不必要的CPU爭用。
  • druid.processing.buffer.sizeBytes:可以設(shè)置為500M;
  • druid.processing.numMergeBuffers:對(duì)于一般使用來說，合并緩沖區(qū)與處理線程的比例為1:4是一個(gè)合理的選擇。

Direct Memory Sizing

• 上面描述的處理緩沖區(qū)和合并緩沖區(qū)是直接內(nèi)存緩沖區(qū)。
• 當(dāng)Historicals處理查詢時(shí)，它必須打開一組Segment以供讀取。這也需要一些直接的內(nèi)存空間，如segment decompression buffers.
• 估計(jì)直接內(nèi)存使用的公式如下:
• (druid.processing.numThreads + druid.processing.numMergeBuffers + 1) * druid.processing.buffer.sizeBytes
• +1因子是一個(gè)模糊的估計(jì)，用于解釋Segment解壓縮緩沖區(qū)。

Connection pool sizing

• 對(duì)于Historicals進(jìn)程，druid.server.http.numThreads的值應(yīng)該比集群中所有Broker的參數(shù)值druid.broker.http.numConnections的和要大一些。
• 優(yōu)化集群，使每個(gè)Historicals可以接受50個(gè)查詢和10個(gè)非查詢，這是一個(gè)合理的起點(diǎn)。

segment緩存大小

• druid.server.maxSize: Coordinator可以分配給Historicals的段數(shù)據(jù)的總大小。
• druid.segmentCache.locations：指定Segment數(shù)據(jù)可以存儲(chǔ)在Historicals中的位置。這些位置上可用磁盤空間的總和應(yīng)該相等druid.server.maxSize。
• Segment由Historicals使用任何可用的空閑系統(tǒng)內(nèi)存。
• 因此druid.server.maxSize應(yīng)該被指定，這樣就不會(huì)為Historicals分配過多的Segment數(shù)據(jù)。free system memory / druid.server.maxSize的值增加，更大比例的Segment可以保存在內(nèi)存中，從而實(shí)現(xiàn)更好的查詢性能。

Historicals的數(shù)量

• 集群中Historicals的數(shù)量取決于集群的數(shù)據(jù)量大小。為了獲得良好的性能，您需要足夠的Historicals，以便每個(gè)Historicals具有良好的(free system memory / druid.server.maxSize)比率，和上文segment緩存部分所講一樣。
• 只要您對(duì)用例有足夠的容錯(cuò)能力，使用少量的大型服務(wù)器通常比使用大量的小型服務(wù)器要好。

SSD存儲(chǔ)

• 我們建議使用Historicals節(jié)點(diǎn)使用SSD磁盤，因?yàn)樗鼈兲幚泶鎯?chǔ)在磁盤上的Segment數(shù)據(jù)。

總內(nèi)存使用

• 要估計(jì)在這些準(zhǔn)則下的Historicals總內(nèi)存使用量:
  • Heap: (0.5GB * number of CPU cores) + (2 * total size of lookup maps) + druid.cache.sizeInBytes
  • Direct Memory: (druid.processing.numThreads + druid.processing.numMergeBuffers + 1) * druid.processing.buffer.sizeBytes
• Historicals將使用任何可用的空閑系統(tǒng)內(nèi)存(即Historicals中JVM和堆/直接內(nèi)存緩沖區(qū)或系統(tǒng)上的其他進(jìn)程沒有使用的內(nèi)存)，用于磁盤上Segment的內(nèi)存映射。為了獲得更好的查詢性能，您需要確保一個(gè)良好的(free system memory / druid.server.maxSize)比率，以便在內(nèi)存中保留更大比例的Segment數(shù)據(jù)。

segment大小問題

• 請(qǐng)務(wù)必檢查segment size optimization
  ，以幫助優(yōu)化Historicals獲得最大的性能。

Broker

heap大小

• Broker中heap的最大貢獻(xiàn)是：
  • 來自Historicals和Task的部分未合并查詢結(jié)果；
  • Segment時(shí)間軸:這包括當(dāng)前所有可用Segment的位置信息(which Historical/Task is serving a segment)。
  • 緩存的Segment元數(shù)據(jù):這包括當(dāng)前所有可用Segment的元數(shù)據(jù)，例如每個(gè)Segment的schema。
  • Broker 的heap 需求根據(jù)集群中的Segment數(shù)量和Segment的總數(shù)據(jù)大小進(jìn)行伸縮。
• 堆大小將根據(jù)數(shù)據(jù)大小和使用模式而變化，但是4G到8G對(duì)于小型或中型集群(~15個(gè)或更少的服務(wù)器)是一個(gè)很好的起點(diǎn)。對(duì)于高端內(nèi)存需求的粗略估計(jì)，大約有100個(gè)節(jié)點(diǎn)的非常大的集群可能需要30GB-60GB的Beoker heap大小。
• 如果在代理上啟用了緩存，那么緩存將存儲(chǔ)在堆上，大小由druid.cache.sizeInBytes決定。

Direct memory sizing

• Broker需要多少直接內(nèi)存取決于配置了多少合并緩沖區(qū)(用于合并GroupBys)。Broker通常不需要處理線程或處理緩沖區(qū)，因?yàn)椴樵兘Y(jié)果是在HTTP連接線程的堆上合并的。
  • druid.processing.buffer.sizeBytes可以設(shè)置為500M；
  • druid.processing.numThreads設(shè)置為1，（允許最小值）。
  • druid.processing.numMergeBuffers：將該值設(shè)置為與Historicals值相同或稍高。
• 有一個(gè)例外，Broker不需要處理線程和處理緩沖區(qū):
  • 如果在查詢上下文中設(shè)置了已廢棄的chunkPeriod屬性，則GroupBy V1查詢將在Broker上使用處理線程和處理緩沖區(qū)。

連接池大小

• General Connection Pool Guidelines
• Broker中，請(qǐng)確保所有節(jié)點(diǎn)的druid.broker.http.numConnections的和要低于Historicals and Tasks的druid.server.http.numThreads。
• Broker中druid.server.http.numThreads的值要略高于druid.broker.http.numConnections。
• 優(yōu)化集群，使每個(gè)歷史記錄可以接受50個(gè)查詢和10個(gè)非查詢，并相應(yīng)地調(diào)整Broker，這是一個(gè)合理的起點(diǎn)。

Broker 背壓

• 當(dāng)檢索查詢結(jié)果從Historical or Tasks,Broker可以選擇指定最大緩沖區(qū)大小排隊(duì),未讀數(shù)據(jù)和施加反壓力的通道達(dá)到Historical or Tasks時(shí)限制。
• 緩沖大小由druid.broker.http.maxQueuedBytes參數(shù)配置。
• 這個(gè)限制是根據(jù)查詢所命中的Historical or Tasks的數(shù)量來劃分的:假設(shè)我有一個(gè)druid.broker.http.maxQueuedBytes設(shè)置為5MB，Broker接收一個(gè)需要擴(kuò)展為兩個(gè)Historical的查詢。在本例中，每個(gè)Historical將獲得2.5MB的緩沖區(qū)。
• 您通常可以將這個(gè)值設(shè)置為大約2MB *Historical數(shù)量。當(dāng)您的集群使用更多的Historical和Task進(jìn)行擴(kuò)展時(shí)，請(qǐng)考慮增加緩沖區(qū)大小并相應(yīng)地增加Broker heap。
  • 如果緩沖區(qū)太小，這可能會(huì)導(dǎo)致效率低下的查詢，因?yàn)榫彌_區(qū)很快就會(huì)填滿并使通道陷入停頓
  • 如果緩沖區(qū)太大，這將給代理帶來更多的內(nèi)存壓力，因?yàn)镠TTP通道中有更多的結(jié)果數(shù)據(jù)在排隊(duì)。

brokers的數(shù)量

• A 1:15 ratio of Brokers to Historicals is a reasonable starting point (this is not a hard rule).
• If you need Broker HA, you can deploy 2 initially and then use the 1:15 ratio guideline for additional Brokers.

總內(nèi)存使用

• 要根據(jù)這些準(zhǔn)則估計(jì)Broker的總內(nèi)存使用量:
  • Heap: allocated heap size
  • Direct Memory: (druid.processing.numThreads + druid.processing.numMergeBuffers + 1) * druid.processing.buffer.sizeBytes

MiddleManager

• MiddleManager是一個(gè)輕量級(jí)的任務(wù)控制器/管理器，它啟動(dòng)執(zhí)行數(shù)據(jù)抽取工作的任務(wù)進(jìn)程。

MiddleManager堆大小

• MiddleManager本身不需要太多的資源，一般可以將堆設(shè)置為~128MB。

SSD存儲(chǔ)

• 建議MiddleManager角色節(jié)點(diǎn)采用SSD磁盤，因?yàn)镸iddleManager發(fā)起的任務(wù)處理存儲(chǔ)在磁盤上的Segment數(shù)據(jù)。

任務(wù)數(shù)量

• MiddleManager可以進(jìn)行的任務(wù)數(shù)量由參數(shù)druid.worker.capacity。
• 集群中需要的MiddleManager數(shù)量取決于您需要為用例運(yùn)行多少個(gè)并發(fā)攝取任務(wù)?？梢栽诮o定機(jī)器上啟動(dòng)的worker的數(shù)量取決于每個(gè)worker分配的資源大小和可用的系統(tǒng)資源。
• 您可以為集群分配更多的MiddleManager機(jī)器來增加任務(wù)容量。

Task配置文件

task heap大小

• A 1GB heap is usually enough for Tasks.

lookups功能

• 兩倍于 lookups的大小內(nèi)存。

Task processing threads and buffers

• 任務(wù)處理線程和緩沖區(qū)
• 對(duì)于任務(wù)，1個(gè)或2個(gè)處理線程通常就足夠了，因?yàn)槿蝿?wù)中可查詢的數(shù)據(jù)往往比Historical進(jìn)程少得多。
  • druid.indexer.fork.property.druid.processing.numThreads: set this to 1 or 2
  • druid.indexer.fork.property.druid.processing.numMergeBuffers: set this to 2
  • druid.indexer.fork.property.druid.processing.buffer.sizeBytes: can be set to 100MB

直接內(nèi)存大小

• 上面描述的處理緩沖區(qū)和合并緩沖區(qū)是直接內(nèi)存緩沖區(qū)。
• 當(dāng)一個(gè)任務(wù)處理一個(gè)查詢時(shí)，它必須打開一組Segment以供讀取。這也需要一些直接的內(nèi)存空間，如 segment decompression buffers所示。

連接池大小

• druid.server.http.numThreads的值大于集群中所有Broker的druid.broker.http.numConnections的和。