互聯網輿情繫統的架構實踐

+>編者按

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

1. 輿情分析的業務特點

1.1 信源覆蓋廣

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

1.2 需求行業多

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

1.3 社會價值高

輿情分析服務能爲目標客戶提供多維度的信息挖掘和高附加值的洞察分析,具有巨大的企業和社會價值:

負面信息挖掘: 負面信息發現,是輿情監測的核心價值點,如果不能及時準確地發現負面信息,造成負面輿論發酵,可能對企業帶來不可挽回的損失,對政府帶來嚴重的公信力質疑。

競品信息監測: 無論是企業市場人員,還是產品經理,競品分析都是門必備的通用技能,通過對現有或潛在的競爭產品或者企業進行信息監測、情報挖掘,分析優劣勢,往往能幫助企業掌握競爭的主動權。

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

事件脈絡分析: 無論對於互聯網熱點事件還是產品傳播營銷,通過對事件細粒度的傳播分析,洞察事件發酵脈絡,挖掘傳播爆點,掌握事件傳播路徑,爲事件處置或營銷效果分析提供決策依據。

民生民意調查: 通過對互聯網事件的輿論監測,挖掘對於互聯網事件的公衆情緒、公衆觀點、意見領袖、傳播路徑,爲政府輿情引導、輿情管控提供決策輔助。

1.4 技術挑戰大

輿情監測系統,不僅需要具備強大的數據採集和處理能力,還需要具備強大的價值挖掘能力,構建強大的輿情監測系統,往往面臨巨大的技術挑戰。

數據全面: 針對海量的互聯網信息,構建強大的數據採集系統,保證數據全面、不遺漏,是輿情監測能力保障的基礎。

檢索精確: 輿情繫統能夠代替人工精準檢索目標數據,這對海量數據的全文檢索提出很高的要求,不僅要找到匹配的信息,還要去除干擾,最大化匹配檢索意圖。

預警及時: 輿論環境瞬息萬變,企業和政府都期望第一時間掌握輿情動態;輿情監測需要提供7&24小時、近實時信息預警,具備秒級採集、處理、研判和下發機制。

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

標籤豐富: 除了基本的輿情大數據全流程處理,輿情繫統還應該具備更深層次的信息挖掘能力,如標籤提取、地域甄別、信息分類、事件發現等,最大化提升附加值挖掘能力,降低人工服務成本。

2. 輿情發展的新趨勢

2.1 精細化運營,實現彎道超車

互聯網輿情行業發展多年,玩家衆多,傳統的輿情分析,場景模式相對固定,競爭趨於白熱化;而輿情分析的細粒度需求,如負面關注度、文本相關性等,越來越趨於差異化和定製化,在 SaaS 標品的模式下,如何針對不同的行業客戶、不同的分析場景實現平臺化、精細化的運營,變得越來越重要,打造業務閉環、構建能夠實現差異化運營的平臺化產品矩陣,才能實現彎道超車。

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

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

2.3 業務模式創新,拓展深度和廣度

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

3. 輿情信息的挖掘過程

3.1 基於實時數據流的數據挖掘

互聯網輿情,本質上是對互聯網公開信息的採集、分析、研判,併產生業務價值,是一個價值數據挖掘的過程,但基於其業務場景和系統要求,與傳統的數據挖掘又有很大差別。

傳統的數據挖掘任務,一般有如下幾個過程:

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

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

信息以流式輸入到在線處理引擎,經過 ETL 處理標準化的數據,進入數據挖掘過程,如基於規則引擎計算文本指標、通過機器學習算法模型計算文本標籤等,這些規則或模型蘊含業務知識,數據計算結果經過存儲,呈現給業務人員,後續隨着業務的評估和迭代,挖掘中的業務知識會被動態干預,形成知識流動迭代的閉環。

因此,傳統的數據挖掘過程,往往是靜態的一次性過程,而輿情分析的信息挖掘,是一個流動的不間斷過程。

3.2 多工種協作的業務閉環

同時,輿情監測體系的運行,也是一個多方共同參與的過程,不同角色的人員共同協作,不斷迭代產生更優的價值挖掘結果,準確及時地呈現給終端客戶。

