Druid 一次海量資料實時處理的實踐

NO IMAGE

前言

之在在專案中使用時序DB的時候,使用的是InfluxDB, 後來隨著資料量的增大,InfluxDB無法滿足需求(在資料量在百萬以下使用InfluxDB真的很好用),在一個偶然的機會下看了Druid,當時還是8.x版本,經過兩週的試用測試,效能表現完美,可以做到PB級資料的快速聚合查詢

簡介

Druid是一個用於大資料實時查詢和分析的高容錯、高效能開源分散式系統,旨在快速處理大規模的資料,並能夠實現快速查詢和分析

主要特徵

Druid的具有以下主要特徵:

  • 為分析而設計——Druid是為OLAP工作流的探索性分析而構建,它支援各種過濾、聚合和查詢等類。
  • 快速的互動式查詢——Druid的低延遲資料攝取架構允許事件在它們建立後毫秒內可被查詢到。
  • 高可用性——Druid的資料在系統更新時依然可用,規模的擴大和縮小都不會造成資料丟失。
  • 可擴充套件——Druid每天能夠處理數十億事件和TB級資料。

現在Druid已經到了9.x版本,新版本在穩定性已經相當好,而且和Hadoop、kafka等結合的更緊密

節點介紹

Druid是由一組不同角色的節點,每種節點都是一個單獨的子系統負責不同的功能,這些節點組成一個系統協同工作,我們來看一下Druid的整體架構見下圖
druid-manage

Coordinator Node

監控Historical節點組,以確保資料可用、可複製,並且在一般的“最佳”配置。它們通過從MySQL讀取資料段的後設資料資訊,來決定哪些資料段應該在叢集中被載入,使用Zookeeper來確定哪個Historical節點存在,並且建立Zookeeper條目告訴Historical節點載入和刪除新資料段。

Historical Node

是對“historical”資料(非實時)進行處理儲存和查詢的地方。Historical節點響應從Broker節點發來的查詢,並將結果返回給broker節點。它們在Zookeeper的管理下提供服務,並使用Zookeeper監視訊號載入或刪除新資料段。

Broker Node

接收來自外部客戶端的查詢,並將這些查詢轉發到Realtime和Historical節點。當Broker節點收到結果,它們將合併這些結果並將它們返回給呼叫者。由於瞭解拓撲,Broker節點使用Zookeeper來確定哪些Realtime和Historical節點的存在。

Real-time Node

實時攝取資料,它們負責監聽輸入資料流並讓其在內部的Druid系統立即獲取,Realtime節點同樣只響應broker節點的查詢請求,返回查詢結果到broker節點。舊資料會被從Realtime節點轉存至Historical節點。

ZooKeeper

為叢集服務發現和維持當前的資料拓撲而服務;

MySQL

用來維持系統服務所需的資料段的後設資料;

Deep Storage

儲存“冷資料”,可以使用HDFS。

實踐

在其中一個專案中使用Druid,驗證了Druid的能力,約使用了10臺機器(其中Druid叢集 4 臺,HDFS 3 臺,web一臺, 其它2臺),專案結構如下圖

image

接收資料端使用Golang,快速的構建了一個分散式,效能還不錯的接收服務,其中一個資料接收結點,每天千萬級報活,每天上傳近億條資料,聚合查詢半月內的資料(約10億條),秒級可返回結果,完美解決問題。

之於為什麼沒選擇Mysql?因為較大資料量下,本人功力有限,實在玩不轉Mysql。綜合需求最終總結為: 需要一個對於時序支援較好,可以海量資料快速查詢,並且高可用的分散式的列儲存系統, 因此最終決定嘗試 Druid。

目前在國內使用Druid的企業越來越多,其中包括小米、嘀嘀、去那兒、獵豹、優酷等。

瞭解更多

官方的使用文件寫的相當不錯,具體細節請移步至Druid Doc(0.9)

官方的使用文件寫的相當不錯,具體細節請移步至Druid Doc(0.9)

和其它專案的關係
Druid vs Spark
Druid vs SQL-on-Hadoop
Druid vs. Key/Value Stores
Druid vs Redshift
Druid vs Elasticsearch

本文作者:ganggang