[druid]大數據挑戰——如何使用Druid實現數據聚合

-- 知道你爲何懼組件不少的一些開源軟件? 由於缺少閱讀能力.

最近我接手了druid+kafka+elk一套等日誌系統. 可是我對druid很陌生, 周旋了幾天, 官網文檔快速開始照着作了下. 看了這個文章才大概明白套路.

入庫: kafka-->tranquility-->overload-->middleManager

查詢: broker-->historical-->deepdrive
coordinator是管理segment的(下載刪除等)

須要注意的是config/_common裏的配置

metadata
zk
deepstorage的配置

deepstorage數據保存多久的配置在 history配置裏.

官網: http://druidio.cn/

參考: https://cnodejs.org/topic/57918503f0d4b46026ba53db
這個文檔寫的很棒. 介紹druid

應用性能管理的本質就是經過對業務數據和IT系統性能數據的準確抓取和深度分析，爲企業業務和IT的可持續發展提供平臺支撐。而云智慧透視寶產品在獲得愈來愈多客戶承認的同時，業務數據也在急劇增長，不管是數據存儲仍是數據查詢，都會給原有透視寶架構帶來較大壓力。

通過反覆挑選，雲智慧透視寶選擇了用於大數據實時查詢和分析的高容錯、高性能開源分佈式系統Druid，接下來就由透視寶開發工程師lucky爲咱們詳細解讀，雲智慧是如何利用Druid實現數據聚合的。

大數據的挑戰—

因爲數據量的激增，雲智慧透視寶後端數據處理系統主要面臨兩方面問題：
首先，在數據存儲方面，由於系統須要保存全部原始數據，天天十幾TB，甚至幾十TB的數據量，直接致使了資源需求和運營成本的增長；

其次，在數據查詢方面，若是查詢是創建在全部原始數據集的基礎上，那麼對機器的cpu和內存要求就會很是高。

那麼Druid會幫咱們解決這些問題嗎？！答案是確定的，使用Druid對原始數據進行聚合，會顯著的減小數據的存儲，同時借鑑搜索架構的思想，Druid建立不變的數據快照，爲分析查詢提供極優的數據結構來存儲，這樣會明顯提升查詢效率。

Druid基本概念—

Druid是一個爲大型冷數據集上實時探索查詢而設計的開源數據分析和存儲系統，提供低延時(實時)的數據接入，靈活的數據探索以及高速的數據聚合(存儲和查詢)。

保存到Druid的數據由三部分組成：

♦ Timestamp列：數據的時間戳列，全部的查詢都是以時間爲中心。

♦ Dimension列：數據的維度列，用於過濾數據。

♦ Metric列：數據的聚合列，用於聚合數據，支持包括sum，count，min和max等計算。

接下來爲你們介紹Druid的幾個基本概念：

♦ 聚合：數據按照時間戳列、維度列、聚合列和聚合粒度進行歸併的過程，稱之爲聚合。

♦ 聚合粒度：接收到多長時間的數據歸併爲一條，稱之爲聚合粒度。

♦ Datasource：數據源，至關於關係型數據庫裏面表的概念。

♦ Segment：Druid用Segment文件保存數據，Segment包含着某個Datasource一段時間內的數據。

♦ Datasource和Segment之間的關係：Segment=Datasource_interval_version_partitionNumber。

從這個關係中不難發現segment也能夠分區(partitonNumber)，就像kafka的topic同樣。其實segment不只能夠分區，而且與kafka的topic同樣，也有副本的概念。

下面結合透視寶的業務場景舉個例子，消化一下上面的概念：咱們在Druid上建立了一個叫作cpu的datasource，他的維度列是account_id(用戶惟一標識)和host_id（主機惟一標識），聚合列是cpuUser,cpuSys,cpuIdle和cpuWait，聚合計算包括sum和count,聚合粒度是30分鐘。

按照如上的方式對cpu數據進行聚合後，每30分鐘一組account_id和host_id只會對應一條數據，這條數據記錄了咱們每一個聚合列的sum值和count值。這樣，當咱們在查詢主機數-最近1天(7天)的cpu數據時，能夠在這個聚合結果的基礎上再次進行聚合查詢。元數據數據量大大減少了，查詢效率是否是就提升了！

Druid工做流程—

一個Druid集羣有各類類型的節點（Node）組成，每種節點都被設計來作某組事情，這樣的設計能夠隔離關注並簡化整個系統的複雜度。Druid包含以下節點：overlord節點，middlemanager節點，broker節點，historical節點和coordinator節點，在設計時充分考慮到了高可用性，各類節點掛掉都不會使Druid中止工做。

下面簡單介紹下Druid不一樣節點的做用：

