Druid 是什麽

　　Druid 單詞來源於西方古羅馬的神話人物，中文常常翻譯成德魯伊。
　　本問介紹的Druid 是一個分布式的支持實時分析的數據存儲系統（Data Store）。美國廣告技術公司MetaMarkets 於2011 年創建了Druid 項目，並且於2012 年晚期開源了Druid 項目。Druid 設計之初的想法就是為分析而生，它在處理數據的規模、數據處理的實時性方面，比傳統的OLAP 系統有了顯著的性能改進，而且擁抱主流的開源生態，包括Hadoop 等。多年以來，Druid 一直是非常活躍的開源項目。
　　Druid 的官方網站是http://druid.io。
　　另外，阿裏巴巴也曾創建過一個開源項目叫作Druid（簡稱阿裏Druid），它是一個數據庫連接池的項目。阿裏Druid 和本問討論的Druid 沒有任何關系，它們解決完全不同的問題。

大數據分析和Druid

　　大數據一直是近年的熱點話題，隨著數據量的急速增長，數據處理的規模也從GB 級別增長到TB 級別，很多圖像應用領域已經開始處理PB 級別的數據分析。大數據的核心目標是提升業務的競爭力，找到一些可以采取行動的洞察（Actionable Insight），數據分析就是其中的核心技術，包括數據收集、處理、建模和分析，最後找到改進業務的方案。
　　最近一兩年，隨著大數據分析需求的爆炸性增長，很多公司都經歷過將以關系型商用數據庫為基礎的數據平臺，轉移到一些開源生態的大數據平臺，例如Hadoop 或Spark 平臺，以可控的軟硬件成本處理更大的數據量。Hadoop 設計之初就是為了批量處理大數據，但數據處理實時性經常是它的弱點。例如，很多時候一個MapReduce 腳本的執行，很難估計需要多長時間才能完成，無法滿足很多數據分析師所期望的秒級返回查詢結果的分析需求。
　　為了解決數據實時性的問題，大部分公司都有一個經歷，將數據分析變成更加實時的可交互方案。其中，涉及新軟件的引入、數據流的改進等。數據分析的幾種常見方法如下圖。

Druid 的三個設計原則

　　在設計之初，開發人員確定了三個設計原則（Design Principle）。
（1）快速查詢（Fast Query）：部分數據的聚合（Partial Aggregate）+內存化（In-emory）+索引（Index）。
（2）水平擴展能力（Horizontal Scalability）：分布式數據（Distributed Data）+ 並行化查詢（Parallelizable Query）。
（3）實時分析（Realtime Analytics）：不可變的過去，只追加的未來（Immutable Past，Append-Only Future）。

1 快速查詢（Fast Query）

　　對於數據分析場景，大部分情況下，我們只關心一定粒度聚合的數據，而非每一行原始數據的細節情況。因此，數據聚合粒度可以是1 分鐘、5 分鐘、1 小時或1 天等。部分數據聚合（Partial Aggregate）給Druid 爭取了很大的性能優化空間。
　　數據內存化也是提高查詢速度的殺手鐧。內存和硬盤的訪問速度相差近百倍，但內存的大小是非常有限的，因此在內存使用方面要精細設計，比如Druid 裏面使用了Bitmap 和各種壓縮技術。
另外，為了支持Drill-Down 某些維度，Druid 維護了一些倒排索引。這種方式可以加快AND 和OR 等計算操作。

2 水平擴展能力（Horizontal Scalability）

　　Druid 查詢性能在很大程度上依賴於內存的優化使用。數據可以分布在多個節點的內存中，因此當數據增長的時候，可以通過簡單增加機器的方式進行擴容。為了保持平衡，Druid按照時間範圍把聚合數據進行分區處理。對於高基數的維度，只按照時間切分有時候是不夠的（Druid 的每個Segment 不超過2000 萬行），故Druid 還支持對Segment 進一步分區。
　　歷史Segment 數據可以保存在深度存儲系統中，存儲系統可以是本地磁盤、HDFS 或遠程的雲服務。如果某些節點出現故障，則可借助Zookeeper 協調其他節點重新構造數據。
　　Druid 的查詢模塊能夠感知和處理集群的狀態變化，查詢總是在有效的集群架構中進行。集群上的查詢可以進行靈活的水平擴展。Druid 內置提供了一些容易並行化的聚合操作，例如Count、Mean、Variance 和其他查詢統計。對於一些無法並行化的操作，例如Median，Druid暫時不提供支持。在支持直方圖（Histogram）方面，Druid 也是通過一些近似計算的方法進行支持，以保證Druid 整體的查詢性能，這些近似計算方法還包括HyperLoglog、DataSketches的一些基數計算。

3 實時分析（Realtime Analytics）

　　Druid 提供了包含基於時間維度數據的存儲服務，並且任何一行數據都是歷史真實發生的事件，因此在設計之初就約定事件一但進入系統，就不能再改變。
　　對於歷史數據Druid 以Segment 數據文件的方式組織，並且將它們存儲到深度存儲系統中，例如文件系統或亞馬遜的S3 等。當需要查詢這些數據的時候，Druid 再從深度存儲系統中將它們裝載到內存供查詢使用。

Druid 的技術特點

　　Druid 具有如下技術特點。
? 數據吞吐量大。
? 支持流式數據攝入和實時。
? 查詢靈活且快。
? 社區支持力度大。

1 數據吞吐量大

　　很多公司選擇Druid 作為分析平臺，都是看中Druid 的數據吞吐能力。每天處理幾十億到幾百億的事件，對於Druid 來說是非常適合的場景，目前已被大量互聯網公司實踐。因此，很多公司選型Druid 是為了解決數據爆炸的問題。

2 支持流式數據攝入

　　很多數據分析軟件在吞吐量和流式能力上做了很多平衡，比如Hadoop 更加青睞批量處理，而Storm 則是一個流式計算平臺，真正在分析平臺層面上直接對接各種流式數據源的系統並不多。

3 查詢靈活且快

　　數據分析師的想法經常是天馬行空，希望從不同的角度去分析數據，為了解決這個問題，OLAP 的Star Schema 實際上就定義了一個很好的空間，讓數據分析師自由探索數據。數據量小的時候，一切安好，但是數據量變大後，不能秒級返回結果的分析系統都是被詬病的對象。因此，Druid 支持在任何維度組合上進行查詢，訪問速度極快，成為分析平臺最重要的兩個殺手鐧。

4 社區支持力度大

　　Druid 開源後，受到不少互聯網公司的青睞，包括雅虎、eBay、阿裏巴巴等，其中雅虎的Committer 有5 個，谷歌有1 個，阿裏巴巴有1 個。最近，MetaMarkets 之前幾個Druid 發明人也成立了一家叫作Imply.io 的新公司，推動Druid 生態的發展，致力於Druid 的繁榮和應用。

Druid 的應用場景

　　從技術定位上看，Druid 是一個分布式的數據分析平臺，在功能上也非常像傳統的OLAP系統，但是在實現方式上做了很多聚焦和取舍，為了支持更大的數據量、更靈活的分布式部署、更實時的數據攝入，Druid 舍去了OLAP 查詢中比較復雜的操作，例如JOIN 等。相比傳統數據庫，Druid 是一種時序數據庫，按照一定的時間粒度對數據進行聚合，以加快分析查詢。
　　在應用場景上，Druid 從廣告數據分析平臺起家，已經廣泛應用在各個行業和很多互聯網公司中，最新列表可以訪問http://druid.io/druidpowered.html。

快速了解Druid——實時大數據分析軟件