前言

網際網路的飛速發展促進了很多新媒體的發展，不論是知名的大V，明星還是圍觀群眾都可以通過手機在微博，朋友圈或者點評網站上發表狀態，分享自己的所見所想，使得“人人都有了麥克風”。不論是熱點新聞還是娛樂八卦，傳播速度遠超我們的想象。可以在短短數分鐘內，有數萬計轉發，數百萬的閱讀。如此海量的資訊可以得到爆炸式的傳播，如何能夠實時的把握民情並作出對應的處理對很多企業來說都是至關重要的。大資料時代，除了媒體資訊以外，商品在各類電商平臺的訂單量，使用者的購買評論也都對後續的消費者產生很大的影響。商家的產品設計者需要彙總統計和分析各類平臺的資料做為依據，決定後續的產品發展，公司的公關和市場部門也需要根據輿情作出相應的及時處理，而這一切也意味著傳統的輿情繫統升級成為大資料輿情采集和分析系統。
分析完輿情場景後，我們再來具體細化看下大資料輿情繫統，對我們的資料儲存和計算系統提出哪些需求：

• 海量原始資料的實時入庫：為了實現一整套輿情繫統，需要有上游原始輸出的採集，也就是爬蟲系統。爬蟲需要採集各類門戶，自媒體的網頁內容。在抓取前需要去重，抓取後還需要分析提取，例如進行子網頁的抓取。
• 原始網頁資料的處理：不論是主流門戶還是自媒體的網頁資訊，抓取後我們需要做一定的資料提取，把原始的網頁內容轉化為結構化資料，例如文章的標題，摘要等，如果是商品點評類訊息也需要提取有效的點評。
• 結構化資料的輿情分析：當各類原始輸出變成結構化的資料後，我們需要有一個實時的計算產品把各類輸出做合理的分類，進一步對分類後的內容進行情感打標。根據業務的需求這裡可能會產生不同的輸出，例如品牌當下是否有熱點話題，輿情影響力分析，轉播路徑分析，參與使用者統計和畫像，輿論情感分析或者是否有重大預警。
• 輿情分析系統中間和結果資料的儲存，互動分析查詢：從網頁原始資料清洗到最終的輿情報表這中間會產生很多型別的資料。這些資料有的會提供給資料分析同學進行輿情分析系統的調優，有的資料會提供給業務部門根據輿情結果進行決策。這些查詢可能會很靈活，需要我們的儲存系統具備全文檢索，多欄位組合靈活的互動分析能力。
• 重大輿情事件的實時預警：對於輿情的結果除了正常的搜尋和展示需求以外，當有重大事件出現我們需要能做到實時的預警。

我們計劃分兩篇介紹完整的輿情新架構，第一篇主要是提供架構設計，會先介紹時下主流的大資料計算架構，並分析一些優缺點，然後引入輿情大資料架構。第二篇會有完整的資料庫表設計和部分示例程式碼。大家敬請期待。

系統設計

需求分析

結合文章開頭對輿情繫統的描述，海量大資料輿情分析系統流程圖大體如下：

圖1 輿情繫統業務流程

• 原始網頁儲存庫，這個庫需要能支援海量資料，低成本，低延時寫入。網頁資料寫入後，要做實時結構化提取，提取出來的資料再進行降噪，分詞，圖片ocr處理等。對分詞文字，圖片進行情感識別產生輿情資料結果集。傳統的離線全量計算很難滿足輿情繫統的時效性需求。
• 計算引擎在做資料處理時，可能還需要從儲存庫中獲取一些元資料，例如使用者資訊，情感詞元資料資訊等。
• 除了實時的計算鏈路，對存量資料定期要做一些聚類，優化我們的情感詞識別庫，或者上游根據業務需要觸發情感處理規則更新，根據新的情感打標庫對存量資料做一次輿情計算。
• 輿情的結果資料集有不同類的使用需求。對於重大輿情，需要做實時的預警。完整的輿情結果資料展示層需要支援全文檢索，靈活的屬性欄位組合查詢。業務上可能根據屬性欄位中的置信度，輿情時間，或者關鍵詞組合進行分析。

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