簡單來看,輿情監測系統,主要由數據採集、SaaS 平臺、運營工具棧構成。

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

同時,我們還需要提供豐富的運營分析工具棧,如數據清洗、報告製作、預警干預、數據宏觀分析、觀點挖掘、事件發現等運營工具,幫助輿情分析師製作人工報告,提供高效率的人工服務。

需要指出的是,在整個輿情服務過程中,輿情監測系統需要能夠實時收集業務知識,並反饋到信息挖掘平臺,不斷優化和提升 SaaS 平臺的信息挖掘能力和水平。

輿情分析師的業務經驗: 輿情分析師是人工服務的價值輸出方,能夠深刻理解客戶的監測需求,沉澱下來的業務知識,將直接錄入挖掘平臺,動態干預定向客戶的分析效果,如客戶的定製化負面評價指標、客戶的定製分析詞庫等。

終端用戶的行爲反饋: 系統應該能夠自動收集用戶的行爲數據,以最大限度地降低用戶的額外工作,提高系統迭代的效率,如數據的收藏行爲、數據的屏蔽行爲、數據的瀏覽行爲等。

概括來講,輿情分析系統是一個基於實時流動信息、多方協作參與的價值信息挖掘平臺。

4. 輿情繫統的架構實踐

4.1 基礎架構分析

輿情監測系統,可以看做是一個價值信息挖掘的平臺體系,重點是兩個能力的建設:

資源構建能力: 通過數據採集和信息挖掘,構建輿情繫統的資源基礎,形成標準一致的信息輸出接口。

業務應用能力: 依託底層的輿情資源,構建貼合場景的業務應用,既服務於輿情 SaaS 客戶,還服務於人工分析師,輸出專業能力的同時,幫助提升組織效率。

簡化版的輿情繫統基礎架構如下:

整個架構分爲兩個層次:

a. 資源層:整合數據採集、計算、存儲,形成整體的輿情資產核心能力;

b. 業務層:基於輿情場景,構建各種上層應用。

數據採集層

依託百分點大數據採集系統,我們構建了超過1000+ 服務器節點的大規模數據採集集羣,覆蓋90%以上的全網公開價值信息;包括新聞、報刊、微博、微信、APP、論壇、貼吧、博客、視頻、問答、外媒網站、Facebook、Twitter、短視頻等近14個信源數據,本文我們不展開講述採集系統的構建。

數據計算層

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

數據存儲層

我們綜合構建了適用於實時業務檢索和離線數據拉取計算的存儲架構,核心基於 ElasticSearch(ES) 和 Hbase 存儲實時輿情數據,基於 HBase + Hive(HDFS)構建離線數據倉庫,爲上層業務分析、數據應用構建提供高效、統一的信息檢索服務。

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

業務服務層

在業務層,我們將輿情的業務模塊化,形成衆多獨立部署的微服務,將用戶管理、話題管理、標籤管理、數據檢索、多維分析、標籤分析等核心業務暴露爲統一的 REST 接口,構建了多個調度中心,負責處理輿情報告、預警、數據處理、服務監控等服務。

技術棧主要以SpringCloud框架和容器雲 Docker 虛擬化爲主,底層基於 Kubernetes 做資源管理和服務編排,構建了超過 200個鏡像節點的線上微服務集羣,支撐每天近萬用戶的複雜檢索和 API 調用。

業務應用層

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

作爲輿情繫統的底層支撐,下面我們將簡單分享我們在平臺資源層的架構實踐,即:高效的數據流處理架構、穩定的數據存儲平臺、完善的指標挖掘體系。

4.2 數據流處理方案

基於輿情業務特點,數據處理需要滿足以下要求:

a. 數據處理高效:數據採集到數據持久化存儲,中間的數據處理時間不能超過30s,最大限度保證輿情消息的及時性;

b. 數據處理穩定:輿情數據有明顯的峯谷週期,夜間數據較少,白天出現多個信息波峯,同時互聯網輿情事件具有突發性,數據處理平臺需要具備削峯填谷的能力;

