作者 ｜ vivo 互聯(lián)網(wǎng)大數(shù)據(jù)團隊-Zheng Xiaofeng

一、背景

Druid 是一個專為大型數(shù)據(jù)集上的高性能切片和 OLAP 分析而設(shè)計的數(shù)據(jù)存儲系統(tǒng)。

由于Druid 能夠同時提供離線和實時數(shù)據(jù)的查詢，因此Druid最常用作為GUI分析、業(yè)務(wù)監(jiān)控、實時數(shù)倉的數(shù)據(jù)存儲系統(tǒng)。

此外Druid擁有一個多進程，分布式架構(gòu)，每個Druid組件類型都可以獨立配置和擴展，為集群提供最大的靈活性。

由于Druid架構(gòu)設(shè)計和數(shù)據(jù)(離線，實時)的特殊性，導(dǎo)致Druid元數(shù)據(jù)管理邏輯比較復(fù)雜，主要體現(xiàn)在Druid具有眾多的元數(shù)據(jù)存儲介質(zhì)以及眾多不同類型組件之間元數(shù)據(jù)傳輸邏輯上。

本文的目的是通過梳理 Druid 元數(shù)據(jù)管理這個側(cè)面從而進一步了解 Druid 內(nèi)部的運行機制。

二、 Druid 元數(shù)據(jù)相關(guān)概念

2.1 Segment

Segment 是Druid管理數(shù)據(jù)的最基本單元，一個Datasource包含多個Segment，每個Segment保存著Datasource某個時間段的數(shù)據(jù)，這個特定時間段的數(shù)據(jù)組織方式是通過Segment的payload(json)來定義的，payload內(nèi)部定義了某個Segment的維度，指標(biāo)等信息。

同一個Datasource的不同Segment的payload信息(維度、指標(biāo))可以不相同，Segment信息主要包含下面幾部分：

【時間段(Interval)】：用于描述數(shù)據(jù)的開始時間和結(jié)束時間。

【DataSource】: 用字符串表示，指定segment隸屬于哪個Datasource。

【版本(Version)】：用一個時間表示，時間段(Interval)相同的Segment，版本高的Segment數(shù)據(jù)可見，版本低的Segment會被刪除掉。

【Payload 信息】：主要包含了此Segment的維度和指標(biāo)信息，以及Segment數(shù)據(jù)存在DeepStorage 位置信息等等。

segment主要組成部分

segment 內(nèi)部數(shù)據(jù)樣例

2.2 Datasource

Datasource相當(dāng)于關(guān)系型數(shù)據(jù)庫的表，Datasource的Schema是根據(jù)其可用的Segment動態(tài)變化的，如果某個Datasource沒有可用的Segment(used=1)，在druid-web的Datasource列表界面和查詢界面看不到這個Datasource。

元數(shù)據(jù)庫中druid_dataSource表并沒有保存Schema信息，只保存了該Datasource對應(yīng) 實時任務(wù)消費數(shù)據(jù)的偏移量信息，都說Druid的Datasource相當(dāng)于關(guān)系型數(shù)據(jù)庫的表，但是Druid中表(Datasource)Schema信息，并不是定義在druid_dataSource元數(shù)據(jù)表里。

那么在druid-web 頁面上看到的Datasource 的Schema信息是怎么來的呢?

其實它是實時根據(jù)該Datasource下所有Segment元數(shù)據(jù)信息合并而來，所以DataSource的Schema是實時變化的，

這樣設(shè)計的好處是很好的適應(yīng)了Datasource維度不斷變化的需求在 ：

Schema的合并過程

2.3 Rule

Rule定義了Datasource的Segment留存規(guī)則，主要分兩大類：Load和Drop。

• Load 表示Segment 保留策略。
• Drop 表示 Segment 刪除策略。

Load/Drop規(guī)則均有三個子類，分別是Forever Load/Drop，Interval Load/Drop以及Period Load/Drop，一個Datasource包含1個或多個Rule規(guī)則，如果沒有定義Rule規(guī)則就使用集群的Default Rule規(guī)則。

