1、Druid在滴滴的應(yīng)用平臺(tái)化建設(shè)技術(shù)創(chuàng)新，變革未來Druid特性簡(jiǎn)介Druid在滴滴的應(yīng)用Druid平臺(tái)化建設(shè)010203目 錄展望04Druid是針對(duì)時(shí)間序列數(shù)據(jù)提供低延時(shí)的數(shù)據(jù)寫入以及快速交互 式查詢的分布式OLAP數(shù)據(jù)庫(kù)。Druid特性介紹-Druid是什么？TSDB(Time-series database)時(shí)間序列數(shù)據(jù)低延時(shí)寫入快速聚合查詢典型的TSDB：InfluxDB、Graphite、OpenTSDB寫入即可查 內(nèi)存增量索引下采樣，RDD 預(yù)聚合Schema less 需要預(yù)先定義schemaDruid特性介紹-時(shí)序數(shù)據(jù)庫(kù)OLAP數(shù)據(jù)庫(kù) - 上卷、切塊、切片、下鉆等操作數(shù)據(jù)檢索

2、引擎 ES預(yù)計(jì)算 + kv存儲(chǔ) - KylinSQL on Hadoop Presto、SparkSQLDruid特性介紹-OLAP數(shù)據(jù)庫(kù)數(shù)據(jù)檢索引擎 ES 結(jié)構(gòu)化數(shù)據(jù)與非結(jié)構(gòu)化數(shù)據(jù)，明細(xì)查詢與聚合能力 存儲(chǔ)空間開銷大 數(shù)據(jù)的寫入與聚合開銷大Druid 結(jié)構(gòu)化數(shù)據(jù) & 預(yù)聚合結(jié)構(gòu)化數(shù)據(jù) 較弱的明細(xì)查詢能力存儲(chǔ)空間更小針對(duì)數(shù)據(jù)的寫入與聚合進(jìn)行優(yōu)化Druid特性介紹-OLAP數(shù)據(jù)庫(kù)預(yù)計(jì)算 + kv存儲(chǔ) - KylinKV存儲(chǔ)通過預(yù)計(jì)算來實(shí)現(xiàn)聚合，key涵蓋了查詢參數(shù)，值就是查詢結(jié)果查詢速度極快損失了查詢的靈活性，復(fù)雜的場(chǎng)景下，預(yù)計(jì)算過程可能十分耗時(shí)只有前綴拼配一種索引方式，大數(shù)據(jù)量下復(fù)雜過濾條件性

3、能下降缺少聚合下推的能力Druid 列式存儲(chǔ) & Bitmap索引查詢速度不如KV存儲(chǔ)內(nèi)存增量索引，增量預(yù)聚合，寫入即可查任意維度列組合過濾、聚合，查詢靈活Scatter & Gather模式，支持一定的聚合下推Druid特性介紹-OLAP數(shù)據(jù)庫(kù)SQL on Hadoop SQL支持強(qiáng)大 無冗余數(shù)據(jù)，不需要預(yù)處理 分鐘級(jí)響應(yīng) QPS 低DruidSQL支持有限必須預(yù)先定義維度指標(biāo)亞秒級(jí)響應(yīng)高并發(fā)Druid特性介紹-OLAP數(shù)據(jù)庫(kù)Druid在滴滴的應(yīng)用-使用概況規(guī)模多個(gè)集群數(shù)百臺(tái)機(jī)器千億級(jí)日原始數(shù)據(jù)寫入量TB級(jí)日落盤數(shù)據(jù)量數(shù)百實(shí)時(shí)數(shù)據(jù)源，千級(jí)實(shí)時(shí)寫入任務(wù)近千萬級(jí)日查詢量承接業(yè)務(wù)監(jiān)控、實(shí)時(shí)報(bào)表、大

