互聯(lián)網(wǎng)的飛速發(fā)展促進(jìn)了很多新媒體的發(fā)展，不論是知名的大V，明星還是圍觀群眾都可以通過手機(jī)在微博，朋友圈或者點(diǎn)評(píng)網(wǎng)站上發(fā)表狀態(tài)，分享自己的所見所想，使得“人人都有了麥克風(fēng)”。不論是熱點(diǎn)新聞還是娛樂八卦，傳播速度遠(yuǎn)超我們的想象�？梢栽诙潭虜�(shù)分鐘內(nèi)，有數(shù)萬(wàn)計(jì)轉(zhuǎn)發(fā)，數(shù)百萬(wàn)的閱讀。如此海量的信息可以得到爆炸式的傳播，如何能夠?qū)崟r(shí)的把握民情并作出對(duì)應(yīng)的處理對(duì)很多企業(yè)來(lái)說(shuō)都是至關(guān)重要的。大數(shù)據(jù)時(shí)代，除了媒體信息以外，商品在各類電商平臺(tái)的訂單量，用戶的購(gòu)買評(píng)論也都對(duì)后續(xù)的消費(fèi)者產(chǎn)生很大的影響。商家的產(chǎn)品設(shè)計(jì)者需要匯總統(tǒng)計(jì)和分析各類平臺(tái)的數(shù)據(jù)做為依據(jù)，決定后續(xù)的產(chǎn)品發(fā)展，公司的公關(guān)和市場(chǎng)部門也需要根據(jù)輿情作出相應(yīng)的及時(shí)處理，而這一切也意味著傳統(tǒng)的輿情系統(tǒng)升級(jí)成為大數(shù)據(jù)輿情采集和分析系統(tǒng)。

　　分析完輿情場(chǎng)景后，我們?cè)賮?lái)具體細(xì)化看下大數(shù)據(jù)輿情系統(tǒng)，對(duì)我們的數(shù)據(jù)存儲(chǔ)和計(jì)算系統(tǒng)提出哪些需求：

　　我們計(jì)劃分兩篇介紹完整的輿情新架構(gòu)，第一篇主要是提供架構(gòu)設(shè)計(jì)，會(huì)先介紹時(shí)下主流的大數(shù)據(jù)計(jì)算架構(gòu)，并分析一些優(yōu)缺點(diǎn)，然后引入輿情大數(shù)據(jù)架構(gòu)。第二篇會(huì)有完整的數(shù)據(jù)庫(kù)表設(shè)計(jì)和部分示例代碼。大家敬請(qǐng)期待。

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

　　圖1 輿情系統(tǒng)業(yè)務(wù)流程

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

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

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

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

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

　　圖2 Lambda架構(gòu)圖

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

　　具體是如何實(shí)現(xiàn)的呢，首先上游一般是一個(gè)隊(duì)列服務(wù)例如kafka，實(shí)時(shí)存儲(chǔ)數(shù)據(jù)的寫入。kafka隊(duì)列會(huì)有兩個(gè)訂閱者，一個(gè)是全量數(shù)據(jù)即圖片中上半部分，全量數(shù)據(jù)會(huì)被存儲(chǔ)在類似HDFS這樣的存儲(chǔ)介質(zhì)上。當(dāng)有離線計(jì)算任務(wù)到來(lái)，計(jì)算資源（例如Hadoop）會(huì)訪問存儲(chǔ)系統(tǒng)上的全量數(shù)據(jù)，進(jìn)行全量批計(jì)算的處理邏輯。經(jīng)過map/reduce環(huán)節(jié)后全量的結(jié)果會(huì)被寫入一個(gè)結(jié)構(gòu)化的存儲(chǔ)引擎例如Hbase中，提供給業(yè)務(wù)方查詢。隊(duì)列的另一個(gè)消費(fèi)訂閱方是流計(jì)算引擎，流計(jì)算引擎往往會(huì)實(shí)時(shí)的消費(fèi)隊(duì)列中的數(shù)據(jù)進(jìn)行計(jì)算處理，例如Spark Streaming實(shí)時(shí)訂閱Kafka的數(shù)據(jù)，流計(jì)算結(jié)果也會(huì)寫入一個(gè)結(jié)構(gòu)化數(shù)據(jù)引擎。批量計(jì)算和流計(jì)算的結(jié)果寫入的結(jié)構(gòu)化存儲(chǔ)引擎即上圖標(biāo)注3的"Serving Layer"，這一層主要提供結(jié)果數(shù)據(jù)的展示和查詢。

