編者按

現(xiàn)代社會是一個信息驅動的社會，每天都有大量的信息產(chǎn)生。據(jù)統(tǒng)計，互聯(lián)網(wǎng)上每天有數(shù)十億條媒體文章產(chǎn)生，在線信息檢索超過500億次。伴隨著互聯(lián)網(wǎng)技術的發(fā)展和新媒體創(chuàng)新應用，人們越來越傾向于通過微博、微信、短視頻等社交媒體，表達看法，傳播訴求，分享信息、甚至建言獻策，收集、處理、挖掘其中的價值，洞察觀點、情緒、口碑、社情民意，不僅能夠為企業(yè)提供商業(yè)情報，輔助商業(yè)決策，還能為政府機構挖掘社情輿論，提升社會治理水平。本文將主要圍繞 SaaS 3.0時代，互聯(lián)網(wǎng)公開數(shù)據(jù)信息挖掘的特點和趨勢，闡述輿情分析系統(tǒng)的架構和實踐。

1.輿情分析的業(yè)務特點

1.1  信源覆蓋廣

輿情分析的數(shù)據(jù)源幾乎覆蓋所有互聯(lián)網(wǎng)公開信息，如常見的資訊網(wǎng)站和社交媒體：新華網(wǎng)、騰訊新聞、百度貼吧、論壇、新浪微博、微信、博客等，近幾年興起的自媒體平臺和短視頻等流媒體應用：小紅書、抖音、快手等，人們有更多的渠道可以發(fā)聲，新時代人人都是自媒體，同時，外媒也是眾多跨國公司和政府機構關注的重點，境外主流新聞網(wǎng)站如華爾街日報、紐約時報等和社交媒體如 Facebook、Twitter，甚至 Tik Tok 等，這些輿論陣地都是輿情分析需要覆蓋的渠道。

1.2  需求行業(yè)多

輿情分析的需求幾乎涵蓋所有行業(yè)，互聯(lián)網(wǎng)時代，信息傳播迅速，網(wǎng)絡熱點事件頻發(fā)，企業(yè)最怕的就是出現(xiàn)各種不良輿論，危及企業(yè)運營，損害品牌形象，輿情監(jiān)測服務被廣泛應用于消費品、汽車、互聯(lián)網(wǎng)金融、地產(chǎn)、教育、餐飲等行業(yè)，同時，在電子政務領域，輿情監(jiān)測服務也為各級政府機構，提供第一時間的輿情資訊，輿情涉及我們生活的方方面面，輿情監(jiān)測和管理，核心是對我們周圍互聯(lián)網(wǎng)公開信息的大數(shù)據(jù)分析和價值挖掘。

1.3  社會價值高

輿情分析服務能為目標客戶提供多維度的信息挖掘和高附加值的洞察分析，具有巨大的企業(yè)和社會價值：

負面信息挖掘：負面信息發(fā)現(xiàn)，是輿情監(jiān)測的核心價值點，如果不能及時準確地發(fā)現(xiàn)負面信息，造成負面輿論發(fā)酵，可能對企業(yè)帶來不可挽回的損失，對政府帶來嚴重的公信力質疑。

競品信息監(jiān)測：無論是企業(yè)市場人員，還是產(chǎn)品經(jīng)理，競品分析都是門必備的通用技能，通過對現(xiàn)有或潛在的競爭產(chǎn)品或者企業(yè)進行信息監(jiān)測、情報挖掘，分析優(yōu)劣勢，往往能幫助企業(yè)掌握競爭的主動權。

口碑信息挖掘：針對自身或競品，進行有針對性的口碑監(jiān)測，如一款產(chǎn)品的評論分析，可以幫助企業(yè)改進產(chǎn)品功能、輔助市場營銷策略，提升客戶或產(chǎn)品滿意度。

事件脈絡分析：無論對于互聯(lián)網(wǎng)熱點事件還是產(chǎn)品傳播營銷，通過對事件細粒度的傳播分析，洞察事件發(fā)酵脈絡，挖掘傳播爆點，掌握事件傳播路徑，為事件處置或營銷效果分析提供決策依據(jù)。

民生民意調(diào)查：通過對互聯(lián)網(wǎng)事件的輿論監(jiān)測，挖掘對于互聯(lián)網(wǎng)事件的公眾情緒、公眾觀點、意見領袖、傳播路徑，為政府輿情引導、輿情管控提供決策輔助。

1.4  技術挑戰(zhàn)大

輿情監(jiān)測系統(tǒng)，不僅需要具備強大的數(shù)據(jù)采集和處理能力，還需要具備強大的價值挖掘能力，構建強大的輿情監(jiān)測系統(tǒng)，往往面臨巨大的技術挑戰(zhàn)。

數(shù)據(jù)全面：針對海量的互聯(lián)網(wǎng)信息，構建強大的數(shù)據(jù)采集系統(tǒng)，保證數(shù)據(jù)全面、不遺漏，是輿情監(jiān)測能力保障的基礎。

檢索精確：輿情系統(tǒng)能夠代替人工精準檢索目標數(shù)據(jù)，這對海量數(shù)據(jù)的全文檢索提出很高的要求，不僅要找到匹配的信息，還要去除干擾，最大化匹配檢索意圖。

預警及時：輿論環(huán)境瞬息萬變，企業(yè)和政府都期望第一時間掌握輿情動態(tài)；輿情監(jiān)測需要提供7&24小時、近實時信息預警，具備秒級采集、處理、研判和下發(fā)機制。