c. 開發運維方便:開發友好,運維簡單。

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

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

如圖所示,Flink 集羣由 Flink Master、TaskManager 組成,Flink Master 中對應多個 JobManager,每個 JobManager 負責管理單個 Job 的調度和執行,而 Resource Manager 負責整個集羣的內外部資源調度,Flink 可以支持嫁接在 Kubernetes、Mesos、Yarn 等資源調度管理系統之上,結合我們現有的大數據處理平臺,我們使用 Yarn 作爲我們 Flink 集羣的底層資源管理系統。

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

以其中一個<數據 Level1 清洗> Job 爲例:

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

使用 Flink 集羣的核心優勢

資源調度: 採用統一的 Yarn 作爲 Flink 資源調度,相比使用裸機的 Storm,大幅提高了資源利用率,同時使資源伸縮變得更方便。

新的 Flink 集羣,在資源利用率持續控制在 60%左右的情況下,物理機資源節約了 50%,不僅節約了硬件成本,還提高了數據處理的能力。

Flink On Yarn 提供2種任務提交方式:
a. Yarn Session:多 Job 共享一個 Flink 集羣,YARN 資源共享;
b. Flink Run :獨立 Job 獨佔 Yarn Session,任務間互不影響。
我們使用第二種方式提交,能做到更好的業務資源隔離和集羣任務監控。

動態反壓機制: Flink 提供比 Storm 更好的動態反壓機制,能夠動態感知被阻塞的 Operator,自適應地降低源頭或上游數據的發送速率,從而維持整個系統的穩定。

針對輿情場景下的數據流量波峯波谷和不確定的熱點事件,Flink 集羣很好的平衡了數據流速,解決了 Storm 集羣頻發的高負載故障。

廣播變量: Flink提供靈活的廣播變量,通過將全局共享的數據廣播出去,不同的任務在同一個節點上都能獲取,數據只存在一份,相比於分佈式緩存,節省了內存開銷。

邏輯解耦: Flink 基於細粒度的算子鏈構建業務任務,可以把業務抽象成粒度足夠小的算子,代碼邏輯高度解耦;單個算子可單獨配置並行度,其 Operator Chain 機制還能自動優化執行邏輯,將並行度一致的算子轉化爲線程內的方法調用,減少網絡通信,提高運行效率。

除了 Flink 自帶的任務資源管理,我們還進一步豐富了 Flink 在YARN Session 級別的監控維度,接入 Grafana:

4.3 數據存儲方案

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

實時數據價值更高: 輿情數據傳播趨勢特徵明顯,人們關注的信息大部分集中在7天之內,且信息採集呈現的及時性,往往是分鐘級的。

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

檢索業務處理集中: 輿情平臺的檢索壓力有明顯的特徵曲線,工作時間負載壓力大,早晚高峯報告查詢集中。

(1)選型發展

信息檢索是輿情繫統的核心需求,基於 Lucene 的全文檢索引擎是實時數據檢索的組件首選,早期我們使用 Solr,但是 Solr 依賴外部組件協調(ZooKeeper),運維成本很高。

2015年,我們引入ElasticSearch(ES)作爲平臺的底層數據庫,提升了輿情數據存儲集羣的運維效率,也提高了平臺存儲的穩定性。

隨着業務發展,數據量越來越大,即使是已經按照業務拆分的集羣隔離也已經不能滿足業務查詢的性能要求,2017年底,我們做了大幅底層集羣優化和硬件升級,從業務集羣隔離拓展到多集羣、多索引的混合集羣模式,版本也升級到了 6.*。伴隨產品維度和數據量的增長,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級的數據增量,以及上萬客戶的複雜輿情檢索和計算。

4.4 檢索優化方案

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

檢索精度要求

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

檢索性能要求

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

數據相關性要求

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

業務靈活性要求

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

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

(1)集羣調優

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

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

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

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

(2)分詞優化

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

ES 的索引字段(analyzed)的分析(analysis)過程如下:

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

Tokenizer 階段: 即切詞階段,接收一個字符流 ,經過分詞器切割拆分爲多個 token,並輸出一個 token 流。

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

