一個(gè)用于實(shí)時(shí)分析的開源數(shù)據(jù)存儲

摘要

Druid是專用于基于大數(shù)據(jù)集的實(shí)時(shí)探索分析的開源數(shù)據(jù)存儲辑鲤。該系統(tǒng)包括列式存儲，分布式的無共享架構(gòu)弛随，高級索引結(jié)構(gòu)宁赤，可用于任意探索具有次秒級延遲的十億行級的數(shù)據(jù)表。這篇文章我們主要描述Druid的架構(gòu)愕够，并且詳細(xì)說明它如何支持快速聚合佛猛、靈活篩選以及低延遲數(shù)據(jù)的加載。

關(guān)鍵字

distributed; real-time; fault-tolerant; highly available; open source; analytics; column-oriented; OLAP

1. 引言

近年來强衡，互聯(lián)網(wǎng)技術(shù)的飛速發(fā)展引發(fā)了機(jī)器生成事件（machine-generated events）的快速增加。分開來看漩勤，這些事件包含的有用信息較少且價(jià)值不高缩搅。鑒于提取大量事件集合意義所需的時(shí)間和資源，許多公司寧愿放棄這些數(shù)據(jù)究飞。雖然基礎(chǔ)架構(gòu)已被構(gòu)建用于處理基于事件的數(shù)據(jù),但它們很大部分以高價(jià)位銷售堂鲤，并且只針對那些能夠負(fù)擔(dān)得起的公司。

幾年前葵擎，Google推出了MapReduce作為其利用商業(yè)硬件來進(jìn)行網(wǎng)絡(luò)索引和日志分析的機(jī)制半哟。不久之后Hadoop項(xiàng)目就遵循并在很大程度上效仿MapReduce原始文檔中的見解签餐。Hadoop目前用于存儲和分析大量的日志數(shù)據(jù)而存在于許多組織中氯檐。Handoop在幫助許多公司將低價(jià)值的事件流轉(zhuǎn)化為高價(jià)值的應(yīng)用程序貢獻(xiàn)良多体捏，例如商業(yè)智能和A-B testing。

與許多偉大的系統(tǒng)一樣译打，Hadoop開啟了我們對一個(gè)新的空間的問題拇颅。具體來說，Hadoop在存儲和提供對大量數(shù)據(jù)的訪問方面表現(xiàn)優(yōu)異韵洋，然而黄锤，它并沒有提供關(guān)于數(shù)據(jù)訪問速度的性能保證。 此外副编，盡管Hadoop是高可用性系統(tǒng)流强，但在高并發(fā)負(fù)載下性能下降。 最后打月，雖然Hadoop在存儲數(shù)據(jù)方面表現(xiàn)良好，但它并未針對提取數(shù)據(jù)和使數(shù)據(jù)立即可讀而進(jìn)行優(yōu)化柴淘。

在開發(fā)metamarkets產(chǎn)品的早期秘通，我們遇到了這些問題，并意識到Hadoop是一個(gè)很好的后臺后臺處理肺稀、批處理和數(shù)據(jù)倉庫系統(tǒng)。然而炸茧，作為一家在高并發(fā)環(huán)境( 1000個(gè)以上用戶)中，要求具有查詢性能和數(shù)據(jù)可用性的產(chǎn)品級保證的公司辕狰，Hadoop不能滿足我們的需求。我們探索了不同的解決方案蔓倍，在嘗試了關(guān)系型數(shù)據(jù)庫管理系統(tǒng)和 NoSQL架構(gòu)之后盐捷，我們得出的結(jié)論是，開放源世界中沒有可以用來充分滿足我們的需求的方法聚谁。我們最終創(chuàng)建了Druid滞诺，一個(gè)開放源，分布式朵耕，面向列編程的淋叶，實(shí)時(shí)分析數(shù)據(jù)存儲。在許多方面处嫌，Druid與其它OLAP系統(tǒng)形娇，交互式查詢系統(tǒng)，內(nèi)存數(shù)據(jù)庫以及廣為人知的分布式數(shù)據(jù)存儲在許多方面具有相似點(diǎn)癣缅。分布和查詢模型還借鑒了當(dāng)代搜索基礎(chǔ)架構(gòu)的見解哄酝。