精準研判：除數(shù)據(jù)采集全面、數(shù)據(jù)處理及時外，信息挖掘研判的準確性往往是衡量服務競爭力的重要指標，通過不斷提升敏感信息研判和相似度判定的準確性，可以最大化降低系統(tǒng)誤判率。

標簽豐富：除了基本的輿情大數(shù)據(jù)全流程處理，輿情系統(tǒng)還應該具備更深層次的信息挖掘能力，如標簽提取、地域甄別、信息分類、事件發(fā)現(xiàn)等，最大化提升附加值挖掘能力，降低人工服務成本。

2.輿情發(fā)展的新趨勢
 
2.1  精細化運營，實現(xiàn)彎道超車

互聯(lián)網(wǎng)輿情行業(yè)發(fā)展多年，玩家眾多，傳統(tǒng)的輿情分析，場景模式相對固定，競爭趨于白熱化；而輿情分析的細粒度需求，如負面關注度、文本相關性等，越來越趨于差異化和定制化，在 SaaS 標品的模式下，如何針對不同的行業(yè)客戶、不同的分析場景實現(xiàn)平臺化、精細化的運營，變得越來越重要，打造業(yè)務閉環(huán)、構建能夠實現(xiàn)差異化運營的平臺化產(chǎn)品矩陣，才能實現(xiàn)彎道超車。

2.2  智能化分析，AI 深度應用

輿情分析是 NLP 文本分析的天然陣地，隨著近幾年AI發(fā)展進入快車道，各種技術框架和分析手段層出不窮，為輿情信息挖掘提供了豐富的工具，不僅局限于分詞、實體識別、情感判定、關鍵詞提取等底層文本分析技術，諸如主動事件發(fā)現(xiàn)、智能化預警研判、智能化信息檢索等逐漸落地應用。同時隨著 AIOps 的發(fā)展，模型算法的工程化落地加速，探索用 AI 代替?zhèn)鹘y(tǒng)輿情服務中的人工部分，以降低成本。

2.3  業(yè)務模式創(chuàng)新，拓展深度和廣度

輿情業(yè)務模式創(chuàng)新，不僅要橫向擴展行業(yè)，積累各領域知識，形成不同行業(yè)的差異化專業(yè)解決方案，還要縱向探索新的分析場景，如針對 KOL 的細粒度監(jiān)測、針對短視頻等流媒體的信息挖掘等，與時俱進，不能禁錮在傳統(tǒng)的輿情思維之中。

3.輿情信息的挖掘過程

3.1  基于實時數(shù)據(jù)流的數(shù)據(jù)挖掘

互聯(lián)網(wǎng)輿情，本質上是對互聯(lián)網(wǎng)公開信息的采集、分析、研判，并產(chǎn)生業(yè)務價值，是一個價值數(shù)據(jù)挖掘的過程，但基于其業(yè)務場景和系統(tǒng)要求，與傳統(tǒng)的數(shù)據(jù)挖掘又有很大差別。

傳統(tǒng)的數(shù)據(jù)挖掘任務，一般有如下幾個過程：

信息收集 - 數(shù)據(jù)集成 - 數(shù)據(jù)加載 - 數(shù)據(jù)清理 - 數(shù)據(jù)變換 - 數(shù)據(jù)挖掘過程 - 模式評估 - 知識表示

ETL階段進行數(shù)據(jù)清洗和標準化，挖掘過程綜合運用各種信息挖掘算法，如規(guī)則推理、機器學習模型、遷移學習算法等，根據(jù)模式評估結果，得到反饋，不斷循環(huán)，達到最優(yōu)。但在輿情場景下，數(shù)據(jù)要從互聯(lián)網(wǎng)源源不斷的輸入，分析結果要準實時的輸出呈現(xiàn)，價值挖掘過程穿插于信息流之中，同時，系統(tǒng)需要具備動態(tài)干預的能力，甚至需要設計單獨的指標回算機制，保證信息挖掘的前后一致性，如下圖所示：

信息以流式輸入到在線處理引擎，經(jīng)過 ETL 處理標準化的數(shù)據(jù)，進入數(shù)據(jù)挖掘過程，如基于規(guī)則引擎計算文本指標、通過機器學習算法模型計算文本標簽等，這些規(guī)則或模型蘊含業(yè)務知識，數(shù)據(jù)計算結果經(jīng)過存儲，呈現(xiàn)給業(yè)務人員，后續(xù)隨著業(yè)務的評估和迭代，挖掘中的業(yè)務知識會被動態(tài)干預，形成知識流動迭代的閉環(huán)。

因此，傳統(tǒng)的數(shù)據(jù)挖掘過程，往往是靜態(tài)的一次性過程，而輿情分析的信息挖掘，是一個流動的不間斷過程。

3.2  多工種協(xié)作的業(yè)務閉環(huán)

同時，輿情監(jiān)測體系的運行，也是一個多方共同參與的過程，不同角色的人員共同協(xié)作，不斷迭代產(chǎn)生更優(yōu)的價值挖掘結果，準確及時地呈現(xiàn)給終端客戶。

簡單來看，輿情監(jiān)測系統(tǒng)，主要由數(shù)據(jù)采集、SaaS 平臺、運營工具棧構成。