這裏需要解決的問題是分詞準確性導致的檢索召回率問題,比如我們要通過“微貸網”檢索數據,無論採用 IK 分詞器的 ik_smart 或 ik_max_word,都無法檢索出下面這句:“微貸網費用有哪些?”

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

我們的方案是調整分詞,將修飾定製的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 被檢索到,而衡量業務場景和索引存儲,我們將 N 設定爲2,入庫的文章均做 2 字分詞切分,保證了倒排索引的存儲相對最優,同時約定檢索關鍵詞字符避免單字,在業務合理範圍內,能夠做到檢索召回接近100%。
  • output_unigrams = False, 將 ik 分詞結果和 shingles 結果分開存儲,便於分別檢索。

(3)存儲優化

索引拆分

根據業務場景,做集羣拆分,如評論口碑數據與新聞網站數據集羣分離,因爲這兩個場景的業務邏輯不通,查詢併發度和分析維度差異很大。

針對單一集羣做時間滾動拆分,比如按天創建數據索引,每天一個增量索引,數據檢索直接跨索引查詢,如前所述,動態規劃新建索引的分片數,將單分片的大小維持在 20 ~ 50G最佳。

字段拆分

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

4.5 指標計算方案

通過分佈式採集系統,保證數據全面性;通過數據流處理平臺,保證數據處理的及時性和穩定性;通過全文檢索數倉,保證數據可以方便的被業務檢索應用。而輿情監測的價值,不僅體現在數據的全面、及時,更體現在數據細粒度的分析和挖掘上,每一條流進系統的數據,分析的結果我們都可以通過標籤來標識,在輿情標籤體系的設計流程中,我們對輿情數據指標劃分了不同的層次,在數據流動的不同環節,產出不同類別的數據標籤。

(1)指標分類

定量指標: 主要是針對互聯網海量信息的流量變化等宏觀統計,如趨勢統計、TopN 榜單、關注數量、熱度分析、信息地理位置分佈等,此類信息主要基於存儲引擎做聚合統計,主要難點在於基礎指標字段的採集和存儲設計。

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

a. L1 全局指標:主要在數據清洗、標準化後,全局計算的文本標籤,包括但不限於:信源分類、媒體分類、行業分類、地域提取、命名實體識別、通用情感判定、垃圾標籤識別、敏感標記、熱詞計算、傳播力指數計算、重要度計算等。

b. L2 個性化指標:基於客戶或領域知識,經過個性化調度流程計算干預的文本標籤,包括但不限於:個性化情感標籤、個性化相關度計算、重要度排名指數、定製化產品識別、定製化品牌提取等。

(2)計算閉環

數據流轉和計算的基本過程如下圖所示,我們可以簡單地分爲:兩個計算中心、一個計算引擎、兩個規則干預點。

Flink 實時流計算中心: 數據進入 Flink 集羣, 經過 ETL 處理,數據標準化之後,進行 L1 通用指標的計算,如相似度標籤計算、行業分類、通用情感計算等,數據計算完成即入庫,前端數據可檢索呈現。

分佈式計算調度中心: 進入數據倉庫的數據,通過定製化計算調度中心,將數據刷新到客戶存儲引擎,數據在此環節按照專題做拆分,同時根據業務配置的干預規則,計算 L2 定製化標籤,如定製化細粒度情感標籤、客戶產品類目標記、文本重要度、文本相關度標籤等。

指標計算引擎: 指標計算引擎是獨立於數據流的一套計算平臺,對外提供 REST 和 gRPC 接口,供計算中心調用;計算引擎封裝了核心的指標計算算法,一般分爲兩類:

a. 規則類:基於規則引擎(某些場景,我們使用了基於 Java 的 DROOLS 業務規則引擎框架)的邏輯規則,如網站黑名單過濾、媒體來源歸一、通用字段錶轉化等,我們提供實時的規則編輯、部署、上線功能,讓規則的干預更及時。