本文介紹了Druid的架構(gòu)，探討了創(chuàng)建一個(gè)永遠(yuǎn)在線的生產(chǎn)系統(tǒng)屡立，為托管服務(wù)提供支持的各種設(shè)計(jì)決策搀军，并嘗試幫助任何面臨類似問題的人解決潛在的解決方法勇皇。 Druid已經(jīng)在幾家技術(shù)公司投產(chǎn)使用敛摘。本文的結(jié)構(gòu)如下：我們首先描述第2節(jié)中的問題。接下來兄淫，我們從第3節(jié)中數(shù)據(jù)如何流經(jīng)系統(tǒng)的角度詳細(xì)介紹系統(tǒng)架構(gòu)捕虽。然后討論如何以及為什么數(shù)據(jù)被轉(zhuǎn)換為第4節(jié)中的二進(jìn)制格式坡脐。我們在第5節(jié)簡要描述了查詢API，并在第6節(jié)介紹了性能結(jié)果挨措。最后崩溪，我們在第7節(jié)中關(guān)于運(yùn)行Druid的教訓(xùn)，以及第8節(jié)中的相關(guān)工作伶唯。

2. 問題定義

Druid最初旨在解決關(guān)于攝取和探索大量事務(wù)事件（日志數(shù)據(jù)）的問題。這種形式的時(shí)間序列數(shù)據(jù)通常在OLAP工作流中發(fā)現(xiàn)瞪讼，并且數(shù)據(jù)的性質(zhì)往往非常重粹断。

例如表1中的數(shù)據(jù)。表1給出了維基百科上發(fā)生的編輯數(shù)據(jù)希柿。每次用戶在維基百科中編輯頁面時(shí)养筒，都會(huì)生成包含有關(guān)編輯的元數(shù)據(jù)的事件。此元數(shù)據(jù)由3個(gè)不同的組件組成挤悉。 首先巫湘，有一個(gè)時(shí)間戳列指示編輯的時(shí)間装悲。 接下來昏鹃，存在指示關(guān)于編輯的各種屬性的設(shè)置維度列，例如編輯的頁面诀诊，進(jìn)行編輯的用戶和用戶的位置盆顾。 最后，有一組度量列包含可以聚合的值（通常為數(shù)字）畏梆，例如在編輯中添加或刪除的字符數(shù)您宪。

我們的目標(biāo)是快速計(jì)算這些數(shù)據(jù)的下鉆和聚合。我們想回答的問題奠涌，如“在舊金山的男性賈斯汀·比伯的頁面上做了多少修改溜畅？”和“在一個(gè)月的時(shí)間內(nèi)卡爾加里的人添加的字符的平均數(shù)是多少慈格？” 我們還希望任何任意維度組合的查詢返回是亞秒級延遲浴捆。

Druid出現(xiàn)的動(dòng)力冲粤，是因?yàn)楫?dāng)前開源的關(guān)系型數(shù)據(jù)庫RDBMS和NoSql的key/value存儲都不能為交互式應(yīng)用提供低延遲數(shù)據(jù)攝取和查詢平臺。在Metamarkets初期傀顾，我們專注于建立一個(gè)托管的儀表板短曾，允許用戶對事件流進(jìn)行任意的探索和可視化隆豹。為儀表板提供支持的數(shù)據(jù)存儲需要足夠快地返回查詢判哥，以便在其上構(gòu)建的數(shù)據(jù)可視化可以為用戶提供交互式體驗(yàn)。

除了查詢延遲需求之外挺身，系統(tǒng)必須是多租戶的并且高度可用章钾。 Metamarkets產(chǎn)品用于高度并發(fā)環(huán)境贱傀。停機(jī)時(shí)間是昂貴的府寒，并且如果在面對軟件升級或網(wǎng)絡(luò)故障時(shí)系統(tǒng)不可用株搔，許多企業(yè)不能等待纤房。而停機(jī)時(shí)間帆卓，對于經(jīng)常缺乏適當(dāng)內(nèi)部運(yùn)營管理的初創(chuàng)公司，可以直接決定業(yè)務(wù)成功或失敗糊啡。

