應(yīng)用性能管理的本質(zhì)就是通過對業(yè)務(wù)數(shù)據(jù)和IT系統(tǒng)性能數(shù)據(jù)的準(zhǔn)確抓取和深度分析，為企業(yè)業(yè)務(wù)和IT的可持續(xù)發(fā)展提供平臺(tái)支撐。而云智慧透視寶產(chǎn)品在得到越 來越多客戶認(rèn)可的同時(shí)，業(yè)務(wù)數(shù)據(jù)也在急劇增加，無論是數(shù)據(jù)存儲(chǔ)還是數(shù)據(jù)查詢，都會(huì)給原有透視寶架構(gòu)帶來較大壓力。

經(jīng)過反復(fù)挑選，云智慧透視寶選擇了用于大數(shù)據(jù)實(shí)時(shí)查詢和分析的高容錯(cuò)、高性能開源分布式系統(tǒng)Druid，接下來就由透視寶開發(fā)工程師Ilucky為我們詳細(xì)解讀，云智慧是如何利用Druid實(shí)現(xiàn)數(shù)據(jù)聚合的。

大數(shù)據(jù)的挑戰(zhàn)

由于數(shù)據(jù)量的激增，云智慧透視寶后端數(shù)據(jù)處理系統(tǒng)主要面臨兩方面問題：

首先，在數(shù)據(jù)存儲(chǔ)方面，因?yàn)橄到y(tǒng)需要保存所有原始數(shù)據(jù)，每天十幾TB，甚至幾十TB的數(shù)據(jù)量，直接導(dǎo)致了資源需求和運(yùn)營成本的增加；

其次，在數(shù)據(jù)查詢方面，如果查詢是建立在所有原始數(shù)據(jù)集的基礎(chǔ)上，那么對機(jī)器的cpu和內(nèi)存要求就會(huì)非常高。

那么Druid會(huì)幫我們解決這些問題嗎？！答案是肯定的，使用Druid對原始數(shù)據(jù)進(jìn)行聚合，會(huì)顯著的減少數(shù)據(jù)的存儲(chǔ)，同時(shí)借鑒搜索架構(gòu)的思想，Druid創(chuàng)建不變的數(shù)據(jù)快照，為分析查詢提供極優(yōu)的數(shù)據(jù)結(jié)構(gòu)來存儲(chǔ)，這樣會(huì)明顯提高查詢效率。

        Druid基本概念

        Druid是一個(gè)為大型冷數(shù)據(jù)集上實(shí)時(shí)探索查詢而設(shè)計(jì)的開源數(shù)據(jù)分析和存儲(chǔ)系統(tǒng)，提供低延時(shí)(實(shí)時(shí))的數(shù)據(jù)接入，靈活的數(shù)據(jù)探索以及高速的數(shù)據(jù)聚合(存儲(chǔ)和查詢)。

        保存到Druid的數(shù)據(jù)由三部分組成：

l Timestamp列：數(shù)據(jù)的時(shí)間戳列，所有的查詢都是以時(shí)間為中心。

l Dimension列：數(shù)據(jù)的維度列，用于過濾數(shù)據(jù)。

l Metric列：數(shù)據(jù)的聚合列，用于聚合數(shù)據(jù)，支持包括sum，count，min和max等計(jì)算。

        接下來為大家介紹Druid的幾個(gè)基本概念：

l 聚合：數(shù)據(jù)按照時(shí)間戳列、維度列、聚合列和聚合粒度進(jìn)行歸并的過程，稱之為聚合。

l 聚合粒度：接收到多長時(shí)間的數(shù)據(jù)歸并為一條，稱之為聚合粒度。

l Datasource：數(shù)據(jù)源，相當(dāng)于關(guān)系型數(shù)據(jù)庫里面表的概念。

l Segment：Druid用Segment文件保存數(shù)據(jù)，Segment包含著某個(gè)Datasource一段時(shí)間內(nèi)的數(shù)據(jù)。

