阿里妹導讀：互聯(lián)網(wǎng)的飛速發(fā)展促進了很多新媒體的發(fā)展，不論是知名的大V，明星還是圍觀群眾都可以通過手機在微博、朋友圈或者點評網(wǎng)站上發(fā)表動態(tài)，分享自己的所見所想，使得“人人都有了麥克風”。不論是熱點新聞還是娛樂八卦，傳播速度遠超我們的想象，一則信息可以在短短數(shù)分鐘內，有數(shù)萬計轉發(fā)，數(shù)百萬的閱讀。海量信息可以得到爆炸式的傳播，那么如何實時把握信息并作出對應的處理呢?是不是真的難以應對?今天，阿里云智能事業(yè)群的宇珩來跟我們聊聊大數(shù)據(jù)輿情系統(tǒng)對數(shù)據(jù)存儲和計算系統(tǒng)會有哪些需求，如何根據(jù)需求來進行系統(tǒng)設計。

大數(shù)據(jù)時代下，除了媒體信息以外，商品在各類電商平臺的訂單量、用戶的購買評論，都會對后續(xù)的消費者產(chǎn)生很大的影響。商家的產(chǎn)品設計者需要匯總統(tǒng)計和分析各類平臺的數(shù)據(jù)做為依據(jù)，決定后續(xù)的產(chǎn)品發(fā)展，公司的公關和市場部門也需要根據(jù)輿情作出相應的及時處理，而這一切也意味著傳統(tǒng)的輿情系統(tǒng)升級成為大數(shù)據(jù)輿情采集和分析系統(tǒng)。具體細化看下大數(shù)據(jù)輿情系統(tǒng)，對我們的數(shù)據(jù)存儲和計算系統(tǒng)提出了以下需求：

海量原始數(shù)據(jù)的實時入庫：為了實現(xiàn)一整套輿情系統(tǒng)，需要有上游原始輸出的采集，也就是爬蟲系統(tǒng)。爬蟲需要采集各類門戶，自媒體的網(wǎng)頁內容。在抓取前需要去重，抓取后還需要分析提取，例如進行子網(wǎng)頁的抓取。

原始網(wǎng)頁數(shù)據(jù)的處理：不論是主流門戶還是自媒體的網(wǎng)頁信息，抓取后我們需要做一定的數(shù)據(jù)提取，把原始的網(wǎng)頁內容轉化為結構化數(shù)據(jù)，例如文章的標題，摘要等，如果是商品點評類消息也需要提取有效的點評。

結構化數(shù)據(jù)的輿情分析：當各類原始輸出變成結構化的數(shù)據(jù)后，我們需要有一個實時的計算產(chǎn)品把各類輸出做合理的分類，進一步對分類后的內容進行情感打標。根據(jù)業(yè)務的需求這里可能會產(chǎn)生不同的輸出，例如品牌當下是否有熱點話題，輿情影響力分析，轉播路徑分析，參與用戶統(tǒng)計和畫像，輿論情感分析或者是否有重大預警。

輿情分析系統(tǒng)中間和結果數(shù)據(jù)的存儲，交互分析查詢：從網(wǎng)頁原始數(shù)據(jù)清洗到最終的輿情報表這中間會產(chǎn)生很多類型的數(shù)據(jù)。這些數(shù)據(jù)有的會提供給數(shù)據(jù)分析同學進行輿情分析系統(tǒng)的調優(yōu)，有的數(shù)據(jù)會提供給業(yè)務部門根據(jù)輿情結果進行決策。這些查詢可能會很靈活，需要我們的存儲系統(tǒng)具備全文檢索，多字段組合靈活的交互分析能力。

重大輿情事件的實時預警：對于輿情的結果除了正常的搜索和展示需求以外，當有重大事件出現(xiàn)我們需要能做到實時的預警。

本文主要是提供架構設計，會先介紹時下主流的大數(shù)據(jù)計算架構，并分析一些優(yōu)缺點，然后引入輿情大數(shù)據(jù)架構。

系統(tǒng)設計

需求分析

結合文章開頭對輿情系統(tǒng)的描述，海量大數(shù)據(jù)輿情分析系統(tǒng)流程圖大體如下：

