螞蜂窩大數據多維分析 DRUID 引擎實踐

編者按：大數據的應用熱潮襲來，如何更好地利用大數據為企業創造價值也是大家的關注點。Druid是一個用於大數據實時查詢和分析的高容錯、高性能開源分散式系統，旨在快速處理大規模的數據，並能夠實現快速查詢和分析。螞蜂窩作為國內最早一批使用Druid 的公司，汪木鈴給大家帶來一場在應用Druid 實戰過程中遇到的問題和優化經驗。以下是此次演講內容整理。

汪木鈴

2014 年至今負責螞蜂窩數據採集、對接、數據產品的開發及整個大數據平台的架構設計、技術選型， 專註於大數據工具鏈的定製開發及應用。

｜螞蜂窩大數據平台

自我介紹一下。我是2014年加入到螞蜂窩，目前是負責整個螞蜂窩的大數據平台。在2014年，其實螞蜂窩整個數據團隊剛成立，那個時候數據分析是用各種簡單的腳本去做各種統計。當時在建設大數據平台，我們也面臨很多問題。比如說怎麼去規範數據的接入、怎麼統一數據的整個處理機制、怎麼統一對外的 API 服務等。

｜螞蜂窩平台技術體系

圖 1

如圖 1 看一下當前螞蜂窩整個數據流，在這張圖裡邊最左邊，包括移動端都埋了打點。APP 內放了 IOS-SDK，所有的 API 都是在用 PHP，封裝三個 PHP SDK，作為統一的數據採集入口。這三個 SDK 採集完數據，統一地把所有數據都導入到 Kafka。三個 SDK 在前端機產生一分鐘文件，這個一分鐘文件再通過 Kafkacat一分鐘引入。另外一個也是通過 Tail-Kafka實時把這一分鐘文件所有的數據統一錄到 Kafka 裡面。在 Kafka 下游，有實時系統，我們叫螞蜂窩事件系統，叫 MES。MES 裡面通過 SparkSteaming 寫入。

另外一個引入實時報表系統理念，作為多維的數據分析。在離線這一塊，Hive作為存儲層，Presto作為查詢層。最終這些所有的數據都有各自的 API，比如實時的報表 Mes Api,Druid API 後台，通過自研的可視化做圖表分析。再接著就是一些個性化推薦的數據，數據存儲在hbase。包括用戶的行為分析，我們叫 MVT 後台，可以追蹤用戶到螞蜂窩，無論是 APP，還是整個網站，都能跟蹤。這是當前螞蜂窩的整個數據情況。

圖 2

圖 2 是當前整個螞蜂窩大數據平台的一個技術體系。在接入層，我去接業務庫的，叫 binlog，採用canal去接入。另外一個就是通過sqoop 去同步mysql業務表。在前端錄數據，錄到 Kafka，包括實時的，就是 TAIL－Kafka。存儲的話在 HDFS。在 REDIS上，當前我們採用spark+redis作為整個實施報表系統的運算。在調度我們是採用 YARN，以及整個 MESOS。MESOS 我們現在用來統一管理spark streaming,presto 。在計算層面很簡單，用的是Hive,Spark,presto,包括後面的 Druid。

在應用平台，我們自研了實時數據報表mes，離線數據倉庫mdw，以及mql。mql是基於 Presto 造了一個可視化的 sql 執行 ui。現在在 Presto 社區，其實基本上是沒有，有的話，像airbnb做可視化很醜陋，而且相對使用上特別不好。所以我們自研了叫MQL及MQL-T。上面通過一分鐘就能夠去搭建各種的 sql 報表。MES 就是我們現在的實時報表，MHA 是我們自研的可以分析每個網頁，每個區塊的各種點擊，UPS/UDS 就是我們一些個性化的服務。在應用就是一些流量統計，用戶畫像，包括一些個性化推薦。最左邊對於整個技術平台一些監控，當前採用Graphite/Grafana，包括基於硬體監控的zabbix，監控我們整個平台各個集群。現在這些集群總共將近有 150 台左右機器，分散到各個集群上面。這是當前螞蜂窩整個平台的技術體系。

K-V 型事件模型

圖 3

在前面提到，怎麼去統一地讓我們的工程師去上報數據，我們引入了 PHP SDK，通過傳入定義一個叫 basic 的技術屬性，以及 attr 的自定義屬性。basic 我們在對外提供的 PHP API 是放了三個參數，第一個叫 app code，第二個叫 event code，第三個是自定義屬性，傳的是 attr ，就可以去自定義自己的各自的業務裡面的關鍵收集點。後面整個數據的一個處理，作為 K-V 事件模型是特別重要的。