銷售、售前人員負責方案制作、需求轉化，客戶成單，需求確定后，由數(shù)據(jù)運營人員跟進，負責客戶全生命周期的數(shù)據(jù)、關鍵詞配置管理、數(shù)據(jù)監(jiān)控，客戶數(shù)據(jù)實時進入數(shù)據(jù)挖掘平臺，供輿情分析師團隊和客戶直接使用，如數(shù)據(jù)篩選、數(shù)據(jù)預警、報告制作、信息挖掘分析等。

同時，我們還需要提供豐富的運營分析工具棧，如數(shù)據(jù)清洗、報告制作、預警干預、數(shù)據(jù)宏觀分析、觀點挖掘、事件發(fā)現(xiàn)等運營工具，幫助輿情分析師制作人工報告，提供高效率的人工服務。

需要指出的是，在整個輿情服務過程中，輿情監(jiān)測系統(tǒng)需要能夠實時收集業(yè)務知識，并反饋到信息挖掘平臺，不斷優(yōu)化和提升 SaaS 平臺的信息挖掘能力和水平。

輿情分析師的業(yè)務經(jīng)驗：輿情分析師是人工服務的價值輸出方，能夠深刻理解客戶的監(jiān)測需求，沉淀下來的業(yè)務知識，將直接錄入挖掘平臺，動態(tài)干預定向客戶的分析效果，如客戶的定制化負面評價指標、客戶的定制分析詞庫等。

終端用戶的行為反饋：系統(tǒng)應該能夠自動收集用戶的行為數(shù)據(jù)，以最大限度地降低用戶的額外工作，提高系統(tǒng)迭代的效率，如數(shù)據(jù)的收藏行為、數(shù)據(jù)的屏蔽行為、數(shù)據(jù)的瀏覽行為等。

概括來講，輿情分析系統(tǒng)是一個基于實時流動信息、多方協(xié)作參與的價值信息挖掘平臺。

4.輿情系統(tǒng)的架構實踐

4.1  基礎架構分析

輿情監(jiān)測系統(tǒng)，可以看做是一個價值信息挖掘的平臺體系，重點是兩個能力的建設：

資源構建能力：通過數(shù)據(jù)采集和信息挖掘，構建輿情系統(tǒng)的資源基礎，形成標準一致的信息輸出接口。

業(yè)務應用能力：依托底層的輿情資源，構建貼合場景的業(yè)務應用，既服務于輿情 SaaS 客戶，還服務于人工分析師，輸出專業(yè)能力的同時，幫助提升組織效率。

簡化版的輿情系統(tǒng)基礎架構如下：

整個架構分為兩個層次：

a. 資源層：整合數(shù)據(jù)采集、計算、存儲，形成整體的輿情資產(chǎn)核心能力；
b. 業(yè)務層：基于輿情場景，構建各種上層應用。

數(shù)據(jù)采集層：

依托百分點大數(shù)據(jù)采集系統(tǒng)，我們構建了超過1000+ 服務器節(jié)點的大規(guī)模數(shù)據(jù)采集集群，覆蓋90%以上的全網(wǎng)公開價值信息；包括新聞、報刊、微博、微信、APP、論壇、貼吧、博客、視頻、問答、外媒網(wǎng)站、Facebook、Twitter、短視頻等近14個信源數(shù)據(jù)，本文我們不展開講述采集系統(tǒng)的構建。

數(shù)據(jù)計算層：

數(shù)據(jù)計算層承擔著輿情數(shù)據(jù)處理的核心部分，除了采集數(shù)據(jù)的 ETL 過程，我們還構建了高效、智能的核心指標計算體系，通過高效的流式處理引擎，支撐文本、規(guī)則指標的計算，挖掘價值信息。

數(shù)據(jù)存儲層：

我們綜合構建了適用于實時業(yè)務檢索和離線數(shù)據(jù)拉取計算的存儲架構，核心基于 ElasticSearch（ES） 和 Hbase 存儲實時輿情數(shù)據(jù)，基于 HBase + Hive(HDFS)構建離線數(shù)據(jù)倉庫，為上層業(yè)務分析、數(shù)據(jù)應用構建提供高效、統(tǒng)一的信息檢索服務。

需要指出的是，基于輿情數(shù)據(jù)應用場景，我們不僅構建了超過100個數(shù)據(jù)節(jié)點的 lambda架構的大數(shù)據(jù)生態(tài)處理平臺，支撐每天億級數(shù)據(jù)的實時和離線處理，還依托百分點人工智能實驗室，結合輿情數(shù)據(jù)應用閉環(huán)，構建了以 GPU 為硬件基礎的深度學習文本算力平臺，應用先進的遷移學習技術，服務于模型化的指標挖掘。

業(yè)務服務層：

在業(yè)務層，我們將輿情的業(yè)務模塊化，形成眾多獨立部署的微服務，將用戶管理、話題管理、標簽管理、數(shù)據(jù)檢索、多維分析、標簽分析等核心業(yè)務暴露為統(tǒng)一的 REST 接口，構建了多個調(diào)度中心，負責處理輿情報告、預警、數(shù)據(jù)處理、服務監(jiān)控等服務。

技術棧主要以SpringCloud框架和容器云 Docker 虛擬化為主，底層基于 Kubernetes 做資源管理和服務編排，構建了超過 200個鏡像節(jié)點的線上微服務集群，支撐每天近萬用戶的復雜檢索和 API 調(diào)用。

業(yè)務應用層：

