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

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

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

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

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

簡(jiǎn)單來(lái)看，輿情監(jiān)測(cè)系統(tǒng)，主要由數(shù)據(jù)采集、SaaS 平臺(tái)、運(yùn)營(yíng)工具棧構(gòu)成。

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

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

需要指出的是，在整個(gè)輿情服務(wù)過(guò)程中，輿情監(jiān)測(cè)系統(tǒng)需要能夠?qū)崟r(shí)收集業(yè)務(wù)知識(shí)，并反饋到信息挖掘平臺(tái)，不斷優(yōu)化和提升 SaaS 平臺(tái)的信息挖掘能力和水平。

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

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

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

4.

輿情系統(tǒng)的架構(gòu)實(shí)踐

4.1  基礎(chǔ)架構(gòu)分析

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

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

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

簡(jiǎn)化版的輿情系統(tǒng)基礎(chǔ)架構(gòu)如下：

整個(gè)架構(gòu)分為兩個(gè)層次：

a. 資源層：整合數(shù)據(jù)采集、計(jì)算、存儲(chǔ)，形成整體的輿情資產(chǎn)核心能力；

b. 業(yè)務(wù)層：基于輿情場(chǎng)景，構(gòu)建各種上層應(yīng)用。

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

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

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

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

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

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

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

業(yè)務(wù)服務(wù)層：

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

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

業(yè)務(wù)應(yīng)用層：

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

作為輿情系統(tǒng)的底層支撐，下面我們將簡(jiǎn)單分享我們?cè)谄脚_(tái)資源層的架構(gòu)實(shí)踐，即：高效的數(shù)據(jù)流處理架構(gòu)、穩(wěn)定的數(shù)據(jù)存儲(chǔ)平臺(tái)、完善的指標(biāo)挖掘體系。

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

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

a. 數(shù)據(jù)處理高效：數(shù)據(jù)采集到數(shù)據(jù)持久化存儲(chǔ)，中間的數(shù)據(jù)處理時(shí)間不能超過(guò)30s，最大限度保證輿情消息的及時(shí)性；

b. 數(shù)據(jù)處理穩(wěn)定：輿情數(shù)據(jù)有明顯的峰谷周期，夜間數(shù)據(jù)較少，白天出現(xiàn)多個(gè)信息波峰，同時(shí)互聯(lián)網(wǎng)輿情事件具有突發(fā)性，數(shù)據(jù)處理平臺(tái)需要具備削峰填谷的能力；

c. 開(kāi)發(fā)運(yùn)維方便：開(kāi)發(fā)友好，運(yùn)維簡(jiǎn)單。

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

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

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

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

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

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

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

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

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

Flink On Yarn 提供2種任務(wù)提交方式：

a. Yarn Session：多 Job 共享一個(gè) Flink 集群，YARN 資源共享；

b. Flink Run ：獨(dú)立 Job 獨(dú)占 Yarn Session，任務(wù)間互不影響。

我們使用第二種方式提交，能做到更好的業(yè)務(wù)資源隔離和集群任務(wù)監(jiān)控。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

（2）存儲(chǔ)架構(gòu)：

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

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

通過(guò)數(shù)據(jù)流計(jì)算完成的標(biāo)準(zhǔn)數(shù)據(jù)，通過(guò) Data Pipeline 同步寫(xiě)入 全量數(shù)據(jù)倉(cāng)庫(kù) 和 ES準(zhǔn)實(shí)時(shí)索引集群，ES 集群存儲(chǔ)文本索引字段，構(gòu)建倒排索引，文檔關(guān)聯(lián)的原始 HTML 和 資源（如圖片、視頻），分別存儲(chǔ)到 HBase和 OSS 對(duì)象存儲(chǔ)平臺(tái)，構(gòu)建ES 文檔關(guān)聯(lián)。

業(yè)務(wù)拆分：

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

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

離線備份：

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

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

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

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

檢索精度要求：

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

檢索性能要求：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Token filter 階段：接收 token 流，通過(guò)配置的filter 算法，對(duì)每個(gè)token進(jìn)行轉(zhuǎn)化，比如小寫(xiě)轉(zhuǎn)化、停用詞刪除、同義詞引入等，ES也提供了多種預(yù)置的 過(guò)濾器。

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

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

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

Shingles 過(guò)濾器是一種特殊的詞元過(guò)濾器，與N-Gram 不同的是，n-gram 過(guò)濾器針對(duì)的是單個(gè)詞匯單元，輸出一個(gè)字母n-gram 詞匯單元序列，而 Shingles 是將一個(gè)序列的詞匯單元，輸出一個(gè)單詞級(jí)別的 n-gram 詞組單元序列。

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

索引拆分：

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

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

字段拆分：

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

4.5  指標(biāo)計(jì)算方案

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

（1）指標(biāo)分類

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

定性指標(biāo)：主要針對(duì)單篇文章，進(jìn)行附加信息的二次判定和挖掘，我們將主要的技術(shù)指標(biāo)劃分為兩類：

