整體架構(gòu)
Druid集群是由一組扮演不同角色的拾因，功能不同的節(jié)點(diǎn)組成的苍匆，我們先從這幅圖介紹一下幾類節(jié)點(diǎn)，以及它們之間的通信方式岖研。
節(jié)點(diǎn)類型
- Broker：接收客戶端的查詢請求；轉(zhuǎn)發(fā)查詢到Realtime和Historical節(jié)點(diǎn)警检；接收查詢結(jié)果并進(jìn)行合并孙援，發(fā)回給客戶端。Broker通過Zookeeper確定Realtime和Historical節(jié)點(diǎn)是否存在扇雕。
- Indexing Service：在將批量和實(shí)時(shí)數(shù)據(jù)導(dǎo)入系統(tǒng)時(shí)拓售，將數(shù)據(jù)轉(zhuǎn)換為Druid的索引結(jié)構(gòu)保存在系統(tǒng)中。
- Coordinator：監(jiān)控Historical節(jié)點(diǎn)镶奉，以確保數(shù)據(jù)的可靠性础淤；協(xié)調(diào)每個(gè)Historical節(jié)點(diǎn)加載的數(shù)據(jù)塊，讀取Zookeeper來判斷存在的Historical節(jié)點(diǎn)哨苛，并通過創(chuàng)建Zookeeper的標(biāo)識(shí)鸽凶，告知Historical進(jìn)行加載或釋放數(shù)據(jù)塊。
- Historial：處理歷史（非實(shí)時(shí)）數(shù)據(jù)的存儲(chǔ)和查詢建峭，和數(shù)據(jù)存儲(chǔ)介質(zhì)緊密聯(lián)系玻侥，響應(yīng)Broker的查詢請求，并將查詢到的結(jié)構(gòu)返回給Broker亿蒸。在Zookeeper中記錄每個(gè)Historical節(jié)點(diǎn)保存的數(shù)據(jù)塊凑兰。
- Realtime：將實(shí)時(shí)數(shù)據(jù)導(dǎo)入到系統(tǒng)中掌桩。
外部依賴
- Zookeeper：各節(jié)點(diǎn)之間通信的主要方式。
- Coordinator節(jié)點(diǎn)和Historical節(jié)點(diǎn)之間的數(shù)據(jù)塊加載和釋放
- Realtime節(jié)點(diǎn)和Historical節(jié)點(diǎn)之間的數(shù)據(jù)塊消息發(fā)布
- Coordinator等的leader選舉
- Indexing服務(wù)任務(wù)的管理
- MySQL：用于Druid元數(shù)據(jù)的保存姑食。
- Deep Storage： 數(shù)據(jù)的實(shí)際存儲(chǔ)波岛。在Druid中的數(shù)據(jù)塊稱為segment，segment存儲(chǔ)在Deep Storage中音半。
