Lambda plus: 雲上大數據解決方案

本文會簡述大數據分析場景須要解決的技術挑戰，討論目前主流大數據架構模式及其發展。最後咱們將介紹如何結合雲上存儲、計算組件，實現更優的通用大數據架構模式，以及該模式能夠涵蓋的典型數據處理場景。

 

大數據處理的挑戰

如今已經有愈來愈多的行業和技術領域需求大數據分析系統，例如金融行業須要使用大數據系統結合VaR(value at risk)或者機器學習方案進行信貸風控，零售、餐飲行業須要大數據系統實現輔助銷售決策，各類IOT場景須要大數據系統持續聚合和分析時序數據，各大科技公司須要創建大數據分析中臺等等。
抽象來看，支撐這些場景需求的分析系統，面臨的都是大體相同的技術挑戰：

• 業務分析的數據範圍橫跨實時數據和歷史數據，既需求低延遲的實時數據分析，也需求對PB級的歷史數據進行探索性的數據分析；
• 可靠性和可擴展性問題，用戶可能會存儲海量的歷史數據，同時數據規模有持續增加的趨勢，須要引入分佈式存儲系統來知足可靠性和可擴展性需求，同時保證成本可控；
• 技術棧深，須要組合流式組件、存儲系統、計算組件和；
• 可運維性要求高，複雜的大數據架構難以維護和管控；

 

簡述大數據架構發展

 

Lambda架構

Lambda架構是目前影響最深入的大數據處理架構，它的核心思想是將不可變的數據以追加的方式並行寫到批和流處理系統內，隨後將相同的計算邏輯分別在流和批系統中實現，而且在查詢階段合併流和批的計算視圖並展現給用戶。Lambda的提出者Nathan Marz還假定了批處理相對簡單不易出現錯誤，而流處理相對不太可靠，所以流處理器可使用近似算法，快速產生對視圖的近似更新，而批處理系統會採用較慢的精確算法，產生相同視圖的校訂版本。

圖 1 Lambda架構示例

