Druid基本概念及架構(gòu)介紹
1.什么是Druid
Druid是一個專為大型數(shù)據(jù)集上的高性能切片和OLAP分析而設計的數(shù)據(jù)存儲。Druid最常用作為GUI分析應用程序提供動力的數(shù)據(jù)存儲遗契，或者用作需要快速聚合的高度并發(fā)API的后端需频。Druid的常見應用領域包括：
點擊流分析
網(wǎng)絡流量分析
服務器指標存儲
應用性能指標
數(shù)字營銷分析
商業(yè)智能/OLAP
2.druid的主要特點
1.列式存儲格式 Druid使用面向列的存儲巩剖，這意味著它只需要加載特定查詢所需的精確列憔古。這為僅查看幾列的查詢提供了巨大的速度提升罢坝。此外暑始，每列都針對其特定數(shù)據(jù)類型進行了優(yōu)化搭独，支持快速掃描和聚合。
2.高可用性與高可拓展性 Druid采用分布式廊镜、SN(share-nothing)架構(gòu)牙肝，管理類節(jié)點可配置HA，工作節(jié)點功能單一嗤朴，不相互依賴配椭，這些特性都使得Druid集群在管理、容錯雹姊、災備股缸、擴容等方面變得十分簡單。Druid通常部署在數(shù)十到數(shù)百臺服務器的集群中吱雏，并且可以提供數(shù)百萬條記錄/秒的攝取率敦姻，保留數(shù)萬億條記錄瘾境，以及亞秒級到幾秒鐘的查詢延遲。
3.大規(guī)模并行處理 Druid可以在整個集群中并行處理查詢镰惦。
4.實時或批量攝取 實時流數(shù)據(jù)分析迷守。區(qū)別于傳統(tǒng)分析型數(shù)據(jù)庫采用的批量導入數(shù)據(jù)進行分析的方式，Druid提供了實時流數(shù)據(jù)分析旺入，采用LSM(Long structure-merge)-Tree結(jié)構(gòu)使Druid擁有極高的實時寫入性能兑凿；同時實現(xiàn)了實時數(shù)據(jù)在亞秒級內(nèi)的可視化。
5.自愈茵瘾，自平衡礼华，易于操作 作為運營商，要將群集擴展或縮小龄捡，只需添加或刪除服務器卓嫂，群集將在后臺自動重新平衡，無需任何停機時間聘殖。如果任何Druid服務器發(fā)生故障晨雳，系統(tǒng)將自動路由損壞，直到可以更換這些服務器奸腺。Druid旨在全天候運行餐禁，無需任何原因計劃停機，包括配置更改和軟件更新突照。
6.云原生帮非，容錯的架構(gòu)，不會丟失數(shù)據(jù) 一旦Druid攝取了您的數(shù)據(jù)讹蘑，副本就會安全地存儲在深層存儲（通常是云存儲末盔，HDFS或共享文件系統(tǒng)）中。即使每個Druid服務器都出現(xiàn)故障座慰，您的數(shù)據(jù)也可以從深層存儲中恢復陨舱。對于僅影響少數(shù)Druid服務器的更有限的故障，復制可確保在系統(tǒng)恢復時仍可進行查詢版仔。
7.亞秒級的OLAP查詢分析 Druid采用了列式存儲游盲、倒排索引、位圖索引等關鍵技術(shù)蛮粮，能夠在亞秒級別內(nèi)完成海量數(shù)據(jù)的過濾益缎、聚合以及多維分析等操作。
8.近似算法 Druid包括用于近似計數(shù) - 不同然想，近似排序以及近似直方圖和分位數(shù)的計算的算法绪抛。這些算法提供有限的內(nèi)存使用匕得，并且通常比精確計算快得多卓舵。對于精確度比速度更重要的情況，Druid還提供精確計數(shù) - 不同且精確的排名熙卡。
9.豐富的數(shù)據(jù)分析功能針對不同用戶群體杖刷，Druid提供了友好的可視化界面励饵、類SQL查詢語言以及REST 查詢接口。
3.為什么會有Druid
大數(shù)據(jù)時代滑燃，如何從海量數(shù)據(jù)中提取有價值的信息役听，是一個亟待解決的難題。針對這個問題表窘，IT巨頭們已經(jīng)開發(fā)了大量的數(shù)據(jù)存儲與分析類產(chǎn)品典予，比如IBM Netezza、HP Vertica乐严、EMC GreenPlum等瘤袖，但是他們大多是昂貴的商業(yè)付費類產(chǎn)品，業(yè)內(nèi)使用者寥寥昂验。
而受益于近年來高漲的開源精神捂敌，業(yè)內(nèi)出現(xiàn)了眾多優(yōu)秀的開源項目，其中最有名的當屬Apache Hadoop生態(tài)圈既琴。時至今日占婉，Hadoop已經(jīng)成為了大數(shù)據(jù)的“標準”解決方案，但是甫恩，人們在享受Hadoop便捷數(shù)據(jù)分析的同時逆济，也必須要忍受Hadoop在設計上的許多“痛點”，下面就羅列三方面的問題：
1.何時能進行數(shù)據(jù)查詢磺箕？ 對于Hadoop使用的Map/Reduce批處理框架奖慌，數(shù)據(jù)何時能夠查詢沒有性能保證。
2.隨機IO問題松靡。 Map/Reduce批處理框架所處理的數(shù)據(jù)需要存儲在HDFS上简僧，而HDFS是一個以集群硬盤作為存儲資源池的分布式文件系統(tǒng)，那么在海量數(shù)據(jù)的處理過程中击困，必然會引起大量的讀寫操作涎劈，此時隨機IO就成為了高并發(fā)場景下的性能瓶頸。
3.數(shù)據(jù)可視化問題阅茶。 HDFS是一個優(yōu)秀的分布式文件系統(tǒng)蛛枚，但是對于數(shù)據(jù)分析以及數(shù)據(jù)的即席查詢，HDFS并不是最優(yōu)的選擇脸哀。
傳統(tǒng)的大數(shù)據(jù)處理架構(gòu)Hadoop更傾向于一種“后臺批處理的數(shù)據(jù)倉庫系統(tǒng)”蹦浦，其作為海量歷史數(shù)據(jù)保存、冷數(shù)據(jù)分析撞蜂，確實是一個優(yōu)秀的通用解決方案盲镶，但是如何保證高并發(fā)環(huán)境下海量數(shù)據(jù)的查詢分析性能侥袜，以及如何實現(xiàn)海量實時數(shù)據(jù)的查詢分析與可視化，Hadoop確實顯得有些無能為力溉贿。
4.Druid直面的痛點
Druid的母公司MetaMarket在2011年以前也是Hadoop的擁躉者枫吧，但是在高并發(fā)環(huán)境下，Hadoop并不能對數(shù)據(jù)可用性以及查詢性能給出產(chǎn)品級別的保證宇色，使得MetaMarket必須去尋找新的解決方案九杂，當嘗試使用了各種關系型數(shù)據(jù)庫以及NoSQL產(chǎn)品后，他們覺得這些已有的工具都不能解決他們的“痛點”宣蠕，所以決定在2011年開始研發(fā)自己的“輪子”Druid例隆，他們將Druid定義為“開源、分布式抢蚀、面向列式存儲的實時分析數(shù)據(jù)存儲系統(tǒng)”镀层，所要解決的“痛點”也是上文中反復提及的“在高并發(fā)環(huán)境下，保證海量數(shù)據(jù)查詢分析性能皿曲，同時又提供海量實時數(shù)據(jù)的查詢唱逢、分析與可視化功能”。
5.什么時候應該使用Druid
-
1.如果您的用例符合以下幾個描述符谷饿，Druid可能是一個不錯的選擇：
插入率非常高惶我，但更新不常見。
您的大多數(shù)查詢都是聚合和報告查詢（“分組依據(jù)”查詢）博投。您可能還有搜索和掃描查詢绸贡。
您將查詢延遲定位為100毫秒到幾秒鐘。
您的數(shù)據(jù)有一個時間組件（Druid包括與時間特別相關的優(yōu)化和設計選擇）毅哗。
您可能有多個表听怕，但每個查詢只能訪問一個大的分布式表。查詢可能會觸發(fā)多個較小的“查找”表虑绵。
您有高基數(shù)數(shù)據(jù)列（例如URL尿瞭，用戶ID），需要對它們進行快速計數(shù)和排名翅睛。
您希望從Kafka声搁，HDFS，平面文件或?qū)ο蟠鎯Γㄈ鏏mazon S3）加載數(shù)據(jù)捕发。
-
2.情況下疏旨，您可能會不希望使用Druid包括：
您需要使用主鍵對現(xiàn)有記錄進行低延遲更新。Druid支持流式插入扎酷，但不支持流式更新（使用后臺批處理作業(yè)進行更新）檐涝。
您正在構(gòu)建一個脫機報告系統(tǒng)，其中查詢延遲不是很重要。
你想做“大”連接（將一個大事實表連接到另一個大事實表）谁榜。
6.Druid架構(gòu)
Druid擁有一個多進程幅聘，分布式架構(gòu)，旨在實現(xiàn)云友好且易于操作窃植。每個Druid流程類型都可以獨立配置和擴展帝蒿，為您的群集提供最大的靈活性。此設計還提供增強的容錯能力：一個組件的中斷不會立即影響其他組件撕瞧。
Druid集群包含多種節(jié)點類型陵叽，分別是Historical Node、Coordinator Node丛版、Broker Node、Indexing Service Node（包括Overlord偏序、MiddleManager和Peon）以及Realtime Node（包括Firehose和Plumber）页畦。
Druid將整個集群切分成上述角色，有兩個目的：
第一研儒，劃分Historical Node和Realtime Node豫缨，是將歷史數(shù)據(jù)的加載與實時流數(shù)據(jù)處理切割開來，因為二者都需要占用大量內(nèi)存與CPU端朵；
第二好芭，劃分Coordinator Node和Broker Node，將查詢需求與數(shù)據(jù)如何在集群內(nèi)分布的需求切割開來冲呢，確保用戶的查詢請求不會影響數(shù)據(jù)在集群內(nèi)的分布情況舍败，從而不會造成數(shù)據(jù)“冷熱不均”，局部過熱敬拓，影響查詢性能的問題邻薯。
下圖給出了Druid集群內(nèi)部的實時/批量數(shù)據(jù)流以及查詢請求過程。我們可以看到乘凸，實時數(shù)據(jù)到達Realtime Node厕诡，經(jīng)過Indexing Service，在時間窗口內(nèi)的數(shù)據(jù)會停留在Realtime Node內(nèi)存中营勤，而時間窗口外的數(shù)據(jù)會組織成Segment存儲到Deep Storage中灵嫌；批量數(shù)據(jù)經(jīng)過Indexing Service也會被組織成Segment存儲到DeepStorage中，同時Segment的元信息都會被注冊到元信息庫中葛作，Coordinator Nodes會定期（默認為1分鐘）去同步元信息庫寿羞，感知新生成的Segment，并通知在線的Historical Node去加載Segment进鸠，Zookeeper也會更新整個集群內(nèi)部數(shù)據(jù)分布拓撲圖稠曼。
當用戶需要查詢信息時，會將請求提交給Broker Node，Broker Node會請求Zookeeper獲取集群內(nèi)數(shù)據(jù)分布拓撲圖霞幅，從而知曉請求應該發(fā)給哪些Historical Node以及Realtime Node漠吻，匯總各節(jié)點的返回數(shù)據(jù)并將最終結(jié)果返回給用戶。
7.Druid集群節(jié)點
7.1Historical Node
Historical Node的職責單一司恳，就是負責加載Druid中非實時窗口內(nèi)且滿足加載規(guī)則的所有歷史數(shù)據(jù)的Segment途乃。每一個Historical Node只與Zookeeper保持同步，不與其他類型節(jié)點或者其他Historical Node進行通信扔傅。
Coordinator Nodes會定期（默認為1分鐘）去同步元信息庫耍共，感知新生成的Segment，將待加載的Segment信息保存在Zookeeper中在線的Historical Nodes的load queue目錄下猎塞，當Historical Node感知到需要加載新的Segment時试读，首先會去本地磁盤目錄下查找該Segment是否已下載，如果沒有荠耽，則會從Zookeeper中下載待加載Segment的元信息钩骇，此元信息包括Segment存儲在何處、如何解壓以及如何如理該Segment铝量。Historical Node使用內(nèi)存文件映射方式將index.zip中的XXXXX.smoosh文件加載到內(nèi)存中倘屹，并在Zookeeper中本節(jié)點的served segments目錄下聲明該Segment已被加載，從而該Segment可以被查詢慢叨。對于重新上線的Historical Node纽匙，在完成啟動后，也會掃描本地存儲路徑拍谐，將所有掃描到的Segment加載如內(nèi)存烛缔，使其能夠被查詢。
7.2Broker Node
Broker Node是整個集群查詢的入口赠尾，作為查詢路由角色力穗，Broker Node感知Zookeeper上保存的集群內(nèi)所有已發(fā)布的Segment的元信息，即每個Segment保存在哪些存儲節(jié)點上气嫁，Broker Node為Zookeeper中每個dataSource創(chuàng)建一個timeline当窗，timeline按照時間順序描述了每個Segment的存放位置。我們知道寸宵，每個查詢請求都會包含dataSource以及interval信息崖面，Broker Node根據(jù)這兩項信息去查找timeline中所有滿足條件的Segment所對應的存儲節(jié)點，并將查詢請求發(fā)往對應的節(jié)點.
對于每個節(jié)點返回的數(shù)據(jù)梯影，Broker Node默認使用LRU緩存策略巫员；對于集群中存在多個Broker Node的情況，Druid使用memcached共享緩存甲棍。對于Historical Node返回的結(jié)果简识，Broker Node認為是“可信的”，會緩存下來，而Real-Time Node返回的實時窗口內(nèi)的數(shù)據(jù)七扰，Broker Node認為是可變的奢赂，“不可信的”，故不會緩存颈走。所以對每個查詢請求膳灶，Broker Node都會先查詢本地緩存，如果不存在才會去查找timeline立由，再向相應節(jié)點發(fā)送查詢請求轧钓。
7.3Coordinator Node
Coordinator Node主要負責Druid集群中Segment的管理與發(fā)布，包括加載新Segment锐膜、丟棄不符合規(guī)則的Segment毕箍、管理Segment副本以及Segment負載均衡等。如果集群中存在多個Coordinator Node枣耀，則通過選舉算法產(chǎn)生Leader霉晕，其他Follower作為備份。
Coordinator會定期（默認一分鐘）同步Zookeeper中整個集群的數(shù)據(jù)拓撲圖捞奕、元信息庫中所有有效的Segment信息以及規(guī)則庫，從而決定下一步應該做什么拄轻。對于有效且未分配的Segment颅围，Coordinator Node首先按照Historical Node的容量進行倒序排序，即最少容量擁有最高優(yōu)先級恨搓，新的Segment會優(yōu)先分配到高優(yōu)先級的Historical Node上院促。由之前介紹我們知道，Coordinator Node不會直接與Historical Node打交道斧抱，而是在Zookeeper中Historical Node對應的load queue目錄下創(chuàng)建待加載Segment的臨時信息常拓，等待Historical Node去加載該Segment。
Coordinator在每次啟動后都會對比Zookeeper中保存的當前數(shù)據(jù)拓撲圖以及元信息庫中保存的數(shù)據(jù)信息辉浦，所有在集群中已被加載的弄抬、卻在元信息庫中標記為失效或者不存在的Segment會被Coordinator Node記錄在remove list中，同一Segment對應的新舊version宪郊，舊version的Segments同樣也會被放入到remove list中掂恕，最終被邏輯丟棄。
對于離線的Historical Node弛槐，Coordinator Node會默認該Historical Node上所有的Segment已失效懊亡，從而通知集群內(nèi)的其他Historical Node去加載該Segment。但是乎串，在生產(chǎn)環(huán)境中店枣，我們會遇到機器臨時下線，Historical Node在很短時間內(nèi)恢復服務的情況，那么如此“簡單粗暴”的策略勢必會加重整個集群內(nèi)的網(wǎng)絡負載鸯两。對于這種場景闷旧，Coordinator會為集群內(nèi)所有已丟棄的Segment保存一個生存時間(lifetime)，這個生存時間表示Coordinator Node在該Segment被標記為丟棄后甩卓，允許不被重新分配最長等待時間鸠匀，如果該Historical Node在該時間內(nèi)重新上線，則Segment會被重新置為有效逾柿，如果超過該時間則會按照加載規(guī)則重新分配到其他Historical Node上缀棍。
考慮一種最極端的情況，如果集群內(nèi)所有的Coordinator Node都停止服務机错，整個集群對外依然有效爬范，不過新Segment不會被加載，過期的Segment也不會被丟棄弱匪，即整個集群內(nèi)的數(shù)據(jù)拓撲會一直保持不變青瀑，直到新的Coordinator Node服務上線。
7.4Indexing Service
Indexing Service是負責“生產(chǎn)”Segment的高可用萧诫、分布式斥难、Master/Slave架構(gòu)服務。主要由三類組件構(gòu)成：負責運行索引任務(indexing task)的Peon帘饶，負責控制Peon的MiddleManager哑诊，負責任務分發(fā)給MiddleManager的Overlord；三者的關系可以解釋為：Overlord是MiddleManager的Master及刻，而MiddleManager又是Peon的Master镀裤。其中，Overlord和MiddleManager可以分布式部署缴饭，但是Peon和MiddleManager默認在同一臺機器上暑劝。圖-3.5給出了Indexing Service的整體架構(gòu)。
-
Overlord
Overlord負責接受任務颗搂、協(xié)調(diào)任務的分配担猛、創(chuàng)建任務鎖以及收集、返回任務運行狀態(tài)給調(diào)用者峭火。當集群中有多個Overlord時毁习，則通過選舉算法產(chǎn)生Leader，其他Follower作為備份卖丸。
Overlord可以運行在local（默認）和remote兩種模式下纺且，如果運行在local模式下，則Overlord也負責Peon的創(chuàng)建與運行工作稍浆，當運行在remote模式下時载碌，Overlord和MiddleManager各司其職猜嘱，根據(jù)圖3.6所示，Overlord接受實時/批量數(shù)據(jù)流產(chǎn)生的索引任務嫁艇，將任務信息注冊到Zookeeper的/task目錄下所有在線的MiddleManager對應的目錄中朗伶，由MiddleManager去感知產(chǎn)生的新任務，同時每個索引任務的狀態(tài)又會由Peon定期同步到Zookeeper中/Status目錄步咪，供Overlord感知當前所有索引任務的運行狀況论皆。
Overlord對外提供可視化界面，通過訪問http://ip/console.html猾漫，我們可以觀察到集群內(nèi)目前正在運行的所有索引任務点晴、可用的Peon以及近期Peon完成的所有成功或者失敗的索引任務。
-
MiddleManager
MiddleManager負責接收Overlord分配的索引任務悯周，同時創(chuàng)建新的進程用于啟動Peon來執(zhí)行索引任務粒督，每一個MiddleManager可以運行多個Peon實例。
在運行MiddleManager實例的機器上禽翼，我們可以在${ java.io.tmpdir}目錄下觀察到以XXX_index_XXX開頭的目錄屠橄，每一個目錄都對應一個Peon實例；同時restore.json文件中保存著當前所有運行著的索引任務信息闰挡，一方面用于記錄任務狀態(tài)锐墙，另一方面如果MiddleManager崩潰，可以利用該文件重啟索引任務长酗。
-
Peon
- Peon是Indexing Service的最小工作單元贮匕，也是索引任務的具體執(zhí)行者，所有當前正在運行的Peon任務都可以通過Overlord提供的web可視化界面進行訪問花枫。
7.5Real-Time Node
在流式處理領域，有兩種數(shù)據(jù)處理模式掏膏，一種為Stream Push劳翰，另一種為Stream Pull。
Stream Pull 如果Druid以Stream Pull方式自主地從外部數(shù)據(jù)源拉取數(shù)據(jù)從而生成Indexing Service Tasks馒疹，我們則需要建立Real-Time Node佳簸。Real-Time Node主要包含兩大“工廠”：一個是連接流式數(shù)據(jù)源、負責數(shù)據(jù)接入的Firehose（中文翻譯為水管颖变，很形象地描述了該組件的職責）生均；另一個是負責Segment發(fā)布與轉(zhuǎn)移的Plumber（中文翻譯為搬運工，同樣也十分形象地描述了該組件的職責）腥刹。在Druid源代碼中马胧，這兩個組件都是抽象工廠方法，使用者可以根據(jù)自己的需求創(chuàng)建不同類型的Firehose或者Plumber衔峰。Firehose和Plumber給我的感覺佩脊，更類似于Kafka_0.9.0版本后發(fā)布的Kafka Connect框架蛙粘，F(xiàn)irehose類似于Kafka Connect Source，定義了數(shù)據(jù)的入口威彰，但并不關心接入數(shù)據(jù)源的類型出牧；而Plumber類似于Kafka Connect Sink，定義了數(shù)據(jù)的出口歇盼，也不關心最終輸出到哪里舔痕。
Stream Push 如果采用Stream Push策略，我們需要建立一個“copy service”豹缀，負責從數(shù)據(jù)源中拉取數(shù)據(jù)并生成Indexing Service Tasks伯复，從而將數(shù)據(jù)“推入”到Druid中，我們在druid_0.9.1版本之前一直使用的是這種模式耿眉，不過這種模式需要外部服務Tranquility边翼，Tranquility組件可以連接多種流式數(shù)據(jù)源，比如Spark-Streaming鸣剪、Storm以及Kafka等组底，所以也產(chǎn)生了Tranquility-Storm、Tranquility-Kafka等外部組件筐骇。
8.外部拓展
Druid集群依賴一些外部組件债鸡，與其說依賴，不如說正是由于Druid開放的架構(gòu)铛纬，所以用戶可以根據(jù)自己的需求厌均，使用不同的外部組件。
Deep Storage Druid目前支持使用本地磁盤(單機模式)告唆、NFS掛載磁盤棺弊、HDFS、Amazon S3等存儲方式保存Segments以及索引任務日志擒悬。
Zookeeper Druid使用Zookeeper作為分布式集群內(nèi)部的通信組件模她，各類節(jié)點通過Curator Framework將實例與服務注冊到Zookeeper上，同時將集群內(nèi)需要共享的信息也存儲在Zookeeper目錄下懂牧，從而簡化集群內(nèi)部自動連接管理侈净、leader選舉、分布式鎖僧凤、path緩存以及分布式隊列等復雜邏輯畜侦。
Metadata Storage Druid集群元信息使用MySQL 或者PostgreSQL存儲，單機版使用derby躯保。在Druid_0.9.1.1版本中旋膳，元信息庫druid主要包含十張表，均以“druid_”開頭吻氧，如圖-3.7所示溺忧。
(1) Load/Drop Segments規(guī)則表 druid_rules
我們通過訪問http://<coordinator>:<port>對不同datasource配置不同的Load/Drop規(guī)則咏连，規(guī)則保存在表druid_rules中，由Coordinator定期獲取鲁森，通知在線的HistoricalNode去加載或者丟棄相應的Segment祟滴。Load/Drop規(guī)則均有三類，分別是Forever Load/Drop Rule歌溉，IntervalLoad/Drop Rule以及Period Load/Drop Rule垄懂。圖-3.9給出的是一條loadforever規(guī)則。
在生產(chǎn)環(huán)境中痛垛，我們建議大家草慧，不要直接在表中操作規(guī)則，以免出現(xiàn)各種未知問題匙头。
(2)規(guī)則審計表druid_audit漫谷。記錄Load/Drop Segment規(guī)則的審計信息
(3)Index Service配置表 druid_config
Overload作為Indexing Service的Master節(jié)點，可以動態(tài)改變Peon運行配置蹂析。舉例說明舔示，如圖3.13所示。我們在使用Druid時电抚，通過JSON over HTTP的方式向http://<overload ip>:<port>/druid/indexer/v1/worker變更Peon工作模式為"equalDistribution",表示MiddleManager在Remote模式下均勻分發(fā)任務給集群內(nèi)所有Peon節(jié)點惕稻，使集群在高負載的情況下，不會出現(xiàn)問題蝙叛。
(4)數(shù)據(jù)源表druid_dataSource
如果使用druid_0.9.1.1新特性Kafka IndexingService俺祠，如圖3.14所示，那么該表會保存每個datasource對應的Kafka Topic信息借帘，一級改Topic下所有Partitions已被消費的offset蜘渣。
(5)Segment元信息表druid_segments
該表中有一個used字段，是用來標識此segment是否被使用肺然，如果某個datasource配置了規(guī)則宋梧，那么Druid只會采用邏輯刪除，即應把對應的segment的used置為0狰挡，而不是物理刪除。
(6)任務表druid_tasks释涛。其中加叁，圖3.18是druid_0.9.1.1版本新增的kafka indexing service tasks。
(5)Segment元信息表druid_segments
(7)任務鎖表druid_tasklocks
(8)等待隊列中的索引任務表druid_pendingSegments
(9)索引任務日志信息表druid_tasklogs
(10)KafkaIndexingService對應supervise表 druid_supervisors
9.加載數(shù)據(jù)
對于加載外部數(shù)據(jù)唇撬，Druid支持兩種模式：實時流(real-time ingestion)和批量導入(batch ingestion)它匕。
Real-Time Ingestion 實時流過程可以采用Apache Storm、Apache Spark Streaming等流式處理框架產(chǎn)生數(shù)據(jù)窖认，再經(jīng)過pipeline工具豫柬，比如Apache Kafka告希、ActiveMQ、RabbitMQ等消息總線類組件烧给，使用Stream Pull 或者Stream Push模式生成Indexing Service Tasks燕偶，最終存儲在Druid中。
Batch Ingestion 批量導入模式可以采用結(jié)構(gòu)化信息作為數(shù)據(jù)源础嫡，比如JSON指么、Avro、Parquet格式的文本榴鼎，Druid內(nèi)部使用Map/Reduce批處理框架導入數(shù)據(jù)伯诬。
10.高可用性
Druid高可用性可以總結(jié)以下幾點：
Historical Node 如前所述，如果某個Historical Node離線時長超過一定閾值巫财，Coordinator Node會將該節(jié)點上已加載的Segments重新分配到其他在線的Historical Nodes上盗似，保證滿足加載規(guī)則的所有Segments不丟失且可查詢。
Coordinator Node 集群可配置多個Coordinator Node實例平项，工作模式為主從同步赫舒，采用選舉算法產(chǎn)生Leader，其他Follower作為備份葵礼。當Leader宕機時号阿，其他Follower能夠迅速failover。
即使當所有Coordinator Node均失效鸳粉，整個集群對外依然有效扔涧，不過新Segments不會被加載，過期的Segments也不會被丟棄届谈，即整個集群內(nèi)的數(shù)據(jù)拓撲會一直保持不變枯夜，直到新的Coordinator Node服務上線。Broker Node Broker Node與Coordinator Node在HA部署方面一致艰山。
Indexing Service Druid可以為同一個Segment配置多個Indexing Service Tasks副本保證數(shù)據(jù)完整性湖雹。
Real-Time Real-Time過程的數(shù)據(jù)完整性主要由接入的實時流語義(semantics)決定。我們在0.9.1.1版本前使用Tranquility-Kafka組件接入實時數(shù)據(jù)曙搬，由于存在時間窗口摔吏，即在時間窗口內(nèi)的數(shù)據(jù)會被提交給Firehose，時間窗口外的數(shù)據(jù)則會被丟棄纵装；如果Tranquility-Kafka臨時下線征讲，會導致Kafka中數(shù)據(jù)“過期”從而被丟棄，無法保證數(shù)據(jù)完整性橡娄，同時這種“copy service”的使用模式不僅占用大量CPU與內(nèi)存诗箍，又不滿足原子操作，所以在0.9.1.1版本后挽唉，我們使用Druid的新特性Kafka Indexing Service滤祖，Druid內(nèi)部使用Kafka高級Consumer API保證exactly-once semantics筷狼，盡最大可能保證數(shù)據(jù)完整性。不過我們在使用中匠童，依然發(fā)現(xiàn)有數(shù)據(jù)丟失問題埂材。
Metadata Storage 如果Metadata Storage失效，Coordinator則無法感知新Segment的生成俏让，整個集群中數(shù)據(jù)拓撲亦不會改變楞遏，不過不會影響老數(shù)據(jù)的訪問。
Zookeeper 如果Zookeeper失效首昔，整個集群的數(shù)據(jù)拓撲不會改變寡喝，由于Broker Node緩存的存在，所以在緩存中的數(shù)據(jù)依然可以被查詢勒奇。
參考:
http://druid.io/docs/latest/design/index.html
https://blog.csdn.net/paicmis/article/details/72625404