原始網(wǎng)頁存儲庫，這個庫需要能支持海量數(shù)據(jù)，低成本，低延時寫入。網(wǎng)頁數(shù)據(jù)寫入后，要做實時結構化提取，提取出來的數(shù)據(jù)再進行降噪，分詞，圖片ocr處理等。對分詞文本，圖片進行情感識別產(chǎn)生輿情數(shù)據(jù)結果集。傳統(tǒng)的離線全量計算很難滿足輿情系統(tǒng)的時效性需求。

計算引擎在做數(shù)據(jù)處理時，可能還需要從存儲庫中獲取一些元數(shù)據(jù)，例如用戶信息，情感詞元數(shù)據(jù)信息等。

除了實時的計算鏈路，對存量數(shù)據(jù)定期要做一些聚類，優(yōu)化我們的情感詞識別庫，或者上游根據(jù)業(yè)務需要觸發(fā)情感處理規(guī)則更新，根據(jù)新的情感打標庫對存量數(shù)據(jù)做一次輿情計算。

輿情的結果數(shù)據(jù)集有不同類的使用需求。對于重大輿情，需要做實時的預警。完整的輿情結果數(shù)據(jù)展示層需要支持全文檢索，靈活的屬性字段組合查詢。業(yè)務上可能根據(jù)屬性字段中的置信度，輿情時間，或者關鍵詞組合進行分析。

根據(jù)前面的介紹，輿情大數(shù)據(jù)分析系統(tǒng)需要兩類計算，一類是實時計算，包括海量網(wǎng)頁內容實時抽取，情感詞分析并進行網(wǎng)頁輿情結果存儲。另一類是離線計算，系統(tǒng)需要對歷史數(shù)據(jù)進行回溯，結合人工標注等方式優(yōu)化情感詞庫，對一些實時計算的結果進行矯正等。所以在系統(tǒng)設計上，需要選擇一套既可以做實時計算又能做批量離線計算的系統(tǒng)。在開源大數(shù)據(jù)解決方案中，Lambda架構恰好可以滿足這些需求，下面我們來介紹下Lambda的架構。

Lambda架構 (wiki)

Lambda架構可以說是Hadoop，Spark體系下最火的大數(shù)據(jù)架構。這套架構的***優(yōu)勢就是在支持海量數(shù)據(jù)批量計算處理(也就是離線處理)同時也支持流式的實時處理(即熱數(shù)據(jù)處理)。

具體是如何實現(xiàn)的呢，首先上游一般是一個隊列服務例如kafka，實時存儲數(shù)據(jù)的寫入。kafka隊列會有兩個訂閱者，一個是全量數(shù)據(jù)即圖片中上半部分，全量數(shù)據(jù)會被存儲在類似HDFS這樣的存儲介質上。當有離線計算任務到來，計算資源(例如Hadoop)會訪問存儲系統(tǒng)上的全量數(shù)據(jù)，進行全量批計算的處理邏輯。

經(jīng)過map/reduce環(huán)節(jié)后全量的結果會被寫入一個結構化的存儲引擎例如Hbase中，提供給業(yè)務方查詢。隊列的另一個消費訂閱方是流計算引擎，流計算引擎往往會實時的消費隊列中的數(shù)據(jù)進行計算處理，例如Spark Streaming實時訂閱Kafka的數(shù)據(jù)，流計算結果也會寫入一個結構化數(shù)據(jù)引擎。批量計算和流計算的結果寫入的結構化存儲引擎即上圖標注3的"Serving Layer"，這一層主要提供結果數(shù)據(jù)的展示和查詢。

在這套架構中，批量計算的特點是需要支持處理海量的數(shù)據(jù)，并根據(jù)業(yè)務的需求，關聯(lián)一些其他業(yè)務指標進行計算。批量計算的好處是計算邏輯可以根據(jù)業(yè)務需求靈活調整，同時計算結果可以反復重算，同樣的計算邏輯多次計算結果不會改變。批量計算的缺點是計算周期相對較長，很難滿足實時出結果的需求，所以隨著大數(shù)據(jù)計算的演進，提出了實時計算的需求。