　　在這套架構(gòu)中，批量計(jì)算的特點(diǎn)是需要支持處理海量的數(shù)據(jù)，并根據(jù)業(yè)務(wù)的需求，關(guān)聯(lián)一些其他業(yè)務(wù)指標(biāo)進(jìn)行計(jì)算。批量計(jì)算的好處是計(jì)算邏輯可以根據(jù)業(yè)務(wù)需求靈活調(diào)整，同時(shí)計(jì)算結(jié)果可以反復(fù)重算，同樣的計(jì)算邏輯多次計(jì)算結(jié)果不會(huì)改變。批量計(jì)算的缺點(diǎn)是計(jì)算周期相對(duì)較長(zhǎng)，很難滿足實(shí)時(shí)出結(jié)果的需求，所以隨著大數(shù)據(jù)計(jì)算的演進(jìn)，提出了實(shí)時(shí)計(jì)算的需求。實(shí)時(shí)計(jì)算在Lambda架構(gòu)中是通過實(shí)時(shí)數(shù)據(jù)流來(lái)實(shí)現(xiàn)，相比批處理，數(shù)據(jù)增量流的處理方式?jīng)Q定了數(shù)據(jù)往往是最近新產(chǎn)生的數(shù)據(jù)，也就是熱數(shù)據(jù)。正因?yàn)闊釘?shù)據(jù)這一特點(diǎn)，流計(jì)算可以滿足業(yè)務(wù)對(duì)計(jì)算的低延時(shí)需求，例如在輿情分析系統(tǒng)中，我們往往希望輿情信息可以在網(wǎng)頁(yè)抓取下來(lái)后，分鐘級(jí)別拿到計(jì)算結(jié)果，給業(yè)務(wù)方充足的時(shí)間進(jìn)行輿情反饋。下面我們就來(lái)具體看一下，基于Lambda架構(gòu)的思想如何實(shí)現(xiàn)一套完整的輿情大數(shù)據(jù)架構(gòu)。

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

　　圖3 開源輿情架構(gòu)圖

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

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

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

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

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

　　通過前面的分析，相信大家都會(huì)有一個(gè)疑問，有沒有簡(jiǎn)化的的大數(shù)據(jù)架構(gòu)，在可以滿足Lambda對(duì)計(jì)算需求的假設(shè)，又能減少存儲(chǔ)計(jì)算以及模塊的個(gè)數(shù)呢。Linkedin的Jay Kreps提出了Kappa架構(gòu)，關(guān)于Lambda和Kappa的對(duì)比可以參考"云上大數(shù)據(jù)方案"這篇，這里不展開詳細(xì)對(duì)比，簡(jiǎn)單說(shuō)下，Kappa為了簡(jiǎn)化兩份存儲(chǔ)，取消了全量的數(shù)據(jù)存儲(chǔ)庫(kù)，通過在Kafka保留更長(zhǎng)日志，當(dāng)有回溯重新計(jì)算需求到來(lái)時(shí)，重新從隊(duì)列的頭部開始訂閱數(shù)據(jù)，再一次用流的方式處理Kafka隊(duì)列中保存的所有數(shù)據(jù)。這樣設(shè)計(jì)的好處是解決了需要維護(hù)兩份存儲(chǔ)和兩套計(jì)算邏輯的痛點(diǎn)，美中不足的地方是隊(duì)列可以保留的歷史數(shù)據(jù)畢竟有限，難以做到無(wú)時(shí)間限制的回溯。分析到這里，我們沿著Kappa針對(duì)Lambda的改進(jìn)思路，向前多思考一些：假如有一個(gè)存儲(chǔ)引擎，既滿足數(shù)據(jù)庫(kù)可以高效的寫入和隨機(jī)查詢，又能像隊(duì)列服務(wù)，滿足先進(jìn)先出，是不是就可以把Lambda和Kappa架構(gòu)揉合在一起，打造一個(gè)Lambda plus架構(gòu)呢？

　　總結(jié)起來(lái)就是整套新架構(gòu)的核心是解決存儲(chǔ)的問題，以及如何靈活的對(duì)接計(jì)算。我們希望整套方案是類似下面的架構(gòu)：

　　圖4 Lambda Plus架構(gòu)