overlord節點：接收和分發任務。上面說到了在Druid上建立了一個叫作cpu的datasource，其實暫時能夠理解爲建立了一個任務，目的是告訴overlord節點這個datasource/任務處理的數據描述（模板）是什麼，描述包括數據的維度列，聚合列，聚合粒度，segment生成時間等等參數，任務會按照這個描述對接收到的數據進行聚合。overlord節點接到任務後並不會直接處理任務，而是分發給middlemaanger節點。

middlemanager節點：管理任務。middlemanager接收到overlord分發給他的任務，會繼續分發任務，分發給誰呢？分發給peon，這纔是真正作聚合任務的同志。

從這張圖能夠看出overlord是如何分發任務給middlemanager的，經過zookeeper（下面會提到，druid的依賴，一些分佈式服務都會依賴它，kafka，hbase等等）。peon完成數據聚合任務後，會生成一個segment文件，而且會將segment文件永久保存到deepstorage，deepstroage也是Druid的一個依賴，Druid依賴deepstorage對segment作永久存儲，經常使用的deepstorage有s3和hdfs。

broker節點：響應外部的查詢請求。broker節點會根據請求參數（時間段參數等），決定從哪裏獲取數據。

historical節點：存儲歷史數據。broker節點響應外部的查詢請求，會從某個或者某些historical節點查詢數據(若是沒有，從deepstorage加載）。

coordinator節點：管理集羣中的Segment操做(下載，刪除等)。

每一個節點都提供了不少api，能夠經過api查看各個節點的狀態信息等，例如查看overlord節點的狀態信息，以下圖：

另外，還能夠經過overlord節點提供的web頁面查看任務的狀態，以及middlemanager的數量，

和每一個middlemanager能夠容納的peon數量等等。

** 下面是官方提供的Druid工做流程圖：**

這個流程圖中沒有畫出overlord和middlemaanger節點，圖中的realtime節點咱們暫時沒有用到，雲智慧用的是tranquility（a high level data producer library for Druid）。經過咱們本身的程序，對數據進行清洗後，藉助tranquility發送數據給overlord，看圖：

上面對Druid節點作了一下大概的介紹，要想讓Druid正常工做，除了運行Druid自身的這些節點外，還須要藉助三個依賴。

♦ deepstorage：用來永久存儲segment數據，通常是s3和hdfs。

♦ zookeeper：用來管理集羣狀態，保證集羣內的數據統一。

♦ metadata storage：用來保存一些元數據，規則數據，配置數據等。

deepstorage功能很單一不用多說，那麼zookeeper和metadata storage在Druid工做流程中，起着什麼樣的做用呢？以聚合數據和查詢數據簡單介紹一下zookeeper和metadata storage在Druid中的工做。

聚合數據： peon在作聚合任務的時候會週期性的告訴zookeeper，正在爲哪一個datasource，生成哪一個時間段的數據，即生成哪一個segment，當聚合任務執行完成後，peon會將segment生成到deepstroage，同時會將生成的segment的描述信息保存到metadata storage中，並同時通知zookeeper。

查詢數據：broker接收數據的查詢請求後，會根據請求參數，經過zookeeper分析請求的segment在哪裏：是在peon上(middlemaanger中尚未徹底生成一個segment，即熱數據/實時數據)，仍是在某個或者某些歷史節點中，分析出結果後分別向對應節點發出請求，獲取數據。broker獲取各個節點返回過來的數據，再次進行數據歸併並最終返回給請求者。

metadata database的做用又是什麼呢？peon完成數據聚合後，首先將其保存到deepstorage中，同時會將聚合的產物segment描述信息(在hdfs中的保存路徑)保存到metadata database中，並通知zookeeper。注意：Coordinator和historical節點一直和zookeeper保持着鏈接，Coordinator還和metadata database保持着鏈接。當Coordinator發現zookeeper上有一個新的segment生成後，會通知historical節點去加載這個數據，通知方式依然是藉助zookeeper。

前文說到Coordinator節點管理segment的下載和刪除，是發生在聚合數據的過程當中，peon完成數據聚合後會通知zookeeper，而Coordinator一直監控着zookeeper，當發現有一個新的segment生成後，會經過zookeeerp通知某個historical節點去下載segment。而刪除是由於Historical節點容量是必定的（可配置的），若是超過了容量，他會刪除過時數據或舊數據。

Druid官方提供的流程圖以下：

Druid在透視寶的做用—

Druid是如何從透視寶接入數據的呢？以下圖所示：

目前，咱們有兩個服務，一個服務是鏈接kafka和Druid，即從kafka消費數據發送給Druid。一個是鏈接broker，並對外提供api，供前端查詢數據作報表展現。經過使用Druid，大大節省了透視寶的數據存儲的空間，提高了數據查詢的效率，更好的知足客戶大數據分析的需求。今天的分享也到此結束，但願能給你的工做帶來一點幫助。