Datasource Rule規(guī)則列表是有序的(自定義規(guī)則在前面，集群默認(rèn)規(guī)則在后面)，在運行Run規(guī)則時，會對該Datasource下所有可用的Segment信息，按照Run規(guī)則的先后順序進行判斷，只要Segment滿足某個Rule規(guī)則，后面的規(guī)則Rule就不再運行(如圖：Rule處理邏輯案例)。Rule規(guī)則主要包含下面幾部分信息：

【類型】：類型有刪除規(guī)則和加載規(guī)則。

【Tier和副本信息】：如果是Load規(guī)則，需要定義在不同Tier的Historical機器副本數(shù)。

【時間信息】：刪除或加載某個時間段的Segment。

Rule 樣例如下：

[
   {
   "period": "P7D",
   "includeFuture": true,
   "tieredReplicants": {
     "_default_tier": 1,
     "vStream":1
   },
   "type": "loadByPeriod"
 },
 {
   "type": "dropForever"
 }
 ]

Rule處理邏輯案例

2.4 Task

Task主要用于數(shù)據(jù)的攝入(本文主要討論實時攝入kafka數(shù)據(jù)的任務(wù))，在Task的運行過程中，它會根據(jù)數(shù)據(jù)時間列產(chǎn)生一個或者多個Segment，Task分為實時和離線任務(wù)。

實時任務(wù)(kafka)是Overload進程根據(jù)Supervisor定義自動生成;

離線任務(wù)(類型：index_hadoop，index_parallel)則需要外部系統(tǒng)通過訪問接口方式提交。

每個任務(wù)主要包含下面幾部分信息：

【dataSchema】：定義了該任務(wù)生成的Segment中有哪些維度(dimensionsSpec)，指標(biāo)(metricsSpec)，時間列(timestampSpec)，Segment粒度(segmentGranularity)，數(shù)據(jù)聚合粒度(queryGranularity)。

【tuningConfig】：任務(wù)在攝入數(shù)據(jù)過程中的優(yōu)化參數(shù)(包括Segment生成策略，索引類型，數(shù)據(jù)丟棄策略等等)，不同的任務(wù)類型有不同的參數(shù)設(shè)置。

【ioConfig】：定義了數(shù)據(jù)輸入的源頭信息，不同的數(shù)據(jù)源配置項有所不同。

【context】：關(guān)于任務(wù)全局性質(zhì)的配置，如任務(wù)Java進程的option信息。

【datasource】：表示該任務(wù)為那個Datasource 構(gòu)造Segment。

實時任務(wù)生成Segment案例

2.5 Supervisor

Supervisor 用于管理實時任務(wù)，離線任務(wù)沒有對應(yīng)的Supervisor，Supervisor與Datasource是一對一的關(guān)系，在集群運行過程中Supervisor對象由Overlord進程創(chuàng)建，通過Overlord接口提交Supervisor信息后，會在元數(shù)據(jù)庫(MySQL)中持久化，Supervisor內(nèi)容與Task相似，可以認(rèn)為實時Task是由Supervisor 克隆出來的。

三、Druid 整體架構(gòu)

前面籠統(tǒng)地介紹了Druid元數(shù)據(jù)相關(guān)概念，為了深入的了解Druid元數(shù)據(jù)，先從宏觀的角度認(rèn)識一下Druid的整體架構(gòu)。

可以形象地把Druid集群類比為一家公司，以Druid不同組件類比這家公司中不同類型員工來介紹Druid集群，Druid組件大體可以分為三類員工：領(lǐng)導(dǎo)層，車間員工和銷售員工，如下圖：

Druid組件分類

領(lǐng)導(dǎo)層： 領(lǐng)導(dǎo)根據(jù)外部市場需求(Overlord接收外部攝入任務(wù)請求)，然后把生產(chǎn)任務(wù)下發(fā)到對應(yīng)的職業(yè)經(jīng)理人(MiddleManager)，職業(yè)經(jīng)理人管理團隊(MiddleManager 啟動Peon進程)，下發(fā)具體生產(chǎn)任務(wù)給不同類型的員工(Peon進程)。

