一、Druid 介紹
Druid 是 MetaMarket 公司研發，專爲海量數據集上的做高性能 OLAP (OnLine Analysis Processing)而設計的數據存儲和分析系統，目前 Druid 已經在 Apache 基金會下孵化。Druid 的主要特性：
- 交互式查詢( Interactive Query ): Druid 的低延遲數據攝取架構允許事件在它們創建後毫秒內查詢，因爲 Druid 的查詢延時通過只讀取和掃描有必要的元素被優化。Druid 是列式存儲，查詢時讀取必要的數據，查詢的響應是亞秒級響應。
- 高可用性( High Available )：Druid 使用 HDFS/S3 作爲 Deep Storage，Segment 會在2個 Historical 節點上進行加載；攝取數據時也可以多副本攝取，保證數據可用性和容錯性。
- 可伸縮( Horizontal Scalable )：Druid 部署架構都可以水平擴展，增加大量服務器來加快數據攝取，以及保證亞秒級的查詢服務
- 並行處理( Parallel Processing ): Druid 可以在整個集羣中並行處理查詢
- 豐富的查詢能力( Rich Query )：Druid支持 Scan、 TopN、 GroupBy、 Approximate 等查詢，同時提供了2種查詢方式：API 和 SQL
Druid 常見應用的領域：
- 網頁點擊流分析
- 網絡流量分析
- 監控系統、APM
- 數據運營和營銷
- BI分析/OLAP
二、爲什麼我們需要用 Druid
有贊作爲一家 SaaS 公司，有很多的業務的場景和非常大量的實時數據和離線數據。在沒有是使用 Druid 之前，一些 OLAP 場景的場景分析，開發的同學都是使用 SparkStreaming 或者 Storm 做的。用這類方案會除了需要寫實時任務之外，還需要爲了查詢精心設計存儲。帶來問題是：開發的週期長，初期的存儲設計很難滿足需求的迭代發展，不可擴展。
在使用 Druid 之後，開發人員只需要填寫一個數據攝取的配置，指定維度和指標，就可以完成數據的攝入。從上面描述的 Druid 特性中我們知道，Druid 支持 SQL，應用 APP 可以像使用普通 JDBC 一樣來查詢數據。通過有贊自研 OLAP 平臺的幫助，數據的攝取配置變得更加簡單方便，一個實時任務創建僅僅需要 10 來分鐘，大大的提高了開發效率。
2.1 Druid 在有贊使用場景
- 系統監控和APM：有讚的監控系統(天網)和大量的APM系統都使用了 Druid 做數據分析
- 數據產品和BI分析：有贊 SaaS 服務爲商家提供了有很多數據產品，例如：商家營銷工具，各類 BI 報表
- 實時OLAP服務：Druid 爲風控、數據產品等C端業務提供了實時 OLAP 服務
三、Druid的架構
Druid 的架構是 Lambda 架構，分成實時層( Overlord、 MiddleManager )和批處理層( Broker 和 Historical )。主要的節點包括（PS: Druid 的所有功能都在同一個軟件包中，通過不同的命令啓動）：
- Coordinator 節點：負責集羣 Segment 的管理和發佈，並確保 Segment 在 Historical 集羣中的負載均衡
- Overlord 節點：Overlord 負責接受任務、協調任務的分配、創建任務鎖以及收集、返回任務運行狀態給客戶端；在Coordinator 節點配置 asOverlord，讓 Coordinator 具備 Overlord 功能，這樣減少了一個組件的部署和運維
- MiddleManager 節點：負責接收 Overlord 分配的索引任務，創建新啓動Peon實例來執行索引任務，一個MiddleManager可以運行多個 Peon 實例
- Broker 節點：負責從客戶端接收查詢請求，並將查詢請求轉發給 Historical 節點和 MiddleManager 節點。Broker 節點需要感知 Segment 信息在集羣上的分佈
- Historical 節點：負責按照規則加載非實時窗口的Segment
- Router 節點：可選節點，在 Broker 集羣之上的API網關，有了 Router 節點 Broker 不在是單點服務了，提高了併發查詢的能力
四、有贊 OLAP 平臺的架構和功能解析
4.1 有贊 OLAP 平臺的主要目標
- 最大程度的降低實時任務開發成本：從開發實時任務需要寫實時任務、設計存儲，到只需填寫配置即可完成實時任務的創建
- 提供數據補償服務，保證數據的安全：解決因爲實時窗口關閉，遲到數據的丟失問題
- 提供穩定可靠的監控服務：OLAP 平臺爲每一個 DataSource 提供了從數據攝入、Segment 落盤，到數據查詢的全方位的監控服務
4.2 有贊 OLAP 平臺架構
有贊 OLAP 平臺是用來管理 Druid 和周圍組件管理系統，OLAP 平臺主要的功能：
- Datasource 管理
- Tranquility 配置和實例管理：OLAP 平臺可以通過配置管理各個機器上 Tranquility 實例，擴容和縮容
- 數據補償管理：爲了解決數據遲延的問題，OLAP 平臺可以手動觸發和自動觸發補償任務
- Druid SQL查詢: 爲了幫助開發的同學調試 SQL，OLAP 平臺集成了 SQL 查詢功能
- 監控報警
4.2 Tranquility 實例管理
OLAP 平臺採用的數據攝取方式是Tranquility工具，根據流量大小對每個 DataSource 分配不同 Tranquility 實例數量； DataSource 的配置會被推送到 Agent-Master 上，Agent-Master 會收集每臺服務器的資源使用情況，選擇資源豐富的機器啓動 Tranquility 實例，目前只要考慮服務器的內存資源。同時 OLAP 平臺還支持 Tranquility 實例的啓停，擴容和縮容等功能。
4.3 解決數據遲延問題———離線數據補償功能
流式數據處理框架都會有時間窗口，遲於窗口期到達的數據會被丟棄。如何保證遲到的數據能被構建到 Segment 中，又避免實時任務窗口長期不能關閉。我們研發了 Druid 數據補償功能，通過 OLAP 平臺配置流式 ETL 將原始的數據存儲在 HDFS 上，基於 Flume 的流式 ETL 可以保證按照 Event 的時間，同一小時的數據都在同一個文件路徑下。再通過 OLAP 平臺手動或者自動觸發 Hadoop-Batch 任務，從離線構建 Segment。
基於 Flume 的 ETL 採用了 HDFS Sink 同步數據，實現了 Timestamp 的 Interceptor，按照 Event 的時間戳字段來創建文件(每小時創建一個文件夾)，延遲的數據能正確歸檔到相應小時的文件中。
4.4 冷熱數據分離
隨着接入的業務增加和長期的運行時間，數據規模也越來越大。Historical 節點加載了大量 Segment 數據，觀察發現大部分查詢都集中在最近幾天，換句話說最近幾天的熱數據很容易被查詢到，因此數據冷熱分離對提高查詢效率很重要。Druid 提供了Historical 的 Tier 分組機制與數據加載 Rule 機制，通過配置能很好的將數據進行冷熱分離。
首先將 Historical 羣進行分組，默認的分組是"_default_tier"，規劃少量的 Historical 節點，使用 SATA 盤；把大量的 Historical 節點規劃到 “hot” 分組，使用 SSD 盤。然後爲每個 DataSource 配置加載 Rule :
- rule1: 加載最近30天的1份 Segment 到 “hot” 分組；
- rule2: 加載最近180天的1份 Segment 到 “_default_tier” 分組；
- rule3: Drop 掉之前的數據（注：Rule機制隻影響 Historical 加載 Segment，Drop 掉的 Segment 在 HDFS 上任有備份）
{"type":"loadByPeriod","tieredReplicants":{"hot":1}, "period":"P30D"} {"type":"loadByPeriod","tieredReplicants":{"_default_tier":1}, "period":"P180D"} {"type":"dropForever"}
提高 "hot"分組集羣的 druid.server.priority 值（默認是0），熱數據的查詢都會落到 “hot” 分組。
4.5 監控與報警
Druid 架構中的各個組件都有很好的容錯性，單點故障時集羣依然能對外提供服務：Coordinator 和 Overlord 有 HA 保障；Segment 是多副本存儲在HDFS/S3上；同時 Historical 加載的 Segment 和 Peon 節點攝取的實時部分數據可以設置多副本提供服務。同時爲了能在節點/集羣進入不良狀態或者達到容量極限時，儘快的發出報警信息。和其他的大數據框架一樣，我們也對 Druid 做了詳細的監控和報警項，分成了2個級別：
- 基礎監控
包括各個組件的服務監控、集羣水位和狀態監控、機器信息監控 - 業務監控
業務監控包括：實時任務創建、數據攝取TPS、消費遲延、持久化相關、查詢 RT/QPS 等的關鍵指標，有單個 DataSource 和全局的2種不同視圖；同時這些監控項都有設置報警項，超過閾值進行報警提醒。業務指標的採集是大部分是通過Druid框架自身提供的Metrics和Alerts信息，然後流入到Kafka/OpenTSDB 等組件，通過流數據分析獲得我們想要的指標。
五、挑戰和未來的展望
5.1 數據攝取系統
目前比較常用的數據攝取方案是：KafkaIndex 和 Tranquility 。我們採用的是 Tranquility 的方案，目前 Tranquility支持了 Kafka 和 Http 方式攝取數據，攝取方式並不豐富；Tranquility 也是 MetaMarket 公司開源的項目，更新速度比較緩慢，不少功能缺失，最關鍵的是監控功能缺失，我們不能監控到實例的運行狀態，攝取速率、積壓、丟失等信息。
目前我們對 Tranquility 的實例管理支持啓停，擴容縮容等操作，實現的方式和 Druid 的 MiddleManager 管理 Peon 節點是一樣的。把 Tranquility 或者自研攝取工具轉換成 Yarn 應用或者 Docker 應用，就能把資源調度和實例管理交給更可靠的調度器來做。
5.2 Druid 的維表 JOIN 查詢
Druid 目前並不沒有支持JOIN查詢，所有的聚合查詢都被限制在單 DataSource 內進行。但是實際的使用場景中，我們經常需要幾個 DataSource 做 JOIN 查詢才能得到所需的結果。這是我們面臨的難題，也是 Druid 開發團隊遇到的難題。
5.3 整點查詢 RT 毛刺問題
對於 C 端的 OLAP 查詢場景，RT 要求比較高。由於 Druid 會在整點創建當前小時的Index任務，如果查詢正好落到新建的 Index 任務上，查詢的毛刺很大，如下圖所示：
我們已經進行了一些優化和調整，首先調整 warmingPeriod 參數，整點前啓動 Druid 的 Index 任務；對於一些 TPS 低，但是 QPS 很高的 DataSource ，調大 SegmentGranularity，大部分 Query 都是查詢最近 24 小時的數據，保證查詢的數據都在內存中，減少新建 Index 任務的，查詢毛刺有了很大的改善。儘管如此，離我們想要的目標還是一定的差距，接下去我們去優化一下源碼。
5.4 歷史數據自動 Rull-Up
現在大部分 DataSource 的 Segment 粒度( SegmentGranularity )都是小時級的，存儲在 HDFS 上就是每小時一個Segment。當需要查詢時間跨度比較大的時候，會導致Query很慢，佔用大量的 Historical 資源，甚至出現 Broker OOM 的情況。如果創建一個 Hadoop-Batch 任務，把一週前(舉例)的數據按照天粒度 Rull-Up 並且 重新構建 Index，應該會在壓縮存儲和提升查詢性能方面有很好的效果。