輿情系統的數據存儲應用

數據存儲方案

輿情監控平臺的核心價值，就是能夠提供快速精準的信息檢索，并且輿情系統的使用場景具有以下特點：

實時數據價值更高

輿情數據傳播趨勢特征明顯，人們關注的信息大部分集中在7天之內，且信息采集呈現的及時性，往往是分鐘級的。

信息檢索維度靈活

客戶信息篩選的維度是多樣的，如根據微博粉絲量、性別、文章段落等。

檢索業務處理集中

輿情平臺的檢索壓力有明顯的特征曲線，工作時間負載壓力大，早晚高峰報告查詢集中。

1.選型發展

信息檢索是輿情系統的核心需求，基于 Lucene 的全文檢索引擎是實時數據檢索的組件首選，早期我們使用 Solr，但是 Solr 依賴外部組件協調（ZooKeeper），運維成本很高。2015年，我們引入ElasticSearch（ES）作為平臺的底層數據庫，提升了輿情數據存儲集群的運維效率，也提高了平臺存儲的穩定性。隨著業務發展，數據量越來越大，即使是已經按照業務拆分的集群隔離也已經不能滿足業務查詢的性能要求，2017年底，我們做了大幅底層集群優化和硬件升級，從業務集群隔離拓展到多集群、多索引的混合集群模式。伴隨產品維度和數據量的增長，2018年我們將 HBase 作為非索引大字段的底層存儲，引入基于 Ceph 底層的 OSS 對象數據存儲引擎，支撐圖片、音視頻的存儲;架構升級后，支持伴隨業務的靈活可擴展的緩存多集群方案。

2.存儲架構

數據寫入

通過數據流計算完成的標準數據，通過 Data Pipeline 同步寫入 全量數據倉庫和ES準實時索引集群，ES 集群存儲文本索引字段，構建倒排索引，文檔關聯的原始 HTML 和 資源（如圖片、視頻），分別存儲到 HBase和 OSS 對象存儲平臺，構建ES 文檔關聯。

業務拆分

按照業務劃分，對實時數據敏感的客戶，熱數據通過 ES 準實時索引構建檢索結果，能夠做到數據采集到UI呈現低于 30 秒的業務體驗，對于預警時效敏感的客戶，系統將信息準實時推送給客戶，但這部分客戶犧牲了一部分的定制化干預功能，如情感標簽的定向優化。

對大部分客戶，我們根據業務規則分組，將客戶的專題規則，經由計算中心，同步計算到可擴展的 ES 業務緩存，這樣做到客戶專題級別的存儲隔離，大幅提高信息檢索的性能，同時，在同步計算節點，我們嵌入了可插拔的規則引擎計算插件，可以二次干預標簽或者附加值計算，給定點客戶提供了更優的數據分析體驗，通過不斷集群調優和算法改造，實時計算上萬客戶的全部專題，UI 數據呈現目前已經能做到延遲小于3分鐘。

離線備份

輿情客戶數據具有鮮明的時間屬性，歷史數據關注度和分析價值不高，因此我們對數據除了 T+1 的同步備份外，線上實時 ES 集群只保留最近2年的數據，保證的集群的性能不隨數據增量衰減，同時，離線備份的數據，同時用于定期的數據統計任務，服務于輿情分析師，作為長周期報告的數據分析來源。

存儲架構的升級和變遷，很大程度上是伴隨著系統的負載壓力和不斷增長的數據和客戶增量，不斷迭代演進的，通過空間換時間，我們目前已經構建了一個超過200個 ES 節點的多集群架構，支撐每天幾十TB級的數據增量，以及上萬客戶的復雜輿情檢索和計算。

檢索優化方案

盡管我們使用 ES作為全文檢索的核心引擎，無論數據索引和簡單查詢，都能做到很好的性能支撐，但是輿情檢索有一定的特殊性和復雜性。

檢索精度要求

輿情服務的客戶，對于數據檢索具有高召回的要求，通過關鍵詞檢索，任何匹配關鍵詞、或匹配關鍵詞組合的數據，都應該被及時檢索并呈現，但中文語法復雜，對于歧義、包含等語義情況，常常存在分詞造成的誤差，導致檢索召回率降低，造成客戶投訴。

檢索性能要求

輿情信息檢索過程中，相似文章需要默認折疊，以分頁形式展示到前端，而數據實時入庫，我們要求折疊數據的計算是實時的，雖然 ES 聚合（aggregation）性能隨著社區發展不斷優化，但其仍不能很好的處理億級數據的分頁聚合需求，尤其面對超過上千復雜關鍵詞邏輯時，性能會變得更差。

數據相關性要求

輿情檢索是要發現價值信息，而 ES 自身的評分機制，并不能完整反映互聯網公開數據的權重，比如權重大的網站發布的文章、傳播量大的文章，或者負面傾向大的文章，往往需要排在數據呈現的前面，即數據的相關性，我們需要做二次的定制。

業務靈活性要求

為了讓信息檢索更靈活，我們設計了一套復雜的檢索語法，如：或、與、非、距離、字段定制、嵌套檢索等，同時一個檢索，還需要加入特定的規則干預，如數據定向、黑白名單、屏蔽過濾等，各種附加的操作都對 ES 的檢索帶來巨大的復雜性。

針對上述種種問題，我們列舉部分檢索優化點供參考：

集群調優

1.內存參數優化

內存對于 ES 來說異常重要，單個數據節點，JVM 內存設置為 31GB（不超過32GB），觸發內存指針壓縮技術，配置 G1垃圾回收器;同時，Lucene 被設計為可以利用操作系統底層機制來緩存內存數據結構，我們至少預留操作系統內存的一半作為 Lucene 的非堆內存，如果物理機內存小于 64G，給到 ES 節點的內存應該不超過內存的 50%;另外，內存交換到磁盤對服務器性能來說是致命的打擊，一般會降低一個數量級，應該配置禁止內存交換。

2.動態分片設置

一個ES ?index 的分片，底層對應一個 Lucene 的索引文件，會消耗系統的文件句柄、CPU和內存資源，每個檢索請求也會路由分類到每個分片，我們需要綜合考慮查詢請求的負載和分片的大小，合理設置分片的數量，因此在我們的 ES 集群管理中，每天的索引分片數是動態計算的（根據近期數據增量，預估當天數據量，調整創建索引的分片數量）。

3.定時段（segment）合并

ES 數據寫入過程中，會產生大量的段文件，ES 每個分片的資源開銷，取決于 segment 的數量，而通過段合并，將較小的分段合并為較大的分段，能減少開銷并提高查詢性能，但段合并是一項十分耗費性能的操作，我們應該關閉索引的自動段合并，在業務低峰時段做定時索引段合并。

硬件優化

盡量選配 SSD 硬盤，考慮到成本原因，可以結合業務場景，對業務檢索有較高的性能要求的，建議使用 SSD 磁盤，檢索不敏感的集群則使用普通磁盤。

同時，當 ES 集群上有大量的索引時，通過單節點配置多個掛載磁盤，能夠讓數據高效寫入不同的磁盤，在硬件性能較差時，能顯著提升數據寫入的效率。

分詞優化

我們知道ES 底層是基于分詞的倒排索引，常見的開源中文分詞器很多，如 ik 分詞器、ansj 分詞器、結巴分詞器、hanlp 分詞器等，但是針對精度要求非常高的輿情數據檢索場景，上述分詞器均存在不同程度的誤差。

的是單個詞匯單元，輸出一個字母n-gram 詞匯單元序列，而 Shingles 是將一個序列的詞匯單元，輸出一個單詞級別的 n-gram 詞組單元序列。