a.  L1 全局指標(biāo)：主要在數(shù)據(jù)清洗、標(biāo)準(zhǔn)化后，全局計(jì)算的文本標(biāo)簽，包括但不限于：信源分類、媒體分類、行業(yè)分類、地域提取、命名實(shí)體識(shí)別、通用情感判定、垃圾標(biāo)簽識(shí)別、敏感標(biāo)記、熱詞計(jì)算、傳播力指數(shù)計(jì)算、重要度計(jì)算等。

 b. L2 個(gè)性化指標(biāo)：基于客戶或領(lǐng)域知識(shí)，經(jīng)過(guò)個(gè)性化調(diào)度流程計(jì)算干預(yù)的文本標(biāo)簽，包括但不限于：個(gè)性化情感標(biāo)簽、個(gè)性化相關(guān)度計(jì)算、重要度排名指數(shù)、定制化產(chǎn)品識(shí)別、定制化品牌提取等。

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

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

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

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

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

a. 規(guī)則類：基于規(guī)則引擎（某些場(chǎng)景，我們使用了基于 Java 的 DROOLS 業(yè)務(wù)規(guī)則引擎框架）的邏輯規(guī)則，如網(wǎng)站黑名單過(guò)濾、媒體來(lái)源歸一、通用字段表轉(zhuǎn)化等，我們提供實(shí)時(shí)的規(guī)則編輯、部署、上線功能，讓規(guī)則的干預(yù)更及時(shí)。

b. 模型類：基于 NLP 模型算法的計(jì)算規(guī)則，如：基于 TF-IDF 的文本關(guān)鍵詞提取算法，基于 TextRank 的關(guān)鍵詞短語(yǔ)和文本摘要提取，基于 Bi-LSTM + Attention 模型的文本分類算法，基于 BERT 及其衍生算法的情感判定算法等。

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

a. 業(yè)務(wù)規(guī)則：第一種為通用規(guī)則，比如定期增量更新的輿情標(biāo)準(zhǔn)媒體庫(kù)，定期更新的網(wǎng)站媒體 Alex 排名，定期更新的網(wǎng)站采集黑白名單等；第二種為分析師知識(shí)庫(kù)，一些規(guī)則往往是隨著業(yè)務(wù)的沉淀、分析師累積，不斷迭代和豐富，如行業(yè)類目庫(kù)、數(shù)據(jù)清洗規(guī)則等。

b. 行為數(shù)據(jù)：客戶行為是我們寶貴的反饋輸入，通過(guò)分析客戶對(duì)于數(shù)據(jù)的判別行為，能幫助我們迭代優(yōu)化分析效果和準(zhǔn)確度，客戶對(duì)數(shù)據(jù)的收藏和屏蔽，往往能反映數(shù)據(jù)對(duì)客戶的價(jià)值度和相關(guān)度，我們基于此不斷迭代優(yōu)化 L2 標(biāo)簽計(jì)算的模型效果。用戶的瀏覽和閱讀行為，也能反映出客戶的信息關(guān)注點(diǎn)，我們基于此不斷調(diào)優(yōu)數(shù)據(jù)配置的合理性和重要度計(jì)算標(biāo)準(zhǔn)，尤其隨著深度遷移學(xué)習(xí)的發(fā)展和應(yīng)用，這種基于小量反饋的模型迭代往往能快速提升文本模型的研判效果。

4.6  AI 技術(shù)賦能信息挖掘

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

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

早在 2015 年，我們就已經(jīng)開(kāi)始探索應(yīng)用 NLP 技術(shù)在輿情分析領(lǐng)域的落地場(chǎng)景，我們通過(guò)邏輯回歸處理文章的分類。

2016年進(jìn)入深度學(xué)習(xí)領(lǐng)域，引入 Word2Vector 在大規(guī)模語(yǔ)料集上進(jìn)行訓(xùn)練，隨后在 TextCNN、TextRNN 等深度學(xué)習(xí)算法上更新迭代，得到了很好的技術(shù)指標(biāo)。

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

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

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

除了在輿情情感判定場(chǎng)景，我們?cè)谳浨闊嵩~提取、事件聚類、多維標(biāo)簽標(biāo)注、文本相似度計(jì)算等方面也在不斷迭代，都取得了不錯(cuò)的成果。

（2）AI 運(yùn)營(yíng)平臺(tái)化

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

簡(jiǎn)要架構(gòu)如上圖所示：

平臺(tái)上層，提供了一套標(biāo)準(zhǔn)的可視化操作界面；

平臺(tái)底層，設(shè)計(jì)了一套 AI 模型訓(xùn)練的 CI\CD 流程。

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

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

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

總結(jié)和展望

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

（1）AI 技術(shù)將持續(xù)精進(jìn)，從賦能者向引領(lǐng)者進(jìn)化

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

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

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

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

【作者： 百分點(diǎn)大數(shù)據(jù)團(tuán)隊(duì) 】

分享到

xiesc

相關(guān)推薦