實時計算在Lambda架構中是通過實時數(shù)據(jù)流來實現(xiàn)，相比批處理，數(shù)據(jù)增量流的處理方式?jīng)Q定了數(shù)據(jù)往往是最近新產(chǎn)生的數(shù)據(jù)，也就是熱數(shù)據(jù)。正因為熱數(shù)據(jù)這一特點，流計算可以滿足業(yè)務對計算的低延時需求，例如在輿情分析系統(tǒng)中，我們往往希望輿情信息可以在網(wǎng)頁抓取下來后，分鐘級別拿到計算結果，給業(yè)務方充足的時間進行輿情反饋。下面我們就來具體看一下，基于Lambda架構的思想如何實現(xiàn)一套完整的輿情大數(shù)據(jù)架構。

開源輿情大數(shù)據(jù)方案

通過這個流程圖，讓我們了解了整個輿情系統(tǒng)的建設過程中，需要經(jīng)過不同的存儲和計算系統(tǒng)。對數(shù)據(jù)的組織和查詢有不同的需求。在業(yè)界基于開源的大數(shù)據(jù)系統(tǒng)并結合Lambda架構，整套系統(tǒng)可以設計如下：

系統(tǒng)的最上游是分布式的爬蟲引擎，根據(jù)抓取任務抓取訂閱的網(wǎng)頁原文內容。爬蟲會把抓取到的網(wǎng)頁內容實時寫入Kafka隊列，進入Kafka隊列的數(shù)據(jù)根據(jù)前面描述的計算需求，會實時流入流計算引擎(例如Spark或者Flink)，也會持久化存儲在Hbase，進行全量數(shù)據(jù)的存儲。全量網(wǎng)頁的存儲可以滿足網(wǎng)頁爬取去重，批量離線計算的需求。

流計算會對原始網(wǎng)頁進行結構化提取，將非結構化網(wǎng)頁內容轉化為結構數(shù)據(jù)并進行分詞，例如提取出網(wǎng)頁的標題、作者、摘要等，對正文和摘要內容進行分詞。提取和分詞結果會寫回Hbase。結構化提取和分詞后，流計算引擎會結合情感詞庫進行網(wǎng)頁情感分析，判斷是否有輿情產(chǎn)生。

流計算引擎分析的輿情結果存儲Mysql或者Hbase數(shù)據(jù)庫中，為了方便結果集的搜索查看，需要把數(shù)據(jù)同步到一個搜索引擎例如Elasticsearch，方便進行屬性字段的組合查詢。如果是重大的輿情時間，需要寫入Kafka隊列觸發(fā)輿情報警。

全量的結構化數(shù)據(jù)會定期通過Spark系統(tǒng)進行離線計算，更新情感詞庫或者接受新的計算策略重新計算歷史數(shù)據(jù)修正實時計算的結果。

開源架構分析

上面的輿情大數(shù)據(jù)架構，通過Kafka對接流計算，Hbase對接批計算來實現(xiàn)Lambda架構中的“batch view”和“real-time view”，整套架構還是比較清晰的，可以很好的滿足在線和離線兩類計算需求。但是把這一套系統(tǒng)應用在生產(chǎn)并不是一件容易的事情，主要有下面一些原因：

整套架構涉及到非常多的存儲和計算系統(tǒng)包括：Kafka，Hbase，Spark，F(xiàn)link，Elasticsearch。數(shù)據(jù)會在不同的存儲和計算系統(tǒng)中流動，運維好整套架構中的每一個開源產(chǎn)品都是一個很大的挑戰(zhàn)。任何一個產(chǎn)品或者是產(chǎn)品間的通道出現(xiàn)故障，對整個輿情分析結果的時效性都會產(chǎn)生影響。

為了實現(xiàn)批計算和流計算，原始的網(wǎng)頁需要分別存儲在Kafka和Hbase中，離線計算是消費hbase中的數(shù)據(jù)，流計算消費Kafka的數(shù)據(jù)，這樣會帶來存儲資源的冗余，同時也導致需要維護兩套計算邏輯，計算代碼開發(fā)和維護成本也會上升。

輿情的計算結果存儲在Mysql或者Hbase，為了豐富組合查詢語句，需要把數(shù)據(jù)同步構建到Elasticsearch中。查詢的時候可能需要組合Mysql和Elasticsearch的查詢結果。這里沒有跳過數(shù)據(jù)庫，直接把結果數(shù)據(jù)寫入Elasticsearch這類搜索系統(tǒng)，是因為搜索系統(tǒng)的數(shù)據(jù)實時寫入能力和數(shù)據(jù)可靠性不如數(shù)據(jù)庫，業(yè)界通常是把數(shù)據(jù)庫和搜索系統(tǒng)整合，整合下的系統(tǒng)兼?zhèn)淞藬?shù)據(jù)庫和搜索系統(tǒng)的優(yōu)勢，但是兩個引擎之間數(shù)據(jù)的同步和跨系統(tǒng)查詢對運維和開發(fā)帶來很多額外的成本。

