阿里妹導讀：大數據與現有的科技手段結合，對大多數產業而言都能產生巨大的經濟及社會價值。這也是當下許多企業，在大數據上深耕的原因。大數據分析場景需要解決哪些技術挑戰?目前，有哪些主流大數據架構模式及其發展?今天，我們都會一一解讀，并介紹如何結合云上存儲、計算組件，實現更優的通用大數據架構模式，以及該模式可以涵蓋的典型數據處理場景。

大數據處理的挑戰

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

• 抽象來看，支撐這些場景需求的分析系統，面臨大致相同的技術挑戰：
• 業務分析的數據范圍橫跨實時數據和歷史數據，既需要低延遲的實時數據分析，也需要對 PB 級的歷史數據進行探索性的數據分析;
• 可靠性和可擴展性問題，用戶可能會存儲海量的歷史數據，同時數據規模有持續增長的趨勢，需要引入分布式存儲系統來滿足可靠性和可擴展性需求，同時保證成本可控;
• 技術棧深，需要組合流式組件、存儲系統、計算組件和;
• 可運維性要求高，復雜的大數據架構難以維護和管控;

簡述大數據架構發展

Lambda 架構

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

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 架構的四個挑戰

1. Lambda 架構非常復雜，在數據寫入、存儲、對接計算組件以及展示層都有復雜的子課題需要優化：
2. 寫入層上，Lambda 沒有對數據寫入進行抽象，而是將雙寫流批系統的一致性問題反推給了寫入數據的上層應用;
3. 存儲上，以 HDFS 為代表的master dataset 不支持數據更新，持續更新的數據源只能以定期拷貝全量 snapshot 到 HDFS 的方式保持數據更新，數據延遲和成本比較大;
4. 計算邏輯需要分別在流批框架中實現和運行，而在類似 Storm 的流計算框架和Hadoop MR 的批處理框架做 job 開發、調試、問題調查都是比較復雜的;

結果視圖需要支持低延遲的查詢分析，通常還需要將數據派生到列存分析系統，并保證成本可控。

流批融合的 Lambda 架構

針對 Lambda 架構的問題3，計算邏輯需要分別在流批框架中實現和運行的問題，不少計算引擎已經開始往流批統一的方向去發展，例如 Spark 和 Flink，從而簡化lambda 架構中的計算部分。實現流批統一通常需要支持：

1. 以相同的處理引擎來處理實時事件和歷史回放事件;
2. 支持 exactly once 語義，保證有無故障情況下計算結果完全相同;
3. 支持以事件發生時間而不是處理時間進行窗口化。

Kappa架構

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

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+ 數據處理架構。 

混合分析系統的 Kappa 架構

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

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，其具體組件分解：

• 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方式查詢; 

針對上述 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 級為主。典型的業務場景如：

大數據輿情分析系統：