我們構建了面向客戶的輿情 SaaS 平臺，為終端客戶提供智能化的輿情監(jiān)測、輿情分析、輿情報告、輿情預警、專題管理等便捷體驗，支持 PC、移動端、微信小程序等；同時，我們還構建了面向輿情運營分析師的多工種協(xié)作平臺，將輿情服務的全流程拆解、工具化，提供了支持眾包的客戶運營、數(shù)據(jù)清洗、報告制作、預警下發(fā)、價值挖掘等獨立的工具平臺，支持近百人的同時在線協(xié)作。

作為輿情系統(tǒng)的底層支撐，下面我們將簡單分享我們在平臺資源層的架構實踐，即：高效的數(shù)據(jù)流處理架構、穩(wěn)定的數(shù)據(jù)存儲平臺、完善的指標挖掘體系。

4.2  數(shù)據(jù)流處理方案

基于輿情業(yè)務特點，數(shù)據(jù)處理需要滿足以下要求：

a. 數(shù)據(jù)處理高效：數(shù)據(jù)采集到數(shù)據(jù)持久化存儲，中間的數(shù)據(jù)處理時間不能超過30s，最大限度保證輿情消息的及時性；
b. 數(shù)據(jù)處理穩(wěn)定：輿情數(shù)據(jù)有明顯的峰谷周期，夜間數(shù)據(jù)較少，白天出現(xiàn)多個信息波峰，同時互聯(lián)網(wǎng)輿情事件具有突發(fā)性，數(shù)據(jù)處理平臺需要具備削峰填谷的能力；
c. 開發(fā)運維方便：開發(fā)友好，運維簡單。

百分點輿情實時流處理架構，伴隨技術演進，經(jīng)歷了多個階段。2015年，我們引入了 Storm 作為實時流處理引擎，當時已經(jīng)能夠支撐高效的數(shù)據(jù)流處理，但隨著業(yè)務量的增長，計算節(jié)點的維護成本越來越高，復雜的業(yè)務流程也加大了研發(fā)運維的復雜度，硬件資源利用瓶頸時有發(fā)生。2019年初，我們最終引入 Flink 作為我們的核心流處理組件，全面升級到了以 Flink 為中心的微批處理計算平臺。

Storm和 Flink 都是流數(shù)據(jù)處理領域成熟的開源組件，但二者有著明顯的區(qū)別，Storm 是基于拓撲（Topology）的無狀態(tài)無限流處理平臺，能夠保證數(shù)據(jù)不丟失，但窗口函數(shù)等高級功能支持較弱；而 Flink 是一個統(tǒng)一了流處理和批處理的分布式數(shù)據(jù)處理引擎，除具備Storm 的高吞吐、低延遲、可擴展、支持容錯性外，還支持非常靈活的窗口處理，同時有更好的反壓機制，對于保證流處理的穩(wěn)定性有很大的作用。

如圖所示，F(xiàn)link 集群由 Flink Master、TaskManager 組成，F(xiàn)link Master 中對應多個 JobManager，每個 JobManager 負責管理單個 Job 的調(diào)度和執(zhí)行，而 Resource Manager 負責整個集群的內(nèi)外部資源調(diào)度，F(xiàn)link 可以支持嫁接在 Kubernetes、Mesos、Yarn 等資源調(diào)度管理系統(tǒng)之上，結合我們現(xiàn)有的大數(shù)據(jù)處理平臺，我們使用 Yarn 作為我們 Flink 集群的底層資源管理系統(tǒng)。

邏輯上，算子（Operator）是 Flink 最基本的數(shù)據(jù)處理單元，一個 Job 是由一系列 Task 組成的 DAG，而每個 Task 中是由一個鏈式的 Operators Chain 構成，因此，我們將輿情數(shù)據(jù)處理中的數(shù)據(jù)清洗、標簽計算、數(shù)據(jù)拉通等計算，從 Storm Topology 中的多個 Spout、Bolt 中遷移到重新設計細化的算子序列，讓計算單元粒度更細、資源并發(fā)度更可控。

以其中一個<數(shù)據(jù) Level1 清洗> Job 為例：

我們將數(shù)據(jù)清洗階段的各步驟（類型轉化、黑名單過濾、媒體來源歸一、地域提取、消重）提取成獨立算子，單獨設置資源和并行度，并且針對全局只讀的字典變量（如數(shù)據(jù)運營設置的網(wǎng)站黑名單、定期更新的網(wǎng)站媒體庫、定期更新的標準地理庫等），通過廣播變量定期更新到各個算子，優(yōu)雅的動態(tài)更新業(yè)務規(guī)則。

使用 Flink 集群的核心優(yōu)勢：

資源調(diào)度：采用統(tǒng)一的 Yarn 作為 Flink 資源調(diào)度，相比使用裸機的 Storm，大幅提高了資源利用率，同時使資源伸縮變得更方便。

新的 Flink 集群，在資源利用率持續(xù)控制在 60%左右的情況下，物理機資源節(jié)約了 50%，不僅節(jié)約了硬件成本，還提高了數(shù)據(jù)處理的能力。

Flink On Yarn 提供2種任務提交方式：
a. Yarn Session：多 Job 共享一個 Flink 集群，YARN 資源共享；
b. Flink Run ：獨立 Job 獨占 Yarn Session，任務間互不影響。
我們使用第二種方式提交，能做到更好的業(yè)務資源隔離和集群任務監(jiān)控。

動態(tài)反壓機制：Flink 提供比 Storm 更好的動態(tài)反壓機制，能夠動態(tài)感知被阻塞的 Operator，自適應地降低源頭或上游數(shù)據(jù)的發(fā)送速率，從而維持整個系統(tǒng)的穩(wěn)定。

