cookieOptions = {...}; .基於大數據處理的輿情分析系統架構 - 3S Market「全球智慧科技應用」市場資訊網

3S MARKET

3S MARKET
2019年6月17日 星期一

AWS re:Invent 2018: Big Data Analytics Architectural Patterns & Best Practices (ANT201-R1)

康橋科技 —— 白光攝影機專業廠商!

來源:InfoQ 作者:宇珩

前言
網路的飛速發展,促進了很多新媒體的發展,不論是知名的大 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 系統進行離線計算,更新情感詞庫或者接受新的計算策略,重新計算歷史數據修正即時計算的結果。
  5. 開源架構分析上面的輿情大數據架構,透過 Kafka 對接流計算,Hbase 對接批計算來實現 Lambda 架構中的「Batch view」和「Real-time view」,整套架構還是比較清晰的,可以很好的滿足在線和離線兩類計算需求。但是把這一套系統應用在生產,並不是一件容易的事情,主要有下面一些原因。

    • 整套架構涉及到非常多的儲存和計算系統包括:Kafka,Hbase,Spark,Flink,Elasticsearch。數據會在不同的儲存和計算系統中流動,維運好整套架構中的每一個開源產品都是一個很大的挑戰。任何一個產品或者是產品間的通道出現故障,對整個輿情分析結果的時效性都會產生影響。
    • 為了實現批計算和流計算,原始的網頁需要分別儲存在 Kafka 和 Hbase 中,離線計算是消費 hbase 中的數據,流計算消費 Kafka 的數據,這樣會帶來儲存資源的冗余,同時也導致需要維護兩套計算邏輯,計算代碼開發和維護成本也會上升。
    • 輿情的計算結果儲存在 Mysql 或者 Hbase,為了豐富組合查詢語句,需要把數據同步構建到 Elasticsearch 中。查詢的時候可能需要組合 Mysql 和 Elasticsearch 的查詢結果。這裡沒有跳過數據庫,直接把結果數據寫入 Elasticsearch 這類搜索系統,是因為搜索系統的數據實時寫入能力和數據可靠性不如數據庫,業界通常是把數據庫和搜索系統整合,整合下的系統兼備了數據庫和搜索系統的優勢,但是兩個引擎之間數據的同步,和跨系統查詢對維運和開發,帶來很多額外的成本。

    1. 新的大數據架構 Lambda plus 透過前面的分析,相信大家都會有一個疑問,有沒有簡化的的大數據架構,在可以滿足 Lambda 對計算需求的假設,又能減少儲存計算以及模塊的個數呢。Linkedin 的 Jay Kreps 提出了 Kappa 架構,關於 Lambda 和 Kappa 的對比可以參考 " 雲上大數據方案 " 這篇,這裡不展開詳細對比,簡單說下,Kappa 為了簡化兩份儲存,取消了全量的數據存儲庫,透過在 Kafka 保留更長日誌,當有回溯重新計算需求到來時,重新從隊列的頭部開始訂閱數據,再一次用流的方式處理 Kafka 隊列中保存的所有數據。這樣設計的好處,是解決了需要維護兩份儲存,和兩套計算邏輯的痛點,美中不足的地方,是隊列可以保留的歷史數據畢竟有限,難以做到無時間限制的回溯。分析到這裡,我們沿著 Kappa 針對 Lambda 的改進思路,向前多思考一些:假如有一個儲存引擎,既滿足數據庫可以高效的寫入和隨機查詢,又能像隊列服務,滿足先進先出,是不是就可以把 Lambda 和 Kappa 架構揉合在一起,打造一個 Lambda plus 架構呢?新架構在 Lambda 的基礎上可以提升以下幾點:
      • 在支持流計算和批計算的同時,讓計算邏輯可以復用,實現「一套代碼兩類需求」。
      • 統一歷史數據全量和在線實時增量數據的儲存,實現「一份儲存兩類計算」。
      • 為了方便輿情結果查詢需求,「batch view」和「real-time view」儲存,在既可以支持高吞吐的即時寫入,也可以支持多字段組合搜索和全文檢索。
    1. 總結起來就是整套新架構的核心,是解決儲存的問題,以及如何靈活的對接計算。我們希望整套方案是類似下面的架構:
4 Lambda Plus 


  1. 數據流即時寫入一個分佈式的數據庫,借助於數據庫查詢能力,全量數據可以輕鬆的對接批量計算系統,進行離線處理。
  2. 數據庫透過數據庫日誌接口,支持增量讀取,實現對接流計算引擎進行即時計算。
  3. 批計算和流計算的結果寫回分布式數據庫,分布式數據庫提供豐富的查詢語意,實現計算結果的交互式查詢。
  4. 整套架構中,儲存層面透過結合數據庫主表數據,和數據庫日誌,來取代大數據架構中的隊列服務,計算系統選取天然支持批和流的計算引擎,例如 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 的新功能,做了現代大數據輿情系統的架構升級,實現了海量資訊下的即時輿情分析儲存系統。也介紹了開源方案,並和我們的方案做了詳細的對比。

http://www.arcran.com/tw/

0 comments: