快速了解Druid 實時大資料分析軟體

引言：druid作為一款開源的實時大資料分析軟體，最近幾年快速風靡全球網際網路公司，特別是對於海量資料和實時性要求高的場景。如果你對druid還很陌生，那趕緊跟著本文快速了解一下吧。

相關圖書《druid實時大資料分析原理與實踐》。

druid 單詞**於西方古羅馬的神話人物，中文常常翻譯成德魯伊。

本問介紹的druid 是乙個分布式的支援實時分析的資料儲存系統（data store）。美國廣告技術公司metamarkets 於2011 年建立了druid 專案，並且於2012 年晚期開源了druid 專案。druid 設計之初的想法就是為分析而生，它在處理資料的規模、資料處理的實時性方面，比傳統的olap 系統有了顯著的效能改進，而且擁抱主流的開源生態，包括hadoop 等。多年以來，druid 一直是非常活躍的開源專案。

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 等。

對於資料分析場景，大部分情況下，我們只關心一定粒度聚合的資料，而非每一行原始資料的細節情況。因此，資料聚合粒度可以是1 分鐘、5 分鐘、1 小時或1 天等。部分資料聚合（partial aggregate）給druid 爭取了很大的效能優化空間。

資料記憶體化也是提高查詢速度的殺手鐗。記憶體和硬碟的訪問速度相差近百倍，但記憶體的大小是非常有限的，因此在記憶體使用方面要精細設計，比如druid 裡面使用了bitmap 和各種壓縮技術。

另外，為了支援drill-down 某些維度，druid 維護了一些倒排索引。這種方式可以加快and 和or 等計算操作。

druid 查詢效能在很大程度上依賴於記憶體的優化使用。資料可以分布在多個節點的記憶體中，因此當資料增長的時候，可以通過簡單增加機器的方式進行擴容。為了保持平衡，druid按照時間範圍把聚合資料進行分割槽處理。對於高基數的維度，只按照時間切分有時候是不夠的（druid 的每個segment 不超過2000 萬行），故druid 還支援對segment 進一步分割槽。

歷史segment 資料可以儲存在深度儲存系統中，儲存系統可以是本地磁碟、hdfs 或遠端的雲服務。如果某些節點出現故障，則可借助zookeeper 協調其他節點重新構造資料。

druid 的查詢模組能夠感知和處理集群的狀態變化，查詢總是在有效的集群架構中進行。集群上的查詢可以進行靈活的水平擴充套件。druid 內建提供了一些容易並行化的聚合操作，例如count、mean、variance 和其他查詢統計。對於一些無法並行化的操作，例如median，druid暫時不提供支援。在支援直方圖（histogram）方面，druid 也是通過一些近似計算的方法進行支援，以保證druid 整體的查詢效能，這些近似計算方法還包括hyperloglog、datasketches的一些基數計算。

druid 提供了包含基於時間維度資料的儲存服務，並且任何一行資料都是歷史真實發生的事件，因此在設計之初就約定事件一但進入系統，就不能再改變。

對於歷史資料druid 以segment 資料檔案的方式組織，並且將它們儲存到深度儲存系統中，例如檔案系統或亞馬遜的s3 等。當需要查詢這些資料的時候，druid 再從深度儲存系統中將它們裝載到記憶體供查詢使用。

druid 具有如下技術特點。

• 資料吞吐量大。

• 支援流式資料攝入和實時。

• 查詢靈活且快。

• 社群支援力度大。

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

很多資料分析軟體在吞吐量和流式能力上做了很多平衡，比如hadoop 更加青睞批量處理，而storm 則是乙個流式計算平台，真正在分析平台層面上直接對接各種流式資料來源的系統並不多。

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

druid 開源後，受到不少網際網路公司的青睞，包括雅虎、ebay、阿里巴巴等，其中雅虎的committer 有5 個，谷歌有1 個，阿里巴巴有1 個。最近，metamarkets 之前幾個druid 發明人也成立了一家叫作imply.io 的新公司，推動druid 生態的發展，致力於druid 的繁榮和應用。

從技術定位上看，druid 是乙個分布式的資料分析平台，在功能上也非常像傳統的olap系統，但是在實現方式上做了很多聚焦和取捨，為了支援更大的資料量、更靈活的分布式部署、更實時的資料攝入，druid 捨去了olap 查詢中比較複雜的操作，例如join 等。相比傳統資料庫，druid 是一種時序資料庫，按照一定的時間粒度對資料進行聚合，以加快分析查詢。

在應用場景上，druid 從廣告資料分析平台起家，已經廣泛應用在各個行業和很多網際網路公司中，最新列表可以訪問

druid 的生態系統正在不斷擴大和成熟，druid 也正在解決越來越多的業務場景。希望《druid實時大資料分析原理與實踐》一書能幫助技術人員做出更好的技術選型，深度了解druid 的功能和原理，更好地解決大資料分析問題。

各大電商**火熱預售中！

本文選自《druid實時大資料分析原理與實踐》，點此鏈結可在博文視點官網檢視此書。

快速了解Druid 實時大資料分析軟體

快速了解Druid 實時大資料分析軟體

快速了解Druid 實時大資料分析軟體

Druid 乙個用於大資料實時處理的開源分布式系統

相關推薦