針對輿情場景下的數(shù)據(jù)流量波峰波谷和不確定的熱點事件，F(xiàn)link 集群很好的平衡了數(shù)據(jù)流速，解決了 Storm 集群頻發(fā)的高負載故障。

廣播變量：Flink提供靈活的廣播變量，通過將全局共享的數(shù)據(jù)廣播出去，不同的任務在同一個節(jié)點上都能獲取，數(shù)據(jù)只存在一份，相比于分布式緩存，節(jié)省了內(nèi)存開銷。

邏輯解耦：Flink 基于細粒度的算子鏈構建業(yè)務任務，可以把業(yè)務抽象成粒度足夠小的算子，代碼邏輯高度解耦；單個算子可單獨配置并行度，其 Operator Chain 機制還能自動優(yōu)化執(zhí)行邏輯，將并行度一致的算子轉化為線程內(nèi)的方法調(diào)用，減少網(wǎng)絡通信，提高運行效率。

除了 Flink 自帶的任務資源管理，我們還進一步豐富了 Flink 在YARN Session 級別的監(jiān)控維度，接入 Grafana：

4.3  數(shù)據(jù)存儲方案

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

實時數(shù)據(jù)價值更高：輿情數(shù)據(jù)傳播趨勢特征明顯，人們關注的信息大部分集中在7天之內(nèi)，且信息采集呈現(xiàn)的及時性，往往是分鐘級的。

信息檢索維度靈活：客戶信息篩選的維度是多樣的，如根據(jù)微博粉絲量、性別、文章段落等。

檢索業(yè)務處理集中：輿情平臺的檢索壓力有明顯的特征曲線，工作時間負載壓力大，早晚高峰報告查詢集中。

（1）選型發(fā)展：

信息檢索是輿情系統(tǒng)的核心需求，基于 Lucene 的全文檢索引擎是實時數(shù)據(jù)檢索的組件首選，早期我們使用 Solr，但是 Solr 依賴外部組件協(xié)調(diào)（ZooKeeper），運維成本很高。

2015年，我們引入ElasticSearch（ES）作為平臺的底層數(shù)據(jù)庫，提升了輿情數(shù)據(jù)存儲集群的運維效率，也提高了平臺存儲的穩(wěn)定性。

隨著業(yè)務發(fā)展，數(shù)據(jù)量越來越大，即使是已經(jīng)按照業(yè)務拆分的集群隔離也已經(jīng)不能滿足業(yè)務查詢的性能要求，2017年底，我們做了大幅底層集群優(yōu)化和硬件升級，從業(yè)務集群隔離拓展到多集群、多索引的混合集群模式，版本也升級到了 6.*。伴隨產(chǎn)品維度和數(shù)據(jù)量的增長，2018年我們將 HBase 作為非索引大字段的底層存儲，引入基于 Ceph 底層的 OSS 對象數(shù)據(jù)存儲引擎，支撐圖片、音視頻的存儲；架構升級后，支持伴隨業(yè)務的靈活可擴展的緩存多集群方案。

（2）存儲架構：

下圖描述了簡要的數(shù)據(jù)寫入流程：

數(shù)據(jù)寫入：

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

業(yè)務拆分：

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

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

離線備份：

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

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

4.4  檢索優(yōu)化方案

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

檢索精度要求：

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

檢索性能要求：

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

數(shù)據(jù)相關性要求：

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

業(yè)務靈活性要求：

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

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

（1）集群調(diào)優(yōu)

內(nèi)存參數(shù)優(yōu)化：內(nèi)存對于 ES 來說異常重要，單個數(shù)據(jù)節(jié)點，JVM 內(nèi)存設置為 31G（不超過32G），觸發(fā)內(nèi)存指針壓縮技術，配置 G1垃圾回收器；同時，Lucene 被設計為可以利用操作系統(tǒng)底層機制來緩存內(nèi)存數(shù)據(jù)結構，我們至少預留操作系統(tǒng)內(nèi)存的一半作為 Lucene 的非堆內(nèi)存，如果物理機內(nèi)存小于 64G，給到 ES 節(jié)點的內(nèi)存應該不超過內(nèi)存的 50%；另外，內(nèi)存交換到磁盤對服務器性能來說是致命的，一般會降低一個數(shù)量級，應該配置禁止內(nèi)存交換（sudo swapoff -a）。

動態(tài)分片設置：一個ES  index 的分片，底層對應一個 Lucene 的索引文件，會消耗系統(tǒng)的文件句柄、CPU和內(nèi)存資源，每個檢索請求也會路由分類到每個分片，我們需要綜合考慮查詢請求的負載和分片的大小，合理設置分片的數(shù)量，一般推薦的分片大小是20 ~ 50G 之間，因此在我們的 ES 集群管理中，每天的索引分片數(shù)是動態(tài)計算的（根據(jù)近期數(shù)據(jù)增量，預估當天數(shù)據(jù)量，調(diào)整創(chuàng)建索引的分片數(shù)量）。

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

硬件優(yōu)化：盡量選配 SSD 硬盤，考慮到成本原因，可以結合業(yè)務場景，對業(yè)務檢索有較高的性能要求的，建議使用 SSD 磁盤，檢索不敏感的集群則使用普通磁盤，同時，當 ES 集群上有大量的索引時，通過單節(jié)點配置多個掛載磁盤，能夠讓數(shù)據(jù)高效的寫入不同的磁盤，在硬件性能較差時，能顯著提升數(shù)據(jù)寫入的效率。

（2）分詞優(yōu)化

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

ES 的索引字段（analyzed）的分析（analysis）過程如下：

Character filter 階段：字符過濾器主要以字符流的方式接收原始文本，經(jīng)過干預轉換，輸出字符流，比如特殊字符過濾或者編碼轉化。

Tokenizer 階段：即切詞階段，接收一個字符流 ，經(jīng)過分詞器切割拆分為多個 token，并輸出一個 token 流。

Token filter 階段：接收 token 流，通過配置的filter 算法，對每個token進行轉化，比如小寫轉化、停用詞刪除、同義詞引入等，ES也提供了多種預置的 過濾器。

這里需要解決的問題是分詞準確性導致的檢索召回率問題，比如我們要通過“微貸網(wǎng)”檢索數(shù)據(jù)，無論采用 IK 分詞器的 ik_smart 或 ik_max_word，都無法檢索出下面這句：“微貸網(wǎng)費用有哪些？”

原因是在分詞階段，在分詞詞庫不添加專有名詞“微貸網(wǎng)”的情況下，分詞 token 均不包含 “微貸網(wǎng)”，而是“網(wǎng)費”被單獨分詞，導致檢索無法匹配。豐富詞庫不能對歷史數(shù)據(jù)生效，并不適用輿情實時的數(shù)據(jù)檢索場景。

我們的方案是調(diào)整分詞，將修飾定制的ik_smart和 shingles Token 過濾器相結合。

Shingles 過濾器是一種特殊的詞元過濾器，與N-Gram 不同的是，n-gram 過濾器針對的是單個詞匯單元，輸出一個字母n-gram 詞匯單元序列，而 Shingles 是將一個序列的詞匯單元，輸出一個單詞級別的 n-gram 詞組單元序列。

Ik_smart 分詞器定制，除了利用IK 分詞器的各種中文定制詞庫外，將其改造為近似的按字標準分詞器。

引入Shingles token filter（Word-based N-Gram 過濾器），對分詞后的 token 做 N 字滑動切分，那么輸入任何 N 個長度的檢索詞，均能保證該 term 被檢索到，而衡量業(yè)務場景和索引存儲，我們將 N 設定為2，入庫的文章均做 2 字分詞切分，保證了倒排索引的存儲相對最優(yōu)，同時約定檢索關鍵詞字符避免單字，在業(yè)務合理范圍內(nèi)，能夠做到檢索召回接近100%。

output_unigrams = False, 將 ik 分詞結果和 shingles 結果分開存儲，便于分別檢索。

（3）存儲優(yōu)化

索引拆分：

根據(jù)業(yè)務場景，做集群拆分，如評論口碑數(shù)據(jù)與新聞網(wǎng)站數(shù)據(jù)集群分離，因為這兩個場景的業(yè)務邏輯不通，查詢并發(fā)度和分析維度差異很大。

針對單一集群做時間滾動拆分，比如按天創(chuàng)建數(shù)據(jù)索引，每天一個增量索引，數(shù)據(jù)檢索直接跨索引查詢，如前所述，動態(tài)規(guī)劃新建索引的分片數(shù)，將單分片的大小維持在 20 ~ 50G最佳。

字段拆分：

ES 是一個全文檢索引擎，我們要將用于全文檢索、聚合分析的索引存儲到 ES，但一些大的文本字段，如 HTML 頁面源碼等，往往占用大量空間，ES 緩存本身非常寶貴，類似字段不僅會占用大量內(nèi)存，也會降低網(wǎng)絡傳輸效率，因此我們對類似大文本字段，只存儲了索引后的分詞結果，并不存儲文本，這樣大大降低了底層 Lucene 文件的大小，也更能充分利用 ES 和系統(tǒng)的緩存。當然，不存儲文本，此類字段將無法提供高亮返回，如有需要，我們通過業(yè)務層做過濾計算匹配即可。

4.5  指標計算方案

通過分布式采集系統(tǒng)，保證數(shù)據(jù)全面性；通過數(shù)據(jù)流處理平臺，保證數(shù)據(jù)處理的及時性和穩(wěn)定性；通過全文檢索數(shù)倉，保證數(shù)據(jù)可以方便的被業(yè)務檢索應用。而輿情監(jiān)測的價值，不僅體現(xiàn)在數(shù)據(jù)的全面、及時，更體現(xiàn)在數(shù)據(jù)細粒度的分析和挖掘上，每一條流進系統(tǒng)的數(shù)據(jù)，分析的結果我們都可以通過標簽來標識，在輿情標簽體系的設計流程中，我們對輿情數(shù)據(jù)指標劃分了不同的層次，在數(shù)據(jù)流動的不同環(huán)節(jié)，產(chǎn)出不同類別的數(shù)據(jù)標簽。

（1）指標分類

定量指標：主要是針對互聯(lián)網(wǎng)海量信息的流量變化等宏觀統(tǒng)計，如趨勢統(tǒng)計、TopN 榜單、關注數(shù)量、熱度分析、信息地理位置分布等，此類信息主要基于存儲引擎做聚合統(tǒng)計，主要難點在于基礎指標字段的采集和存儲設計。

定性指標：主要針對單篇文章，進行附加信息的二次判定和挖掘，我們將主要的技術指標劃分為兩類：