新的大數(shù)據(jù)架構Lambda plus

通過前面的分析，相信大家都會有一個疑問，有沒有簡化的的大數(shù)據(jù)架構，在可以滿足Lambda對計算需求的假設，又能減少存儲計算以及模塊的個數(shù)呢?

Linkedin的Jay Kreps提出了Kappa架構，關于Lambda和Kappa的對比可以參考文末的文獻，這里不展開詳細對比，簡單說下，Kappa為了簡化兩份存儲，取消了全量的數(shù)據(jù)存儲庫，通過在Kafka保留更長日志，當有回溯重新計算需求到來時，重新從隊列的頭部開始訂閱數(shù)據(jù)，再一次用流的方式處理Kafka隊列中保存的所有數(shù)據(jù)。這樣設計的好處是解決了需要維護兩份存儲和兩套計算邏輯的痛點，美中不足的地方是隊列可以保留的歷史數(shù)據(jù)畢竟有限，難以做到無時間限制的回溯。

分析到這里，我們沿著Kappa針對Lambda的改進思路，向前多思考一些：假如有一個存儲引擎，既滿足數(shù)據(jù)庫可以高效的寫入和隨機查詢，又能像隊列服務，滿足先進先出，是不是就可以把Lambda和Kappa架構揉合在一起，打造一個Lambda plus架構呢?

新架構在Lambda的基礎上可以提升以下幾點：

1. 在支持流計算和批計算的同時，讓計算邏輯可以復用，實現(xiàn)“一套代碼兩類需求”。
2. 統(tǒng)一歷史數(shù)據(jù)全量和在線實時增量數(shù)據(jù)的存儲，實現(xiàn)“一份存儲兩類計算”。
3. 為了方便輿情結果查詢需求，“batch view”和“real-time view”存儲在既可以支持高吞吐的實時寫入，也可以支持多字段組合搜索和全文檢索。

總結起來就是整套新架構的核心是解決存儲的問題，以及如何靈活的對接計算。我們希望整套方案是類似下面的架構：

1. 數(shù)據(jù)流實時寫入一個分布式的數(shù)據(jù)庫，借助于數(shù)據(jù)庫查詢能力，全量數(shù)據(jù)可以輕松的對接批量計算系統(tǒng)進行離線處理。
2. 數(shù)據(jù)庫通過數(shù)據(jù)庫日志接口，支持增量讀取，實現(xiàn)對接流計算引擎進行實時計算。
3. 批計算和流計算的結果寫回分布式數(shù)據(jù)庫，分布式數(shù)據(jù)庫提供豐富的查詢語意，實現(xiàn)計算結果的交互式查詢。

整套架構中，存儲層面通過結合數(shù)據(jù)庫主表數(shù)據(jù)和數(shù)據(jù)庫日志來取代大數(shù)據(jù)架構中的隊列服務，計算系統(tǒng)選取天然支持批和流的計算引擎例如Flink或者Spark。這樣一來，我們既可以像Lambda進行***制的歷史數(shù)據(jù)回溯，又可以像Kappa架構一樣一套邏輯，存儲處理兩類計算任務。這樣的一套架構我們取名為“Lambda plus”，下面就詳細展開如何在阿里云上打造這樣的一套大數(shù)據(jù)架構。

云上輿情系統(tǒng)架構

在阿里云眾多存儲和計算產(chǎn)品中，貼合上述大數(shù)據(jù)架構的需求，我們選用兩款產(chǎn)品來實現(xiàn)整套輿情大數(shù)據(jù)系統(tǒng)。存儲層面使用阿里云自研的分布式多模型數(shù)據(jù)庫Tablestore，計算層選用Blink來實現(xiàn)流批一體計算。

這套架構在存儲層面，全部基于Tablestore，一個數(shù)據(jù)庫解決不同存儲需求，根據(jù)之前輿情系統(tǒng)的介紹，網(wǎng)頁爬蟲數(shù)據(jù)在系統(tǒng)流動中會有四個階段分別是原始網(wǎng)頁內容，網(wǎng)頁結構化數(shù)據(jù)，分析規(guī)則元數(shù)據(jù)和輿情結果，輿情結果索引。