最后棚蓄，Metamarkets早期面臨的另一個(gè)挑戰(zhàn)是允許用戶和警報(bào)系統(tǒng)能夠“實(shí)時(shí)”做出業(yè)務(wù)決策梭依。 從創(chuàng)建事件到該事件可查詢的時(shí)間決定了感興趣方能夠?qū)ζ湎到y(tǒng)中潛在的災(zāi)難性情況作出反應(yīng)的速度役拴。 流行的開源數(shù)據(jù)倉庫系統(tǒng)（如Hadoop）無法提供我們所需的次秒級數(shù)據(jù)提取延遲。

數(shù)據(jù)探索褥紫，攝取和可用性的問題跨越多個(gè)行業(yè)髓考。自從2012年10月Druid開源以來氨菇，它被部署為多個(gè)公司的視頻门驾，網(wǎng)絡(luò)監(jiān)控多柑，運(yùn)營監(jiān)控和在線廣告分析平臺竣灌。

3. 架構(gòu)

Druid集群由不同類型的節(jié)點(diǎn)組成初嘹，每個(gè)節(jié)點(diǎn)類型被設(shè)計(jì)為執(zhí)行一組特定的事情屯烦。 我們相信這種設(shè)計(jì)功能分離并簡化了整個(gè)系統(tǒng)的復(fù)雜性驻龟。不同的節(jié)點(diǎn)類型相互獨(dú)立地操作翁狐，并且使它們之間的交互最小化露懒。 因此，集群內(nèi)通信故障對數(shù)據(jù)可用性的影響也最小蛇耀。

為了解決復(fù)雜的數(shù)據(jù)分析問題纺涤，不同的節(jié)點(diǎn)類型匯聚在一起形成一個(gè)完全工作的系統(tǒng)。 Druid的名字來自許多角色扮演游戲中的角色德魯伊：它是一個(gè)能夠變身的人象迎，能夠采取許多不同的形式，以履行在一個(gè)組中的各種不同的角色。 Druid集群中的數(shù)據(jù)的組成和數(shù)據(jù)流向如圖1所示。

3.1 Real-time Node

實(shí)時(shí)節(jié)點(diǎn)封裝了事件流的攝取和查詢功能。通過這些節(jié)點(diǎn)索引的事件可立即用于查詢。節(jié)點(diǎn)僅關(guān)心一些小時(shí)間范圍的事件，并且周期性地將它們在這個(gè)小時(shí)間范圍上收集的不可變批量的事件移交給專門處理不可變事件批處理的Druid集群中的其他節(jié)點(diǎn)。實(shí)時(shí)節(jié)點(diǎn)利用Zookeeper與Druid群集的其余部分進(jìn)行協(xié)調(diào)嫡纠。節(jié)點(diǎn)向Zookeeper服務(wù)宣布他們的在線狀態(tài)和數(shù)據(jù)挫以。

實(shí)時(shí)節(jié)點(diǎn)為所有傳入事件維護(hù)一個(gè)內(nèi)存索引緩沖區(qū)。這些索引隨著事件被攝取而遞增地填充，并且索引也是可直接查詢的待榔。查詢存在于此基于JVM堆的緩沖區(qū)中的事件時(shí)绳瘟，Druid更像一個(gè)行式存儲。為了避免堆溢出問題蘸泻，實(shí)時(shí)節(jié)點(diǎn)會(huì)定期或在達(dá)到最大行限制后將其內(nèi)存索引保留到磁盤。這個(gè)持久進(jìn)程將存儲在內(nèi)存中緩沖區(qū)中的數(shù)據(jù)轉(zhuǎn)換為第4節(jié)中描述的面向列的存儲格式。每個(gè)持久化索引是不可變的，實(shí)時(shí)節(jié)點(diǎn)將持久索引加載到堆外存儲器中，以便仍然可以查詢它們蹋肮。該過程在[33]中詳細(xì)描述并且在圖2中示出。

