Druid + Grafana 應用實踐


談到大數據,大家首先想到的肯定是Hadoop,近年來互聯網技術的快速增長催生了各類大體量數據的爆發,Hadoop最大的貢獻在於幫助企業將那些低價值的事件流數據轉化為高價值的聚合數據,為企業的經營決策提供數據支撐。但Hadoop擅長的是存儲和獲取大規模數據,但是它並不提供任何性能上的保證。從這個角度來講,我們可以把Hadoop看作是一個很好的后端、批量處理和數據倉庫系統。在一個需要高並發並且保證查詢性能和數據可用性的場景下,Hadoop並不能滿足需求, 因此而引出了我們今天要介紹的主角: Druid集群。

Druid是一套基於大數據集之上做實時統計分析而設計的開源系統,主要特點包含分布式、列存儲、內存數據庫、實時分析。當前版本 0.10.0 (官網:http://druid.io), 主要作者:楊仿金同學已回到中國,另一老外成立自己的公司,在Druid集群之上提供商業化服務,包含PloySQL、Pivot等增值化組件。

在五橫一豎常規的大數據架構中,從數據采集、數據處理、數據分析、數據訪問、數據應用每一層均提供N多可供選擇的組件包,可謂是“百花齊放”、能讓您選花了眼。Druid 主要優勢在於實時流式數據的處理與高效OLAP分析,與其它開源組件優劣對比見上圖。

Druid集群主要包含了以下幾類角色:

Ø  RealNode:封裝了導入和查詢事件數據的功能,經由這些節點導入的事件數據可以立刻被查詢

Ø  HistoricalNode:封裝了加載和處理由實時節點創建的不可變數據塊(segment)的功能。在很多現實世界的工作流程中,大部分導入到Druid集群中的數據都是不可變的,因此,歷史節點通常是Druid集群中的主要工作組件。

Ø  BrokerNode:扮演着歷史節點和實時節點的查詢路由的角色。

Ø  CoordinatorNode:主要負責數據的管理和在歷史節點上的分布。協調節點告訴歷史節點加載新數據、卸載過期數據、復制數據、和為了負載均衡移動數據。

Ø  除了上面介紹的節點角色外,Druid還依賴於外部的三個組件:ZooKeeper, Metadata Storage, Deep Storage,數據與查詢流的交互如上圖,簡述如下:

ü  ① 實時數據寫入到實時節點,會創建索引結構的Segment

ü  ② 實時節點的Segment經過一段時間會轉存到DeepStorage

ü  ③ 元數據寫入MySQL; 實時節點轉存的Segment會在ZooKeeper中新增一條記錄

ü  ④ 協調節點從MySQL獲取元數據,比如schema信息(維度列和指標列)

ü  ⑤ 協調節點監測ZK中有新分配/要刪除的Segment,寫入ZooKeeper信息:歷史節點需要加載/刪除Segment

ü  ⑥ 歷史節點監測ZK, 從ZooKeeper中得到要執行任務的Segment

ü  ⑦ 歷史節點從DeepStorage下載Segment並加載到內存/或者將已經保存的Segment刪除掉

ü  ⑧ 歷史節點的Segment可以用於Broker的查詢路由

實時節點在處理數據導入、持久化、合並和傳送這些階段都是流動的,並且在這些處理階段中不會有任何數據的丟失,數據流圖如上:

Ø  節點啟動於13:47,並且只會接受當前小時和下一小時的事件數據。當事件數據開始導入后,節點會宣布它為13:00到14:00這個時間段的Segment數據提供服務

Ø  每10分鍾(這個時間間隔是可配置的),節點會將內存中的緩存數據刷到磁盤中進行持久化,在當前小時快結束的時候,節點會准備接收14:00到15:00的事件數據,一旦這個情況發生了,節點會准備好為下一個小時提供服務,並且會建立一個新的內存中的索引。

Ø  隨后,節點宣布它也為14:00到15:00這個時段提供一個segment服務。節點並不是馬上就合並13:00到14:00這個時段的持久化索引,而是會等待一個可配置的窗口時間,直到所有的13:00到14:00這個時間段的一些延遲數據的到來。這個窗口期的時間將事件數據因延遲而導致的數據丟失減低到最小。

Ø  在窗口期結束時,節點會合並13:00到14:00這個時段的所有持久化的索引合並到一個獨立的不可變的segment中,並將這個segment傳送走,一旦這個segment在Druid集群中的其他地方加載了並可以查詢了,實時節點會刷新它收集的13:00到14:00這個時段的數據的信息,並且宣布取消為這些數據提供服務。

上圖為我們正式集群DataSource 存儲結構示意圖,所有的NoSQL中都有數據分片的概念,比如ES的分片,HBase的Region,都表示的是數據的存儲介質.為什么要進行分片,因為數據大了,不能都存成一個大文件吧?所以要拆分成小文件以便於快速查詢. 伴隨拆分通常都有合並小文件

 通過實時采集充電日志,以按區域、場站等維度實時分析充電相關的指標分析為場景進行案例分享

分享案例統計維度如上圖

數據流處理示意圖

擴展Grafana可視化組件的數據源插件、UI插件

按區域實時監控每分鍾充電指標,通過選擇左上角的導航面板中不同的區域,觸發Dashboard內其它面板數據刷新

基於場站實時監控,支持全文檢索或選擇高級過濾的方式快速定位電站,選中第一列的小眼睛,行背景變綠,觸發當前電站下面板內其它部件數據刷新。

同樣原理,更細粒度下到終端的實時監控。

歷史年度數據趨勢分析

   大數據需要伴隨着業務的驅動來發揮其應有的價值,需要大家的共同參與來一步步夯實其底層的基礎平台,期待着下一期更精彩的技術分享。

 


免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM