大數據架構如何作到流批一體？

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

大數據處理的挑戰

如今已經有愈來愈多的行業和技術領域需求大數據分析系統，例如金融行業須要使用大數據系統結合 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 架構的四個挑戰

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 流的方式從新流入流計算引擎，從新產生歷史數據的視圖。

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 級爲主。典型的業務場景如：

大數據輿情分析系統：

參考資料
[1].https://yq.aliyun.com/articles/704171?spm=a2c4e.11153959.0.0.229847a2BpWNvc
[2].http://lambda-architecture.net/
[3].http://shop.oreilly.com/product/0636920032175.do, Martin Kleppmann
[4].https://www.oreilly.com/ideas/applying-the-kappa-architecture-in-the-telco-industry
[5].https://www.oreilly.com/ideas/questioning-the-lambda-architecture,Jay Kreps
[6].http://milinda.pathirage.org/kappa-architecture.com/
[7].Moving from Lambda and Kappa Architectures to Kappa+ at Uber
[8].https://eng.uber.com/hoodie/, Prasanna Rajaperumal and Vinoth Chandar
[9].https://eng.uber.com/uber-big-data-platform/, Reza Shiftehfar

---

本文做者：阿里技術

閱讀原文

本文來自雲棲社區合做夥伴「阿里技術」，如需轉載請聯繫原做者。