　　整套架構(gòu)中，存儲(chǔ)層面通過結(jié)合數(shù)據(jù)庫(kù)主表數(shù)據(jù)和數(shù)據(jù)庫(kù)日志來(lái)取代大數(shù)據(jù)架構(gòu)中的隊(duì)列服務(wù)，計(jì)算系統(tǒng)選取天然支持批和流的計(jì)算引擎例如Flink或者Spark。這樣一來(lái)，我們既可以像Lambda進(jìn)行無(wú)限制的歷史數(shù)據(jù)回溯，又可以像Kappa架構(gòu)一樣一套邏輯，存儲(chǔ)處理兩類計(jì)算任務(wù)。這樣的一套架構(gòu)我們?nèi)∶麨?ldquo;Lambda plus”，下面就詳細(xì)展開如何在阿里云上打造這樣的一套大數(shù)據(jù)架構(gòu)。

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

　　圖5 云上輿情大數(shù)據(jù)架構(gòu)

　　這套架構(gòu)在存儲(chǔ)層面，全部基于Tablestore，一個(gè)數(shù)據(jù)庫(kù)解決不同存儲(chǔ)需求，根據(jù)之前輿情系統(tǒng)的介紹，網(wǎng)頁(yè)爬蟲數(shù)據(jù)在系統(tǒng)流動(dòng)中會(huì)有四個(gè)階段分別是原始網(wǎng)頁(yè)內(nèi)容，網(wǎng)頁(yè)結(jié)構(gòu)化數(shù)據(jù)，分析規(guī)則元數(shù)據(jù)和輿情結(jié)果，輿情結(jié)果索引。我們利用Tablestore寬行和schema free的特性，合并原始網(wǎng)頁(yè)和網(wǎng)頁(yè)結(jié)構(gòu)化數(shù)據(jù)成一張網(wǎng)頁(yè)數(shù)據(jù)。網(wǎng)頁(yè)數(shù)據(jù)表和計(jì)算系統(tǒng)通過Tablestore新功能通道服務(wù)進(jìn)行對(duì)接。通道服務(wù)基于數(shù)據(jù)庫(kù)日志，數(shù)據(jù)的組織結(jié)構(gòu)按照數(shù)據(jù)的寫入順序進(jìn)行存儲(chǔ)，正是這一特性，賦能數(shù)據(jù)庫(kù)具備了隊(duì)列流式消費(fèi)能力。使得存儲(chǔ)引擎既可以具備數(shù)據(jù)庫(kù)的隨機(jī)訪問，也可以具備隊(duì)列的按照寫入順序訪問，這也就滿足我們上面提到整合Lambda和kappa架構(gòu)的需求。分析規(guī)則元數(shù)據(jù)表由分析規(guī)則，情感詞庫(kù)組層，對(duì)應(yīng)實(shí)時(shí)計(jì)算中的維表。

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

　　https://yq.aliyun.com/articles/692526

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

　　運(yùn)維復(fù)雜，需要有運(yùn)維hbase和solr兩套系統(tǒng)的能力，同時(shí)還需要維護(hù)數(shù)據(jù)同步的鏈路。

　　Solr數(shù)據(jù)一致性不如Hbase，在Hbase和Solr數(shù)據(jù)語(yǔ)意并不是完全一致，加上Solr/Elasticsearch在數(shù)據(jù)一致性很難做到像數(shù)據(jù)庫(kù)那么嚴(yán)格。在一些極端情況下會(huì)出現(xiàn)數(shù)據(jù)不一致的問題，開源方案也很難做到跨系統(tǒng)的一致性比對(duì)。

　　查詢接口需要維護(hù)兩套API，需要同時(shí)使用Hbase client和Solr client，索引中沒有的字段需要主動(dòng)反查Hbase，易用性較差。

　　1、Lambda大數(shù)據(jù)架構(gòu)

　　https://mapr.com/tech-briefs/stream-processing-mapr/

　　2、Kappa大數(shù)據(jù)架構(gòu)

　　https://www.oreilly.com/ideas/questioning-the-lambda-architecture

　　3、Lambda和Kappa架構(gòu)對(duì)比

　　https://www.ericsson.com/en/blog/2015/11/data-processing-architectures--lambda-and-kappa

　　本文基于《百億級(jí)全網(wǎng)輿情分析系統(tǒng)存儲(chǔ)設(shè)計(jì)》并結(jié)合Tablestore的新功能做了現(xiàn)代大數(shù)據(jù)輿情系統(tǒng)的架構(gòu)升級(jí)，實(shí)現(xiàn)了海量信息下的實(shí)時(shí)輿情分析存儲(chǔ)系統(tǒng)。也介紹了開源方案，并和我們的方案做了詳細(xì)的對(duì)比。