• 基于apache-druid-0.17.0
• Configuration和HTTP endpoints詳見官網(wǎng)；

概覽

• Druid中Coordinator進(jìn)程主要是負(fù)責(zé)Segment的管理和分配。更具體的說，Coordinator進(jìn)程和Historical進(jìn)程保持通信，根據(jù)Configuration信息加載或者刪除Segment。Coordinator進(jìn)程負(fù)責(zé)加載新的Segment、刪除過期的Segment、管理Segment的復(fù)制備份、Segment的負(fù)載均衡。
• Coordinator進(jìn)程會(huì)定期運(yùn)行，時(shí)間間隔是依據(jù)配置參數(shù)druid.coordinator.period（default：PT60S）。當(dāng)Coordinator進(jìn)程運(yùn)行時(shí)，在Coordinator進(jìn)程決定執(zhí)行某些動(dòng)作(actions)之前，會(huì)評估集群的當(dāng)前狀態(tài)。Coordinator進(jìn)程同 Broker 和Historical進(jìn)程一樣，會(huì)將當(dāng)前集群狀態(tài)信息維護(hù)到zookeeper集群中。Coordinator進(jìn)程將rules和可用的Segment的信息保存到數(shù)據(jù)庫中?？捎玫腟egment會(huì)存儲(chǔ)在Segment Table中，并列出集群中應(yīng)該加載的所有的Segment集合。rules信息存儲(chǔ)在Rule Table中，指導(dǎo)Coordinator進(jìn)程如何處理Segment。
• 在任何未分配的Segment 由Historical進(jìn)程提供服務(wù)之前，每個(gè)層的可用Historical進(jìn)程首先按照容量排序，容量最小的服務(wù)器擁有最高的優(yōu)先級。未分配的Segment總是分配給容量最小的Historical進(jìn)程，以保持Historical進(jìn)程之間的平衡。Coordinator進(jìn)程在為Historical進(jìn)程分配新的Segment時(shí)不直接與它通信;相反，Coordinator進(jìn)程在Historical進(jìn)程的負(fù)載隊(duì)列路徑下創(chuàng)建一些關(guān)于新的Segment臨時(shí)信息。當(dāng) Historical看到這個(gè)請求，就會(huì)立即加載這個(gè)Segment，并開始為這個(gè)Segment提供服務(wù)。

Coordinator啟動(dòng)命令

org.apache.druid.cli.Main server coordinator

Rules (Segment相關(guān)規(guī)則)

• Coordinator可以根據(jù)一組規(guī)則從集群中自動(dòng)加載和刪除Segment。
• 詳見 ： Retaining or automatically dropping data
  

清理Segment

• 每次運(yùn)行時(shí)，Coordinator進(jìn)程都會(huì)比較數(shù)據(jù)庫中可用的Segment列表和集群中當(dāng)前的Segment列表。不在數(shù)據(jù)庫中但仍在集群中提供服務(wù)的Segment將被標(biāo)記并附加到刪除列表中。被覆蓋的Segments(它們的版本太舊，它們的數(shù)據(jù)被更新的Segment取代l)也被刪除。

Segment可用性

• 如果一個(gè)Historical進(jìn)程重新啟動(dòng)或者因?yàn)槿魏卧蜃兊貌豢捎脮r(shí)，Coordinator將會(huì)注意到這個(gè)Historical進(jìn)程已經(jīng)丟失，并將這個(gè)Historical進(jìn)程服務(wù)的所有Segments視為被丟棄。如果有足夠的時(shí)間，Coordinator可以將Segments重新分配給集群中的其他Historical進(jìn)程。但是，被刪除的每個(gè)Segment不會(huì)立即被Coordinator丟棄。取而代之的是一個(gè)過渡性的數(shù)據(jù)結(jié)構(gòu)，這個(gè)數(shù)據(jù)結(jié)構(gòu)存儲(chǔ)所有帶著生存期(lifetime)的已經(jīng)刪除的Segment。(生存期為Coordinator不會(huì)分配已經(jīng)刪除的Segment的時(shí)間)。因此，如果Historical進(jìn)程在短時(shí)間內(nèi)變得不可用并再次可用時(shí)，則Historical進(jìn)程將啟動(dòng)并從其緩存保存的Segment，而不會(huì)在集群中重新分配這些Segment。

