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

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 腳本的執行，很難估計須要多長時間才能完成，沒法知足不少數據分析師所指望的秒級返回查詢結果的分析需求。 
　　爲了解決數據實時性的問題，大部分公司都有一個經歷，將數據分析變成更加實時的可交互方案。其中，涉及新軟件的引入、數據流的改進等。數據分析的幾種常見方法以下圖。 

　　整個數據分析的基礎架構一般分爲如下幾類。 
（1）使用Hadoop/Spark 的MR 分析。 
（2）將Hadoop/Spark 的結果注入RDBMS 中提供實時分析。 
（3）將結果注入到容量更大的NoSQL 中，例如HBase 等。 
（4）將數據源進行流式處理，對接流式計算框架，如Storm，結果落在RDBMS/NoSQL 中。 
（5）將數據源進行流式處理，對接分析數據庫，例如Druid、Vertica 等。

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實時大數據分析原理與實踐》，點此連接可在博文視點官網查看此書。 
　　　　　　　　　　　　　　　　　　　　

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