大資料架構如何做到流批一體？

大資料處理的挑戰

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

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

業務分析的資料範圍橫跨實時資料和歷史資料，既需要低延遲的實時資料分析，也需要對 PB 級的歷史資料進行探索性的資料分析;

可靠性和可擴充套件性問題，使用者可能會儲存海量的歷史資料，同時資料規模有持續增長的趨勢，需要引入分散式儲存系統來滿足可靠性和可擴充套件性需求，同時保證成本可控;

技術棧深，需要組合流式元件、儲存系統、計算元件和;

可運維性要求高，複雜的大資料架構難以維護和管控;

簡述大資料架構發展

Lambda 架構

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

圖 1 Lambda架構示例

Lambda架構典型資料流程是()：

所有的資料需要分別寫入批處理層和流處理層;

批處理層兩個職責：(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 架構中的計算部分。實現流批統一通常需要支援：

以相同的處理引擎來處理實時事件和歷史回放事件;

支援 exactly once 語義，保證有無故障情況下計算結果完全相同;

支援以事件發生時間而不是處理時間進行視窗化。

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，不強依賴引擎計算結果。

Lambda plus 的適用場景

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

大資料輿情分析系統：

中安威士 ：保護核心資料，捍衛網路安全

來源：51CTO