Lambda架構 （wiki）

圖2 Lambda架構圖

Lambda架構可以說是Hadoop，Spark體系下最火的大資料架構。這套架構的最大優勢就是在支援海量資料批量計算處理（也就是離線處理）同時也支援流式的實時處理（即熱資料處理）。
具體是如何實現的呢，首先上游一般是一個佇列服務例如kafka，實時儲存資料的寫入。kafka佇列會有兩個訂閱者，一個是全量資料即圖片中上半部分，全量資料會被儲存在類似HDFS這樣的儲存介質上。當有離線計算任務到來，計算資源（例如Hadoop）會訪問儲存系統上的全量資料，進行全量批計算的處理邏輯。經過map/reduce環節後全量的結果會被寫入一個結構化的儲存引擎例如Hbase中，提供給業務方查詢。佇列的另一個消費訂閱方是流計算引擎，流計算引擎往往會實時的消費佇列中的資料進行計算處理，例如Spark Streaming實時訂閱Kafka的資料，流計算結果也會寫入一個結構化資料引擎。批量計算和流計算的結果寫入的結構化儲存引擎即上圖標註3的"Serving Layer"，這一層主要提供結果資料的展示和查詢。

在這套架構中，批量計算的特點是需要支援處理海量的資料，並根據業務的需求，關聯一些其他業務指標進行計算。批量計算的好處是計算邏輯可以根據業務需求靈活調整，同時計算結果可以反覆重算，同樣的計算邏輯多次計算結果不會改變。批量計算的缺點是計算週期相對較長，很難滿足實時出結果的需求，所以隨著大資料計算的演進，提出了實時計算的需求。實時計算在Lambda架構中是通過實時資料流來實現，相比批處理，資料增量流的處理方式決定了資料往往是最近新產生的資料，也就是熱資料。正因為熱資料這一特點，流計算可以滿足業務對計算的低延時需求，例如在輿情分析系統中，我們往往希望輿情資訊可以在網頁抓取下來後，分鐘級別拿到計算結果，給業務方充足的時間進行輿情反饋。下面我們就來具體看一下，基於Lambda架構的思想如何實現一套完整的輿情大資料架構。

開源輿情大資料方案

通過這個流程圖，讓我們瞭解了整個輿情繫統的建設過程中，需要經過不同的儲存和計算系統。對資料的組織和查詢有不同的需求。在業界基於開源的大資料系統並結合Lambda架構，整套系統可以設計如下：

圖3 開源輿情架構圖

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”儲存在既可以支援高吞吐的實時寫入，也可以支援多欄位組合搜尋和全文檢索。

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

圖4 Lambda Plus架構

1. 資料流實時寫入一個分散式的資料庫，藉助於資料庫查詢能力，全量資料可以輕鬆的對接批量計算系統進行離線處理。
2. 資料庫通過資料庫日誌介面，支援增量讀取，實現對接流計算引擎進行實時計算。
3. 批計算和流計算的結果寫回分散式資料庫，分散式資料庫提供豐富的查詢語意，實現計算結果的互動式查詢。

整套架構中，儲存層面通過結合資料庫主表資料和資料庫日誌來取代大資料架構中的佇列服務，計算系統選取天然支援批和流的計算引擎例如Flink或者Spark。這樣一來，我們既可以像Lambda進行無限制的歷史資料回溯，又可以像Kappa架構一樣一套邏輯，儲存處理兩類計算任務。這樣的一套架構我們取名為“Lambda plus”，下面就詳細展開如何在阿里雲上打造這樣的一套大資料架構。

雲上輿情繫統架構

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

圖5 雲上輿情大資料架構

這套架構在儲存層面，全部基於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的新功能做了現代大資料輿情繫統的架構升級，實現了海量資訊下的實時輿情分析儲存系統。也介紹了開源方案，並和我們的方案做了詳細的對比。

原文連結
本文為雲棲社群原創內容，未經