4、屏展示等業(yè)務(wù)Druid在滴滴的應(yīng)用-應(yīng)用案例業(yè)務(wù)實(shí)時(shí)監(jiān)控承接公司所有核心業(yè)務(wù)的指標(biāo)監(jiān)控與告警Druid在滴滴的應(yīng)用-應(yīng)用案例實(shí)時(shí)報(bào)表類應(yīng)用運(yùn)營(yíng)數(shù)據(jù)分析、客戶端網(wǎng)絡(luò)性能分析、客服應(yīng)答實(shí)時(shí)統(tǒng)計(jì)等等Druid在滴滴的應(yīng)用-應(yīng)用案例大屏展示類應(yīng)用客服服務(wù)狀態(tài)大屏Druid平臺(tái)化建設(shè)背景業(yè)務(wù)數(shù)據(jù)主要來源，日志、binlog公司統(tǒng)一數(shù)據(jù)通道Kafka業(yè)務(wù)監(jiān)控指標(biāo)多樣，邏輯復(fù)雜多變Druid接入配置較復(fù)雜，工單接入方式成本高數(shù)據(jù)進(jìn)入Druid之前通常需要流計(jì)算處理數(shù)據(jù)鏈路較長(zhǎng)，上下游關(guān)系需要梳理Druid服務(wù)需要提供數(shù)據(jù)可視化能力Druid平臺(tái)化建設(shè)實(shí)時(shí)計(jì)算平臺(tái)提供流計(jì)算，Druid數(shù)據(jù)儲(chǔ)存，指標(biāo)查詢，數(shù)據(jù)

5、可視化一站式服務(wù)。Druid平臺(tái)化建設(shè)基本工作流Druid數(shù)據(jù)源用戶自助接入Druid平臺(tái)化建設(shè)Druid查詢Web化配置，100%SQLDruid平臺(tái)化建設(shè)Druid平臺(tái)化建設(shè)-穩(wěn)定性挑戰(zhàn)核心業(yè)務(wù)與非核心業(yè)務(wù)共享資源，存在風(fēng)險(xiǎn)。用戶提交任務(wù)配置、查詢不合理，造成異常狀況，甚至影響集群穩(wěn)定性。隨著業(yè)務(wù)的快速發(fā)展，Druid依賴組件熱遷移到獨(dú)立部署環(huán)境。針對(duì)不同重要程度的業(yè)務(wù)共享資源的問題Druid集群異地雙活，核心數(shù)據(jù)源集群級(jí)雙活統(tǒng)一網(wǎng)關(guān)建設(shè)對(duì)用戶屏蔽多集群細(xì)節(jié)根據(jù)用戶身份進(jìn)行查詢路由，實(shí)現(xiàn)查詢資源隔離業(yè)務(wù)分級(jí)：核心業(yè)務(wù)集群級(jí)雙活；對(duì)查詢資源需求較高的大業(yè)務(wù)分配獨(dú)立查詢資源組其他使用默認(rèn)資源池

6、Druid平臺(tái)化建設(shè)-穩(wěn)定性異地雙活、業(yè)務(wù)分級(jí)、資源隔離Druid平臺(tái)化建設(shè)-穩(wěn)定性Druid平臺(tái)化建設(shè)-穩(wěn)定性針對(duì)用戶配置與查詢不合理造成的異常引擎層面bad case防范（earlyMessageRejectPeriod的case）封裝druid原生API，提供更合理的默認(rèn)配置項(xiàng)完善指標(biāo)監(jiān)控體系與異常定位手段，確保能捕捉到異常查詢?nèi)罩九c指標(biāo)收集結(jié)合Druid的聚合查詢能力與ES的明細(xì)查詢能力進(jìn)行問題定位第三方依賴熱遷移Zookeeper遷移：擴(kuò)容-集群分裂-縮容的遷移方案zk1zk2zk3zk1zk2zk3zk5zk6zk7zk4zk1zk2zk3zk5zk6zk7zk4zk1zk2zk3