車間員工： 生產(chǎn)員工(Peon) 負責(zé)生產(chǎn)產(chǎn)品(segment)，倉庫管理員(Coordinator)負責(zé)把生產(chǎn)出來的產(chǎn)品(segment)分配到倉庫(Historical)中去。

銷售員工： 銷售員(Broker)從生產(chǎn)員工(Peon)獲取最新的產(chǎn)品(segment)，從倉庫中獲取原來生產(chǎn)的產(chǎn)品(segment)，然后把產(chǎn)品整理打包(數(shù)據(jù)進一步合并聚合)之后交給顧客(查詢用戶)。

上面通過類比公司的方式，對Druid集群有了初步的整體印象。

下面具體介紹 Druid 集群架構(gòu)，Druid 擁有一個多進程，分布式架構(gòu)，每個Druid組件類型都可以獨立配置和擴展，為集群提供最大的靈活性。

一個組件的中斷不會立即影響其他組件。

下面我們簡要介紹Druid各個組件在集群中起到的作用。

Druid架構(gòu)

Overlord

Overlord負責(zé)接受任務(wù)、協(xié)調(diào)任務(wù)的分配、創(chuàng)建任務(wù)鎖以及收集、返回任務(wù)運行狀態(tài)給調(diào)用者。當(dāng)集群中有多個Overlord時，則通過選舉算法產(chǎn)生Leader，其他Follower作為備份。

MiddleManager

MiddleManager負責(zé)接收Overlord分配的實時任務(wù)，同時創(chuàng)建新的進程用于啟動Peon來執(zhí)行實時任務(wù)，每一個MiddleManager可以運行多個Peon實例，每個實時Peon既提供實時數(shù)據(jù)查詢也負責(zé)實時數(shù)據(jù)的攝入工作。

Coordinator

Coordinator 主要負責(zé)Druid集群中Segment的管理與發(fā)布(主要是管理歷史Segment)，包括加載新Segment、丟棄不符合規(guī)則的Segment、管理Segment副本以及Segment負載均衡等。如果集群中存在多個Coordinator Node，則通過選舉算法產(chǎn)生Leader，其他Follower作為備份。

Historical

Historical 的職責(zé)是負責(zé)加載Druid中非實時窗口內(nèi)且滿足加載規(guī)則的所有歷史數(shù)據(jù)的Segment。每一個Historical Node只與Zookeeper保持同步，會把加載完成的Segment同步到Zookeeper。

Broker

Broker Node 是整個集群查詢的入口，Broker 實時同步Zookeeper上保存的集群內(nèi)所有已發(fā)布的Segment的元信息，即每個Segment保存在哪些存儲節(jié)點上，Broker 為Zookeeper中每個dataSource創(chuàng)建一個timeline，timeline按照時間順序描述了每個Segment的存放位置。

每個查詢請求都會包含dataSource以及interval信息，Broker 根據(jù)這兩項信息去查找timeline中所有滿足條件的Segment所對應(yīng)的存儲節(jié)點，并將查詢請求發(fā)往對應(yīng)的節(jié)點。

四、 Druid元數(shù)據(jù)存儲介質(zhì)

Druid 根據(jù)自身不同的業(yè)務(wù)需要，把元數(shù)據(jù)存儲在不同的存儲介質(zhì)中，為了提升查詢性能，同時也會將所有元數(shù)據(jù)信息緩存在內(nèi)存中。把歷史數(shù)據(jù)的元數(shù)據(jù)信息保存到元數(shù)據(jù)庫(MySQL)，以便集群重啟時恢復(fù)。

由于Druid 擁有一個多進程，分布式架構(gòu)，需要使用Zookeeper進行元數(shù)據(jù)傳輸，服務(wù)發(fā)現(xiàn)，主從選舉等功能，并且歷史節(jié)點會把Segment元數(shù)據(jù)信息存儲在本地文件。

那么歷史節(jié)點(Historical)為什么會把該節(jié)點加載的Segment元數(shù)據(jù)信息緩存在自己節(jié)點的本地呢?

