AWS re:Invent 2018: Big Data Analytics Architectural Patterns & Best Practices (ANT201-R1)
 |
| 康橋科技 —— 白光攝影機專業廠商！ |
前言
網路的飛速發展，促進了很多新媒體的發展，不論是知名的大 V，明星還是圍觀群眾，都可以透過手機在社群媒體、朋友圈或者點評網站上發表狀態，分享自己的所見所想，使得「人人都有了麥克風」。
不論是熱點新聞還是娛樂八卦，傳播速度遠超我們的想像。可以在短短數分鐘內，有數萬計轉發，數百萬的閱讀。如此海量的資訊可以得到爆炸式的傳播，如何能夠即時的把握民情，並作出對應的處理，對很多企業來說都是至關重要的。
大數據時代，除了媒體資訊以外，商品在各類電商平台的訂單量，用戶的購買評論，也都對後續的消費者產生很大的影響。
商家的產品設計者需要匯總統計，和分析各類平台的數據做為依據，決定後續的產品發展，公司的公關和市場部門，也需要根據輿情作出相應的及時處理，而這一切也意味著傳統的輿情系統，升級成為大數據輿情採集和分析系統。
分析完輿情場景後，我們再來具體細化看下大數據輿情系統，對我們的數據儲存和計算系統，提出哪些需求：
- 海量原始數據的即時入庫：為了實現一整套輿情系統，需要有上游原始輸出的採集，也就是爬蟲系統。爬蟲需要採集各類門戶，自媒體的網頁內容。在抓取前需要去重，抓取後還需要分析提取，例如進行子網頁的抓取。
- 原始網頁數據的處理：不論是主流門戶還是自媒體的網頁資訊，抓取後我們需要做一定的數據提取，把原始的網頁內容轉化為結構化數據，例如文章的標題，摘要等，如果是商品點評類消息，也需要提取有效的點評。
- 結構化數據的輿情分析：當各類原始輸出，變成結構化的數據後，我們需要有一個實時的計算產品，把各類輸出做合理的分類，進一步對分類後的內容進行情感打標。根據業務的需求，這裡可能會產生不同的輸出，例如品牌當下是否有熱點話題，輿情影響力分析，轉播路徑分析，參與用戶統計和畫像，輿論情感分析或者是否有重大預警。
- 輿情分析系統中間和結果數據的儲存，交互分析查詢：從網頁原始數據清洗，到最終的輿情報表，這中間會產生很多類型的數據。這些數據有的會提供給數據分析同學，進行輿情分析系統的調優，有的數據會提供給業務部門，根據輿情結果進行決策。這些查詢可能會很靈活，需要我們的儲存系統具備全文檢索，多字段組合靈活的交互分析能力。
- 重大輿情事件的即時預警：對於輿情的結果，除了正常的搜索和展示需求以外，當有重大事件出現，我們需要能做到即時的預警。
我們計劃分兩篇介紹完整的輿情新架構，第一篇主要是提供架構設計，會先介紹時下主流的大數據計算架構，並分析一些優缺點，然後引入輿情大數據架構。第二篇會有完整的數據庫表設計和部分示例代碼。
系統設計
需求分析
結合文章開頭對輿情系統的描述，海量大數據輿情分析系統流程圖大體如下：
- 原始網頁儲存庫，這個庫需要能支持海量數據，低成本，低延時寫入。網頁數據寫入後，要做即時結構化提取，提取出來的數據再進行降噪，分詞，圖片 OCR 處理等。對分詞文本，圖片進行情感辨識產生輿情數據結果集。傳統的離線全量計算，很難滿足輿情系統的時效性需求。
- 計算引擎在做數據處理時，可能還需要從儲存庫中，獲取一些元數據，例如用戶資訊、情感詞元數據資訊等。
- 除了即時的計算鏈路，對存量數據定期要做一些聚類，優化我們的情感詞辨識庫，或者上游根據業務需要，觸發情感處理規則更新，根據新的情感打標庫，對存量數據做一次輿情計算。
- 輿情的結果數據集，有不同類的使用需求。對於重大輿情，需要做即時的預警。完整的輿情結果數據展示層，需要支持全文檢索，靈活的屬性字段組合查詢。業務上可能根據屬性字段中的置信度，輿情時間，或者關鍵詞組合進行分析。
- 根據前面的介紹，輿情大數據分析系統需要兩類計算，一類是即時計算，包括海量網頁內容實時抽取，情感詞分析並進行網頁輿情結果儲存。另一類是離線計算，系統需要對歷史數據進行回溯，結合人工標注等方式，優化情感詞庫，對一些即時計算的結果進行矯正等。所以在系統設計上，需要選擇一套既可以做即時計算，又能做批量離線計算的系統。在開源大數據解決方案中，Lambda 架構恰好可以滿足這些需求，下面我們來介紹下 Lambda 的架構。Lambda 架構 （wiki）
Lambda 架構可以說是 Hadoop，Spark 體系下最火的大數據架構。這套架構的最大優勢，就是在支持海量數據批量計算處理（也就是離線處理），同時也支持流式的即時處理（即熱數據處理）。
具體是如何實現的呢，首先上游一般是一個隊列服務例如 kafka，即時儲存數據的寫入。kafka 隊列會有兩個訂閱者，一個是全量數據即圖片中上半部分，全量數據會被儲存在類似 HDFS 這樣的儲存媒介上。
當有離線計算任務到來，計算資源（例如 Hadoop）會訪問儲存系統上的全量數據，進行全量批計算的處理邏輯。經過 map/reduce 環節後全量的結果，會被寫入一個結構化的儲存引擎。例如 Hbase 中，提供給業務方查詢。
隊列的另一個消費訂閱方是流計算引擎，流計算引擎往往會即時的消費隊列中的數據進行計算處理，例如 Spark Streaming 即時訂閱 Kafka 的數據，流計算結果也會寫入一個結構化數據引擎。批量計算和流計算的結果，寫入的結構化儲存引擎，即上圖標注 3 的 "Serving Layer"，這一層主要提供結果數據的展示和查詢。
當有離線計算任務到來，計算資源（例如 Hadoop）會訪問儲存系統上的全量數據，進行全量批計算的處理邏輯。經過 map/reduce 環節後全量的結果，會被寫入一個結構化的儲存引擎。例如 Hbase 中，提供給業務方查詢。
隊列的另一個消費訂閱方是流計算引擎，流計算引擎往往會即時的消費隊列中的數據進行計算處理，例如 Spark Streaming 即時訂閱 Kafka 的數據，流計算結果也會寫入一個結構化數據引擎。批量計算和流計算的結果，寫入的結構化儲存引擎，即上圖標注 3 的 "Serving Layer"，這一層主要提供結果數據的展示和查詢。
在這套架構中，批量計算的特點是需要支持處理海量的數據，並根據業務的需求，關聯一些其他業務指標進行計算。批量計算的好處，是計算邏輯可以根據業務需求靈活調整，同時計算結果可以反覆重算，同樣的計算邏輯多次計算結果不會改變。批量計算的缺點是計算週期相對較長，很難滿足實時出結果的需求，所以隨著大數據計算的演進，提出了即時計算的需求。
即時計算在 Lambda 架構中，是透過即時數據流來實現，相比批處理，數據增量流的處理方式，決定了數據往往是最近新產生的數據，也就是熱數據。
正因為熱數據這一特點，流計算可以滿足業務對計算的低延時需求，例如在輿情分析系統中，我們往往希望輿情資訊，可以在網頁抓取下來後，分鐘級別拿到計算結果，給業務方充足的時間進行輿情反饋。
下面我們就來具體看一下，基於 Lambda 架構的思想，如何實現一套完整的輿情大數據架構。
即時計算在 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 架構的需求。分析規則元數據表由分析規則，情感詞庫組層，對應即時計算中的維表。
網頁數據表和計算系統，透過 Tablestore 新功能通道服務進行對接。通道服務基於數據庫日誌，數據的組織結構，按照數據的寫入順序進行儲存，正是這一特性，賦能數據庫具備了隊列流式消費能力。
使得儲存引擎既可以具備數據庫的隨機訪問，也可以具備隊列的按照寫入順序訪問，這也就滿足我們上面提到整合 Lambda 和 kappa 架構的需求。分析規則元數據表由分析規則，情感詞庫組層，對應即時計算中的維表。
計算系統這裡選用雲端即時流計算產品 Blink，Blink 是一款支持流計算和批計算一體的即時計算產品。並且類似 Tablestore 可以很容易的做到分布式水平擴展，讓計算資源隨著業務數據成長彈性擴容。使用 Tablestore + Blink 的優勢有以下幾點：
- Tablestore 已經深度和 Blink 進行整合，支持源表，維表和目的表，業務無需為數據流動開發代碼。
- 整套架構大幅降低組建個數，從開源產品的 6～7 個組建減少到 2 個，Tablestore 和 Blink 都是全托管 0 維運的產品，並且都能做到很好的水平彈性，業務峰值擴展無壓力，使得大數據架構的維運成本大幅降低。
- 業務方只需要關注數據的處理部分邏輯，和 Tablestore 的交互邏輯都已經整合在 Blink 中。
- 開源方案中，如果數據庫源希望對接即時計算，還需要雙寫一個隊列，讓流計算引擎消費隊列中的數據。我們的架構中數據庫既作為數據表，又是隊列通道可以即時增量數據消費。大大簡化了架構的開發和使用成本。
- 流批一體，在輿情系統中即時性是至關重要的，所以我們需要一個即時計算引擎，而 Blink 除了即時計算以外，也支持批處理 Tablestore 的數據， 在業務低峰期，往往也需要批量處理一些數據，並作為反饋結果寫回 Tablestore，例如情感分析反饋等。那麼一套架構既可以支持流處理，又可以支持批處理是再好不過。這裡我們可以參考之前的一篇文章《即時計算最佳實踐：基於表格儲 和 Blink 的大數據即時計算》。一套架構帶來的優勢是，一套分析代碼既可以做即時流計算，又可以離線批處理。
整個計算流程，會產生即時的輿情計算結果。重大輿情事件的預警，透過 Tablestore 和函數計算觸發器對接來實現。
Tablestore 和函數計算做了增量數據的無縫對接，透過結果表寫入事件，可以輕鬆的透過函數計算，觸發簡訊或者郵件通知。完整的輿情分析結果，和展示搜索利用了 Tablestore 的新功能多元索引，徹底解決了開源 Hbase+Solr 多引擎的痛點：
Tablestore 和函數計算做了增量數據的無縫對接，透過結果表寫入事件，可以輕鬆的透過函數計算，觸發簡訊或者郵件通知。完整的輿情分析結果，和展示搜索利用了 Tablestore 的新功能多元索引，徹底解決了開源 Hbase+Solr 多引擎的痛點：
- 維運複雜，需要有維運 hbase 和 solr 兩套系統的能力，同時還需要維護數據同步的鏈路。
- Solr 數據一致性不如 Hbase，在 Hbase 和 Solr 數據語意，並不是完全一致，加上 Solr/Elasticsearch 在數據一致性，很難做到像數據庫那麼嚴格。在一些極端情況下，會出現數據不一致的問題，開源方案也很難做到，跨系統的一致性比對。
- 查詢接口需要維護兩套 API，需要同時使用 Hbase client 和 Solr client，索引中沒有的字段，需要主動反查 Hbase，易用性較差。
參考文獻
總結
本文基於《百億級全網輿情分析系統儲存設計》並結合 Tablestore 的新功能，做了現代大數據輿情系統的架構升級，實現了海量資訊下的即時輿情分析儲存系統。也介紹了開源方案，並和我們的方案做了詳細的對比。
 |
| http://www.arcran.com/tw/ |
 |
沒有留言:
張貼留言