｜實時數據探索

圖 4

在數據實時探索，在過去每一次按天或者按小時。但是現在螞蜂窩在發展，按小時，按天的話肯定就不符合當前的情況。所以我們需要有實時的數據探索。這個在螞蜂窩的事件系統，叫 MES。通過自研，在上面的紅框當中（圖 4），每一層級叫 app code，event code，包括自定義的 attr。最終在 MES 裡邊，假如說他上報一個數據只需要在整個 MES 裡面去配調規則，這個數據就實時能夠在這個報表上看到。

圖 5

這是在最開始我們引入 Druid 之前，我們通過自研第一代的 MES，就是用spark＋redis＋hbase。這是現在當前整個 MES 實時報表系統，我們兩個，採用兩代。第一代就是，跟大家說叫 spark＋redis＋hbase。後面引入 Druid 就叫 Spark+Druid，通過 Thrift-Service 去給 MES 報表系統，給用戶做一些實時的數據探索。

圖 6

但是這兩個引擎，第一代MES，計算UV是精確的，因為需要去精確計算每一個用戶。實現的功能的就是虛擬 key，第一代自研的就是支持虛擬 key，就是我們一個產品需要衍生出產品名稱。另外一個有一個一對多的關係，比如我們的一個目的地，需要映射到國家級的或者是省級的，這是第一代。

第一代MES，作為精確的UV計算，在 redis 裡面去實時的數據分析，但是在精確計算帶來價格的同時，消耗需要再用大量的資源，包括各種計算的資源。第一代的 MES，比如說我們在每次大促，這個時候在流量上來的時候，在第一代 MES 這個引擎裡面會造成大量延遲。比如說一分鐘有幾百萬的數據進來，第一代是滿足不了，有些可能延遲十幾分鐘，二十幾分鐘。

在另外一個，整個第一代 MES 只支持你配好規則之後，我們才按這條規則給你算出這個結果。但是假如我們工程師之前在自定義屬性attr上報了一個欄位key。想在下個禮拜我想要再去算這個key，這個時候只能是重新把這一天的數據導入。所以這個時候算一天，第一代算一天十幾個小時，各種 UV，各種複雜的特別多的運算，包括 UV 的計算規則，KV 的計算壓力，很多很多，達到幾千萬，上百萬。

所以在同時，我們當時考慮到，在數據量大的情況下，是不是我們可以去犧牲 UV 的計算。所以就引入在 Druid 裡面。把 Druid 引入到 MES，誤差基本上保持在 2% 左右。後面我們又通過雅虎提供的data sketch,可以精確調控 UV 的計算，它的默認值是 16384，16384 以下可以是精確的。當然這個值是可以控制的，就是 2 的 N 次冪，當前我們是調到特別大，800 多萬。但 Druid 裡面不支持MES第一代的虛擬 key。

｜MES 第一代:Spark+Redis+Hbase 實時數據探索

因此，第一代存在下述問題。

流量高峰期處理延遲

緯度交叉分析，不靈活

消耗資源大

系統故障，重算慢

這是第一代、消耗大、系統故障，在大內存情況下很容易導致崩潰。馬蜂窩之前就遇到突發，一組三台，每一台 512 個 G，這個時候內存太大了，哪天一個內存條壞的話，這一天的數據可能就要重新算，而且對於現在當前整個實時數據量來看，完全就不符合當前的現狀，算一天需要十幾個小時。

｜MES第二代:Druid實時數據探索

圖 7

第二代 MES 我們就引入了 Druid 實時數據探索。圖 7 是 Druid 的一個基本架構圖，在 Clint 端發起請求，由 BROKER 發配，發配到實時節點上，取得當前實時數據，包括在HISTORICAL，這個節點就是存儲歷史的，請求完之後，在 BROKER 之後，再返回的一個結果。這是比較簡單的。

圖 8

圖 8 是當前整個 Druid 在螞蜂的一個配置，有三台機器上面掛 overlord 及 coordinator。另外三台就叫 middleManager。另外還有八台作為數據存儲的（historical）。我們在這 8 台當中又拆分了兩個小的集群，就相當於有兩個作為熱備。另外 6 台，叫冷數據。我們在這兩台熱數據的只能允許查詢最近 15 天的。在 15 天之前的數據發配到 Cold-historical 6 台機器去查詢。在 broker 區分出 hot 跟 cold，最終通過一排 broker router 去發路由。這樣的話，在查詢高峰互不影響。

圖 9