是因為在歷史節(jié)點發(fā)生重啟之后，讀取Segment的元數(shù)據(jù)信息不用去Mysql等其他元數(shù)據(jù)存儲介質(zhì)進行跨節(jié)點讀取而是本地讀取， 這樣就極大地提升了歷史節(jié)點數(shù)據(jù)的恢復(fù)效率。

下面分別介紹這些存儲介質(zhì)(內(nèi)存、元數(shù)據(jù)庫、Zookeeper、本地文件)里的數(shù)據(jù)和作用。

4.1 元數(shù)據(jù)庫(MySQL)

MySQL 數(shù)據(jù)庫主要用于長期持久化 Druid 元數(shù)據(jù)信息，比如segment部分元數(shù)據(jù)信息存在druid_segments表中，歷史的Task信息存在druid_tasks，Supervisor信息存儲在druid_supervisors等等。

Druid部分服務(wù)進程在啟動時會加載元數(shù)據(jù)庫持久化的數(shù)據(jù)，如：Coordinator進程會定時加載表druid_segments 中used字段等于1的segment列表，Overlord 啟動時會自動加載druid_supervisors表信息，以恢復(fù)原來實時攝入任務(wù)等等。

MySQL 元數(shù)據(jù)庫表

4.2 Zookeeper

Zookeeper 主要存儲 Druid 集群運行過程中實時產(chǎn)生的元數(shù)據(jù)，Zookeeper 數(shù)據(jù)目錄大概可以分為Master節(jié)點高可用、數(shù)據(jù)攝入、數(shù)據(jù)查詢3類目錄。

下面介紹Druid相關(guān)Zookeeper目錄元數(shù)據(jù)內(nèi)容。

Zookeeper 元數(shù)據(jù)節(jié)點分類

4.2.1 Master 節(jié)點高可用相關(guān)目錄

${druid.zk.paths.base}/coordinator: coordinator 主從高可用目錄，有多個臨時有序節(jié)點 編號小的是leader。

${druid.zk.paths.base}/overlord: overlord 主從高可用目錄，有多個臨時有序節(jié)點 編號小的是leader。

4.2.2 數(shù)據(jù)查詢相關(guān)目錄

${druid.zk.paths.base}/announcements：只存儲historical，peon進程的host:port，沒有MiddleManager，broker，coodinator等進程信息，用于查詢相關(guān)節(jié)點服務(wù)發(fā)現(xiàn)。

${druid.zk.paths.base}/segments：當(dāng)前集群中能被查詢到的segment列表。目錄結(jié)構(gòu)：historical或peon的host:port/${segmentId}，Broker節(jié)點會實時同步這些Segment信息，作為數(shù)據(jù)查詢的重要依據(jù)。

4.2.3 數(shù)據(jù)攝入相關(guān)目錄

${druid.zk.paths.base}/loadQueue: Historical需要加載和刪除的segment信息列表(不止只有加載)，Historical進程會監(jiān)聽這個目錄下自己需要處理的事件(加載或刪除)，事件完成之后會主動刪除這個目錄下的事件。

${druid.zk.paths.indexer.base}=${druid.zk.paths.base}/indexer：關(guān)于攝入任務(wù)數(shù)據(jù)的base目錄。

${druid.zk.paths.indexer.base}/announcements：保存當(dāng)前存活MiddleManager列表，注意historical，peon 列表不在這里，這里只存儲攝入相關(guān)的服務(wù)信息，用于數(shù)據(jù)攝入相關(guān)節(jié)點服務(wù)發(fā)現(xiàn)。

${druid.zk.paths.indexer.base}/tasks Overlord 分配的任務(wù)信息放在這個目錄(MiddleManager的host:port/taskInfo)，等任務(wù)在MiddleManager上運行起來了，任務(wù)節(jié)點信息將被刪除。

${druid.zk.paths.indexer.base}/status：保存任務(wù)運行的狀態(tài)信息，Overlord通過監(jiān)聽這個目錄獲取任務(wù)的最新運行狀態(tài)。

4.3 內(nèi)存

