海量數據下的輿情分析，該如何搭建？
阿里妹導讀：互聯網的飛速發展促進了很多新媒體的發展，不論是知名的大V，明星還是圍觀群眾都可以通過手機在微博、朋友圈或者點評網站上發表動態，分享自己的所見所想，使得“人人都有了麥克風”。不論是熱點新聞還是娛樂八卦，傳播速度遠超我們的想象，一則信息可以在短短數分鐘內，有數萬計轉發，數百萬的閱讀。海量信息可以得到爆炸式的傳播，那么如何實時把握信息并作出對應的處理呢?是不是真的難以應對?今天，阿里云智能事業群的宇珩來跟我們聊聊大數據輿情系統對數據存儲和計算系統會有哪些需求，如何根據需求來進行系統設計。
大數據時代下，除了媒體信息以外，商品在各類電商平臺的訂單量、用戶的購買評論，都會對后續的消費者產生很大的影響。商家的產品設計者需要匯總統計和分析各類平臺的數據做為依據，決定后續的產品發展，公司的公關和市場部門也需要根據輿情作出相應的及時處理，而這一切也意味著傳統的輿情系統升級成為大數據輿情采集和分析系統。具體細化看下大數據輿情系統，對我們的數據存儲和計算系統提出了以下需求：
海量原始數據的實時入庫：為了實現一整套輿情系統，需要有上游原始輸出的采集，也就是爬蟲系統。爬蟲需要采集各類門戶，自媒體的網頁內容。在抓取前需要去重，抓取后還需要分析提取，例如進行子網頁的抓取。
原始網頁數據的處理：不論是主流門戶還是自媒體的網頁信息，抓取后我們需要做一定的數據提取，把原始的網頁內容轉化為結構化數據，例如文章的標題，摘要等，如果是商品點評類消息也需要提取有效的點評。
結構化數據的輿情分析：當各類原始輸出變成結構化的數據后，我們需要有一個實時的計算產品把各類輸出做合理的分類，進一步對分類后的內容進行情感打標。根據業務的需求這里可能會產生不同的輸出，例如品牌當下是否有熱點話題，輿情影響力分析，轉播路徑分析，參與用戶統計和畫像，輿論情感分析或者是否有重大預警。
輿情分析系統中間和結果數據的存儲，交互分析查詢：從網頁原始數據清洗到最終的輿情報表這中間會產生很多類型的數據。這些數據有的會提供給數據分析同學進行輿情分析系統的調優，有的數據會提供給業務部門根據輿情結果進行決策。這些查詢可能會很靈活，需要我們的存儲系統具備全文檢索，多字段組合靈活的交互分析能力。
重大輿情事件的實時預警：對于輿情的結果除了正常的搜索和展示需求以外，當有重大事件出現我們需要能做到實時的預警。
本文主要是提供架構設計，會先介紹時下主流的大數據計算架構，并分析一些優缺點，然后引入輿情大數據架構。
系統設計
需求分析
結合文章開頭對輿情系統的描述，海量大數據輿情分析系統流程圖大體如下：
原始網頁存儲庫，這個庫需要能支持海量數據，低成本，低延時寫入。網頁數據寫入后，要做實時結構化提取，提取出來的數據再進行降噪，分詞，圖片ocr處理等。對分詞文本，圖片進行情感識別產生輿情數據結果集。傳統的離線全量計算很難滿足輿情系統的時效性需求。
計算引擎在做數據處理時，可能還需要從存儲庫中獲取一些元數據，例如用戶信息，情感詞元數據信息等。
除了實時的計算鏈路，對存量數據定期要做一些聚類，優化我們的情感詞識別庫，或者上游根據業務需要觸發情感處理規則更新，根據新的情感打標庫對存量數據做一次輿情計算。
輿情的結果數據集有不同類的使用需求。對于重大輿情，需要做實時的預警。完整的輿情結果數據展示層需要支持全文檢索，靈活的屬性字段組合查詢。業務上可能根據屬性字段中的置信度，輿情時間，或者關鍵詞組合進行分析。
根據前面的介紹，輿情大數據分析系統需要兩類計算，一類是實時計算，包括海量網頁內容實時抽取，情感詞分析并進行網頁輿情結果存儲。另一類是離線計算，系統需要對歷史數據進行回溯，結合人工標注等方式優化情感詞庫，對一些實時計算的結果進行矯正等。所以在系統設計上，需要選擇一套既可以做實時計算又能做批量離線計算的系統。在開源大數據解決方案中，Lambda架構恰好可以滿足這些需求，下面我們來介紹下Lambda的架構。
Lambda架構 (wiki)
Lambda架構可以說是Hadoop，Spark體系下最火的大數據架構。這套架構的***優勢就是在支持海量數據批量計算處理(也就是離線處理)同時也支持流式的實時處理(即熱數據處理)。
具體是如何實現的呢，首先上游一般是一個隊列服務例如kafka，實時存儲數據的寫入。kafka隊列會有兩個訂閱者，一個是全量數據即圖片中上半部分，全量數據會被存儲在類似HDFS這樣的存儲介質上。當有離線計算任務到來，計算資源(例如Hadoop)會訪問存儲系統上的全量數據，進行全量批計算的處理邏輯。
經過map/reduce環節后全量的結果會被寫入一個結構化的存儲引擎例如Hbase中，提供給業務方查詢。隊列的另一個消費訂閱方是流計算引擎，流計算引擎往往會實時的消費隊列中的數據進行計算處理，例如Spark Streaming實時訂閱Kafka的數據，流計算結果也會寫入一個結構化數據引擎。批量計算和流計算的結果寫入的結構化存儲引擎即上圖標注3的"Serving Layer"，這一層主要提供結果數據的展示和查詢。
在這套架構中，批量計算的特點是需要支持處理海量的數據，并根據業務的需求，關聯一些其他業務指標進行計算。批量計算的好處是計算邏輯可以根據業務需求靈活調整，同時計算結果可以反復重算，同樣的計算邏輯多次計算結果不會改變。批量計算的缺點是計算周期相對較長，很難滿足實時出結果的需求，所以隨著大數據計算的演進，提出了實時計算的需求。
實時計算在Lambda架構中是通過實時數據流來實現，相比批處理，數據增量流的處理方式決定了數據往往是最近新產生的數據，也就是熱數據。正因為熱數據這一特點，流計算可以滿足業務對計算的低延時需求，例如在輿情分析系統中，我們往往希望輿情信息可以在網頁抓取下來后，分鐘級別拿到計算結果，給業務方充足的時間進行輿情反饋。下面我們就來具體看一下，基于Lambda架構的思想如何實現一套完整的輿情大數據架構。
開源輿情大數據方案
通過這個流程圖，讓我們了解了整個輿情系統的建設過程中，需要經過不同的存儲和計算系統。對數據的組織和查詢有不同的需求。在業界基于開源的大數據系統并結合Lambda架構，整套系統可以設計如下：
系統的最上游是分布式的爬蟲引擎，根據抓取任務抓取訂閱的網頁原文內容。爬蟲會把抓取到的網頁內容實時寫入Kafka隊列，進入Kafka隊列的數據根據前面描述的計算需求，會實時流入流計算引擎(例如Spark或者Flink)，也會持久化存儲在Hbase，進行全量數據的存儲。全量網頁的存儲可以滿足網頁爬取去重，批量離線計算的需求。
流計算會對原始網頁進行結構化提取，將非結構化網頁內容轉化為結構數據并進行分詞，例如提取出網頁的標題、作者、摘要等，對正文和摘要內容進行分詞。提取和分詞結果會寫回Hbase。結構化提取和分詞后，流計算引擎會結合情感詞庫進行網頁情感分析，判斷是否有輿情產生。
流計算引擎分析的輿情結果存儲Mysql或者Hbase數據庫中，為了方便結果集的搜索查看，需要把數據同步到一個搜索引擎例如Elasticsearch，方便進行屬性字段的組合查詢。如果是重大的輿情時間，需要寫入Kafka隊列觸發輿情報警。
全量的結構化數據會定期通過Spark系統進行離線計算，更新情感詞庫或者接受新的計算策略重新計算歷史數據修正實時計算的結果。
開源架構分析
上面的輿情大數據架構，通過Kafka對接流計算，Hbase對接批計算來實現Lambda架構中的“batch view”和“real-time view”，整套架構還是比較清晰的，可以很好的滿足在線和離線兩類計算需求。但是把這一套系統應用在生產并不是一件容易的事情，主要有下面一些原因：
整套架構涉及到非常多的存儲和計算系統包括：Kafka，Hbase，Spark，Flink，Elasticsearch。數據會在不同的存儲和計算系統中流動，運維好整套架構中的每一個開源產品都是一個很大的挑戰。任何一個產品或者是產品間的通道出現故障，對整個輿情分析結果的時效性都會產生影響。
為了實現批計算和流計算，原始的網頁需要分別存儲在Kafka和Hbase中，離線計算是消費hbase中的數據，流計算消費Kafka的數據，這樣會帶來存儲資源的冗余，同時也導致需要維護兩套計算邏輯，計算代碼開發和維護成本也會上升。
輿情的計算結果存儲在Mysql或者Hbase，為了豐富組合查詢語句，需要把數據同步構建到Elasticsearch中。查詢的時候可能需要組合Mysql和Elasticsearch的查詢結果。這里沒有跳過數據庫，直接把結果數據寫入Elasticsearch這類搜索系統，是因為搜索系統的數據實時寫入能力和數據可靠性不如數據庫，業界通常是把數據庫和搜索系統整合，整合下的系統兼備了數據庫和搜索系統的優勢，但是兩個引擎之間數據的同步和跨系統查詢對運維和開發帶來很多額外的成本。
新的大數據架構Lambda plus
通過前面的分析，相信大家都會有一個疑問，有沒有簡化的的大數據架構，在可以滿足Lambda對計算需求的假設，又能減少存儲計算以及模塊的個數呢?
Linkedin的Jay Kreps提出了Kappa架構，關于Lambda和Kappa的對比可以參考文末的文獻，這里不展開詳細對比，簡單說下，Kappa為了簡化兩份存儲，取消了全量的數據存儲庫，通過在Kafka保留更長日志，當有回溯重新計算需求到來時，重新從隊列的頭部開始訂閱數據，再一次用流的方式處理Kafka隊列中保存的所有數據。這樣設計的好處是解決了需要維護兩份存儲和兩套計算邏輯的痛點，美中不足的地方是隊列可以保留的歷史數據畢竟有限，難以做到無時間限制的回溯。
分析到這里，我們沿著Kappa針對Lambda的改進思路，向前多思考一些：假如有一個存儲引擎，既滿足數據庫可以高效的寫入和隨機查詢，又能像隊列服務，滿足先進先出，是不是就可以把Lambda和Kappa架構揉合在一起，打造一個Lambda plus架構呢?
新架構在Lambda的基礎上可以提升以下幾點：
- 在支持流計算和批計算的同時，讓計算邏輯可以復用，實現“一套代碼兩類需求”。
- 統一歷史數據全量和在線實時增量數據的存儲，實現“一份存儲兩類計算”。
- 為了方便輿情結果查詢需求，“batch view”和“real-time view”存儲在既可以支持高吞吐的實時寫入，也可以支持多字段組合搜索和全文檢索。
總結起來就是整套新架構的核心是解決存儲的問題，以及如何靈活的對接計算。我們希望整套方案是類似下面的架構：
- 數據流實時寫入一個分布式的數據庫，借助于數據庫查詢能力，全量數據可以輕松的對接批量計算系統進行離線處理。
- 數據庫通過數據庫日志接口，支持增量讀取，實現對接流計算引擎進行實時計算。
- 批計算和流計算的結果寫回分布式數據庫，分布式數據庫提供豐富的查詢語意，實現計算結果的交互式查詢。
整套架構中，存儲層面通過結合數據庫主表數據和數據庫日志來取代大數據架構中的隊列服務，計算系統選取天然支持批和流的計算引擎例如Flink或者Spark。這樣一來，我們既可以像Lambda進行***制的歷史數據回溯，又可以像Kappa架構一樣一套邏輯，存儲處理兩類計算任務。這樣的一套架構我們取名為“Lambda plus”，下面就詳細展開如何在阿里云上打造這樣的一套大數據架構。
云上輿情系統架構
在阿里云眾多存儲和計算產品中，貼合上述大數據架構的需求，我們選用兩款產品來實現整套輿情大數據系統。存儲層面使用阿里云自研的分布式多模型數據庫Tablestore，計算層選用Blink來實現流批一體計算。
這套架構在存儲層面，全部基于Tablestore，一個數據庫解決不同存儲需求，根據之前輿情系統的介紹，網頁爬蟲數據在系統流動中會有四個階段分別是原始網頁內容，網頁結構化數據，分析規則元數據和輿情結果，輿情結果索引。
我們利用Tablestore寬行和schema free的特性，合并原始網頁和網頁結構化數據成一張網頁數據。網頁數據表和計算系統通過Tablestore新功能通道服務進行對接。通道服務基于數據庫日志，數據的組織結構按照數據的寫入順序進行存儲，正是這一特性，賦能數據庫具備了隊列流式消費能力。使得存儲引擎既可以具備數據庫的隨機訪問，也可以具備隊列的按照寫入順序訪問，這也就滿足我們上面提到整合Lambda和kappa架構的需求。分析規則元數據表由分析規則，情感詞庫組層，對應實時計算中的維表。
計算系統這里選用阿里云實時流計算產品Blink，Blink是一款支持流計算和批計算一體的實時計算產品。并且類似Tablestore可以很容易的做到分布式水平擴展，讓計算資源隨著業務數據增長彈性擴容。使用Tablestore + Blink的優勢有以下幾點：
- Tablestore已經深度和Blink進行整合，支持源表，維表和目的表，業務無需為數據流動開發代碼。
- 整套架構大幅降低組建個數，從開源產品的6～7個組建減少到2個，Tablestore和Blink都是全托管0運維的產品，并且都能做到很好的水平彈性，業務峰值擴展無壓力，使得大數據架構的運維成本大幅降低。
- 業務方只需要關注數據的處理部分邏輯，和Tablestore的交互邏輯都已經集成在Blink中。
- 開源方案中，如果數據庫源希望對接實時計算，還需要雙寫一個隊列，讓流計算引擎消費隊列中的數據。我們的架構中數據庫既作為數據表，又是隊列通道可以實時增量數據消費。大大簡化了架構的開發和使用成本。
- 流批一體，在輿情系統中實時性是至關重要的，所以我們需要一個實時計算引擎，而Blink除了實時計算以外，也支持批處理Tablestore的數據， 在業務低峰期，往往也需要批量處理一些數據并作為反饋結果寫回Tablestore，例如情感分析反饋等。那么一套架構既可以支持流處理又可以支持批處理是再好不過。一套架構帶來的優勢是，一套分析代碼既可以做實時流計算又可以離線批處理。
整個計算流程會產生實時的輿情計算結果。重大輿情事件的預警，通過Tablestore和函數計算觸發器對接來實現。Tablestore和函數計算做了增量數據的無縫對接，通過結果表寫入事件，可以輕松的通過函數計算觸發短信或者郵件通知。完整的輿情分析結果和展示搜索利用了Tablestore的新功能多元索引，徹底解決了開源Hbase+Solr 多引擎的痛點：
- 運維復雜，需要有運維hbase和solr兩套系統的能力，同時還需要維護數據同步的鏈路。
- Solr數據一致性不如Hbase，在Hbase和Solr數據語意并不是完全一致，加上Solr/Elasticsearch在數據一致性很難做到像數據庫那么嚴格。在一些極端情況下會出現數據不一致的問題，開源方案也很難做到跨系統的一致性比對。
- 查詢接口需要維護兩套API，需要同時使用Hbase client和Solr client，索引中沒有的字段需要主動反查Hbase，易用性較差。