圖 9 是螞蜂窩三個重要的業務日誌，在維度方面，比如說像 server-event 有 700 多個維度。 700 多個維度，當然維度越多，查詢性能就會受影響，包括導入數據，通過批量錄數據到 Druid 裡面，這個時候也是非常緩慢的。我們保留的周期當前每天基本上數據量很大，進來整個數據，包括集群存儲都不夠，所以說我們在最重要的三個日誌源裡面保留最近 15 天的。在維度越多的情況下查起來，比如發一個請求，code 去查詢當天的 PV 或者 UV，PV 還可以，但是最影響性能就是查詢 UV 的時候。一分鐘都查不出來，基本上都是三四分鐘。所以說在這三個大的數據源情況下，假如說要去查詢之前歷史數據一段時間，可能查好幾十分鐘，或者基本上是沒有辦法達到秒級情況下查詢出來。

所以在基於三個大的業務模塊情況下，拆分出對於螞蜂窩比較重要的幾塊業務，就是圖中下圖。logdata、mobile、以及 Page，以及另外一個就是我們給用戶發的 push。各自的維度基本上都是在 20、30 個，指標就 5 個。在維度小的情況下，基本上查詢，比如我查詢一年的 PV，就這五個指標，我同時發起請求去查詢，基本上是在秒級響應。假如說我把請求放置到上面那三個模塊裡邊，查詢整個前端都會超時。

圖 10

在 Druid 裡面對於datasource有一個按時間密度去分的，我們歷史數據在查詢力度這個層面，只能讓他查到按每小時去查，其他按天去分配。最新的數據就在最近 15 天，我們可以讓他精確到一分鐘的查詢，對於歷史數據，力度越精確，數據量到 Druid 裡面越大。

圖 11

現在在整個螞蜂窩裡面做了一個是從實時的數據，然後有一個用 spark，這個組件實時地導入到 Druid 裡面。在這個裡面，我們做事情之前，對外提供數據採集的時候，有一個 attr 自定義屬性，那裡面所有的 attr key 我們是未知的。所以我們需要把 attr 裡面所有的數據在錄 Druid 之前都打平之後，每一天達到 700 多個維度。

在離線批量導入，現在 Druid 支持，T+1 的數據校正。如果在 PSPARK+TRANQUILITY 這一階段，因為 SPARK 的 task 失敗的話，可能會導致這個數據到 Druid 裡面 PV 會上升。所以說需要每天凌晨通過批量導入的方法把上一天的數據做一個數據校準。同樣的是需要打平在 attr 里打平所有工程師上報的數據制定的值。

在 Druid 方面，通過 thrift－service 提供給 MES 展現。

圖 12

圖 12 是grafana,grafana現在有一個插件，可以去查詢 Druid 裡面的數據。當前我們幾個比較重要的日誌源，就會每天去監控。

｜Druid 集群注意事項

在 Druid 裡面配置，

1、維度不要太多，像螞蜂窩最開始 700 多個維度。每天導進去將近 100 個 G，導進去十分耗時。

2、維度大小，不要太大。比如你來一個維度值幾兆的，這個不行。

3、要去合理配置比例。在最開始，我們就拿了跟我們之前節點掛上了 10 個 T 的磁碟，作為整個 Druid 節點的數據存儲，但是發現在你去查，無論你是去查任務，或者查歷史數據。10 個 T 的磁碟跟不上來，查詢各種超時，各種響應。

4、磁碟選用。其實採用的固態盤，基本上像我們現在的配置，就是 256 個 G 內存，1.2T 的固態盤。這個配置起來，你去查詢整個歷史數據，或者無論你查詢其他的數據都是很快的。5、在segment大小，我們最開始是按天的，100個G，後面拆分成每小時去分。這個時候到幾個G，幾個G也不行，我們就是要在去拆分幾個G，到最終查詢相當於是在在300-700兆左右。

6、在Druid裡面，不支持逗號，因為Druid 里在底層逗號是用來分隔。

7、優先去升級 Druid 的版本。我們在最早從 0.6 慢慢升級到 0.8，我們現在用的是 0.9。每一次 Druid 的發版，優化了很多東西。你覺得每一個查詢有問題，或者說你想要去更快查詢這些數據，可以優先考慮一下去 github 上面去看看 Druid 的最新近況。

這個就是今天給大家分享的一些東西。當然我們在使用 Druid 的過程當中，其實還遇到其他很多問題。也希望Druid 能越來越好。

9月23日 上海七牛雲推出「移動架構與性能優化」主題架構師實踐日

將攜手三位來自魔都的移動互聯網創業新秀

二次元最愛的視頻彈幕平台B站

致力於用人工智慧技術讓大家輕鬆說一口流利英語的英語流利說

以及專註於APP熱更新技術多年的樂變技術

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！