l Datasource和Segment之間的關(guān)系：Segment=Datasource_interval_version_partitionNumber。

        從這個(gè)關(guān)系中不難發(fā)現(xiàn)segment也可以分區(qū)(partitonNumber)，就像kafka的topic一樣。其實(shí)segment不僅可以分區(qū)，并且與kafka的topic一樣，也有副本的概念。

        下面結(jié)合透視寶的業(yè)務(wù)場景舉個(gè)例子，消化一下上面的概念：我們在Druid上創(chuàng)建了一個(gè)叫做cpu的datasource，他的維度列是 account_id(用戶唯一標(biāo)識(shí))和host_id（主機(jī)唯一標(biāo)識(shí)），聚合列是cpuUser,cpuSys,cpuIdle和cpuWait，聚合 計(jì)算包括sum和count,聚合粒度是30分鐘。

         按照如上的方式對cpu數(shù)據(jù)進(jìn)行聚合后，每30分鐘一組account_id和host_id只會(huì)對應(yīng)一條數(shù)據(jù)，這條數(shù)據(jù)記錄了我們每個(gè)聚合列的sum 值和count值。這樣，當(dāng)我們在查詢主機(jī)數(shù)-最近1天(7天)的cpu數(shù)據(jù)時(shí)，可以在這個(gè)聚合結(jié)果的基礎(chǔ)上再次進(jìn)行聚合查詢。元數(shù)據(jù)數(shù)據(jù)量大大減小了， 查詢效率是不是就提高了！

         Druid工作流程

        一個(gè)Druid集群有各種類型的節(jié)點(diǎn)（Node）組成，每種節(jié)點(diǎn)都被設(shè)計(jì)來做某組事情，這樣的設(shè)計(jì)可以隔離關(guān)注并簡化整個(gè)系統(tǒng)的復(fù)雜度。Druid包含如 下節(jié)點(diǎn)：overlord節(jié)點(diǎn)，middlemanager節(jié)點(diǎn)，broker節(jié)點(diǎn)，historical節(jié)點(diǎn)和coordinator節(jié)點(diǎn)，在設(shè)計(jì)時(shí)充 分考慮到了高可用性，各種節(jié)點(diǎn)掛掉都不會(huì)使Druid停止工作。

        下面簡單介紹下Druid不同節(jié)點(diǎn)的作用：

        overlord節(jié)點(diǎn)：接 收和分發(fā)任務(wù)。上面說到了在Druid上創(chuàng)建了一個(gè)叫做cpu的datasource，其實(shí)暫時(shí)可以理解為創(chuàng)建了一個(gè)任務(wù)，目的是告訴overlord節(jié) 點(diǎn)這個(gè)datasource/任務(wù)處理的數(shù)據(jù)描述（模板）是什么，描述包括數(shù)據(jù)的維度列，聚合列，聚合粒度，segment生成時(shí)間等等參數(shù)，任務(wù)會(huì)按照 這個(gè)描述對接收到的數(shù)據(jù)進(jìn)行聚合。overlord節(jié)點(diǎn)接到任務(wù)后并不會(huì)直接處理任務(wù)，而是分發(fā)給middlemaanger節(jié)點(diǎn)。

        middlemanager節(jié)點(diǎn)：管理任務(wù)。middlemanager接收到overlord分發(fā)給他的任務(wù)，會(huì)繼續(xù)分發(fā)任務(wù)，分發(fā)給誰呢？分發(fā)給peon，這才是真正做聚合任務(wù)的同志。

