• 基于apache-druid-0.17

概述

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

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

Historical 進程

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

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

lookups功能

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

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

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

Direct Memory Sizing

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

Connection pool sizing

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

segment緩存大小

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

Historicals的數(shù)量

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

SSD存儲

• 我們建議使用Historicals節(jié)點使用SSD磁盤，因為它們處理存儲在磁盤上的Segment數(shù)據(jù)。

總內(nèi)存使用

• 要估計在這些準則下的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)上的其他進程沒有使用的內(nèi)存)，用于磁盤上Segment的內(nèi)存映射。為了獲得更好的查詢性能，您需要確保一個良好的(free system memory / druid.server.maxSize)比率，以便在內(nèi)存中保留更大比例的Segment數(shù)據(jù)。

segment大小問題

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

Broker

heap大小

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

Direct memory sizing

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

連接池大小

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

Broker 背壓

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

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ù)這些準則估計Broker的總內(nèi)存使用量:
  • Heap: allocated heap size
  • Direct Memory: (druid.processing.numThreads + druid.processing.numMergeBuffers + 1) * druid.processing.buffer.sizeBytes

MiddleManager

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

MiddleManager堆大小

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

SSD存儲

• 建議MiddleManager角色節(jié)點采用SSD磁盤，因為MiddleManager發(fā)起的任務(wù)處理存儲在磁盤上的Segment數(shù)據(jù)。

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

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

Task配置文件

task heap大小

• A 1GB heap is usually enough for Tasks.

lookups功能

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

Task processing threads and buffers

• 任務(wù)處理線程和緩沖區(qū)
• 對于任務(wù)，1個或2個處理線程通常就足夠了，因為任務(wù)中可查詢的數(shù)據(jù)往往比Historical進程少得多。
  • 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ū)。
• 當一個任務(wù)處理一個查詢時，它必須打開一組Segment以供讀取。這也需要一些直接的內(nèi)存空間，如 segment decompression buffers所示。

連接池大小

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