Druid為了提升元數(shù)據(jù)訪問的效率會把元數(shù)據(jù)同步到內(nèi)存，主要通過定時SQL 查詢訪問方式同步MySQL元數(shù)據(jù)或者使用Apache Curator Recipes實時同步Zookeeper上的元數(shù)據(jù)到內(nèi)存如下圖。

每個進程中的元數(shù)據(jù)不一樣，下面一一介紹一下各個角色進程緩存了哪些數(shù)據(jù)。

Druid進程元數(shù)據(jù)同步方式

4.3.1 Overlord

實時同步Zookeeper目錄(${druid.zk.paths.indexer.base}/announcements)下的數(shù)據(jù)，使用變量RemoteTaskRunner::zkWorkers(類型：Map)存儲，每ZkWorker對應(yīng)一個MM進程，在ZkW orker對象中會實時同步Zookeeper目錄(${druid.zk.paths.indexer.base}/status/${mm_host:port})任務(wù)信息，使用RemoteTaskRunner::runningTasks變量存儲。

默認(rèn)每分鐘同步數(shù)據(jù)庫中druid_tasks active = 1的數(shù)據(jù)，使用變量TaskQueue::tasks(類型：List )存儲，在同步時會把內(nèi)存中的Task列表與最新元數(shù)據(jù)里的Task列表進行比較，得到新增的task列表和刪除的task列表，把新增的Task加到內(nèi)存變量TaskQueue::tasks，清理掉將要被刪除的task

4.3.2 Coordinator

默認(rèn)每1分鐘同步元數(shù)據(jù)庫中druid_segemtns 中列 used=1的segment列表到變量SQLMetadataSegmentManager::dataSourcesSnapshot。

默認(rèn)每1分鐘同步元數(shù)據(jù)庫druid_rules表信 SQLMetadataRuleManager::rules變量使用CoordinatorServerView類(后面會介紹)實時同步${druid.zk.paths.base}/announcements，${druid.zk.paths.base}/segments的數(shù)據(jù)，用于與元數(shù)據(jù)庫中的segment對比，用來判斷哪些segment應(yīng)該加載或刪除。

4.3.3 Historical

會實時同步${druid.zk.paths.base}/loadQueue/${historical_host:port} 下的數(shù)據(jù),進行segment的加載與刪除操作,操作完成之后會主動刪除對應(yīng)的節(jié)點。

Historical通過上報segment信息到${druid.zk.paths.base}/segments來暴露segment。

4.3.4 MiddleManager

會實時同步${druid.zk.paths.indexer.base}/tasks/${mm_host:port}的數(shù)據(jù)，進行任務(wù)(peon)進程的啟動，啟動完成之后會主動刪除對應(yīng)的節(jié)點。

MiddleManager上報segment信息到${druid.zk.paths.base}/segments來暴露segment。

4.3.5 Broker

使用BrokerServerView類實時同步${druid.zk.paths.base}/announcements，${druid.zk.paths.base}/segments的數(shù)據(jù)，構(gòu)建出整個系統(tǒng)的時間軸對象(BrokerServerView::timelines) 作為數(shù)據(jù)查詢的基本依據(jù)。同步過程中類的依賴關(guān)系如下圖。

下層的類對象使用監(jiān)聽上層類對象的方式感知sement的增刪改，并做相應(yīng)的邏輯處理， 會同時監(jiān)聽${druid.zk.paths.base}/announcements和${druid.zk.paths.base}/segments的數(shù)據(jù)的數(shù)據(jù)變化，通過回調(diào)監(jiān)聽器的方式通知到下層類對象。

zk中segment同步到Druid進程過程中對象之間的監(jiān)聽關(guān)系

4.4 本地文件

本地文件的元數(shù)據(jù)主要用于恢復(fù)單個節(jié)點時讀取并加載。

例如：Historical節(jié)點第一個數(shù)據(jù)目錄下的info_dir目錄(如：/data1/druid/segment-cache/info_dir)，保存了該節(jié)點加載的所有segment信息，在Historical進程重啟時會讀取該目錄下的segment元數(shù)據(jù)信息，判斷本地是否有該segment的數(shù)據(jù)，如果沒有就去深度存儲系統(tǒng)(hdfs)下載，數(shù)據(jù)下載完成后會上報segment信息到Zookeeper(路徑：${druid.zk.paths.base}/segments)。

