Druid 在小米公司的技術實踐

Druid 作為一款開源的實時大數據分析軟體，自誕生以來，憑藉著自己優秀的特質，逐漸在技術圈收穫了越來越多的知名度與口碑，並陸續成為了很多技術團隊解決方案中的關鍵一環，從而真正在很多公司的技術棧中贏得了一席之地。

在成為Druid 用戶的公司中不乏很多國外赫赫有名的互聯網企業，也包含了很多國內同樣聲名遐邇的知名公司，同時也覆蓋了許多朝氣蓬勃的創業團隊。本文通過對小米公司技術團隊對Druid 的實踐案例與經驗的介紹，讓大家對Druid 有更加全面和深入的了解，希望能夠幫助你事半功倍地學習Druid 這項年輕的技術。

小米公司正式成立於2010 年4 月，是一家專註於高端智能手機、互聯網電視以及智能家居生態鏈建設的創新型科技企業。

「讓每個人都能享受科技的樂趣」是小米公司的願景。小米公司應用互聯網模式開發產品，用工匠精神做產品，用互聯網模式節省了中間環節，致力於讓全球每個人都能享用來自中國的優質科技產品。

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

場景一：小米統計服務

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

實時的數據分析重要需求，在產品發展過程中，也經歷了幾個技術階段，這幾個階段並非完全互斥，而是應用於不同的場景和時間。

第一階段：數據存儲在Hadoop 中，通過MapReduce 的腳本進行分析和處理。有一部分複雜的任務會以天為單位被執行，並且最後會將結果寫入到如MySQL 的RDBMS 中。

第二階段：在業務發展過程中MySQL 很快變成了瓶頸，有兩個原因，一是資料庫的Schema 更改成本高，新業務不斷需要增加新列和新表，流程煩瑣而且需要進行Schema 設計；二是在進行大量寫操作的情況下，資料庫的負載增加會導致資料庫的讀性能下降，而且偶爾有死鎖的現象。為了解決這些問題，引入了HBase 作為主要存儲資料庫，利用HBase 的列族，方便增加數據列。另外，HBase 的可用性也高於MySQL。

第三階段：為了改進數據的實時性，後期增加了Storm 分散式計算模式，使用Storm 可以方便地進行各種複雜的數據處理，各種聚合和處理需要通過程序實現，增加一個數據維度，改動比較大，需要從上游到下游整體修改。這種方式的優點是可靠性好，數據處理能力強，可以進行各種角度的優化。

第四階段：小米統計的很多數據查詢都是選擇一些指標和過濾條件，很多場景類似於傳統的數據倉庫，因此引入Druid 處理一些標準報告的實時數據查詢場景。數據流會依次通過Kaa 和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實時大數據分析原理與實踐》

------------

更多科技資訊請見微信公眾號：博文視點Broadview（微信號：bvbooks）

推薦閱讀：