Segment的負(fù)載均衡

• 為了確保集群中各個(gè)Historical進(jìn)程之間Segment的均勻分布，Coordinator進(jìn)程將在Coordinator每次運(yùn)行時(shí)查找每個(gè)Historical進(jìn)程所服務(wù)的所有Segment的總大小。對于集群中的每個(gè)Historical進(jìn)程，Coordinator進(jìn)程將判斷出利用率最高的Historical和利用率最低的Historical進(jìn)程。Coordinator計(jì)算兩個(gè)Historical進(jìn)程之間的利用率差異百分比，如果結(jié)果超過某個(gè)閾值，Coordinator則將一些段從利用率最高的Historical進(jìn)程移動(dòng)到利用率最低的Historical進(jìn)程（閾值為可配置項(xiàng)）。要移動(dòng)的Segment是隨機(jī)選擇的，只有當(dāng)Coordinator計(jì)算出的利用率最高和最低服務(wù)器之間的百分比差異已經(jīng)減小時(shí)才會(huì)移動(dòng)。

壓縮Segment

• 每次運(yùn)行時(shí)，Coordinator通過合并小的Segment或者切割大的Segment來壓縮片段。當(dāng)您的segment沒有做相應(yīng)的優(yōu)化時(shí)，這些時(shí)非常有用的。詳見segment-optimization。
• Coordinator首先根據(jù)Segment搜索策略(Segment search policy)找到要壓縮的Segment。一旦找到這些Segment，Coordinator就發(fā)出一個(gè)壓縮任務(wù)來壓縮這些Segments。壓縮任務(wù)同時(shí)運(yùn)行的數(shù)量為(sum of worker capacity * slotRatio, maxSlots)。請注意，即使(sum of worker capacity * slotRatio, maxSlots)= 0，如果數(shù)據(jù)源啟用了壓縮，也始終會(huì)提交至少一個(gè)壓縮任務(wù)。詳情見官網(wǎng)：compaction-configuration和compaction-dynamic-configuration
• 壓縮任務(wù)存在失敗原因如下：
  • 如果壓縮任務(wù)的輸入Segment在啟動(dòng)之前被刪除或覆蓋，則該壓縮任務(wù)將立即失敗。
  • 如果一個(gè)高優(yōu)先級的任務(wù)獲得一個(gè)時(shí)間塊鎖(time chunk lock
    )，該時(shí)間塊鎖的時(shí)間間隔與一個(gè)壓縮任務(wù)的時(shí)間間隔重疊，則壓縮任務(wù)失敗。
• 一旦壓縮任務(wù)失敗，Coordinator只需再次檢查失敗任務(wù)間隔中的Segments，并在下一次運(yùn)行時(shí)發(fā)出另一個(gè)壓縮任務(wù)。

Segment搜索策略

近期Segment優(yōu)先策略

• 在Coordinator每次運(yùn)行時(shí)，該策略都會(huì)按時(shí)間塊的由早到晚的順序查找時(shí)間塊，并檢查這些時(shí)間塊中的段是否需要壓縮。如果滿足以下所有條件，則需要壓縮一組段。
  • 1-Total size of segments in the time chunk is smaller than or equal to the configured inputSegmentSizeBytes.
  • 2-Segments have never been compacted yet or compaction spec has been updated since the last compaction, especially maxRowsPerSegment, maxTotalRows, and indexSpec.
• 案例如下：假如我們有兩個(gè)數(shù)據(jù)源：dataSources (foo, bar)