五、Druid 元數(shù)據(jù)相關(guān)業(yè)務(wù)邏輯

由于Druid組件類型比較多，業(yè)務(wù)邏輯比較復(fù)雜，從整體到局部方式，從宏觀到細節(jié)，循序漸進地了解Druid的業(yè)務(wù)邏輯，以便了解Druid元數(shù)據(jù)在業(yè)務(wù)邏輯中發(fā)揮的作用。

5.1 Druid 元數(shù)據(jù)整體業(yè)務(wù)邏輯

前面從整體了解了 Druid 集群各個組件的協(xié)作關(guān)系，下面分別從攝入任務(wù)管理、數(shù)據(jù)攝入、數(shù)據(jù)查詢?nèi)齻€方面的業(yè)務(wù)邏輯來梳理元數(shù)據(jù)在 Druid 集群所起的作用。

5.1.1 攝入任務(wù)管理

攝入數(shù)據(jù)之前需要用戶提交攝入任務(wù)，Overlord根據(jù)任務(wù)的配置會相應(yīng)命令MiddlerManager啟動該任務(wù)的相關(guān)進程(peon進程)用于攝入數(shù)據(jù)，具體流程如下圖中數(shù)據(jù)序號順序執(zhí)行。

任務(wù)提交與管理

下面分別按照上圖中數(shù)字序號順序介紹 Druid 內(nèi)部關(guān)于任務(wù)管理的業(yè)務(wù)邏輯：

① Overlord進程收到任務(wù)提交請求之后，會把任務(wù)信息寫入druid_tasks表，此時字段active等于1。

② Overlord分配任務(wù)給特定的MiddleManager節(jié)點，并把task信息寫入Zookeeper目錄(${druid.zk.paths.indexer.base}/tasks )下。

③ MiddleManager進程監(jiān)聽當(dāng)前節(jié)點在Zookeeper目錄

(${ruid.zk.paths.indexer.base}/task)需要啟動的task信息。

④ MiddleManager會以fork的方式啟動Peon進程(task)此時Peon進程開始攝入數(shù)據(jù)，并把任務(wù)Running狀態(tài)寫入Zookeeper目錄

(${ruid.zk.paths.indexer.base}/status)。

⑤ Overlord會實時監(jiān)聽Zookeeper目錄

(${ruid.zk.paths.indexer.base}/status)獲取任務(wù)運行最新狀態(tài)。

⑥ 任務(wù)完成后Overlord會把task狀態(tài)信息更新到數(shù)據(jù)庫表druid_tasks，此時字段active=0。

5.1.2 數(shù)據(jù)攝入邏輯

Druid數(shù)據(jù)攝入邏輯

下面分別按照上圖中數(shù)字序號順序介紹Druid內(nèi)部關(guān)于數(shù)據(jù)攝入的業(yè)務(wù)邏輯：

① Peon進程在本地生產(chǎn)segment之后，會上傳segment數(shù)據(jù)到深度存儲Hdfs。

② 插入一條segment元數(shù)據(jù)信息到元數(shù)據(jù)druid_segments表中，包括segment數(shù)據(jù)hdfs地址，Interval信息，注意此時used字段為1。

③ Coordinator進程定時拉取druid_segments表中used為1的數(shù)據(jù)。

④ Coordinator進程把segment分配信息寫入Zookeeper目錄：

${druid.zk.paths.base}/loadQueue。

⑤ HIstorical進程監(jiān)聽當(dāng)前節(jié)點在Zookeeper目錄

(${druid.zk.paths.base}/loadQueue)獲取需要加載的segment信息。

⑥ 從Hdfs下載segment數(shù)據(jù)，加載segment。

⑦把已加載的segment的元數(shù)據(jù)信息同步到Zookeeper目錄(${druid.zk.paths.base}/segments)。

5.1.3 數(shù)據(jù)查詢邏輯

