原文鏈接： https://blog.csdn.net/njpjsoftdev/article/details/52955676
Druid.io（以下簡稱Druid）是面向海量數據的、用於實時查詢與分析的OLAP存儲系統。Druid的四大關鍵特性總結如下：
-
亞秒級的OLAP查詢分析。Druid采用了列式存儲、倒排索引、位圖索引等關鍵技術，能夠在亞秒級別內完成海量數據的過濾、聚合以及多維分析等操作。
-
實時流數據分析。區別於傳統分析型數據庫采用的批量導入數據進行分析的方式，Druid提供了實時流數據分析，采用LSM(Long structure merge)-Tree結構使Druid擁有極高的實時寫入性能；同時實現了實時數據在亞秒級內的可視化。
-
豐富的數據分析功能。針對不同用戶群體，Druid提供了友好的可視化界面、類SQL查詢語言以及REST 查詢接口。
-
高可用性與高可拓展性。Druid采用分布式、SN(share-nothing)架構，管理類節點可配置HA，工作節點功能單一，不相互依賴，這些特性都使得Druid集群在管理、容錯、災備、擴容等方面變得十分簡單。
1 為什么會有Druid
大數據技術從最早的Hadoop項目開始已經有十多年的歷史了，而Druid是在2013年年底才開源的，雖然目前還不是Apache頂級項目，但是作為后起之秀，依然吸引了大量用戶的目光，社區也非常活躍。那么，為什么會有Druid，而Druid又解決了傳統大數據處理框架下的哪些“痛點”問題，下面我們來一一解答。
大數據時代，如何從海量數據中提取有價值的信息，是一個亟待解決的難題。針對這個問題，IT巨頭們已經開發了大量的數據存儲與分析類產品，比如IBM Netezza、HP Vertica、EMC GreenPlum等，但是他們大多是昂貴的商業付費類產品，業內使用者寥寥。
而受益於近年來高漲的開源精神，業內出現了眾多優秀的開源項目，其中最有名的當屬Apache Hadoop生態圈。時至今日，Hadoop已經成為了大數據的“標准”解決方案，但是，人們在享受Hadoop便捷數據分析的同時，也必須要忍受Hadoop在設計上的許多“痛點”，下面就羅列三方面的問題：
-
何時能進行數據查詢？對於Hadoop使用的Map/Reduce批處理框架，數據何時能夠查詢沒有性能保證。
-
隨機IO問題。Map/Reduce批處理框架所處理的數據需要存儲在HDFS上，而HDFS是一個以集群硬盤作為存儲資源池的分布式文件系統，那么在海量數據的處理過程中，必然會引起大量的讀寫操作，此時隨機IO就成為了高並發場景下的性能瓶頸。
-
數據可視化問題。HDFS是一個優秀的分布式文件系統，但是對於數據分析以及數據的即席查詢，HDFS並不是最優的選擇。
傳統的大數據處理架構Hadoop更傾向於一種“后台批處理的數據倉庫系統”，其作為海量歷史數據保存、冷數據分析，確實是一個優秀的通用解決方案，但是如何保證高並發環境下海量數據的查詢分析性能，以及如何實現海量實時數據的查詢分析與可視化，Hadoop確實顯得有些無能為力。
2 Druid直面痛點
Druid的母公司MetaMarket在2011年以前也是Hadoop的擁躉者，但是在高並發環境下，Hadoop並不能對數據可用性以及查詢性能給出產品級別的保證，使得MetaMarket必須去尋找新的解決方案，當嘗試使用了各種關系型數據庫以及NoSQL產品后，他們覺得這些已有的工具都不能解決他們的“痛點”，所以決定在2011年開始研發自己的“輪子”Druid，他們將Druid定義為“開源、分布式、面向列式存儲的實時分析數據存儲系統”，所要解決的“痛點”也是上文中反復提及的“在高並發環境下，保證海量數據查詢分析性能，同時又提供海量實時數據的查詢、分析與可視化功能”。