Lambda plus: 雲上大資料解決方案

本文會簡述大資料分析場景需要解決的技術挑戰，讨論目前主流大資料架構模式及其發展。最後我們将介紹如何結合雲上存儲、計算元件，實作更優的通用大資料架構模式，以及該模式可以涵蓋的典型資料處理場景。

大資料處理的挑戰

現在已經有越來越多的行業和技術領域需求大資料分析系統，例如金融行業需要使用大資料系統結合VaR(value at risk)或者機器學習方案進行信貸風控，零售、餐飲行業需要大資料系統實作輔助銷售決策，各種IOT場景需要大資料系統持續聚合和分析時序資料，各大科技公司需要建立大資料分析中台等等。

抽象來看，支撐這些場景需求的分析系統，面臨的都是大緻相同的技術挑戰：

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

簡述大資料架構發展

Lambda架構

Lambda架構是目前影響最深刻的大資料處理架構，它的核心思想是将不可變的資料以追加的方式并行寫到批和流處理系統内，随後将相同的計算邏輯分别在流和批系統中實作，并且在查詢階段合并流和批的計算視圖并展示給使用者。Lambda的提出者Nathan Marz還假定了批處理相對簡單不易出現錯誤，而流處理相對不太可靠，是以流處理器可以使用近似算法，快速産生對視圖的近似更新，而批處理系統會采用較慢的精确算法，産生相同視圖的校正版本。

圖 1 Lambda架構示例

Lambda架構典型資料流程是(

http://lambda-architecture.net/)

：

所有的資料需要分别寫入批處理層和流處理層；
批處理層兩個職責：(i)管理master dataset(存儲不可變、追加寫的全量資料), (ii)預計算batch view；
服務層對batch view建立索引，以支援低延遲、ad-hoc方式查詢view；
流計算層作為速度層，對實時資料計算近似的real-time view，作為高延遲batch view的補償快速視圖；
所有的查詢需要合并batch view和real-time view；

Lambda架構設計推廣了在不可變的事件流上生成視圖，并且可以在必要時重新處理事件的原則，該原則保證了系統随需求演進時，始終可以建立相應的新視圖出來，切實可行的滿足了不斷變化的曆史資料和實時資料分析需求。

Lambda架構的四個挑戰

Lambda架構非常複雜，在資料寫入、存儲、對接計算元件以及展示層都有複雜的子課題需要優化：

寫入層上，Lambda沒有對資料寫入進行抽象，而是将雙寫流批系統的一緻性問題反推給了寫入資料的上層應用；
存儲上，以HDFS為代表的master dataset不支援資料更新，持續更新的資料源隻能以定期拷貝全量snapshot到HDFS的方式保持資料更新，資料延遲和成本比較大；
計算邏輯需要分别在流批架構中實作和運作，而在類似Storm的流計算架構和Hadoop MR的批處理架構做job開發、調試、問題調查都是比較複雜的；
結果視圖需要支援低延遲的查詢分析，通常還需要将資料派生到列存分析系統，并保證成本可控；

流批融合的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的解決思路：

針對資料寫入的問題，Lambda plus資料隻需要寫入表格存儲，Blink流計算架構通過通道服務API直讀表格存儲的實時資料，不需要使用者雙寫隊列或者自己實作資料同步；
存儲上，Lambda plus直接使用表格存儲作為master dataset，表格存儲支援使用者tp系統低延遲讀寫更新，同時也提供了索引功能ad-hoc查詢分析，資料使用率高，容量型表格存儲執行個體也可以保證資料存儲成本可控；
計算上，Lambda plus利用blink流批一體計算引擎，統一流批代碼；
展示層，表格存儲提供了多元索引和全局二級索引功能，使用者可以根據解決視圖的查詢需求和存儲體量，合理選擇索引方式；

總結，表格存儲實作了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，不強依賴引擎計算結果；