1、 Druid平臺的原理及實踐本文的內容分為兩部分，第一部分是Druid原理，包括相關選型、原理、架構以及調優經驗。第二部分是BDAS使用場景，是基于Druid做的監控日志報表系統。Druid非阿里開源的數據連接池，是一個MOLAP數據庫，架構是MMDB架構，是一個多節點的系統。同時也是一個內存數據庫，面向列的存儲。同時會使用PreAGG，是一個NoSQL數據庫，處理記錄與時間有強關聯的時序數據庫。Druid同時在社區支持很多插件，如kafka插件、mysql插件、hdfs插件等。我們從去年五月份做技術選型，spark是用的比較廣的框架，特性Schema free，之前不用先定義數據格式就可以做

2、存儲解析；效率高（中間結果不落盤），響應時間依據數據量而定。最后沒有選用spark是因為并發量上不去，因為我們業務并發量可能上千，使用spark很容易造成高溫。Elastic Search也是很熱門的一個領域，大家常見的理解就是一個全文搜索的引擎，其實在分析方面也有很多新技術。其特性也是Schemafree，本身架構兼容這種數據格式，對比Druid的優點是會保存原始數據。同時擁有一個完整的技術棧（elk），非常通用完善。在分析的基礎上有一個檢索的功能。其實選擇什么框架需要依據具體的場景，不同場景不同框架有不同的優勢。支持高基維，但是缺點是數據量上不去，有時數據入庫需要做倒排索引，但是索引數據量

3、和原始數據相差不大，最后舍棄。Druid需要預先定義維度和指標，還支持預聚合，根據時間或維度做預聚合，這樣入庫后會丟棄原始數據。數據響應亞秒級，數據可用毫秒級，基本滿足需求；Lambda 架構，擴張性、容錯性高，我們選用的是Druid。SQL on Hadoop主要技術為MPP（大規模并行處理）和CS（列式存儲），特點是吞吐量大需要離線批量處理，我們目前是實時與離線并行使用。其他商業產品企業級特性，SQL支持良好，定制化硬件，天花板低（PB級別以下），非線性拓展，擴容需要停機維護，最重要的一點是二次開發困難。最后技術選型為Druid，將其定位為實時可用一個上升的SaaS層服務，支持大型冷數據上

4、的OLAP 場景，實現對一個多維度高基數的亞秒級響應的支持。下面是原始數據從一開始的產生到入庫的一些概念，原始數據有點類似傳統數據庫格式，而發表者、廣告商我們認為是一個多維度，在入庫時都要定義好。Druid還有一個特性就是面向行級別依據時間做切分，不同的行可能會切到不同的segment里面，對于列會做一個壓縮。Segment是Druid存儲的基本單元，是以timestamp進行數據分塊的，這樣做的好處是查詢的時候可以避免全局掃描，查詢就是遍歷起始時間終止時間并找到對應數據塊，因此查詢場景比較快，真實的數據塊命名格式為數據源加開始時間和結束時間。需要注意的是如果是比較大的場景，幾個小時數據量可能

5、就達到TB級別，這時建議在數據塊上再做一個分塊。接下來講一下Druid數據流轉，流轉圖中有很多節點，每個節點都有自己的職責。中間有一個zookeeper，每一個節點都或多或少與其相連，zookeeper在其中負責同步作用，每一個節點不會做強關聯工作，只需要用zookeeper同步。從左到右是一個數據寫入過程，有離線數據和批量數據。中樞節點Broker是查詢節點，對外提供 REST 接口，接受來自外部客戶端的查詢，并將這些查詢轉發到 Realtime 和 Historical 節點。從這兩個節點拿數據，然后將節點返回給Broker，將數據進行合并返回給客戶端。這里broker節點起到一個轉發和合

6、并的作用，合并過程需要規定的內存，推薦配置內存相對大一點。歷史節點Historical 節點是非實時數據進行處理存儲和查詢的地方，只響應Broker請求。在查詢數據時現在本地找，然后在深度存儲里查找，查找到后返回給Broker，沒有與其他節點關聯。在 Zookeeper 的管理下提供服務，并使用 Zookeeper 監視信號加載或刪除新數據段。這個節點也是非常吃內存，該節點可以多個節點，建議使用多個節點，每個節點互相不通信，同樣利用zookeeper同步，將信息解耦開來。Coordinator扮演一個管理者的角色，負責Historical節點組的數據負載均衡，確保數據可用、可復制，并且處于“最

7、佳”配置。同時通過從My SQL讀取數據段的元數據信息，來決定哪些數據段應該在集群中被加載，使用 Zookeeper 來確定哪個 Historical 節點存在，并且創建Zookeeper 條目告訴 Historical 節點加載和刪除新數據段。該節點可以是一個，多個的節點進行選舉產生 Leader，其余節點作為備份，一般兩個也是滿足需求的。實時節點Realtime是實時攝取數據，負責監聽輸入數據流并讓其在內部的 Druid 系統立即獲取。如果不需要實時加載數據就可以將該節點去掉，他只會響應broker請求將數據返回給broker。如果Realtime和Historical節點同時返回同一種數