在定期的基礎(chǔ)上，每個(gè)實(shí)時(shí)節(jié)點(diǎn)將調(diào)度一個(gè)后臺任務(wù)，來搜索所有本地持久化索引夷陋。任務(wù)將這些索引合并在一起肌稻，并構(gòu)建一個(gè)不可變的數(shù)據(jù)塊诺凡，其中包含實(shí)時(shí)節(jié)點(diǎn)在一段時(shí)間內(nèi)攝取的所有事件。我們將這個(gè)數(shù)據(jù)塊為“segment”凉袱。 在切換階段期間钉稍，實(shí)時(shí)節(jié)點(diǎn)將該segment上傳到永久備份存儲，通常是諸如S3 [12]或HDFS [36]的分布式文件系統(tǒng)嫩挤，Druid稱之為“深存儲”。ingest、persist、merge和handoff 步驟是流動(dòng)的茵汰，在任何過程中沒有數(shù)據(jù)丟失。

圖3展示了實(shí)時(shí)節(jié)點(diǎn)的操作奥洼。節(jié)點(diǎn)從13:37啟動(dòng)，并且只接受當(dāng)前小時(shí)或下一小時(shí)的事件。當(dāng)事件被攝取時(shí)，節(jié)點(diǎn)宣布它正在服務(wù)從13:00到14:00的間隔的數(shù)據(jù)段箫踩。每隔10分鐘（持續(xù)時(shí)間是可配置的）吱韭，節(jié)點(diǎn)將刷新并保持其內(nèi)存緩沖區(qū)到磁盤。接近小時(shí)結(jié)束時(shí)衷快，節(jié)點(diǎn)可能在14:00至15:00看到事件调窍。發(fā)生這種情況時(shí)，節(jié)點(diǎn)準(zhǔn)備為下一小時(shí)提供數(shù)據(jù)宝剖，并創(chuàng)建一個(gè)新的內(nèi)存索引雅镊。然后，該節(jié)點(diǎn)宣布它也在從14:00到15:00服務(wù)段。該節(jié)點(diǎn)不會(huì)立即合并13:00到14:00的持久化索引征唬，而是等待13:00到14:00期間事件的可配置的窗口到達(dá)。此窗口時(shí)間段使事件傳遞延遲導(dǎo)致的數(shù)據(jù)丟失風(fēng)險(xiǎn)最小化。在窗口期結(jié)束時(shí)，該節(jié)點(diǎn)將所有持續(xù)索引從13:00到14:00合并成單個(gè)不可變段，并將該段handoff 摩桶。一旦這個(gè)段在Druid集群中的其他地方被加載和查詢典格，實(shí)時(shí)節(jié)點(diǎn)將它收集的13:00到14:00的數(shù)據(jù)的所有信息清除，并且停止宣布它對這些數(shù)據(jù)的服務(wù)防嗡。

3.1.1 可用性和可擴(kuò)展性

實(shí)時(shí)節(jié)點(diǎn)是數(shù)據(jù)的消費(fèi)者蚁趁，并且需要相應(yīng)的生產(chǎn)者來提供數(shù)據(jù)流。通常，為了數(shù)據(jù)持久性的目的，會(huì)如圖4所示，在生產(chǎn)者和實(shí)時(shí)節(jié)點(diǎn)之間采用如kafka[21]的消息總線。實(shí)時(shí)節(jié)點(diǎn)通過從消息總線讀取事件來攝取數(shù)據(jù)。從事件創(chuàng)建到事件消費(fèi)的時(shí)間通常在幾百毫秒的量級譬挚。

