基於大數據的輿情分析系統架構 - 架構篇

前言

互聯網的飛速發展促進了不少新媒體的發展，不管是知名的大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架構，整套系統能夠設計以下：

1. 系統的最上游是分佈式的爬蟲引擎，根據抓取任務抓取訂閱的網頁原文內容。爬蟲會把抓取到的網頁內容實時寫入Kafka隊列，進入Kafka隊列的數據根據前面描述的計算需求，會實時流入流計算引擎（例如Spark或者Flink），也會持久化存儲在Hbase，進行全量數據的存儲。全量網頁的存儲能夠知足網頁爬取去重，批量離線計算的需求。
2. 流計算會對原始網頁進行結構化提取，將非結構化網頁內容轉化爲結構數據並進行分詞，例如提取出網頁的標題，做者，摘要等，對正文和摘要內容進行分詞。提取和分詞結果會寫回Hbase。結構化提取和分詞後，流計算引擎會結合情感詞庫進行網頁情感分析，判斷是否有輿情產生。
3. 流計算引擎分析的輿情結果存儲Mysql或者Hbase數據庫中，爲了方便結果集的搜索查看，須要把數據同步到一個搜索引擎例如Elasticsearch，方便進行屬性字段的組合查詢。若是是重大的輿情時間，須要寫入Kafka隊列觸發輿情報警。
4. 全量的結構化數據會按期經過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的基礎上能夠提高如下幾點：

1. 在支持流計算和批計算的同時，讓計算邏輯能夠複用，實現「一套代碼兩類需求」。
2. 統一歷史數據全量和在線實時增量數據的存儲，實現「一份存儲兩類計算」。
3. 爲了方便輿情結果查詢需求，「batch view」和「real-time view」存儲在既能夠支持高吞吐的實時寫入，也能夠支持多字段組合搜索和全文檢索。

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

1. 數據流實時寫入一個分佈式的數據庫，藉助於數據庫查詢能力，全量數據能夠輕鬆的對接批量計算系統進行離線處理。
2. 數據庫經過數據庫日誌接口，支持增量讀取，實現對接流計算引擎進行實時計算。
3. 批計算和流計算的結果寫回分佈式數據庫，分佈式數據庫提供豐富的查詢語意，實現計算結果的交互式查詢。

整套架構中，存儲層面經過結合數據庫主表數據和數據庫日誌來取代大數據架構中的隊列服務，計算系統選取自然支持批和流的計算引擎例如Flink或者Spark。這樣一來，咱們既能夠像Lambda進行無限制的歷史數據回溯，又能夠像Kappa架構同樣一套邏輯，存儲處理兩類計算任務。這樣的一套架構咱們取名爲「Lambda plus」，下面就詳細展開如何在阿里雲上打造這樣的一套大數據架構。

雲上輿情繫統架構

在阿里雲衆多存儲和計算產品中，貼合上述大數據架構的需求，咱們選用兩款產品來實現整套輿情大數據系統。存儲層面使用阿里雲自研的分佈式多模型數據庫Tablestore，計算層選用Blink來實現流批一體計算。

這套架構在存儲層面，所有基於Tablestore，一個數據庫解決不一樣存儲需求，根據以前輿情繫統的介紹，網頁爬蟲數據在系統流動中會有四個階段分別是原始網頁內容，網頁結構化數據，分析規則元數據和輿情結果，輿情結果索引。咱們利用Tablestore寬行和schema free的特性，合併原始網頁和網頁結構化數據成一張網頁數據。網頁數據表和計算系統經過Tablestore新功能通道服務進行對接。通道服務基於數據庫日誌，數據的組織結構按照數據的寫入順序進行存儲，正是這一特性，賦能數據庫具有了隊列流式消費能力。使得存儲引擎既能夠具有數據庫的隨機訪問，也能夠具有隊列的按照寫入順序訪問，這也就知足咱們上面提到整合Lambda和kappa架構的需求。分析規則元數據表由分析規則，情感詞庫組層，對應實時計算中的維表。
計算系統這裏選用阿里雲實時流計算產品Blink，Blink是一款支持流計算和批計算一體的實時計算產品。而且相似Tablestore能夠很容易的作到分佈式水平擴展，讓計算資源隨着業務數據增加彈性擴容。使用Tablestore + Blink的優點有如下幾點：

1. Tablestore已經深度和Blink進行整合，支持源表，維表和目的表，業務無需爲數據流動開發代碼。
2. 整套架構大幅下降組建個數，從開源產品的6～7個組建減小到2個，Tablestore和Blink都是全託管0運維的產品，而且都能作到很好的水平彈性，業務峯值擴展無壓力，使得大數據架構的運維成本大幅下降。
3. 業務方只須要關注數據的處理部分邏輯，和Tablestore的交互邏輯都已經集成在Blink中。
4. 開源方案中，若是數據庫源但願對接實時計算，還須要雙寫一個隊列，讓流計算引擎消費隊列中的數據。咱們的架構中數據庫既做爲數據表，又是隊列通道能夠實時增量數據消費。大大簡化了架構的開發和使用成本。
5. 流批一體，在輿情繫統中實時性是相當重要的，因此咱們須要一個實時計算引擎，而Blink除了實時計算之外，也支持批處理Tablestore的數據， 在業務低峯期，每每也須要批量處理一些數據並做爲反饋結果寫回Tablestore，例如情感分析反饋等。那麼一套架構既能夠支持流處理又能夠支持批處理是再好不過。這裏咱們能夠參考以前的一篇文章《實時計算最佳實踐：基於表格存儲和Blink的大數據實時計算》。一套架構帶來的優點是，一套分析代碼既能夠作實時流計算又能夠離線批處理。

整個計算流程會產生實時的輿情計算結果。重大輿情事件的預警，經過Tablestore和函數計算觸發器對接來實現。Tablestore和函數計算作了增量數據的無縫對接，經過結果表寫入事件，能夠輕鬆的經過函數計算觸發短信或者郵件通知。完整的輿情分析結果和展現搜索利用了Tablestore的新功能多元索引，完全解決了開源Hbase+Solr多引擎的痛點：

1. 運維複雜，須要有運維hbase和solr兩套系統的能力，同時還須要維護數據同步的鏈路。
2. Solr數據一致性不如Hbase，在Hbase和Solr數據語意並非徹底一致，加上Solr/Elasticsearch在數據一致性很難作到像數據庫那麼嚴格。在一些極端狀況下會出現數據不一致的問題，開源方案也很難作到跨系統的一致性比對。
3. 查詢接口須要維護兩套API，須要同時使用Hbase client和Solr client，索引中沒有的字段須要主動反查Hbase，易用性較差。

參考文獻

1. Lambda大數據架構
2. Kappa大數據架構
3. Lambda和Kappa架構對比

總結

本文基於《百億級全網輿情分析系統存儲設計》並結合Tablestore的新功能作了現代大數據輿情繫統的架構升級，實現了海量信息下的實時輿情分析存儲系統。也介紹了開源方案，並和咱們的方案作了詳細的對比。

---

本文做者：宇珩

原文連接

本文爲雲棲社區原創內容，未經容許不得轉載。