8、據，Broker會認為Historical節點數據是可信的，如果數據進入深度存儲Druid默認數據是不變的。該節點本身會存儲數據，如果超過一段時間窗口會將數據傳入深度存儲，深度存儲將數據提供給Historical節點。MySQL、zookeeper、深度存儲都是Druid的外部依賴，Deep Storage：可以是 HDFS 或 S3 或本地磁盤，用來保存“冷數據”，有兩個個數據來源，一個是批數據攝入, 另一個來自實時節點；ZooKeeper 集群：為集群服務發現和維持當前的數據拓撲而服務； My SQL 實例：用來維持系統服務所需的數據段的元數據，比如去哪里加載數據段、每個數據段的元信息。總

9、結下各節點間分工明確，而且職責分離，掛掉某一個節點不影響其他節點的工作，對擴容友好，容錯率高。冷熱數據分離，不同數據通過硬件資源進行物理隔離。查詢需求與數據如何在集群內分布的需求分離：確保用戶的查詢請求不會影響數據在集群內的分布情況，避免局部過熱，影響查詢性能。沒有絕對master結構，不僅僅是一個內存數據庫，增加了內存映射的能力。Lamada架構，能夠實時校正數據，如果數據進入進來節點沒有被消費掉會被丟棄掉，就會出現數據庫性能問題。社區比較成熟的框架就是數據實時進來寫到kafka，kafka數據兩次消費，一次在存儲節點上，一次在Hadoop上，如果數據不完整就再在Hadoop做一次embed

10、ding操作，補回數據。上面是一個推薦的架構，希望broker節點越多越好，Coordinator節點兩個，overload兩個，realtime其他節點也是越多越好。性能方面也會做不同性能的轉換。調優方面經驗，對于broker消耗內存大戶 ，建議 20G-30G 堆內存，歷史節點除了內存還有硬盤消耗，希望用更多的內存去釋放硬盤的IO，Coordinator 消耗內存相對較小，只需要滿足要求即可。查詢時盡量做一些聚合優化，在攝入就做聚合，盡量少去group by。Historical 和Realtime 分離，Coordinator 和Broker 分離，在Broker 上加Nginx 做負載

11、均衡，并高可用。異構硬件方面通過劃分 Tier，讓 Historical 加載不同時間范圍的數據。接下來講一下具體項目應用，產險原使用 Cognos （ Oracle ）處理清單報表，上線有十年歷史。隨著數據量的增長、以及分析處理的訴求增加，Cognos 在 cube 過大時受限的弊端日益體現，無法滿足實際生產需要。需要實現的第一個就是要快，第二個是想實現行級別的全列控制。DBAS系統從去年五月份調入Druid，九月份上線了清單功能，直接查hive上數據做業務分析，12月份完全引入Druid，實現多維分析功能。線上一共有數十個數據源，最大數據源有上百個維度，單一維度最大屬性有幾十萬萬。聚合后單

12、表行記錄有幾十億，最大單一數據源有幾十G，日均訪問量數千級，主要應用于產險內部分析，并發峰值數百，平均響應時間 2s。接下來介紹下在HDFS下的使用場景，第一種是透視圖概念，用戶在某一定條件（不斷衰減）查看數據大體概要，一般采用Top N查詢，秒級響應。響應方式是在前端一個維度一個維度拖動，后端將上一次結果緩存，最后只查詢幾個維度。Top N查詢第一次查詢只查單一維度，當增加維度在redis中取上一次緩存結果加下一維度，多維度會呈指數級增長，查詢速度明顯下降。我們引入單線程當初考慮了兩種方式，第一種方式是依次將N個維度的top N都查出來，然后構造M*N*P個多線程，這樣查詢速度會很快，大概就

13、是一個top N的時間，這樣存在一個問題就是順序不能保障。第二種方式采用遞歸的方式，并統一由線程池執行（是不是線程開線程？不是）更細粒度的緩存：如由維度A ，維度A+維度B 改為 維度A+A1，維度A+A2，維度A+A1+維度B+B1 ，這樣可以充分利用Druid的升降序，花費的時間可能多點，大約需要N*M個top N的時間。第二種場景是交叉表，分析人需要看到全量數據而不是概要數據。開始就是無論查多少維度都將其組裝成一起，當超過4-5個維度就會效率很低。改進的方式也是采用多線程，前面基本按照top N的方式構造，保留最后兩個維度進行group by，A1+B1+C維在查詢時有緩存策略，由于小集群采用block緩存，這樣可以省去網絡傳輸。兩種場景一種采用top N，一種采用group by。兩者區別top N可能會不準確，top 1000能保證前900是準確的。第三種場景