面臨大數據挑戰 透視寶如何使用Druid實現數據聚合
應用性能管理的本質就是通過對業務數據和IT系統性能數據的準確抓取和深度分析，為企業業務和IT的可持續發展提供平臺支撐。而云智慧透視寶產品在得到越 來越多客戶認可的同時，業務數據也在急劇增加，無論是數據存儲還是數據查詢，都會給原有透視寶架構帶來較大壓力。
經過反復挑選，云智慧透視寶選擇了用于大數據實時查詢和分析的高容錯、高性能開源分布式系統Druid，接下來就由透視寶開發工程師Ilucky為我們詳細解讀，云智慧是如何利用Druid實現數據聚合的。
大數據的挑戰
由于數據量的激增，云智慧透視寶后端數據處理系統主要面臨兩方面問題：
首先，在數據存儲方面，因為系統需要保存所有原始數據，每天十幾TB，甚至幾十TB的數據量，直接導致了資源需求和運營成本的增加；
其次，在數據查詢方面，如果查詢是建立在所有原始數據集的基礎上，那么對機器的cpu和內存要求就會非常高。
那么Druid會幫我們解決這些問題嗎？！答案是肯定的，使用Druid對原始數據進行聚合，會顯著的減少數據的存儲，同時借鑒搜索架構的思想，Druid創建不變的數據快照，為分析查詢提供極優的數據結構來存儲，這樣會明顯提高查詢效率。
Druid基本概念
Druid是一個為大型冷數據集上實時探索查詢而設計的開源數據分析和存儲系統，提供低延時(實時)的數據接入，靈活的數據探索以及高速的數據聚合(存儲和查詢)。
保存到Druid的數據由三部分組成：
l Timestamp列：數據的時間戳列，所有的查詢都是以時間為中心。
l Dimension列：數據的維度列，用于過濾數據。
l Metric列：數據的聚合列，用于聚合數據，支持包括sum，count，min和max等計算。
接下來為大家介紹Druid的幾個基本概念：
l 聚合：數據按照時間戳列、維度列、聚合列和聚合粒度進行歸并的過程，稱之為聚合。
l 聚合粒度：接收到多長時間的數據歸并為一條，稱之為聚合粒度。
l Datasource：數據源，相當于關系型數據庫里面表的概念。
l Segment：Druid用Segment文件保存數據，Segment包含著某個Datasource一段時間內的數據。
l 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自身的這些節點外，還需要借助三個依賴。
l deepstorage：用來永久存儲segment數據，一般是s3和hdfs。
l zookeeper：用來管理集群狀態，保證集群內的數據統一。
l 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，大大 節省了透視寶的數據存儲的空間，提升了數據查詢的效率，更好的滿足客戶大數據分析的需求。今天的分享也到此結束，希望能給你的工作帶來一點幫助。