a.  L1 全局指標：主要在數(shù)據(jù)清洗、標準化后，全局計算的文本標簽，包括但不限于：信源分類、媒體分類、行業(yè)分類、地域提取、命名實體識別、通用情感判定、垃圾標簽識別、敏感標記、熱詞計算、傳播力指數(shù)計算、重要度計算等。
 b. L2 個性化指標：基于客戶或領域知識，經(jīng)過個性化調(diào)度流程計算干預的文本標簽，包括但不限于：個性化情感標簽、個性化相關度計算、重要度排名指數(shù)、定制化產(chǎn)品識別、定制化品牌提取等。

（2）計算閉環(huán)

數(shù)據(jù)流轉和計算的基本過程如下圖所示，我們可以簡單地分為：兩個計算中心、一個計算引擎、兩個規(guī)則干預點。

Flink 實時流計算中心：數(shù)據(jù)進入 Flink 集群， 經(jīng)過 ETL 處理，數(shù)據(jù)標準化之后，進行 L1 通用指標的計算，如相似度標簽計算、行業(yè)分類、通用情感計算等，數(shù)據(jù)計算完成即入庫，前端數(shù)據(jù)可檢索呈現(xiàn)。

分布式計算調(diào)度中心：進入數(shù)據(jù)倉庫的數(shù)據(jù)，通過定制化計算調(diào)度中心，將數(shù)據(jù)刷新到客戶存儲引擎，數(shù)據(jù)在此環(huán)節(jié)按照專題做拆分，同時根據(jù)業(yè)務配置的干預規(guī)則，計算 L2 定制化標簽，如定制化細粒度情感標簽、客戶產(chǎn)品類目標記、文本重要度、文本相關度標簽等。

指標計算引擎：指標計算引擎是獨立于數(shù)據(jù)流的一套計算平臺，對外提供 REST 和 gRPC 接口，供計算中心調(diào)用；計算引擎封裝了核心的指標計算算法，一般分為兩類：

a. 規(guī)則類：基于規(guī)則引擎（某些場景，我們使用了基于 Java 的 DROOLS 業(yè)務規(guī)則引擎框架）的邏輯規(guī)則，如網(wǎng)站黑名單過濾、媒體來源歸一、通用字段表轉化等，我們提供實時的規(guī)則編輯、部署、上線功能，讓規(guī)則的干預更及時。
b. 模型類：基于 NLP 模型算法的計算規(guī)則，如：基于 TF-IDF 的文本關鍵詞提取算法，基于 TextRank 的關鍵詞短語和文本摘要提取，基于 Bi-LSTM + Attention 模型的文本分類算法，基于 BERT 及其衍生算法的情感判定算法等。

規(guī)則干預點：信息挖掘算法應該通過特定輸入，能夠增量迭代、不斷提升文本計算的效果，這里主要分為業(yè)務規(guī)則和行為數(shù)據(jù)：

a. 業(yè)務規(guī)則：第一種為通用規(guī)則，比如定期增量更新的輿情標準媒體庫，定期更新的網(wǎng)站媒體 Alex 排名，定期更新的網(wǎng)站采集黑白名單等；第二種為分析師知識庫，一些規(guī)則往往是隨著業(yè)務的沉淀、分析師累積，不斷迭代和豐富，如行業(yè)類目庫、數(shù)據(jù)清洗規(guī)則等。
b. 行為數(shù)據(jù)：客戶行為是我們寶貴的反饋輸入，通過分析客戶對于數(shù)據(jù)的判別行為，能幫助我們迭代優(yōu)化分析效果和準確度，客戶對數(shù)據(jù)的收藏和屏蔽，往往能反映數(shù)據(jù)對客戶的價值度和相關度，我們基于此不斷迭代優(yōu)化 L2 標簽計算的模型效果。用戶的瀏覽和閱讀行為，也能反映出客戶的信息關注點，我們基于此不斷調(diào)優(yōu)數(shù)據(jù)配置的合理性和重要度計算標準，尤其隨著深度遷移學習的發(fā)展和應用，這種基于小量反饋的模型迭代往往能快速提升文本模型的研判效果。

4.6  AI 技術賦能信息挖掘

基于互聯(lián)網(wǎng)公開信息的輿情分析，重點針對的就是非結構化的自然語言文本，而經(jīng)過多年的輿情技術架構演進，傳統(tǒng)的單純追求信息采集快、覆蓋全、檢索準的定量分析，已經(jīng)不能滿足企業(yè)或政府輿情分析的需求，針對輿情信息的智能化分析越來越成為輿情行業(yè)競爭的核心，輿情分析可以說是最適合 NLP（自然語言處理）技術落地和實踐的產(chǎn)業(yè)陣地。

（1）技術發(fā)展路線

早在 2015 年，我們就已經(jīng)開始探索應用 NLP 技術在輿情分析領域的落地場景，我們通過邏輯回歸處理文章的分類。

2016年進入深度學習領域，引入 Word2Vector 在大規(guī)模語料集上進行訓練，隨后在 TextCNN、TextRNN 等深度學習算法上更新迭代，得到了很好的技術指標。

2017年，結合輿情業(yè)務的特點，通過基于依存句法及詞性模板的篇章級情感計算，依據(jù)可擴充的句法規(guī)則及敏感詞庫進行特定的分析，支持文本中針對品牌或關注主體的情感判定。

2019年上半年，隨著以 BERT 為代表的遷移學習誕生，并且支持在下游進行 Fine-Tune，通過較小的訓練數(shù)據(jù)集，即可得到不錯的效果，解決了輿情訓練樣本不足、模型效果難以提升的難題。