[[168664]]

        從這張圖可以看出overlord是如何分發(fā)任務(wù)給middlemanager的，通過zookeeper（下面會(huì)提到，druid的依賴，一些分布式服 務(wù)都會(huì)依賴它，kafka，hbase等等）。peon完成數(shù)據(jù)聚合任務(wù)后，會(huì)生成一個(gè)segment文件，并且會(huì)將segment文件永久保存到 deepstorage，deepstroage也是Druid的一個(gè)依賴，Druid依賴deepstorage對segment做永久存儲(chǔ)，常用的 deepstorage有s3和hdfs。

        broker節(jié)點(diǎn)：響應(yīng)外部的查詢請求。broker節(jié)點(diǎn)會(huì)根據(jù)請求參數(shù)（時(shí)間段參數(shù)等），決定從哪里獲取數(shù)據(jù)。

        historical節(jié)點(diǎn)：存儲(chǔ)歷史數(shù)據(jù)。broker節(jié)點(diǎn)響應(yīng)外部的查詢請求，會(huì)從某個(gè)或者某些historical節(jié)點(diǎn)查詢數(shù)據(jù)(如果沒有，從deepstorage加載）。

        coordinator節(jié)點(diǎn)：管理集群中的Segment操作(下載，刪除等)。

        每個(gè)節(jié)點(diǎn)都提供了很多api，可以通過api查看各個(gè)節(jié)點(diǎn)的狀態(tài)信息等，例如查看overlord節(jié)點(diǎn)的狀態(tài)信息，如下圖：

        另外，還可以通過overlord節(jié)點(diǎn)提供的web頁面查看任務(wù)的狀態(tài)，以及middlemanager的數(shù)量，

        和每個(gè)middlemanager可以容納的peon數(shù)量等等。

[[168665]]

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

        這個(gè)流程圖中沒有畫出overlord和middlemaanger節(jié)點(diǎn)，圖中的realtime節(jié)點(diǎn)我們暫時(shí)沒有用到，云智慧用的是 tranquility（a high level data producer library for Druid）。通過我們自己的程序，對數(shù)據(jù)進(jìn)行清洗后，借助tranquility發(fā)送數(shù)據(jù)給overlord，看圖：

        上面對Druid節(jié)點(diǎn)做了一下大概的介紹，要想讓Druid正常工作，除了運(yùn)行Druid自身的這些節(jié)點(diǎn)外，還需要借助三個(gè)依賴。

l deepstorage：用來永久存儲(chǔ)segment數(shù)據(jù)，一般是s3和hdfs。

l zookeeper：用來管理集群狀態(tài)，保證集群內(nèi)的數(shù)據(jù)統(tǒng)一。

l metadata storage：用來保存一些元數(shù)據(jù)，規(guī)則數(shù)據(jù)，配置數(shù)據(jù)等。

        deepstorage功能很單一不用多說，那么zookeeper和metadata storage在Druid工作流程中，起著什么樣的作用呢？以聚合數(shù)據(jù)和查詢數(shù)據(jù)簡單介紹一下zookeeper和metadata storage在Druid中的工作。

        聚合數(shù)據(jù)： peon在做聚合任務(wù)的時(shí)候會(huì)周期性的告訴zookeeper，正在為哪個(gè)datasource，生成哪個(gè)時(shí)間段的數(shù)據(jù)，即生成哪個(gè)segment，當(dāng)聚 合任務(wù)執(zhí)行完成后，peon會(huì)將segment生成到deepstroage，同時(shí)會(huì)將生成的segment的描述信息保存到metadata storage中，并同時(shí)通知zookeeper。

        查詢數(shù)據(jù)：broker接收數(shù)據(jù)的查詢請求后，會(huì)根據(jù)請求參數(shù)，通過zookeeper分析請求的segment在哪里：是在peon上 (middlemaanger中還沒有完全生成一個(gè)segment，即熱數(shù)據(jù)/實(shí)時(shí)數(shù)據(jù))，還是在某個(gè)或者某些歷史節(jié)點(diǎn)中，分析出結(jié)果后分別向?qū)?yīng)節(jié)點(diǎn)發(fā) 出請求，獲取數(shù)據(jù)。broker獲取各個(gè)節(jié)點(diǎn)返回過來的數(shù)據(jù)，再次進(jìn)行數(shù)據(jù)歸并并最終返回給請求者。

           metadata database的作用又是什么呢？peon完成數(shù)據(jù)聚合后，首先將其保存到deepstorage中，同時(shí)會(huì)將聚合的產(chǎn)物segment描述信息(在 hdfs中的保存路徑)保存到metadata database中，并通知zookeeper。注意：Coordinator和historical節(jié)點(diǎn)一直和zookeeper保持著連 接，Coordinator還和metadata database保持著連接。當(dāng)Coordinator發(fā)現(xiàn)zookeeper上有一個(gè)新的segment生成后，會(huì)通知historical節(jié)點(diǎn)去加載 這個(gè)數(shù)據(jù)，通知方式依然是借助zookeeper。

        前文說到Coordinator節(jié)點(diǎn)管理segment的下載和刪除，是發(fā)生在聚合數(shù)據(jù)的過程中，peon完成數(shù)據(jù)聚合后會(huì)通知zookeeper，而 Coordinator一直監(jiān)控著zookeeper，當(dāng)發(fā)現(xiàn)有一個(gè)新的segment生成后，會(huì)通過zookeeerp通知某個(gè)historical節(jié) 點(diǎn)去下載segment。而刪除是因?yàn)镠istorical節(jié)點(diǎn)容量是一定的（可配置的），如果超過了容量，他會(huì)刪除過期數(shù)據(jù)或舊數(shù)據(jù)。

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

        Druid在透視寶的作用

        Druid是如何從透視寶接入數(shù)據(jù)的呢？如下圖所示：

目前，我們有兩個(gè)服務(wù)，一個(gè)服務(wù)是連接kafka和 Druid，即從kafka消費(fèi)數(shù)據(jù)發(fā)送給Druid。一個(gè)是連接broker，并對外提供api，供前端查詢數(shù)據(jù)做報(bào)表展示。通過使用Druid，大大 節(jié)省了透視寶的數(shù)據(jù)存儲(chǔ)的空間，提升了數(shù)據(jù)查詢的效率，更好的滿足客戶大數(shù)據(jù)分析的需求。今天的分享也到此結(jié)束，希望能給你的工作帶來一點(diǎn)幫助。