druid 是 metamarket 公司研發，專為海量資料集上的做高效能 olap (online analysis processing)而設計的資料儲存和分析系統，目前druid已經在apache**會下孵化。druid的主要特性：
druid常見應用的領域：
druid 的架構是 lambda 架構，分成實時層( overlord、 middlemanager )和批處理層( broker 和 historical )。主要的節點包括（ps: druid 的所有功能都在同乙個軟體包中，通過不同的命令啟動）：
有讚 olap 平台的主要目標：
有讚 olap 平台架構
有讚 olap 平台是用來管理 druid 和周圍元件管理系統，olap平台主要的功能：
olap 平台採用的資料攝取方式是tranquility工具，根據流量大小對每個 datasource 分配不同 tranquility 例項數量； datasource 的配置會被推送到 agent-master 上，agent-master 會收集每台伺服器的資源使用情況，選擇資源豐富的機器啟動 tranquility 例項，目前只要考慮伺服器的記憶體資源。同時 olap 平台還支援 tranquility 例項的啟停，擴容和縮容等功能。
流式資料處理框架都會有時間視窗，遲於視窗期到達的資料會被丟棄。如何保證遲到的資料能被構建到 segment 中，又避免實時任務視窗長期不能關閉。我們研發了 druid 資料補償功能，通過 olap 平台配置流式 etl 將原始的資料儲存在 hdfs 上，基於 flume 的流式 etl 可以保證按照 event 的時間，同一小時的資料都在同乙個檔案路徑下。再通過 olap 平台手動或者自動觸發 hadoop-batch 任務，從脫機構建 segment。
基於 flume 的 etl 採用了 hdfs sink 同步資料，實現了 timestamp 的 interceptor，按照 event 的時間戳字段來建立檔案(每小時建立乙個資料夾)，延遲的資料能正確歸檔到相應小時的檔案中。
隨著接入的業務增加和長期的執行時間，資料規模也越來越大。historical 節點載入了大量 segment 資料，觀察發現大部分查詢都集中在最近幾天，換句話說最近幾天的熱資料很容易被查詢到，因此資料冷熱分離對提高查詢效率很重要。druid 提供了historical 的 tier 分組機制與資料載入 rule 機制，通過配置能很好的將資料進行冷熱分離。
首先將 historical 群進行分組，預設的分組是"_default_tier"，規劃少量的 historical 節點，使用 sata 盤；把大量的 historical 節點規劃到 "hot" 分組，使用 ssd 盤。然後為每個 datasource 配置載入 rule :
, "period":"p30d"}
, "period":"p180d"}
druid 架構中的各個元件都有很好的容錯性，單點故障時集群依然能對外提供服務：coordinator 和 overlord 有 ha 保障；segment 是多副本儲存在hdfs/s3上；同時 historical 載入的 segment 和 peon 節點攝取的實時部分資料可以設定多副本提供服務。同時為了能在節點/集群進入不良狀態或者達到容量極限時，盡快的發出報警資訊。和其他的大資料框架一樣，我們也對 druid 做了詳細的監控和報警項，分成了2個級別：
目前比較常用的資料攝取方案是：kafkaindex 和 tranquility 。我們採用的是 tranquility 的方案，目前 tranquility支援了 kafka 和 http 方式攝取資料，攝取方式並不豐富；tranquility 也是 metamarket 公司開源的專案，更新速度比較緩慢，不少功能缺失，最關鍵的是監控功能缺失，我們不能監控到例項的執行狀態，攝取速率、積壓、丟失等資訊。
目前我們對 tranquility 的例項管理支援啟停，擴容縮容等操作，實現的方式和 druid 的 middlemanager 管理 peon 節點是一樣的。把 tranquility 或者自研攝取工具轉換成 yarn 應用或者 docker 應用，就能把資源排程和例項管理交給更可靠的排程器來做。
druid 目前並不沒有支援join查詢，所有的聚合查詢都被限制在單 datasource 內進行。但是實際的使用場景中，我們經常需要幾個 datasource 做 join 查詢才能得到所需的結果。這是我們面臨的難題，也是 druid 開發團隊遇到的難題。
對於 c 端的 olap 查詢場景，rt 要求比較高。由於 druid 會在整點建立當前小時的index任務，如果查詢正好落到新建的 index 任務上，查詢的毛刺很大，如下圖所示：
我們已經進行了一些優化和調整，首先調整 warmingperiod 引數，整點前啟動 druid 的 index 任務；對於一些 tps 低，但是 qps 很高的 datasource ，調大 segmentgranularity，大部分 query 都是查詢最近24小時的資料，保證查詢的資料都在記憶體中，減少新建 index 任務的，查詢毛刺有了很大的改善。儘管如此，離我們想要的目標還是一定的差距，接下去我們去優化一下原始碼。
現在大部分 datasource 的 segment 粒度( segmentgranularity )都是小時級的，儲存在 hdfs 上就是每小時乙個segment。當需要查詢時間跨度比較大的時候，會導致query很慢，占用大量的 historical 資源，甚至出現 broker oom 的情況。如果 olap 平台能提供乙個功能自動提交 hadoop-batch 任務，把一周前(舉例)的資料按照天粒度 rull-up 並且 rebuild index，應該會在壓縮儲存和提公升查詢效能方面有很好的效果。
訪客路徑分析 Druid實踐
訪客分析是常見資料分析的一種，通過如上圖 google analytics 以比較直觀的方式展現使用者達到 後各條訪問路徑的流失情況，幫助 優化減少流失率。訪客路徑分析有如下幾個關鍵點 通過上述分析，要實現訪客路徑分析需要完成如下幾項工作 計算每一級所有網頁的會話總數。計算每一級會話數top 5的網...
Druid是什麼和Druid的介紹
druid的簡介 druid首先是乙個資料庫連線池。druid是目前最好的資料庫連線池，在功能 效能 擴充套件性方面，都超過其他資料庫連線池，包括dbcp c3p0 bonecp proxool jboss datasource。druid已經在阿里巴巴部署了超過600個應用，經過一年多生產環境大規...
Druid是什麼和Druid的介紹
druid的簡介 druid首先是乙個資料庫連線池。druid是目前最好的資料庫連線池，在功能 效能 擴充套件性方面，都超過其他資料庫連線池，包括dbcp c3p0 bonecp proxool jboss datasource。druid已經在阿里巴巴部署了超過600個應用，經過一年多生產環境大規...