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 的生態系統正在不斷擴大和成熟，Druid 也正在解決越來越多的業務場景。希望《Druid實時大資料分析原理與實踐》一書能幫助技術人員做出更好的技術選型，深度瞭解Druid 的功能和原理，更好地解決大資料分析問題。 
各大電商網站火熱預售中！ 
　　本文選自《Druid實時大資料分析原理與實踐》，點此連結可在博文視點官網檢視此書。 
　　　　　　　　　　　　　　　　　　　　

想及時獲得更多精彩文章，可在微信中搜索“博文視點”或者掃描下方二維碼並關注。