圖4中的消息總線的目的是雙重的盐须。 首先，消息總線充當(dāng)傳入事件的緩沖區(qū)。 諸如Kafka的消息總線保持指示消費(fèi)者（實(shí)時(shí)節(jié)點(diǎn)）在事件流中讀取了多遠(yuǎn)的位置偏移（offset）。 消費(fèi)者可以以編程方式更新這些偏移量。 實(shí)時(shí)節(jié)點(diǎn)每次將它們的內(nèi)存緩沖區(qū)持久保存到磁盤時(shí)都會(huì)更新此偏移量烹吵。在故障恢復(fù)方案中锈津，如果節(jié)點(diǎn)上磁盤沒有損壞一姿，它可以從磁盤重新加載所有持久索引，并從其提交的最后一個(gè)偏移繼續(xù)讀取事件先较。從最近提交的偏移中獲取事件大大減少了節(jié)點(diǎn)的恢復(fù)時(shí)間。在實(shí)踐中，我們看到節(jié)點(diǎn)在幾秒鐘內(nèi)從這種故障情況中恢復(fù)。

消息總線的第二個(gè)目的是充當(dāng)單個(gè)端點(diǎn)（endpoint）磁奖，使多個(gè)實(shí)時(shí)節(jié)點(diǎn)可以從該端點(diǎn)讀取事件抄囚。多個(gè)實(shí)時(shí)節(jié)點(diǎn)可以從總線獲取相同的一組事件，從而創(chuàng)建事件的復(fù)制谬哀。在節(jié)點(diǎn)完全失敗并磁盤數(shù)據(jù)丟失的情況下，復(fù)制流確保沒有數(shù)據(jù)丟失。單一數(shù)據(jù)攝取端點(diǎn)還允許對數(shù)據(jù)流進(jìn)行分割官脓，使得多個(gè)實(shí)時(shí)節(jié)點(diǎn)各自攝取流的一部分。這允許無縫地添加附加的實(shí)時(shí)節(jié)點(diǎn)赤兴。在實(shí)踐中，這種模型允許超大型生產(chǎn)Druid集群能夠以大約500 MB/s（150,000個(gè)事件/秒或2TB/小時(shí)）的速度消耗原始數(shù)據(jù)疲牵。

3.2 Historical Nodes

歷史節(jié)點(diǎn)封裝了用于加載和服務(wù)由實(shí)時(shí)節(jié)點(diǎn)創(chuàng)建的不可變的數(shù)據(jù)塊（segments）的功能。 在許多現(xiàn)實(shí)的工作流中姜挺，在Druid集群中加載的大多數(shù)數(shù)據(jù)是不可變的，因此慧妄，歷史節(jié)點(diǎn)通常是Druid集群的主要工作者罪裹。 歷史節(jié)點(diǎn)遵循無共享架構(gòu)，并且在節(jié)點(diǎn)之間沒有單點(diǎn)競爭裤翩。節(jié)點(diǎn)不具有知識共享并且在操作簡單，它們只知道如何加載变擒，刪除和服務(wù)不可變段。

與實(shí)時(shí)節(jié)點(diǎn)類似材部，歷史節(jié)點(diǎn)向Zookeeper告知其在線狀態(tài)及提供的數(shù)據(jù)苦丁。加載和刪除段的指令也通過Zookeeper發(fā)送物臂，并包含關(guān)于段在深存儲中的位置以及如何解壓縮和處理段的信息棵磷。在歷史節(jié)點(diǎn)從深存儲下載特定段之前仪媒，首先檢查本地緩存算吩，該緩存維護(hù)關(guān)于節(jié)點(diǎn)上已存在的段的信息赌莺。如果關(guān)于段的信息不存在于高速緩存中，則歷史節(jié)點(diǎn)將繼續(xù)從深存儲下載段挎扰。此過程如圖5所示。一旦處理完成尽超，段會(huì)在Zookeeper中通知，此時(shí)巩踏，該段是可查詢的续搀。本地高速緩存還允許歷史節(jié)點(diǎn)快速更新和重新啟動(dòng)彪杉。在啟動(dòng)時(shí)牵咙，節(jié)點(diǎn)檢查其緩存渴丸，并立即提供它所定義的任何數(shù)據(jù)曙强。

歷史節(jié)點(diǎn)可以支持讀一致性，因?yàn)樗鼈冎惶幚聿豢勺兊臄?shù)據(jù)囊卜。不變數(shù)據(jù)塊還支持簡單的并行化模型：歷史節(jié)點(diǎn)可以同時(shí)進(jìn)行掃描和聚合不可變塊而不用阻塞。

