作者：Syn良子 出處：https://www.cnblogs.com/cssdongl/p/9588079.html 轉載請注明出處
最近在學習和使用Druid.覺得一些章節有必要按照自己的理解翻譯一下並分享出來,翻譯不到位的地方歡迎指正.
Druid是什么?
Druid是一個為大規模數據集上進行高性能的交互分析而設計的("OLAP"式)的數據存儲引擎.Druid經常用來作為數據存儲來驅動基於GUI的分析方面的應用,也可以為需要快速聚合的應用提供高並發的后端API.Druid通常包含以下一些應用:
- 點擊流分析
- 網絡流量分析
- 服務器指標存儲
- 應用性能指標
- 數字市場分析
- 商業智能/OLAP
Druid關鍵性的功能如下:
- 列式存儲.Druid使用面向列的存儲，這意味着它對一些特殊的查詢僅僅需要加載相應的列就可以了.這能帶來巨大的性能提升因為它僅僅需要查詢很少的列.此外，它的每一列是按照它自己的獨有的數據類型而進行過的優化存儲,這樣可以支持快速的掃描和聚合.
- 可擴展的分布式系統.Druid一般部署在成百上千的服務器上,它能夠實現每秒百萬級別的數據采集速率，以及萬億級別的數據記錄存儲以及亞秒級別的數據查詢延遲
- 大規模並行式處理.Druid能夠在整個集群上對查詢進行並行處理.
- 實時的或者批處理的數據攝取.Druid能夠實時的攝取數據(攝取的數據能夠立刻被用來查詢)或者以批處理的方式進行攝取。
- 自愈性,自平衡，容易管理.作為一個集群的管理者，很方便可以來擴大或者縮小集群的規模.對於后台來講，簡單的從集群上添加或者刪除服務器不用停機集群自己就能夠自動實現重新平衡.任意一個druid節點壞掉的話，集群自己就可以繞過壞點直到這些有問題的服務器被替換掉.Druid被設計成一個永不停機7*24小時無間斷運行的集群，即使配置改變以及軟件升級也不應該做為它停機的理由.
- 永遠不會丟失數據的容錯的雲原生架構.一旦Druid已經攝取了數據，那么一個備份就會被拷貝到deep storage(這個存儲方式可以是雲存儲，HDFS或者其他共享文件系統).如果單個Druid服務器失敗那么能夠從deep storage進行恢復.對於影響一部分druid服務器的有限故障，replication能夠確保查詢在服務器恢復的時候仍然是可能的
- 快速過濾的索引.Druid使用CONCISE或者Roaring壓縮的位圖索引來創建索引用於控制在多列上進行快速過濾和查詢
- 近似算法.Druid包含一些近似count-distinct,近似排名,近似直方圖和中位數這些近似算法.這些算法使用較少的內存但是通過能夠提供比精確計算更快的速度.當然，對於那些要求精確比速度更重要的場景，druid仍然能夠提供精確的計算和排名.
- 數據攝取預聚合.Druid支持在攝取數據的時候進行預聚合.這種對數據攝取的預聚合能夠節省消耗以及提升性能.
何時使用Druid
如果你的case滿足下面一些特征那么Druid應該是一個好的選擇:
- 插入數據的頻次非常高，但是修改非常少
- 你的大部分查詢時聚合和報表查詢(比如"group by"查詢).當然你可以還有一些查找和掃描的查詢
- 你的意願是希望查詢延遲在100ms到幾秒之間
- 你的數據有時間的屬性(Druid包含一些特殊的設計和優化對於時間序列)
- 你可能有不止一個表，而且每個查詢僅命中一些大的分布式的表.查詢可能也會命中不止一個小的lookup表.
- 你需要在一些高基數的列上面(比如URLS,user IDs)做一些快速的計算和排序
- 你需要從Kafka,HDFS,flat files或者對象存儲比如Amszon S3上加載數據
下面一些情況你可能不太適合用Druid:
- 你需要對已經存在的記錄利用主鍵進行低延遲的更新操作.Druid支持流式插入，但是不是更新(一般用后台的批處理任務來進行更新)
- 你正在構建一個線下的報表系統而且對查詢延遲不是非常在意
- 你想做一些大的表的關聯(比如連接大的事實表和另外一個大的事實表).