• foo
  • foo_2017-11-01T00:00:00.000Z_2017-12-01T00:00:00.000Z_VERSION
  • foo_2017-11-01T00:00:00.000Z_2017-12-01T00:00:00.000Z_VERSION_1
  • foo_2017-09-01T00:00:00.000Z_2017-10-01T00:00:00.000Z_VERSION
• bar
  • bar_2017-10-01T00:00:00.000Z_2017-11-01T00:00:00.000Z_VERSION
  • bar_2017-10-01T00:00:00.000Z_2017-11-01T00:00:00.000Z_VERSION_1

• 假如每個(gè)Segment為10M且從未壓縮過。搜索策略會(huì)優(yōu)先返回兩個(gè)segment，foo_2017-11-01T00:00:00.000Z_2017-12-01T00:00:00.000Z_VERSION和foo_2017-11-01T00:00:00.000Z_2017-12-01T00:00:00.000Z_VERSION_1進(jìn)行壓縮。因?yàn)?code>2017-11-01T00:00:00.000Z/2017-12-01T00:00:00.000Z是最近的時(shí)間塊。
• 如果Coordinator有足夠的slots用于壓縮任務(wù)，搜索策略會(huì)繼續(xù)查找bar_2017-10-01T00:00:00.000Z_2017-11-01T00:00:00.000Z_VERSION和bar_2017-10-01T00:00:00.000Z_2017-11-01T00:00:00.000Z_VERSION_1。最后，foo_2017-09-01T00:00:00.000Z_2017-10-01T00:00:00.000Z_VERSION也會(huì)被執(zhí)行，盡管在時(shí)間塊2017-09-01T00:00:00.000Z/2017-10-01T00:00:00.000Z中只有一個(gè)Segment。
• 開始查找的時(shí)間點(diǎn)可以按照skipOffsetFromLatest進(jìn)行配置。此策略將忽略掉在時(shí)間段的Segment(最近的Segment的結(jié)束時(shí)間—skipOffsetFromLatest)。
  這是為了避免壓縮任務(wù)和實(shí)時(shí)任務(wù)之間的沖突。注意，在默認(rèn)情況下，實(shí)時(shí)任務(wù)的優(yōu)先級高于壓縮任務(wù)。如果壓縮任務(wù)的時(shí)間間隔重疊，Realtime任務(wù)將撤銷它們的鎖，從而導(dǎo)致壓縮任務(wù)終止。

FAQ

Client是否會(huì)永遠(yuǎn)與 Coordinator 進(jìn)程保持通信？

• 答：Coordinator不涉及query。
  • Historical進(jìn)程從不直接與Coordinator進(jìn)程通信。Coordinator告訴通過Zookeeper告訴Historical進(jìn)程加載/刪除數(shù)據(jù)，而且Historical進(jìn)程完全不知道Coordinator。
  • Broker也從不與Coordinator通信。Broker是根據(jù)Historical進(jìn)程寫入ZK的元數(shù)據(jù)來理解數(shù)據(jù)拓?fù)洌M(jìn)程完全不知道Coordinator。

Coordinator進(jìn)程在其他進(jìn)程之前或之后啟動(dòng)有關(guān)系（區(qū)別）嗎?

• 答：無區(qū)別。
• 如果Coordinator沒有啟動(dòng)，集群中不會(huì)加載新的segment，過期的Segment也不會(huì)被丟棄。但是，Coordinator進(jìn)程可以在任何時(shí)候啟動(dòng)，并且在可配置的延遲之后，將開始運(yùn)行Coordinator任務(wù)。
• 這也意味著，如果有一個(gè)正在工作的集群，并且所有Coordinator都已停止運(yùn)行，那么集群將繼續(xù)運(yùn)行，它只是不會(huì)感知到任何數(shù)據(jù)拓?fù)浣Y(jié)構(gòu)的更改。