3.2.1 層

歷史節(jié)點(diǎn)可以分組在不同的層中玉掸，其中給定層中的所有節(jié)點(diǎn)被相同地配置司浪。 可以為每個(gè)層設(shè)置不同的性能和容錯(cuò)參數(shù)。分層節(jié)點(diǎn)的目的是使得更高或更低優(yōu)先級的段能夠根據(jù)它們的重要性來分布吁伺。例如篮奄，可以旋轉(zhuǎn)（spin up）具有大量核和大存儲容量的歷史節(jié)點(diǎn)的“熱”層窟却】浜眨“熱”集群可以配置為下載更頻繁訪問的數(shù)據(jù)憔足。 也可以使用不太強(qiáng)大的硬件資源來創(chuàng)建并行“冷”集群滓彰〗野螅“冷”集群將僅包含較不頻繁訪問的段他匪。

3.2.2 可用性

歷史節(jié)點(diǎn)依賴于Zookeeper的段加載和卸載指令邦蜜。 如果Zookeeper變得不可用亥至，則歷史節(jié)點(diǎn)不再能夠服務(wù)新數(shù)據(jù)或丟棄過時(shí)的數(shù)據(jù)悼沈，然而，因?yàn)椴樵兪峭ㄟ^HTTP提供的姐扮，歷史節(jié)點(diǎn)仍然能夠響應(yīng)他們當(dāng)前服務(wù)的數(shù)據(jù)的查詢請求絮供。 這意味著Zookeeper中斷不會(huì)影響歷史節(jié)點(diǎn)上的當(dāng)前數(shù)據(jù)可用性

3.3 Broker Nodes

Broker節(jié)點(diǎn)充當(dāng)歷史節(jié)點(diǎn)和實(shí)時(shí)節(jié)點(diǎn)的查詢路由器。Broker節(jié)點(diǎn)能夠理解Zookeeper中發(fā)布的元數(shù)據(jù)茶敏，知道哪些段可以查詢以及這些段所在位置的壤靶。Broker節(jié)點(diǎn)路由進(jìn)入的查詢，使得查詢能夠命中正確的歷史或?qū)崟r(shí)節(jié)點(diǎn)惊搏。Broker節(jié)點(diǎn)還合并歷史和實(shí)時(shí)節(jié)點(diǎn)的部分結(jié)果贮乳，然后將最終合并結(jié)果返回給調(diào)用者包雀。

3.3.1 緩存

Broker節(jié)點(diǎn)包含具有LRU（最近最少使用）無效策略的高速緩存赞草。緩存可以使用本地堆內(nèi)存或外部分布式key/value存儲疑务，如Memcached温鸽。每次Broker節(jié)點(diǎn)接收到查詢時(shí)，它首先將查詢映射到一組segments榆芦。某些段的結(jié)果可能已經(jīng)存在于緩存中犬绒，并且不需要重新計(jì)算它們咐鹤。對于緩存中不存在的任何結(jié)果捧请，代理節(jié)點(diǎn)將將查詢轉(zhuǎn)發(fā)到正確的歷史和實(shí)時(shí)節(jié)點(diǎn)可款。一旦歷史節(jié)點(diǎn)返回其結(jié)果，Broker節(jié)點(diǎn)將基于每個(gè)段來緩存這些結(jié)果以供將來使用。該過程如圖6所示谜慌。實(shí)時(shí)數(shù)據(jù)從不被緩存妨蛹，因此對實(shí)時(shí)數(shù)據(jù)的請求將總是被轉(zhuǎn)發(fā)到實(shí)時(shí)節(jié)點(diǎn)神年。實(shí)時(shí)數(shù)據(jù)永遠(yuǎn)改變，緩存結(jié)果是不可靠的。
緩存還充當(dāng)附加級別的數(shù)據(jù)持久化。在所有歷史節(jié)點(diǎn)失敗的情況下松靡，如果這些結(jié)果已經(jīng)存在于高速緩存中啦逆，則仍然可以查詢結(jié)果沟蔑。