數(shù)據(jù)查詢主要涉及到Peon、Historical，Broker三個角色，Broker會根據(jù)client的查詢請求中包含的dataSource和interval信息，篩選出需要查詢的segment，然后Broker作為客戶端從Peon獲取實時數(shù)據(jù)，從Historical獲取歷史數(shù)據(jù)，再根據(jù)查詢要求，將兩部分?jǐn)?shù)據(jù)進一步聚合，如下圖：

Druid數(shù)據(jù)查詢邏輯

5.2 Druid 元數(shù)據(jù)具體業(yè)務(wù)邏輯

有了前面對Druid集群整體認(rèn)識之后，下面更為細致的探討Druid元數(shù)據(jù)在各個組件之間發(fā)揮的作用。

如下圖虛線箭頭表示元數(shù)據(jù)的傳輸，下面按照圖中數(shù)字序號介紹每個虛線箭頭兩端組件與元數(shù)據(jù)存儲介質(zhì)(MySQL、Zookeeper)之間的元數(shù)據(jù)，每條具體從組件對元數(shù)據(jù)存儲介質(zhì)包含讀和寫兩方面來介紹，如下：

Druid元數(shù)據(jù)業(yè)務(wù)邏輯

① 寫：啟動任務(wù)時寫入task信息，提交實時任務(wù)時寫入supervisor信息。讀：broker調(diào)用overlord接口時會查詢不同狀態(tài)下的task信息，進程重啟時恢復(fù)supervisor信息。

② 寫：分配任務(wù)到MiddleManager時，寫入任務(wù)信息。讀：同步正在運行任務(wù)的狀態(tài)信息。

③ 寫：寫入當(dāng)前節(jié)點任務(wù)狀態(tài)信息到Zookeeper，讀：讀取帶啟動或終止任務(wù)信息。

④ 寫：任務(wù)啟動后上報實時segment信息。

⑤ 讀：coordinator定時讀取字段used=1的segment列表信息。

⑥ 寫：coordinator分配的segment信息，讀：已分配的segment列表信息。

⑦ 寫：已加載完成的segment信息，讀：需要加載的segment信息。

⑧ 讀：加載完成的segment信息，作為數(shù)據(jù)查詢的依據(jù)。

六、總結(jié)

前面以整體到局部、抽象到細節(jié)的方式從四個方面(Druid元數(shù)據(jù)基本概念、Druid整體架構(gòu)、Druid元數(shù)據(jù)存儲介質(zhì)Druid元數(shù)據(jù)相關(guān)業(yè)務(wù)邏輯)介紹了Druid元數(shù)據(jù)在Druid集群中扮演的角色。

Druid 擁有一個多進程，分布式架構(gòu)，每個組件只關(guān)注自己的業(yè)務(wù)邏輯和元數(shù)據(jù)，通過RPC通信或Zookeeper 進行組件之間的解耦，每個 Druid 組件類型都可以獨立配置和擴展，極大提供集群的靈活性，以至于一個組件的中斷不會立即影響其他組件，下面對Druid元數(shù)據(jù)做一個總結(jié)：

• Druid元數(shù)據(jù)存儲介質(zhì)有內(nèi)存、元數(shù)據(jù)庫(MySQL)、Zookeeper、本地文件。
• 元數(shù)據(jù)庫(MySQL)和本地的元數(shù)據(jù)起到備份、持久化的作用。Zookeeper主要起到元數(shù)據(jù)傳輸橋梁，實時保存元數(shù)據(jù)的作用，同時把元數(shù)據(jù)同步到內(nèi)存，極大提升了Druid數(shù)據(jù)查詢和數(shù)據(jù)攝入的性能，而本地文件的元數(shù)據(jù)主要用于恢復(fù)單個節(jié)點時快速讀取并加載到內(nèi)存。
• 在Druid組件進程中會把Zookeeper和元數(shù)據(jù)庫(MySQL)里的元數(shù)據(jù)分別通過實時同步和定時拉取的方式同步到進程的內(nèi)存中，以提高訪問效率。
• 保存在各個組件進程中內(nèi)存的元數(shù)據(jù)才是當(dāng)前集群中最新最全的元數(shù)據(jù)。