7、zk5zk6zk7zk4zk1zk2zk3zk5zk6zk7zk4zk1zk2zk3zk5zk6zk7zk41.2.3.4.5.6.Druid平臺(tái)化建設(shè)-穩(wěn)定性第三方依賴熱遷移MySQL遷移：開發(fā)實(shí)時(shí)任務(wù)狀態(tài)凍結(jié)API（針對(duì)Kafka-indexing-service），保證元數(shù) 據(jù)的不變性，隨后進(jìn)行遷移Druid平臺(tái)化建設(shè)-穩(wěn)定性第三方依賴熱遷移HDFS遷移：保證歷史節(jié)點(diǎn)可以讀取兩個(gè)HDFS集群，混動(dòng)升級(jí)MM，改變?cè)隽繑?shù)據(jù)寫入 地址；批量修改元數(shù)據(jù)，改變存量數(shù)據(jù)的加載地址。Druid平臺(tái)化建設(shè)-穩(wěn)定性Druid平臺(tái)化建設(shè)-性能優(yōu)化實(shí)時(shí)數(shù)據(jù)接入方式對(duì)比Standalone Realtime N

8、ode數(shù)據(jù)消費(fèi)任務(wù)為單機(jī)模式，任務(wù)失敗后無法恢復(fù)使用Kafka高階API，多任務(wù)消費(fèi)數(shù)據(jù)時(shí)，難以保證副本任務(wù)消費(fèi)相同的數(shù)據(jù)Tranquility + indexing-service任務(wù)失敗后無法恢復(fù)，如果所有副本任務(wù)都失敗，那么還是會(huì)丟失數(shù)據(jù)數(shù)據(jù)遲到容忍窗口與任務(wù)時(shí)長(zhǎng)掛鉤，無法做到容忍較長(zhǎng)時(shí)間的數(shù)據(jù)遲到Kafka-indexing-service實(shí)時(shí)任務(wù)數(shù)據(jù)消費(fèi)依賴Overlord服務(wù)，所以O(shè)verlord單機(jī)性能將會(huì)成為集群規(guī)模的瓶頸由于Segment與Kafka topic的partition關(guān)聯(lián)，容易造成元數(shù)據(jù)過度膨脹，引發(fā)性能問題Druid平臺(tái)化建設(shè)-性能優(yōu)化問題背景：主要Kafka

9、-indexing-service作為數(shù)據(jù)寫入方式，具有高可用、接入便捷的優(yōu)勢(shì)，但是高度依賴Overlord節(jié)點(diǎn)服務(wù)。 Overlord節(jié)點(diǎn)高峰期的性能瓶頸導(dǎo)致：Druid消費(fèi)能力下降實(shí)時(shí)任務(wù)調(diào)度不及時(shí)，實(shí)時(shí)任務(wù)狀態(tài)判斷錯(cuò)誤經(jīng)過定位，瓶頸有以下原因Mysql查詢性能問題元數(shù)據(jù)JSON化存儲(chǔ)，反序列化耗時(shí)ZK watch回調(diào)單線程模型事件處理排隊(duì)Druid平臺(tái)化建設(shè)-性能優(yōu)化針對(duì)Mysql查詢瓶頸Druid元數(shù)據(jù)存儲(chǔ)索引優(yōu)化元數(shù)據(jù)合并精簡(jiǎn)，Segment定時(shí)Merge，合理設(shè)置數(shù)據(jù)生命周期數(shù)據(jù)庫(kù)連接池DBCP2參數(shù)修改針對(duì)反序列化與Watch回調(diào)問題對(duì)Druid進(jìn)行多Overlord改造，引入namespace概念，增加Overlord水平擴(kuò)展能力MM1MM3MM2tasktasktasktasktasknam espace:n1nam espace:n2展望Druid數(shù)據(jù)消費(fèi)能力依賴kafka topic的partition，引入Flink等流計(jì)算引擎，