3.3.2 可用性

如果和Zookeeper通信中斷，數(shù)據(jù)仍然是可查詢的抢蚀。如果broker 節(jié)點(diǎn)無法與Zookeeper通信劫樟，他們使用他們的最后一個(gè)已知的集群視圖拒课，繼續(xù)轉(zhuǎn)發(fā)查詢到實(shí)時(shí)和歷史節(jié)點(diǎn)。broker節(jié)點(diǎn)假定集群的結(jié)構(gòu)與中斷之前的結(jié)構(gòu)相同。 實(shí)際上关带，這種可用性模型允許我們的Druid集群在我們診斷為Zookeeper中斷時(shí)繼續(xù)服務(wù)查詢一段相當(dāng)長的時(shí)間。

3.4 Coordinator Nodes

Druid coordinator 節(jié)點(diǎn)主要負(fù)責(zé)歷史節(jié)點(diǎn)上的數(shù)據(jù)管理和分發(fā)厕诡。coordinator 節(jié)點(diǎn)告訴歷史節(jié)點(diǎn)加載新數(shù)據(jù)虱岂，刪除過期數(shù)據(jù)燎窘，復(fù)制數(shù)據(jù)，并將數(shù)據(jù)移動(dòng)到負(fù)載平衡。Druid使用多版本并發(fā)控制交換協(xié)議來管理不可變段，以保持穩(wěn)定的視圖杠河。如果任何不可變段包含完全由較新段覆蓋的數(shù)據(jù)，則過時(shí)段將從集群中刪除立由。coordinator節(jié)點(diǎn)需要經(jīng)歷leader選擇過程弛房，來確定運(yùn)行協(xié)調(diào)器功能的單個(gè)節(jié)點(diǎn)為主种远，剩余的協(xié)調(diào)器節(jié)點(diǎn)充當(dāng)冗余備份。

coordinator節(jié)點(diǎn)周期性地運(yùn)行以確定集群的當(dāng)前狀態(tài)懊亡。它通過將群集的預(yù)期狀態(tài)與群集在運(yùn)行時(shí)的實(shí)際狀態(tài)進(jìn)行比較來做出決策。與所有Druid節(jié)點(diǎn)一樣匠襟，coordinator節(jié)點(diǎn)通過Zookeeper連接來維護(hù)當(dāng)前集群信息钝侠。coordinator節(jié)點(diǎn)還維護(hù)與包含其他操作參數(shù)和配置的MySQL數(shù)據(jù)庫的連接该园。MySQL中的關(guān)鍵信息之一是包含了歷史節(jié)點(diǎn)提供的所有段的列表的表。此表可以由創(chuàng)建段的任何服務(wù)（例如帅韧，實(shí)時(shí)節(jié)點(diǎn)）更新里初。MySQL數(shù)據(jù)庫還包含一個(gè)規(guī)則表，用于管理在集群中的segments如何創(chuàng)建忽舟，銷毀和復(fù)制双妨。

3.4.1 規(guī)則

規(guī)則決定了如何從集群加載和刪除歷史段。規(guī)則指示應(yīng)如何將段分配給不同的歷史節(jié)點(diǎn)層叮阅，以及在每個(gè)層中應(yīng)存在段的多少個(gè)復(fù)制刁品。規(guī)則還可以決定何時(shí)應(yīng)該完全從群集中刪除段。規(guī)則通常設(shè)置為一段時(shí)間浩姥。 例如哑诊，用戶可以使用規(guī)則將最近一個(gè)月的段加載到“熱”集群中，將最近一年的段加載到“冷”集群中及刻，并且刪除比較老的段。

coordinator 節(jié)點(diǎn)從MySQL的規(guī)則表中裝入一組規(guī)則竞阐。規(guī)則可以針對數(shù)據(jù)源進(jìn)行特定的配置缴饭，和/或可以配置默認(rèn)規(guī)則集。coordinator 節(jié)點(diǎn)將循環(huán)遍歷所有可用的段骆莹，并將每個(gè)段與適用于它的第一個(gè)規(guī)則匹配颗搂。

