Druid 在小米公司部分技術實踐

引言：Druid作為一款開源的實時大數(shù)據(jù)分析軟件，自誕生以來，憑借自己優(yōu)秀的特質，不僅逐漸在技術圈收獲了越來越多的知名度與口碑，并且陸續(xù)成為了很多技術團隊解決方案中的關鍵一環(huán)，從而真正在很多公司的技術棧中贏得了一席之地。
　　 本文通過對小米公司技術團隊對Druid 的實踐案例與經驗的介紹，讓大家對Druid有更加全面和深入的了解，希望能夠幫助你事半功倍地學習Druid 這項年輕的技術。
　　 本文選自《Druid實時大數(shù)據(jù)分析原理與實踐》。

　　小米公司正式成立于2010 年4 月，是一家專注于高端智能手機、互聯(lián)網電視以及智能家居生態(tài)鏈建設的創(chuàng)新型科技企業(yè)。
　　“讓每個人都能享受科技的樂趣”是小米公司的愿景。小米公司應用互聯(lián)網模式開發(fā)產品，用工匠精神做產品，用互聯(lián)網模式節(jié)省了中間環(huán)節(jié)，致力于讓全球每個人都能享用來自中國的優(yōu)質科技產品。
　　　　　　　　　　　
　　　　　　　　　　　　　　　　　　　　　小米大云平臺技術架構示意圖

　　Druid 在數(shù)據(jù)分析層幫助實時收集海量的事件數(shù)據(jù)，快速進行商業(yè)分析，在多個場景中都有應用。這里介紹Druid 在小米統(tǒng)計產品和小米廣告平臺中的部分技術實踐。

場景一：小米統(tǒng)計服務

　　小米統(tǒng)計是小米為App 開發(fā)者提供的移動應用數(shù)據(jù)統(tǒng)計服務，幫助開發(fā)者通過數(shù)據(jù)了解應用發(fā)展狀況、渠道推廣效果和用戶參與情況等信息，使開發(fā)者可以更好地優(yōu)化體驗和運營，促進產品不斷發(fā)展進步。小米統(tǒng)計的入口是#xiaomi.com，服務界面如下。
　　　　　　　　　　　　　　　
　　　　　　　　　　　　　　　　　　　　　小米統(tǒng)計服務界面

　　實時的數(shù)據(jù)分析重要需求，在產品發(fā)展過程中，也經歷了幾個技術階段，這幾個階段并非完全互斥，而是應用于不同的場景和時間。
　　第一階段：數(shù)據(jù)存儲在Hadoop 中，通過MapReduce 的腳本進行分析和處理。有一部分復雜的任務會以天為單位被執(zhí)行，并且最后會將結果寫入到如MySQL 的RDBMS 中。
　　第二階段：在業(yè)務發(fā)展過程中MySQL 很快變成了瓶頸，有兩個原因，一是數(shù)據(jù)庫的Schema 更改成本高，新業(yè)務不斷需要增加新列和新表，流程煩瑣而且需要進行Schema 設計；二是在進行大量寫操作的情況下，數(shù)據(jù)庫的負載增加會導致數(shù)據(jù)庫的讀性能下降，而且偶爾有死鎖的現(xiàn)象。為了解決這些問題，引入了HBase 作為主要存儲數(shù)據(jù)庫，利用HBase 的列族，方便增加數(shù)據(jù)列。另外，HBase 的可用性也高于MySQL。
　　第三階段：為了改進數(shù)據(jù)的實時性，后期增加了Storm 分布式計算模式，使用Storm 可以方便地進行各種復雜的數(shù)據(jù)處理，各種聚合和處理需要通過程序實現(xiàn)，增加一個數(shù)據(jù)維度，改動比較大，需要從上游到下游整體修改。這種方式的優(yōu)點是可靠性好，數(shù)據(jù)處理能力強，可以進行各種角度的優(yōu)化。
　　第四階段：小米統(tǒng)計的很多數(shù)據(jù)查詢都是選擇一些指標和過濾條件，很多場景類似于傳統(tǒng)的數(shù)據(jù)倉庫，因此引入Druid 處理一些標準報告的實時數(shù)據(jù)查詢場景。數(shù)據(jù)流會依次通過Kaa 和Tranquility，最后進入Druid 集群。Druid 集群最終能提供最近一天的數(shù)據(jù)查詢功能，并且允許用戶直接訪問。
　　　　　　　　　　　　　　　　　
　　　　　　　　　　　　　　　　　　　　　　小米統(tǒng)計數(shù)據(jù)流