2019年下半年，從輿情的業(yè)務問題入手，通過優(yōu)化提取更加精準、貼近業(yè)務的情感摘要作為模型輸入，使用定制化模型以及多模型組合方案，聯(lián)合對數(shù)據(jù)進行情感打標。融合基于特定實體（ATSA，aspect -term sentiment analysis）的負面信息研判，使用 Bert-Sentence Pair 的訓練方式，將摘要文本、實體聯(lián)合輸入，進行實體的情感傾向性判定，在定點客戶上取得不錯的成績，最后的F1值能達到0.95。

除了在輿情情感判定場景，我們在輿情熱詞提取、事件聚類、多維標簽標注、文本相似度計算等方面也在不斷迭代，都取得了不錯的成果。

（2）AI 運營平臺化

如前文所述，盡管設計了一套能反饋干預的閉環(huán)標簽計算流程，但隨著客戶和數(shù)據(jù)量的增長，不同行業(yè)和不同客戶的業(yè)務規(guī)則越來越難以統(tǒng)一，定制化干預的計算需求越來越多，模型訓練、部署的任務就不能僅局限在研發(fā)人員身上，因此為了提升業(yè)務定制化干預的效率，我們設計和實現(xiàn)了一套打通了業(yè)務閉環(huán)，集數(shù)據(jù)標注、模型訓練、模型自動化部署的 AI  模型訓練平臺，將相關部門協(xié)同聯(lián)動起來，大大提升了不同客戶效果迭代的效率。

簡要架構如上圖所示：

平臺上層，提供了一套標準的可視化操作界面；

平臺底層，設計了一套 AI 模型訓練的 CI\CD 流程。

自助訓練，支持TensorFlow 和PyTorch 框架，方便研發(fā)人員對底層模型算法的靈活擴充，該流程實現(xiàn)了從算法、數(shù)據(jù) 到 模型的過程。

自動部署，基于Kubernetes 和Docker 容器云平臺，打通了模型鏡像 到 服務發(fā)布的全流程，提供模型容器編排、接口映射、服務發(fā)布、版本管理等功能。

2020年7月份，AI運營平臺1.0版本發(fā)布后，上線了超過200個個性化定制實時預測模型，依靠底層強大的GPU算力，每天都有數(shù)十個分類等模型在迭代運算，在情感判定定制化干預模型下，個別客戶已經(jīng)能夠做到99%的負面判定準確度。

（3）AI工具賦能效率提升

依托百分點人工智能實驗室，我們致力于通過人工智能技術提升信息挖掘的智能化水平，同時，我們也專注于通過 AI 幫助提高人員的服務效率，在輿情服務的全周期過程中，我們不僅通過自主研發(fā)的 AI 運營平臺，為輿情分析師提供文本挖掘效率輔助，還引入了百分點自主研發(fā)的智能媒體校對系統(tǒng)，在輿情系統(tǒng)和輿情分析師的報告輸出環(huán)節(jié)，做自動化的媒體稿件審校，避免錯誤，讓報告服務更專業(yè)。

總結和展望

本文簡要介紹了互聯(lián)網(wǎng)輿情系統(tǒng)的架構思路和若干技術選型，簡單來看，輿情服務體系的構建不僅僅是一個匯集數(shù)據(jù)采集、處理、呈現(xiàn)的大數(shù)據(jù)流式系統(tǒng)，而是一個服務于輿情客戶生態(tài)的業(yè)務閉環(huán)，如何充分利用反饋數(shù)據(jù)，迭代提升指標效果非常重要。隨著 SaaS 發(fā)展進入了 3.0 時代，從技術角度看，結合輿情發(fā)展的新趨勢，我們?nèi)詫⒕劢挂韵聝牲c：

（1）AI 技術將持續(xù)精進，從賦能者向引領者進化

在數(shù)據(jù)采集方面，將持續(xù)推進網(wǎng)絡采集機器人的智能化，讓人工干預更少，信息覆蓋更全，站點采集更穩(wěn)定；在文本分析方面，將持續(xù)探索深度遷移學習在輿情數(shù)據(jù)信息分類、事件聚類、情緒識別、熱點追蹤等場景的落地應用；同時，將持續(xù)推進 AIOps 在輿情服務體系的應用實踐，讓 AI 自動化提升信息系統(tǒng)迭代效率，支撐企業(yè)細分場景下個性化的需求。

（2）聚焦效率提升，降低邊際成本

我們?nèi)詫⒕劢雇ㄟ^技術驅動提升服務效率，降低邊際成本。在數(shù)據(jù)處理層面，推動構建實時數(shù)倉，大幅提升數(shù)據(jù)定量分析效率；在數(shù)據(jù)運營層面，進一步豐富數(shù)據(jù) ETL 自動化工具，降低人工服務的工時成本；在產(chǎn)品創(chuàng)新的同時，促進模式創(chuàng)新，提升輿情服務體系的運轉效率。

百分點輿情洞察服務體系是一個持續(xù)進化十余年的互聯(lián)網(wǎng)媒體服務平臺，服務了近萬家各行業(yè)企事業(yè)單位，積累了大量的輿情服務體系業(yè)務專業(yè)知識，在覆蓋全面、更新及時、挖掘精準的同時，進一步提升 AI 分析和挖掘水平，讓輿情決策更智能。

來源：百分點