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

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

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

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

場景一：小米統計服務

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

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

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

場景二：廣告平臺實時數據分析

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

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

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

• 廣告媒體分析數據：各個廣告媒體的請求、展現等數據。

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

1. 關于查詢界面

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

2. 關于查詢效率

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

3. 部署情況

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

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

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