Druid 大數據分析之概況 - yangyangmyself的專欄 - 博客頻道 - CSDN.NET http://blog.csdn.net/yangyangmyself/article/details/52346795?locationNum=6
數據量如此大，如何滿足后期分析，傳統面向OLTP型數據庫（ORACLE、MYSQL等）無法要求，漸漸開始轉向OLAP，如GreenPlum等，雖然很多OLAP數據庫吸收分布式計算思想，數據達到20億以上后，進行Count、聚合等操作性能仍然達不到客戶實時分析要求。
雖然相關大數據框架及組件已經很流行：Hadoop（離線分析）、Spark、storm、Hive、Impala、Hbase等，Hadoop生態系統大龐大，Spark一站式安裝部署，但是滿足實時分析還需借助其它組件、開發要求很高。
一、概述
隨著互聯網快速發展，數據量增長快，達到TB、PB，以交通車流量為例，如湖南省每月的車輛流量至少達到4億，這個數據量遠不止如此。數據量如此大，如何滿足后期分析，傳統面向OLTP型數據庫（ORACLE、MYSQL等）無法要求，漸漸開始轉向OLAP，如GreenPlum等，雖然很多OLAP數據庫吸收分布式計算思想，數據達到20億以上后，進行Count、聚合等操作性能仍然達不到客戶實時分析要求。 雖然相關大數據框架及組件已經很流行：Hadoop（離線分析）、Spark、storm、Hive、Impala、Hbase等，Hadoop生態系統大龐大，Spark一站式安裝部署，但是滿足實時分析還需借助其它組件、開發要求很高。 Druid是一個用于大數據實時查詢和分析的高容錯、高性能開源分布式系統，旨在快速處理大規模的數據，并能夠實現快速查詢和分析。尤其是當發生代碼部署、機器故障以及其他產品系統遇到宕機等情況時，Druid仍能夠保持100%正常運行。創建Druid的最初意圖主要是為了解決查詢延遲問題，當時試圖使用Hadoop來實現交互式查詢分析，但是很難滿足實時分析的需要。而Druid提供了以交互方式訪問數據的能力，并權衡了查詢的靈活性和性能而采取了特殊的存儲格式。 如下圖所示，類似基于時間序列的數據庫系統，Druid今年排情況：
二、Druid 數據
Druid是一個開源的數據存儲設計的事件數據的OLAP查詢，提供一個高層次的概述如何存儲數據和Druid集群的體系結構。 我們先看看示例數據：
數據集由三個不同的組件組成： ** 1. 時間序列化列：**以時間序列進行數據分片，所有查詢以時間為中心軸。 2. 維度列：Druid基于列式存儲，查詢結果展示列，常用于數據過濾，如示例數據集有四個維度:出 版商，廣告商，性別和國家。 3. 聚合列：通常用于計算值，操作方法如：COUNT、SUM等。
三、Druid 聚合
上述例子數據集中的單條信息作用不大，因為這樣的數據萬億。然而這種類型的數據研究概述可以產生經濟效益。Druid使用我們稱之為“聚合”的過程對這些原始數據聚合操作，類似（偽代碼）如下：
Java代碼
GROUP BY timestamp, publisher, advertiser, gender, country
:: impressions = COUNT(1), clicks = SUM(click), revenue = SUM(price)
在實踐中我們看到聚合數據可以大大減少需要被存儲的數據的大小（高達100倍）。減少存儲確實是以成本為代價的，聚合數據后無法查詢單個數據的能力；另一種解決方式減少聚合粒度，盡量滿足查詢數據的最小粒度。因此Druid通過queryGranularity方法(或屬性granularity)定義這個粒度查詢數據，最低支持為毫秒。 通過上述偽代碼聚合后的數據：
四、Druid 分片數據
Druid的分片稱之為Segment（即段），通常按時間對數據進行分片。如對示例數據進行壓縮，我們可以創建兩個段，按每小時分片。 段是保存時間間隔內數據，段包含按列存儲的數據以及這些列的索引，Druid查詢索引掃描段。段由數據源、間隔、版本的唯一標識，和一個可選的分區號。段命名規范如：datasource_interval_version_partitionnumber例如：
五、Druid 索引數據
Druid查詢速度取決于如何存儲數據。從搜索基礎架構借用想法，Druid創建只讀數據快照，查詢分析存儲在高度優化的數據結構。 Druid是一個列存儲，每列被單獨存儲。Druid查詢相當好，是因為只查詢所需的列。不同的列還可以采用不同的壓縮方式，不同的列也可以有與它們相關的不同的索引。 Druid 索引數據在數據分片級別上。
六、Druid 數據加載
Druid有兩方式獲取數據，實時和批量，Druid實時獲取很費勁，確切的說Druid不能保證實時獲取。批量獲取可以保證批量創建段及相應數據。Druid通常采用實時管道獲取實時數據（最近數據），采用批管道獲取副本數據。
七、Druid 數據查詢
Druid的本地查詢語言是JSON通過HTTP，雖然社區在眾多的語言中提供了查詢庫，包括SQL查詢貢獻庫；Druid設計用于單表操作，目前不支持聯接。許多產品準備在ETL集成，數據加載到Druid之前需要規范化。
八、Druid 集群
Druid是由不同角色的系統構建而成的一個整體系統，它的名字來自在許多角色扮演游戲中的Druid類：它是一個shape-shifter，可以在一個群組中采取許多不同的形式來滿足各種不同的角色。Druid的整體架構中目前包括以下節點類型：** 1. Historical ** 對“historical”數據（非實時）進行處理存儲和查詢的地方。historical節點響應從broker節點發來的查詢，并將結果返回給broker節點。它們在Zookeeper的管理下提供服務，并使用Zookeeper監視信號加載或刪除新數據段。** 2. Realtime** 實時攝取數據，它們負責監聽輸入數據流并讓其在內部的Druid系統立即獲取，Realtime節點同樣只響應broker節點的查詢請求，返回查詢結果到broker節點。舊數據會被從Realtime節點轉存至Historical節點。** 3. Coordinator** 監控historical節點組，以確保數據可用、可復制，并且在一般的“最佳”配置。它們通過從MySQL讀取數據段的元數據信息，來決定哪些數據段應該在集群中被加載，使用Zookeeper來確定哪個historical節點存在，并且創建Zookeeper條目告訴historical節點加載和刪除新數據段。** 4. Broker ** 接收來自外部客戶端的查詢，并將這些查詢轉發到Realtime和Historical節點。當Broker節點收到結果，它們將合并這些結果并將它們返回給調用者。由于了解拓撲，Broker節點使用Zookeeper來確定哪些Realtime和Historical節點的存在。** 5. Indexer** 節點會形成一個加載批處理和實時數據到系統中的集群，同時會對存儲在系統中的數據變更（也稱為索引服務）做出響應。這種分離讓每個節點只關心自身的最優操作。通過將Historical和Realtime分離，將對進入系統的實時流數據監控和處理的內存分離。通過將Coordinator和Broker分離，把查詢操作和維持集群上的“好的”數據分布的操作分離。數據流和各個節點的關系如下圖: 相關節點和集群管理所依賴的其他組件（Zookeeper）如下：
最后編輯于 ：
?著作權歸作者所有,轉載或內容合作請聯系作者
平臺聲明：文章內容（如有圖片或視頻亦包括在內）由作者上傳并發布，文章內容僅代表作者本人觀點，簡書系信息發布平臺，僅提供信息存儲服務。