　　Druid 作為一種實時分析數(shù)據(jù)庫，提升了小米大數(shù)據(jù)平臺和商業(yè)產品部門的實時數(shù)據(jù)分析能力。

場景二：廣告平臺實時數(shù)據(jù)分析

　　Druid 來源于廣告業(yè)務，小米廣告平臺也利用Druid 進行實時的數(shù)據(jù)分析，幫助實時分析線上的各種維度的變化，包括上線部署的實時監(jiān)控分析、A/B 測試的效果查詢、一些細粒度的數(shù)據(jù)分析。
　　對廣告數(shù)據(jù)有兩條路徑進行處理：一條是實時的數(shù)據(jù)流，通過Druid 處理，主要是針對內部的實時數(shù)據(jù)分析需求；另一條是通過Mini-batch 方式。
　　數(shù)據(jù)的DataSource（數(shù)據(jù)源）包括：

• 小米廣告交易平臺（Xiaomi Ad Exchange, MAX）：廣告流量的調度管理平臺。

• 廣告平臺的計費分析模塊：廣告主的計費、各種維度數(shù)據(jù)。

• 廣告媒體分析數(shù)據(jù)：各個廣告媒體的請求、展現(xiàn)等數(shù)據(jù)。

比如對于廣告計費分析模塊，Druid 會包括實時的廣告主計費信息，這些數(shù)據(jù)用于內部的數(shù)據(jù)分析，不用于廣告主投放平臺。廣告主投放平臺使用Mini-batch 方式，通過可重放的方式更新和聚合數(shù)據(jù)結果。
　　在使用Druid 的過程中也會碰到一些問題。

1. 關于查詢界面

　　Druid 的查詢語言還不是特別友好，在第一階段部署Druid 后，我們開發(fā)了一套Druid查詢接口，主要是滿足業(yè)務的需求，初期效果還好，但是隨著數(shù)據(jù)源的增加，每次增加數(shù)據(jù)源都需要額外開發(fā)一些界面，增加維度，也需要修改前端工程，因此效率也不高。在后期的工作中，嘗試了Pivot 工具，功能使用方便，漸漸代替了自定義的查詢界面。

2. 關于查詢效率

　　Druid 的大部分時間性能表現(xiàn)都很好，但是如果進行長時間范圍的查詢，系統(tǒng)會變得非常慢。為了解決這個問題，對于頻繁查詢的數(shù)據(jù)源，可以分為兩個部分：一部分是按照分鐘級別聚合的數(shù)據(jù)源，數(shù)據(jù)保持10 天；另一部分是按照小時級別聚合的數(shù)據(jù)源，數(shù)據(jù)保持2年。每天晚上的時候，聚合小時級別的數(shù)據(jù)，這樣可以避開高負載的集群時間。聚合粒度與查詢效率的關系如下。
　　　　　　　　　　　　
　　　　　　　　　　　　　　　　　　　　　　　聚合粒度與查詢效率的關系

3. 部署情況

　　Druid 集群每天處理近百億的事件請求，集群規(guī)模為近10 臺機器，索引服務和歷史節(jié)點數(shù)量相當，機器的數(shù)量隨著事件數(shù)的增長而增加。當數(shù)據(jù)源在某時間數(shù)據(jù)急劇增加時，系統(tǒng)索引文件所占用的CPU 會很高，有時候影響正常的查詢性能。
　　第一階段，我們嘗試在服務層使用流量控制，但是后來放棄了。原因是，數(shù)據(jù)在1 小時后會有過期機制，因此如果有數(shù)據(jù)無法進入系統(tǒng)，那么這些數(shù)據(jù)可能丟失。因此，我們還是盡量讓數(shù)據(jù)進入Druid 系統(tǒng)，雖然偶爾會帶來系統(tǒng)的峰值壓力。
基于Druid 的架構和數(shù)據(jù)流如下。
　　　　　　　　　　　　　
　　　　　　　　　　　　　　　　　　　　　　　基于Druid 的架構和數(shù)據(jù)流

　　“紙上得來終覺淺，絕知此事要躬行”，如同學習其他技術一樣，掌握Druid 最好的方法就是實踐，因此大家在對Druid 有了一定的認識后應該盡快上手練習，并且爭取早日將其應用到自己的實際工作中，在戰(zhàn)斗中學習戰(zhàn)斗，讓在實踐中碰到的問題驅動自己對Druid 技術的學習和理解。

　　本文選自《Druid實時大數(shù)據(jù)分析原理與實踐》，點此鏈接可在博文視點官網查看此書。
　　　　　　　　　　　　　　　　　　　　
　　想及時獲得更多精彩文章，可在微信中搜索“博文視點”或者掃描下方二維碼并關注。