3.4.2 負(fù)載均衡

在典型的生產(chǎn)環(huán)境中，查詢經(jīng)常碰到幾十個(gè)甚至幾百個(gè)段幕垦。由于每個(gè)歷史節(jié)點(diǎn)具有有限的資源丢氢，因此coordinator必須在分布在群集各節(jié)點(diǎn)之間，以確保群集負(fù)載不會(huì)太不平衡先改。確定最佳負(fù)載分布需要一些關(guān)于查詢模式和速度的知識疚察。通常，查詢會(huì)覆蓋單個(gè)數(shù)據(jù)源的連續(xù)時(shí)間間隔的最近的segments仇奶。平均來說貌嫡，訪問較小段的查詢速度更快。

這些查詢模式建議高速率的復(fù)制最近的歷史段该溯，擴(kuò)展不同歷史節(jié)點(diǎn)上時(shí)間上接近大的segments岛抄，以及共同定位不同數(shù)據(jù)源的段。為了在群集中最優(yōu)地分布和平衡segments狈茉，我們開發(fā)了一個(gè)基于成本的優(yōu)化過程夫椭，其考慮了segment的數(shù)據(jù)源、新近度和大小氯庆。算法的確切細(xì)節(jié)已經(jīng)超出了本文的范圍蹭秋，可能在未來的文獻(xiàn)中會(huì)進(jìn)行討論扰付。

3.4.3 復(fù)制

coordinator節(jié)點(diǎn)可以告訴不同的歷史節(jié)點(diǎn)加載相同segment的副本。歷史節(jié)點(diǎn)集群的每個(gè)層中的副本數(shù)是完全可配置的感凤。需要高級別容錯(cuò)的設(shè)置可以配置為具有大量的副本悯周。segment副本的處理方式與原件相同，并遵循相同的負(fù)載分布算法陪竿。通過復(fù)制segment禽翼，單個(gè)歷史節(jié)點(diǎn)故障在Druid集群中是透明的。我們使用此屬性進(jìn)行軟件升級族跛。我們可以無縫地使歷史節(jié)點(diǎn)下線闰挡，更新它，將其備份礁哄，并對集群中的每個(gè)歷史節(jié)點(diǎn)重復(fù)該過程长酗。在過去兩年中疏叨，我們從未在我們的Druid集群中進(jìn)行軟件升級的停機(jī)做院。

3.4.4 可用性

Druid協(xié)調(diào)器節(jié)點(diǎn)有Zookeeper和MySQL作為外部依賴。coordinator 節(jié)點(diǎn)依靠Zookeeper來確定集群中已經(jīng)存在哪些歷史節(jié)點(diǎn)吊奢。如果Zookeeper不可用茉继，coordinator將不再能夠發(fā)送指令來分配咧叭，平衡和丟棄segments。但是烁竭，這些操作不會(huì)影響數(shù)據(jù)可用性菲茬。
集群中存在哪些段的segment元數(shù)據(jù)信息，還是哪些段應(yīng)該存在集群中的segment元數(shù)據(jù)信息

MySQL和Zookeeper故障響應(yīng)的設(shè)計(jì)原則是相同的：如果負(fù)責(zé)協(xié)調(diào)的外部依賴失敗派撕，集群維持現(xiàn)狀婉弹。 Druid使用MySQL存儲操作管理信息，關(guān)于集群中應(yīng)存在哪些段的元數(shù)據(jù)信息终吼。如果MySQL停止镀赌，此信息對協(xié)調(diào)器節(jié)點(diǎn)不可用。但是际跪，這并不意味著數(shù)據(jù)本身不可用佩脊。如果協(xié)調(diào)器節(jié)點(diǎn)不能與MySQL通信，它們將停止分配新的段并丟棄過時(shí)的節(jié)點(diǎn)垫卤。在MySQL中斷期間威彰，Broker、歷史和實(shí)時(shí)節(jié)點(diǎn)仍然可以查詢穴肘。