b. 模型類:基於 NLP 模型算法的計算規則,如:基於 TF-IDF 的文本關鍵詞提取算法,基於 TextRank 的關鍵詞短語和文本摘要提取,基於 Bi-LSTM + Attention 模型的文本分類算法,基於 BERT 及其衍生算法的情感判定算法等。

規則干預點: 信息挖掘算法應該通過特定輸入,能夠增量迭代、不斷提升文本計算的效果,這裏主要分爲業務規則和行爲數據:

a. 業務規則:第一種爲通用規則,比如定期增量更新的輿情標準媒體庫,定期更新的網站媒體 Alex 排名,定期更新的網站採集黑白名單等;第二種爲分析師知識庫,一些規則往往是隨着業務的沉澱、分析師累積,不斷迭代和豐富,如行業類目庫、數據清洗規則等。

b. 行爲數據:客戶行爲是我們寶貴的反饋輸入,通過分析客戶對於數據的判別行爲,能幫助我們迭代優化分析效果和準確度,客戶對數據的收藏和屏蔽,往往能反映數據對客戶的價值度和相關度,我們基於此不斷迭代優化 L2 標籤計算的模型效果。用戶的瀏覽和閱讀行爲,也能反映出客戶的信息關注點,我們基於此不斷調優數據配置的合理性和重要度計算標準,尤其隨着深度遷移學習的發展和應用,這種基於小量反饋的模型迭代往往能快速提升文本模型的研判效果。

4.6 AI 技術賦能信息挖掘

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

(1)技術發展路線

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

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

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

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

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

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

(2)AI 運營平臺化

如前文所述,儘管設計了一套能反饋干預的閉環標籤計算流程,但隨着客戶和數據量的增長,不同行業和不同客戶的業務規則越來越難以統一,定製化干預的計算需求越來越多,模型訓練、部署的任務就不能僅侷限在研發人員身上,因此爲了提升業務定製化干預的效率,我們設計和實現了一套打通了業務閉環,集數據標註、模型訓練、模型自動化部署的 AI 模型訓練平臺,將相關部門協同聯動起來,大大提升了不同客戶效果迭代的效率。

簡要架構如上圖所示:

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

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

  • 自助訓練,支持TensorFlow 和PyTorch 框架,方便研發人員對底層模型算法的靈活擴充,該流程實現了從算法、數據 到 模型的過程。
  • 自動部署,基於Kubernetes 和Docker 容器雲平臺,打通了模型鏡像 到 服務發佈的全流程,提供模型容器編排、接口映射、服務發佈、版本管理等功能。

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

(3)AI工具賦能效率提升

依託百分點人工智能實驗室,我們致力於通過人工智能技術提升信息挖掘的智能化水平,同時,我們也專注於通過 AI 幫助提高人員的服務效率,在輿情服務的全週期過程中,我們不僅通過自主研發的 AI 運營平臺,爲輿情分析師提供文本挖掘效率輔助,還引入了百分點自主研發的智能媒體校對系統,在輿情繫統和輿情分析師的報告輸出環節,做自動化的媒體稿件審校,避免錯誤,讓報告服務更專業。

總結和展望

本文簡要介紹了互聯網輿情繫統的架構思路和若干技術選型,簡單來看,輿情服務體系的構建不僅僅是一個彙集數據採集、處理、呈現的大數據流式系統,而是一個服務於輿情客戶生態的業務閉環,如何充分利用反饋數據,迭代提升指標效果非常重要。隨着 SaaS 發展進入了 3.0 時代,從技術角度看,結合輿情發展的新趨勢,我們仍將聚焦以下兩點:

(1)AI 技術將持續精進,從賦能者向引領者進化

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

(2)聚焦效率提升,降低邊際成本

我們仍將聚焦通過技術驅動提升服務效率,降低邊際成本。在數據處理層面,推動構建實時數倉,大幅提升數據定量分析效率;在數據運營層面,進一步豐富數據 ETL 自動化工具,降低人工服務的工時成本;在產品創新的同時,促進模式創新,提升輿情服務體系的運轉效率。

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

本文轉載自公衆號百分點(ID:baifendian_com)。

原文鏈接

互聯網輿情繫統的架構實踐

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章