Lambda架構典型數據流程是(http://lambda-architecture.net/)：

1. 全部的數據須要分別寫入批處理層和流處理層；
2. 批處理層兩個職責：(i)管理master dataset(存儲不可變、追加寫的全量數據), (ii)預計算batch view；
3. 服務層對batch view創建索引，以支持低延遲、ad-hoc方式查詢view；
4. 流計算層做爲速度層，對實時數據計算近似的real-time view，做爲高延遲batch view的補償快速視圖；
5. 全部的查詢須要合併batch view和real-time view；

Lambda架構設計推廣了在不可變的事件流上生成視圖，而且能夠在必要時從新處理事件的原則，該原則保證了系統隨需求演進時，始終能夠建立相應的新視圖出來，切實可行的知足了不斷變化的歷史數據和實時數據分析需求。

Lambda架構的四個挑戰

Lambda架構很是複雜，在數據寫入、存儲、對接計算組件以及展現層都有複雜的子課題須要優化：

1. 寫入層上，Lambda沒有對數據寫入進行抽象，而是將雙寫流批系統的一致性問題反推給了寫入數據的上層應用；
2. 存儲上，以HDFS爲表明的master dataset不支持數據更新，持續更新的數據源只能以按期拷貝全量snapshot到HDFS的方式保持數據更新，數據延遲和成本比較大；
3. 計算邏輯須要分別在流批框架中實現和運行，而在相似Storm的流計算框架和Hadoop MR的批處理框架作job開發、調試、問題調查都是比較複雜的；
4. 結果視圖須要支持低延遲的查詢分析，一般還須要將數據派生到列存分析系統，並保證成本可控；

流批融合的Lambda架構

針對Lambda架構的問題3，計算邏輯須要分別在流批框架中實現和運行的問題，很多計算引擎已經開始往流批統一的方向去發展，例如Spark和Flink，從而簡化lambda架構中的計算部分。實現流批統一一般須要支持：1.以相同的處理引擎來處理實時事件和歷史回放事件；2.支持exactly once語義，保證有無端障狀況下計算結果徹底相同；3.支持以事件發生時間而不是處理時間進行窗口化；

Kappa架構

Kappa架構由Jay Kreps提出，不一樣於Lambda同時計算流計算和批計算併合並視圖，Kappa只會經過流計算一條的數據鏈路計算併產生視圖。Kappa一樣採用了從新處理事件的原則，對於歷史數據分析類的需求，Kappa要求數據的長期存儲可以以有序log流的方式從新流入流計算引擎，從新產生歷史數據的視圖。
 

圖2 Kappa大數據架構

Kappa方案經過精簡鏈路解決了1數據寫入和3計算邏輯複雜的問題，但它依然沒有解決存儲和展現的問題，特別是在存儲上，使用相似kafka的消息隊列存儲長期日誌數據，數據沒法壓縮，存儲成本很大，繞過方案是使用支持數據分層存儲的消息系統（如Pulsar，支持將歷史消息存儲到雲上存儲系統），可是分層存儲的歷史日誌數據僅能用於Kappa backfill做業，數據的利用率依然很低。

Lambda和Kappa的場景區別：

• Kappa不是Lambda的替代架構，而是其簡化版本，Kappa放棄了對批處理的支持，更擅長業務自己爲append-only數據寫入場景的分析需求，例如各類時序數據場景，自然存在時間窗口的概念，流式計算直接知足其實時計算和歷史補償任務需求；
• Lambda直接支持批處理，所以更適合對歷史數據有不少ad hoc查詢的需求的場景，好比數據分析師須要按任意條件組合對歷史數據進行探索性的分析，而且有必定的實時性需求，指望儘快獲得分析結果，批處理能夠更直接高效地知足這些需求；

Kappa+

Kappa+是Uber提出流式數據處理架構，它的核心思想是讓流計算框架直讀HDFS類的數倉數據，一併實現實時計算和歷史數據backfill計算，不須要爲backfill做業長期保存日誌或者把數據拷貝回消息隊列。Kappa+將數據任務分爲無狀態任務和時間窗口任務，無狀態任務比較簡單，根據吞吐速度合理併發掃描全量數據便可，時間窗口任務的原理是將數倉數據按照時間粒度進行分區存儲，窗口任務按時間序一次計算一個partition的數據，partition內亂序併發，全部分區文件所有讀取完畢後，全部source才進入下個partition消費並更新watermark。事實上，Uber開發了Apache hudi框架來存儲數倉數據，hudi支持更新、刪除已有parquet數據，也支持增量消費數據更新部分，從而系統性解決了問題2存儲的問題。下圖3是完整的Uber大數據處理平臺，其中Hadoop -> Spark -> Analytical data user涵蓋了Kappa+數據處理架構。

圖3 Uber圍繞Hadoop dataset的大數據架構

混合分析系統的Kappa架構

Lambda和Kappa架構都還有展現層的困難點，結果視圖如何支持ad-hoc查詢分析，一個解決方案是在Kappa基礎上衍生數據分析流程，以下圖4，在基於使用Kafka + Flink構建Kappa流計算數據架構，針對Kappa架構分析能力不足的問題，再利用Kafka對接組合ElasticSearch實時分析引擎，部分彌補其數據分析能力。可是ElasticSearch也只適合對合理數據量級的熱數據進行索引，沒法覆蓋全部批處理相關的分析需求，這種混合架構某種意義上屬於Kappa和Lambda間的折中方案。

圖4 Kafka + Flink + ElasticSearch的混合分析系統

 

Lambda plus：Tablestore + Blink流批一體處理框架

Lambda plus是基於Tablestore和Blink打造的雲上存在能夠複用、簡化的大數據架構模式，架構方案全serverless即開即用，易搭建免運維。
表格存儲（Tablestore）是阿里雲自研的NoSQL多模型數據庫，提供PB級結構化數據存儲、千萬TPS以及毫秒級延遲的服務能力，表格存儲提供了通道服務（TunnelService）支持用戶以按序、流式地方式消費寫入表格存儲的存量數據和實時數據，同時表格存儲還提供了多元索引功能，支持用戶對結果視圖進行實時查詢和分析。
Blink是阿里雲在Apache Flink基礎上深度改進的實時計算平臺，Blink旨在將流處理和批處理統一，實現了全新的 Flink SQL 技術棧，在功能上，Blink支持如今標準 SQL 幾乎全部的語法和語義，在性能上，Blink也比社區Flink更增強大。
在TableStore + blink的雲上Lambda架構中，用戶能夠同時使用表格存儲做爲master dataset和batch&stream view，批處理引擎直讀表格存儲產生batch view，同時流計算引擎經過Tunnel Service流式處理實時數據，持續生成stream view。

圖5 Tablestore + Blink的Lambda plus大數據架構

如上圖5，其具體組件分解：

• Lambda batch層：

  • Tablestore直接做爲master dataset，支持用戶直讀，配合Tablestore多元索引，用戶的線上服務直讀、ad-hoc查詢master dataset並將結果返回給用戶；
  • blink批處理任務向Tablestore下推SQL的查詢條件，直讀Tablestore master dataset，計算batch view，並將batch view從新寫回Tablestore；

• Streaming層:

  • blink流處理任務經過表格存儲TunnelService API直讀master dataset中的實時數據，持續產生stream view；
  • Kappa架構的backfill任務，能夠經過創建全量類型數據通道，流式消費master dataset的存量數據，重新計算；

• Serving層：

  • 爲存儲batch view和stream view的Tablestore結果表創建全局二級索引和多元索引，業務能夠低延遲、ad-hoc方式查詢；

圖6 Lambda plus的數據鏈路

針對上述Lambda架構1-4的技術問題，Lambda plus的解決思路：

1. 針對數據寫入的問題，Lambda plus數據只須要寫入表格存儲，Blink流計算框架經過通道服務API直讀表格存儲的實時數據，不須要用戶雙寫隊列或者本身實現數據同步；
2. 存儲上，Lambda plus直接使用表格存儲做爲master dataset，表格存儲支持用戶tp系統低延遲讀寫更新，同時也提供了索引功能ad-hoc查詢分析，數據利用率高，容量型表格存儲實例也能夠保證數據存儲成本可控；
3. 計算上，Lambda plus利用blink流批一體計算引擎，統一流批代碼；
4. 展現層，表格存儲提供了多元索引和全局二級索引功能，用戶能夠根據解決視圖的查詢需求和存儲體量，合理選擇索引方式；

總結，表格存儲實現了batch view、master dataset直接查詢、stream view的功能全集，Blink實現流批統一，Tablestore加blink的Lambda plus模式能夠明顯簡化Lambda架構的組件數量，下降搭建和運維難度，拓展用戶數據價值。

 

表格存儲是如何實現支持上述功能全集的

• 存儲引擎的高併發、低延遲特性：

  • 表格存儲面向在線業務提供高併發、低延遲的訪問，而且tps按分區水平擴展，能夠有效支持批處理和Kappa backfill的高吞吐數據掃描和流計算按分區粒度併發實時處理；

• 使用通道服務精簡架構：

  • Tablestore數據通道支持用戶以按序、流式地方式消費寫入表格存儲的存量數據和實時數據，避免Lambda架構引入消息隊列系統以及master dataset和隊列的數據一致性問題；

• 二級索引和多元索引的靈活查詢能力：

  • 存儲在表格存儲的batch view和real-time view可使用多元索引和二級索引實現ad-hoc查詢，使用多元索引進行聚合分析計算；
  • 同時展現層也能夠利用二級索引和多元索引直接查詢表格存儲master dataset，不強依賴引擎計算結果；

 

Lambda plus的適用場景

基於Tablestore和Blink的Lambda plus架構，適用於基於分佈式NoSQL數據庫存儲數據的大數據分析場景，如IOT、時序數據、爬蟲數據、用戶行爲日誌數據存儲等，數據量以TB級爲主。典型的業務場景如：

• 大數據輿情分析系統

 

拓展閱讀

能夠參考下列資源快速體驗表格存儲+blink的大數據架構、表格存儲多元索引及其相關場景：

• 實時計算的最佳實踐：基於表格存儲和Blink的大數據實時計算
• 大數據同步利器: 表格存儲全增量一體消費通道
• TableStore多元索引，大數據查詢的利器

 

本文做者：Dendi

原文連接 

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