Hermes：來自騰訊的實時檢索分析平臺
實時檢索分析平臺(Hermes)是騰訊數據平臺部為大數據分析業務提供一套實時的、多維的、交互式的查詢、統計、分析系統，為各個產品在大數據的統計分析方面提供完整的解決方案，讓萬級維度、千億級數據下的秒級統計分析變為現實。
Hermes實時檢索分析場景
1、營銷分析
作為營銷人員，首先需要確認營銷目標群體，并且在什么時間以什么形式，開展什么營銷活動效果最好？首先需要找到目標群體號碼包，通過指定條件（如性別、年 齡、興趣愛好，曾經有過類似行為）提取號碼包；通過大數據分析，得知在某個時間段參與人數較多，哪種類型的活動效果更受歡迎，目標用戶群體有哪些共同特 征。掌握這些，你的營銷活動效果更加好；
2、系統運營分析
一個產品的后臺有著成千上萬個接口，各個接口的性能指標是開發人員、運維人員特別關注的，每個接口可能都有不同的版本號，要判斷系統是否穩定不是某個 時間點的數據能體現出來的，需要對比分析歷史數據才能發現潛在的問題。也許問題只出現在某個接口的某個版本中，并且只有特定版本的接口發送到特定接口才會 重現這種問題，開發人員除了大量的日志外，沒有很直觀的途徑能指導開發人員有針對性的定位問題。如果對這些性能數據進行實時的多維度的數據分析，只需要根 據問題的表象分析對應的版本號、對應的接口就能查看到對應的性能數據指標，從而快速縮小問題發生范圍，為問題定位提供高效的解決途徑。此外不同版本性能的 周期性對比、新版本上線性能跟蹤等都是系統運營分析所不可或缺的。
3、趨勢分析
當面對每天幾百幾千萬的數據，mysql等傳統的數據庫能幫你搞定，但是當你要分析周期性數據, 比如最近三十天，這個數據量，也許你沒瘋mysql就已經”瘋”了。當要分析的數據按月按年計算呢？肯定很多人考慮hadoop，沒錯，它是能幫你解決這 么大的數據量的分析工作，但是hadoop不能讓你即查即所見？一個分析人員效率高低，很多時候取決于工具的時效性，這直接影響著分析人員、運營人員的分 析思維連貫性。
4、探索性分析
很多分析人員分析的目的是驗證性的、是探索性的，在不斷的調整驗證自己的猜想最終發掘有效信息從而為產品發展找到決策性數據依據。假設你有10億的數 據量，字段數達到上百個，分析人員任何一個YY分析需求都有可能是這上百個字段其中的組合，假設我們從中取5個字段做組合分析，100個字段中取五個字段 的組合數能達到75287520，每次查詢就算耗時500毫秒，預處理也要430多天。可見，任意組合的查詢分析、即查即所見的多維組合分析是探索性分析 必需具備的”硬件”條件。
5、全文檢索
很多場景需要根據關鍵字對數據進行實時檢索服務， 目前我們支持數據的實時接入，也支持數據的批量導入。除此高效的毫秒級檢索分析服務外，我們還支持用戶對結果集的導出。
Hermes設計概要
1、架構描述
系統核心進程均采用分散化設計，根據業務發展需求，可隨意擴縮容機器；
周期性數據直接通過tdw處理落地到分布式文件系統；
實時數據加載采用先落地本地磁盤,最終落地到分布式文件系統，最終都由調度進程分發到計算層；
2、分析引擎設計
基于單個實例數據的分析處理，datasource主要包含兩類數據：用戶導入的數據(位圖文件)以及源數據(索引文件)，內核主要根據用戶請求邏輯處理索引文件以及位圖文件。
3、內核設計
整個數據對應多份，按照不同規則均勻分布在各個分析實例中，數據的merge服務在其中的一個分片中進行，每次請求將根據機器負載情況選擇負載輕的作為merge服務
4、存儲設計
通過對數據結構的重新組織，結合分析系統的特點，實現嵌套列存儲，充分避開隨機讀，采用塊讀取+位圖計算大幅度降低耗時弊病，使大數據的統計分析計算耗時縮短至秒級；
在詞條文件中采用字典排序，并在此基礎上實現前綴壓縮；
在序列文件中采用遞增排序，并對序列號采用可變長類型，有效壓縮存儲空間，便于計算位圖的構建;
5、存儲格式
存儲格式主要包含四類文件
meta文件: 描述表結構,內存文件；
詞條文件: 描述各個字段的詞條集信息,磁盤文件；
詞條索引文件: 詞條文件的跳表映射文件，用于加速定位目標詞條,內存文件；
序列號文件: 詞條出現的序列集，采用可變長類型存儲序列號, 每個詞條對應的序列號集又包含跳表映射數據塊，用于加速具體序列的定位,磁盤文件;
存儲分析過程示例：
6、流程設計
進程容災：根據進程的特殊性，采用Master-Slave或者冗余解決進程容災問題。
數據加載支持實時和周期性兩種方式。
7、數據接入
歷史數據服務：提供T+1數據以及數據補錄等場景，保證數據有效周期。
Hermes與開源的Solr、ElasticSearch的不同
1、Hermes與Solr,ES定位不同
Solr、ES：偏重于為小規模的數據提供全文檢索服務；Hermes：則更傾向于為大規模的數據倉庫提供索引支持，為大規模數據倉庫提供即席分析的解決方案，并降低數據倉庫的成本，Hermes數據量更“大”。
Solr、ES的使用特點如下：
·源自搜索引擎，側重搜索與全文檢索。
·數據規模從幾百萬到千萬不等，數據量過億的集群特別少。有可能存在個別系統數據量過億，但這并不是普遍現象（就像Oracle的表里的數據規模有可能超過Hive里一樣，但需要小型機）。
Hermes:的使用特點如下：
·一個基于大索引技術的海量數據實時檢索分析平臺。側重數據分析。
·數據規模從幾億到萬億不等。最小的表也是千萬級別。在騰訊17 臺TS5機器，就可以處理每天450億的數據(每條數據1kb左右)，數據可以保存一個月之久。
2、Hermes與Solr,ES在技術實現上也會有一些區別
Solr、ES在大索引上存在的問題：
一級跳躍表是完全Load在內存中的。這種方式需要消耗很多內存不說，首次打開索引的加載速度會特別慢。在Solr\ES中的索引是一直處于打開狀態的，不會頻繁的打開與關閉；這種模式會制約一臺機器的索引數量與索引規模，通常一臺機器固定負責某個業務的索引。
為了排序，將列的全部值Load到放到內存里。排序和統計（sum，max，min）的時候，是通過遍歷倒排表， 將某一列的全部值都Load到內存里，然后基于內存數據進行統計，即使一次查詢只會用到其中的一條記錄，也會將整列的全部值都Load到內存里,太浪費資 源，首次查詢的性能太差。數據規模受物理內存限制很大，索引規模上千萬后OOM是常事。
索引存儲在本地硬盤，恢復難.一旦機器損壞，數據即使沒有丟失，一個幾T的索引，僅僅數據copy時間就需要好幾個小時才能搞定。
集群規模太小.支持Master/Slave模式，但是跟傳統MySQL數據庫一樣，集群規模并沒有特別大的（百臺以內）。這種模式處理集群規模受限外，每次擴容的數據遷移將是一件非常痛苦的事情，數據遷移時間太久。
數據傾斜問題。倒排檢索即使某個詞語存在數據傾斜，因數據量比較小，也可以將全部的doc list都讀取過來（比如說男、女），這個doc list會占用較大的內存進行Cache，當然在數據規模較小的情況下占用內存不是特別多，查詢命中率很高，會提升檢索速度，但是數據規模上來后，這里的 內存問題越來越嚴重。
節點和數據規模受限。Merger Server只能是一個，制約了查詢的節點數量；數據不能進行動態分區，數據規模上來后單個索引太大。
高并發導入的情況下， GC占用CPU太高，多線程并發性能上不去。AttributeSource使用了 WeakHashMap來管理類的實例化，并使用了全局鎖，無論加了多大的線程，導入性能上不去。AttributeSource與 NumbericField,使用了大量的LinkHashMap以及很多無用的對象，導致每一條記錄都要在內存中創建很多無用的對象，造成了JVM要頻 繁的回收這些對象，CPU消耗過高。FieldCacheImpl使用的WeakHashMap有BUG，大數據的情況下有OOM的風險。單機導入性能在 筆者的環境下（1kb的記錄每臺機器想突破2w/s 很難）
并不是說Solr與ES的這種方式不好，在數據規模較小的情況下，Solr的這種處理方式表現優越，并發性能較好，Cache利用率較高，事實證明在 生產領域Solr和ES是非常穩定的，并且性能也很卓越；但是在數據規模較大，并且數據在頻繁的實時導入的情況下，就需要進行一些優化。
Hermes在索引上的改進：
索引按需加載。大部分的索引處于關閉狀態，只有真正用到索引才會去打開；一級跳躍表采用按需Load，并不會 Load整個跳躍表，用來節省內存和提高打開索引的速度。Hermes經常會根據業務的不同動態的打開不同的索引，關閉那些不經常使用的索引，這樣同樣一 臺機器，可以被多種不同的業務所使用，機器利用率高。
排序和統計按需加載。排序和統計并不會使用數據的真實值，而是通過標簽技術將大數據轉換成占用內存很小的數據標簽，占用內存是原先的幾十分之一。
另外不會將這個列的全部值都Load到內存里，而是用到哪些數據Load哪些數據，依然是按需Load。不用了的數據會從內存里移除。
索引存儲在HDFS中。理論上只要HDFS有空間，就可以不斷的添加索引，索引規模不在嚴重受機器的物理內存和物理磁盤的限制。容災和數據遷移容易得多。
采用Gaia進行進程管理（騰訊版的Yarn）。數據在HDFS中，集群規模和擴容都是一件很容易的事情，Gaia在騰訊集群規模已達萬臺）。
采用多條件組合跳躍降低數據傾斜。如果某個詞語存在數據傾斜，則會與其他條件組合進行跳躍合并（參考doclist的skip list資料）。
多級Merger與自定義分區
GC上進行了一些優化自己進行內存管理，關鍵地方的內存對象的創建和釋放java內部自己控制，減少GC的壓力（類似Hbase的Block Buffer Cache）。不使用WeakHashMap和全局鎖，WeakHashMap使用不當容易內存泄露，而且性能太差。用于分詞的相關對象是共用的，減少反 復的創建對象和釋放對象。1kb大小的數據，在筆者的環境下，一臺機器每秒能處理4~8W條記錄.
Hermes的出現，并不是為了替代Solr、ES的，就像Hadoop的出現并不是為了干掉Oracle和MySQL一樣。而是為了滿足不同層面的需求。
Hermes應用案例
微信數據門戶多維分析 (約370億)
提供系統各個性能指標數據的實時分析。
信息安全部回溯項目(目前接入約2300億)
基于全文檢索查詢、分析、統計并導出相關記錄。
結果秒級返回。
Hermes性能數據
微信多維分析天數據370+億，目前實時統計分析3s左右；
10億記錄數，10TB存儲量，3臺服務器(64G內存),8000+維度，查詢分析耗時3s。
每天接入量2000+億，最大寬表維度8000+，單機寫入（包括數據預處理）性能8W/s。
參考鏈接：
http://data.qq.com/article?id=817
http://data.qq.com/article?id=1315
本文來源：標點符 原文鏈接：http://www.biaodianfu.com/hermes.html</span>
本文由用戶 jopen 自行上傳分享，僅供網友學習交流。所有權歸原作者，若您的權利被侵害，請聯系管理員。
轉載本站原創文章，請注明出處，并保留原始鏈接、圖片水印。
本站是一個以用戶分享為主的開源技術平臺，歡迎各類分享！