2024Druid原理及產(chǎn)險(xiǎn)實(shí)踐

今天分享的內(nèi)容分為兩部分，第一部分是Druid原理，包括相關(guān)選型、原理、架構(gòu)以及調(diào)優(yōu)經(jīng)驗(yàn)。第二部分是BDAS使用場景，是基于Druid做的監(jiān)控日志報(bào)表系統(tǒng)。DruidMOLAPMMDBPreAGG，是一個(gè)如kafka插件、mysql插件、hdfs插件等。我們從去年五月份做技術(shù)選型，sparkSchemafree，之前不用最后沒有選用spark是因?yàn)椴l(fā)量上不去，因?yàn)槲覀儤I(yè)務(wù)并發(fā)量可能上千，使用spark很容易造成高溫。ElasticSearch也是很熱門的一個(gè)領(lǐng)域，大家常見的理解就是一個(gè)全文搜索的引擎，其實(shí)在分析方面也有很多新技術(shù)。其特性也是Schemafree，本身架構(gòu)兼容這種數(shù)據(jù)格式，對比Druid的優(yōu)點(diǎn)是會保存原始數(shù)據(jù)。同時(shí)擁有一個(gè)完整的技術(shù)棧（elk），非要做倒排索引，但是索引數(shù)據(jù)量和原始數(shù)據(jù)相差不大，最后舍棄。Druid亞秒級，數(shù)據(jù)可用毫秒級，基本滿足需求；Lambda架構(gòu)，擴(kuò)張性、容錯(cuò)性高，我們選用Druid。SQLonHadoopMPP（大規(guī)模并行處理）CS（列式存儲），特性，SQL支持良好，定制化硬件，天花板低（PB級別以下），非線性拓展，擴(kuò)容需要停Druid，將其定位為實(shí)時(shí)可用一個(gè)上升的SaaS層服務(wù)，支持大型冷數(shù)據(jù)上的OLAP場景，實(shí)現(xiàn)對一個(gè)多維度高基數(shù)的亞秒縮。SegmentDruidtimestamp接下來講一下Druid數(shù)據(jù)流轉(zhuǎn)，流轉(zhuǎn)圖中有很多節(jié)點(diǎn)，每個(gè)節(jié)點(diǎn)都有自己的職責(zé)。中間有zookeeper，每一個(gè)節(jié)點(diǎn)都或多或少與其相連，zookeeperzookeeperBrokerREST些查詢轉(zhuǎn)發(fā)到Realtime和Historical節(jié)點(diǎn)。從這兩個(gè)節(jié)點(diǎn)拿數(shù)據(jù)，然后將節(jié)點(diǎn)返回給HistoricalBroker在查詢數(shù)據(jù)時(shí)現(xiàn)在本地找，然后在深度存儲里查找，查找到后返回給Broker，沒有與其他節(jié)點(diǎn)關(guān)聯(lián)。在Zookeeper的管理下提供服務(wù)，并使用Zookeeper監(jiān)視信號加載或刪除互相不通信，同樣利用zookeeper同步，將信息解耦開來。用、可復(fù)制，并且處于“最佳”配置。同時(shí)通過從MySQL讀取數(shù)據(jù)段的元數(shù)據(jù)信息，來決定哪些數(shù)據(jù)段應(yīng)該在集群中被加載，使用Zookeeper來確定哪個(gè)Historical節(jié)點(diǎn)存Zookeeper條目告訴Historical節(jié)點(diǎn)加載和刪除新數(shù)據(jù)段。該節(jié)點(diǎn)可以是一個(gè)，多個(gè)的節(jié)點(diǎn)進(jìn)行選舉產(chǎn)生Leader，其余節(jié)點(diǎn)作為備份，一般兩個(gè)也是滿足需求的。實(shí)時(shí)節(jié)點(diǎn)Realtime是實(shí)時(shí)攝取數(shù)據(jù)，負(fù)責(zé)監(jiān)聽輸入數(shù)據(jù)流并讓其在內(nèi)部的Druid系統(tǒng)立broker回給broker。如果Realtime和Historical節(jié)點(diǎn)同時(shí)返回同一種數(shù)據(jù)，Broker會認(rèn)為身會存儲數(shù)據(jù)，如果超過一段時(shí)間窗口會將數(shù)據(jù)傳入深度存儲，深度存儲將數(shù)據(jù)提供給Historical節(jié)點(diǎn)。MySQLzookeeperDruidDeepStorageHDFSS3或本地磁盤，用來保存“冷數(shù)據(jù)”，有兩個(gè)個(gè)數(shù)據(jù)來源，一個(gè)是批數(shù)據(jù)攝入,另一個(gè)來自實(shí)時(shí)節(jié)點(diǎn)；ZooKeeperMySQL局部過熱，影響查詢性能。沒有絕對master丟棄掉，就會出現(xiàn)數(shù)據(jù)庫性能問題。社區(qū)比較成熟的框架就是數(shù)據(jù)實(shí)時(shí)進(jìn)來寫到kafka，kafka數(shù)據(jù)兩次消費(fèi)，一次在存儲節(jié)點(diǎn)上，一次在Hadoop上，如果數(shù)據(jù)不完整就再在Hadoop做一次embedding操作，補(bǔ)回?cái)?shù)據(jù)。上面是一個(gè)推薦的架構(gòu)，希望broker節(jié)點(diǎn)越多越好，Coordinator節(jié)點(diǎn)兩個(gè)，overload對于broker消耗內(nèi)存大戶，建議20G-30G堆內(nèi)存，歷史節(jié)點(diǎn)除了內(nèi)存還有硬盤消耗，希望用更多的內(nèi)存去釋放硬盤的IO，Coordinator消耗內(nèi)存相對較小，只需要滿足要求即可。查詢時(shí)盡量做一些聚合優(yōu)化，在攝入就做聚合，盡量少去groupbyHistorical和Realtime分離，Coordinator和Broker分離，在Broker上加Nginx做負(fù)，讓Cognos（Oracle）處理清單報(bào)表，上線有十年歷史。隨著數(shù)據(jù)量的增長、以及分析處理的訴求增加，Cognos在cube過大時(shí)受限的DBASDruidhive分析，12Druid，實(shí)現(xiàn)多維分析功能。線上一共有數(shù)十個(gè)數(shù)據(jù)源，最大數(shù)據(jù)間<2s。接下來介紹下在HDFS下的使用場景，第一種是透視圖概念，用戶在某一定條件（不斷衰減）查看數(shù)據(jù)大體概要，一般采用TopN查詢，秒級響應(yīng)。響應(yīng)方式是在前端一個(gè)維度一個(gè)維度拖動，后端將上一次結(jié)果緩存，最后只查詢幾個(gè)維度。TopN查詢第一次查詢只查redis查詢速度明顯下降。我們引入單線程當(dāng)初考慮了兩種方式，第一種方式是依次將N個(gè)維度topNM*N*PtopN的時(shí)間，這樣存在一個(gè)問題就是順序不能保障。第二種方式采用遞歸的方式，并統(tǒng)一由線程池執(zhí)行（是不是線程開線程？不是）AAB改為維度A+A1A+A2A+A1B+B1，這樣可以充分利用Druid序，花費(fèi)的時(shí)間可能多點(diǎn)，，大約需要N*M個(gè)topN的時(shí)間。都將其組裝成一起，當(dāng)超過4-5個(gè)維度就會效率很低。改進(jìn)的方式也是采用多線程，前面b