本文根據平安產險大數據開發工程師李凱勃、關志華在平安產險&DataFunTalk大數據技術沙龍中分享的《Druid原理及產險實踐》編輯整理而成。
今天分享的內容分為兩部分，第一部分是Druid原理，包括相關選型、原理、架構以及調優經驗。第二部分是BDAS使用場景，是基於Druid做的監控日誌報表系統。
Druid非阿里開源的數據連接池，是一個MOLAP數據庫，架構是MMDB架構，是一個多節點的系統。同時也是一個內存數據庫，面向列的存儲。同時會使用PreAGG，是一個NoSQL數據庫，處理記錄與時間有強關聯的時序數據庫。Druid同時在社區支持很多插件，如kafka插件、mysql插件、hdfs插件等。
我們從去年五月份做技術選型，spark是用的比較廣的框架，特性Schema free，之前不用先定義數據格式就可以做存儲解析；效率高（中間結果不落盤），響應時間依據數據量而定。最後沒有選用spark是因為併發量上不去，因為我們業務併發量可能上千，使用spark很容易造成高溫。Elastic Search也是很熱門的一個領域，大家常見的理解就是一個全文搜索的引擎，其實在分析方面也有很多新技術。其特性也是Schema free，本身架構兼容這種數據格式，對比Druid的優點是會保存原始數據。同時擁有一個完整的技術棧（elk），非常通用完善。在分析的基礎上有一個檢索的功能。其實選擇什麼框架需要依據具體的場景，不同場景不同框架有不同的優勢。支持高基維，但是缺點是數據量上不去，有時數據入庫需要做倒排索引，但是索引數據量和原始數據相差不大，最後捨棄。Druid需要預先定義維度和指標，還支持預聚合，根據時間或維度做預聚合，這樣入庫後會丟棄原始數據。數據響應亞秒級，數據可用毫秒級，基本滿足需求；Lambda 架構，擴張性、容錯性高，我們選用的是Druid。SQL on Hadoop主要技術為MPP（大規模並行處理）和CS（列式存儲），特點是吞吐量大需要離線批量處理，我們目前是實時與離線並行使用。其他商業產品企業級特性，SQL支持良好，定製化硬件，天花板低（PB級別以下），非線性拓展，擴容需要停機維護，最重要的一點是二次開發困難。最後技術選型為Druid，將其定位為實時可用一個上升的SaaS層服務，支持大型冷數據上的OLAP 場景，實現對一個多維度高基數的亞秒級響應的支持。
下面是原始數據從一開始的產生到入庫的一些概念，原始數據有點類似傳統數據庫格式，而發表者、廣告商我們認為是一個多維度，在入庫時都要定義好。Druid還有一個特性就是面向行級別依據時間做切分，不同的行可能會切到不同的segment裡面，對於列會做一個壓縮。Segment是Druid存儲的基本單元，是以timestamp進行數據分塊的，這樣做的好處是查詢的時候可以避免全局掃描，查詢就是遍歷起始時間終止時間並找到對應數據塊，因此查詢場景比較快，真實的數據塊命名格式為數據源加開始時間和結束時間。需要注意的是如果是比較大的場景，幾個小時數據量可能就達到TB級別，這時建議在數據塊上再做一個分塊。
接下來講一下Druid數據流轉，流轉圖中有很多節點，每個節點都有自己的職責。中間有一個zookeeper，每一個節點都或多或少與其相連，zookeeper在其中負責同步作用，每一個節點不會做強關聯工作，只需要用zookeeper同步。從左到右是一個數據寫入過程，有離線數據和批量數據。
中樞節點Broker是查詢節點，對外提供 REST 接口，接受來自外部客戶端的查詢，並將這些查詢轉發到 Realtime 和 Historical 節點。從這兩個節點拿數據，然後將節點返回給Broker，將數據進行合併返回給客戶端。這裡broker節點起到一個轉發和合並的作用，合併過程需要規定的內存，推薦配置內存相對大一點。
歷史節點Historical 節點是非實時數據進行處理存儲和查詢的地方，只響應Broker請求。在查詢數據時現在本地找，然後在深度存儲裡查找，查找到後返回給Broker，沒有與其他節點關聯。在 Zookeeper 的管理下提供服務，並使用 Zookeeper 監視信號加載或刪除新數據段。這個節點也是非常吃內存，該節點可以多個節點，建議使用多個節點，每個節點互相不通信，同樣利用zookeeper同步，將信息解耦開來。
Coordinator扮演一個管理者的角色，負責Historical節點組的數據負載均衡，確保數據可用、可複製，並且處於“最佳”配置。同時通過從My SQL讀取數據段的元數據信息，來決定哪些數據段應該在集群中被加載，使用 Zookeeper 來確定哪個 Historical 節點存在，並且創建Zookeeper 條目告訴 Historical 節點加載和刪除新數據段。該節點可以是一個，多個的節點進行選舉產生 Leader，其餘節點作為備份，一般兩個也是滿足需求的。
實時節點Realtime是實時攝取數據，負責監聽輸入數據流並讓其在內部的 Druid 系統立即獲取。如果不需要實時加載數據就可以將該節點去掉，他只會響應broker請求將數據返回給broker。如果Realtime和Historical節點同時返回同一種數據，Broker會認為Historical節點數據是可信的，如果數據進入深度存儲Druid默認數據是不變的。該節點本身會存儲數據，如果超過一段時間窗口會將數據傳入深度存儲，深度存儲將數據提供給Historical節點。
MySQL、zookeeper、深度存儲都是Druid的外部依賴，Deep Storage：可以是 HDFS 或 S3 或本地磁盤，用來保存“冷數據”，有兩個個數據來源，一個是批數據攝入, 另一個來自實時節點；ZooKeeper 集群：為集群服務發現和維持當前的數據拓撲而服務； My SQL 實例：用來維持系統服務所需的數據段的元數據，比如去哪裡加載數據段、每個數據段的元信息。
總結下各節點間分工明確，而且職責分離，掛掉某一個節點不影響其他節點的工作，對擴容友好，容錯率高。冷熱數據分離，不同數據通過硬件資源進行物理隔離。查詢需求與數據如何在集群內分佈的需求分離：確保用戶的查詢請求不會影響數據在集群內的分佈情況，避免局部過熱，影響查詢性能。沒有絕對master結構，不僅僅是一個內存數據庫，增加了內存映射的能力。Lamada架構，能夠實時校正數據，如果數據進入進來節點沒有被消費掉會被丟棄掉，就會出現數據庫性能問題。社區比較成熟的框架就是數據實時進來寫到kafka，kafka數據兩次消費，一次在存儲節點上，一次在Hadoop上，如果數據不完整就再在Hadoop做一次embedding操作，補回數據。
上面是一個推薦的架構，希望broker節點越多越好，Coordinator節點兩個，overload兩個，realtime 其他節點也是越多越好。性能方面也會做不同性能的轉換。調優方面經驗，對於broker消耗內存大戶 ，建議 20G-30G 堆內存，歷史節點除了內存還有硬盤消耗，希望用更多的內存去釋放硬盤的IO，Coordinator 消耗內存相對較小，只需要滿足要求即可。查詢時儘量做一些聚合優化，在攝入就做聚合，儘量少去group by。Historical 和 Realtime 分離，Coordinator 和 Broker 分離，在 Broker 上加 Nginx 做負載均衡，並高可用。異構硬件方面通過劃分 Tier，讓 Historical 加載不同時間範圍的數據。
接下來講一下具體項目應用，產險原使用 Cognos （ Oracle ）處理清單報表，上線有十年曆史。隨著數據量的增長、以及分析處理的訴求增加，Cognos 在 cube 過大時受限的弊端日益體現，無法滿足實際生產需要。需要實現的第一個就是要快，第二個是想實現行級別的全列控制。
DBAS系統從去年五月份調入Druid，九月份上線了清單功能，直接查hive上數據做業務分析，12月份完全引入Druid，實現多維分析功能。線上一共有數十個數據源，最大數據源有上百個維度，單一維度最大屬性有幾十萬萬。聚合後單錶行記錄有幾十億，最大單一數據源有幾十G，日均訪問量數千級，主要應用於產險內部分析，併發峰值數百，平均響應時間 <2s。
接下來介紹下在HDFS下的使用場景，第一種是透視圖概念，用戶在某一定條件（不斷衰減）查看數據大體概要，一般採用Top N查詢，秒級響應。響應方式是在前端一個維度一個維度拖動，後端將上一次結果緩存，最後只查詢幾個維度。Top N查詢第一次查詢只查單一維度，當增加維度在redis中取上一次緩存結果加下一維度，多維度會呈指數級增長，查詢速度明顯下降。我們引入單線程當初考慮了兩種方式，第一種方式是依次將N個維度的top N都查出來，然後構造M*N*P個多線程，這樣查詢速度會很快，大概就是一個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是準確的。
第三種場景就是指標計算，第一種方式是先將其計算出來存儲到hive上，到進入Druid，這樣消耗很大。第二種方式是在Druid中計算，每次查詢自定義就可以比較快的得到結果。
維度合併和隱藏，合併是用戶希望把一些屬性值統一對待，隱藏就是減少眼睛干擾，其實更好的方式是減少一個維度就好。第四個就是實現行全權控制，這是需要接入用戶賬號才能實現，用戶有一個department code，因此在每個數據源都設置了四個列，過濾後達到行全權控制。
李凱勃、關志華倆位老師在大數據領域有多年工作經驗，對bdas系統、Druid數據庫系統等有深入瞭解，專注於研究和開發大數據技術在金融領域的落地應用。
——END——
閱讀更多 datafuntalk 的文章