我們利用Tablestore寬行和schema free的特性，合并原始網(wǎng)頁和網(wǎng)頁結構化數(shù)據(jù)成一張網(wǎng)頁數(shù)據(jù)。網(wǎng)頁數(shù)據(jù)表和計算系統(tǒng)通過Tablestore新功能通道服務進行對接。通道服務基于數(shù)據(jù)庫日志，數(shù)據(jù)的組織結構按照數(shù)據(jù)的寫入順序進行存儲，正是這一特性，賦能數(shù)據(jù)庫具備了隊列流式消費能力。使得存儲引擎既可以具備數(shù)據(jù)庫的隨機訪問，也可以具備隊列的按照寫入順序訪問，這也就滿足我們上面提到整合Lambda和kappa架構的需求。分析規(guī)則元數(shù)據(jù)表由分析規(guī)則，情感詞庫組層，對應實時計算中的維表。

計算系統(tǒng)這里選用阿里云實時流計算產(chǎn)品Blink，Blink是一款支持流計算和批計算一體的實時計算產(chǎn)品。并且類似Tablestore可以很容易的做到分布式水平擴展，讓計算資源隨著業(yè)務數(shù)據(jù)增長彈性擴容。使用Tablestore + Blink的優(yōu)勢有以下幾點：

1. Tablestore已經(jīng)深度和Blink進行整合，支持源表，維表和目的表，業(yè)務無需為數(shù)據(jù)流動開發(fā)代碼。
2. 整套架構大幅降低組建個數(shù)，從開源產(chǎn)品的6～7個組建減少到2個，Tablestore和Blink都是全托管0運維的產(chǎn)品，并且都能做到很好的水平彈性，業(yè)務峰值擴展無壓力，使得大數(shù)據(jù)架構的運維成本大幅降低。
3. 業(yè)務方只需要關注數(shù)據(jù)的處理部分邏輯，和Tablestore的交互邏輯都已經(jīng)集成在Blink中。
4. 開源方案中，如果數(shù)據(jù)庫源希望對接實時計算，還需要雙寫一個隊列，讓流計算引擎消費隊列中的數(shù)據(jù)。我們的架構中數(shù)據(jù)庫既作為數(shù)據(jù)表，又是隊列通道可以實時增量數(shù)據(jù)消費。大大簡化了架構的開發(fā)和使用成本。
5. 流批一體，在輿情系統(tǒng)中實時性是至關重要的，所以我們需要一個實時計算引擎，而Blink除了實時計算以外，也支持批處理Tablestore的數(shù)據(jù)， 在業(yè)務低峰期，往往也需要批量處理一些數(shù)據(jù)并作為反饋結果寫回Tablestore，例如情感分析反饋等。那么一套架構既可以支持流處理又可以支持批處理是再好不過。一套架構帶來的優(yōu)勢是，一套分析代碼既可以做實時流計算又可以離線批處理。

整個計算流程會產(chǎn)生實時的輿情計算結果。重大輿情事件的預警，通過Tablestore和函數(shù)計算觸發(fā)器對接來實現(xiàn)。Tablestore和函數(shù)計算做了增量數(shù)據(jù)的無縫對接，通過結果表寫入事件，可以輕松的通過函數(shù)計算觸發(fā)短信或者郵件通知。完整的輿情分析結果和展示搜索利用了Tablestore的新功能多元索引，徹底解決了開源Hbase+Solr 多引擎的痛點：

1. 運維復雜，需要有運維hbase和solr兩套系統(tǒng)的能力，同時還需要維護數(shù)據(jù)同步的鏈路。
2. Solr數(shù)據(jù)一致性不如Hbase，在Hbase和Solr數(shù)據(jù)語意并不是完全一致，加上Solr/Elasticsearch在數(shù)據(jù)一致性很難做到像數(shù)據(jù)庫那么嚴格。在一些極端情況下會出現(xiàn)數(shù)據(jù)不一致的問題，開源方案也很難做到跨系統(tǒng)的一致性比對。
3. 查詢接口需要維護兩套API，需要同時使用Hbase client和Solr client，索引中沒有的字段需要主動反查Hbase，易用性較差。