?

導(dǎo)讀：大數(shù)據(jù)與現(xiàn)有的科技手段結(jié)合，對(duì)大多數(shù)產(chǎn)業(yè)而言都能產(chǎn)生巨大的經(jīng)濟(jì)及社會(huì)價(jià)值。這也是當(dāng)下許多企業(yè)，在大數(shù)據(jù)上深耕的原因。大數(shù)據(jù)分析場(chǎng)景需要解決哪些技術(shù)挑戰(zhàn)？目前，有哪些主流大數(shù)據(jù)架構(gòu)模式及其發(fā)展？今天，我們都會(huì)一一解讀，并介紹如何結(jié)合云上存儲(chǔ)、計(jì)算組件，實(shí)現(xiàn)更優(yōu)的通用大數(shù)據(jù)架構(gòu)模式，以及該模式可以涵蓋的典型數(shù)據(jù)處理場(chǎng)景。

?

大數(shù)據(jù)處理的挑戰(zhàn)

?

現(xiàn)在已經(jīng)有越來越多的行業(yè)和技術(shù)領(lǐng)域需求大數(shù)據(jù)分析系統(tǒng)，例如金融行業(yè)需要使用大數(shù)據(jù)系統(tǒng)結(jié)合 VaR(value at risk) 或者機(jī)器學(xué)習(xí)方案進(jìn)行信貸風(fēng)控，零售、餐飲行業(yè)需要大數(shù)據(jù)系統(tǒng)實(shí)現(xiàn)輔助銷售決策，各種 IOT 場(chǎng)景需要大數(shù)據(jù)系統(tǒng)持續(xù)聚合和分析時(shí)序數(shù)據(jù)，各大科技公司需要建立大數(shù)據(jù)分析中臺(tái)等等。

抽象來看，支撐這些場(chǎng)景需求的分析系統(tǒng)，面臨大致相同的技術(shù)挑戰(zhàn)：

?

• 業(yè)務(wù)分析的數(shù)據(jù)范圍橫跨實(shí)時(shí)數(shù)據(jù)和歷史數(shù)據(jù)，既需要低延遲的實(shí)時(shí)數(shù)據(jù)分析，也需要對(duì) PB ?級(jí)的歷史數(shù)據(jù)進(jìn)行探索性的數(shù)據(jù)分析；

• 可靠性和可擴(kuò)展性問題，用戶可能會(huì)存儲(chǔ)海量的歷史數(shù)據(jù)，同時(shí)數(shù)據(jù)規(guī)模有持續(xù)增長的趨勢(shì)，需要引入分布式存儲(chǔ)系統(tǒng)來滿足可靠性和可擴(kuò)展性需求，同時(shí)保證成本可控；

• 技術(shù)棧深，需要組合流式組件、存儲(chǔ)系統(tǒng)、計(jì)算組件和；

• 可運(yùn)維性要求高，復(fù)雜的大數(shù)據(jù)架構(gòu)難以維護(hù)和管控；

?

簡(jiǎn)述大數(shù)據(jù)架構(gòu)發(fā)展

?

Lambda 架構(gòu)

?

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

?

圖 1 Lambda架構(gòu)示例

?

Lambda架構(gòu)典型數(shù)據(jù)流程是(http://lambda-architecture.net/)：

?

所有的數(shù)據(jù)需要分別寫入批處理層和流處理層；

批處理層兩個(gè)職責(zé)：(i)管理 master dataset (存儲(chǔ)不可變、追加寫的全量數(shù)據(jù))，(ii)預(yù)計(jì)算batch view；

服務(wù)層對(duì) batch view 建立索引，以支持低延遲、ad-hoc 方式查詢 view；

流計(jì)算層作為速度層，對(duì)實(shí)時(shí)數(shù)據(jù)計(jì)算近似的 real-time view，作為高延遲batch view 的補(bǔ)償快速視圖；

所有的查詢需要合并 batch view 和 real-time view；

?

Lambda 架構(gòu)設(shè)計(jì)推廣了在不可變的事件流上生成視圖，并且可以在必要時(shí)重新處理事件的原則，該原則保證了系統(tǒng)隨需求演進(jìn)時(shí)，始終可以創(chuàng)建相應(yīng)的新視圖出來，切實(shí)可行地滿足了不斷變化的歷史數(shù)據(jù)和實(shí)時(shí)數(shù)據(jù)分析需求。

?

Lambda 架構(gòu)的四個(gè)挑戰(zhàn)

?

Lambda 架構(gòu)非常復(fù)雜，在數(shù)據(jù)寫入、存儲(chǔ)、對(duì)接計(jì)算組件以及展示層都有復(fù)雜的子課題需要優(yōu)化：

?

寫入層上，Lambda 沒有對(duì)數(shù)據(jù)寫入進(jìn)行抽象，而是將雙寫流批系統(tǒng)的一致性問題反推給了寫入數(shù)據(jù)的上層應(yīng)用；

存儲(chǔ)上，以 HDFS 為代表的master dataset 不支持?jǐn)?shù)據(jù)更新，持續(xù)更新的數(shù)據(jù)源只能以定期拷貝全量 snapshot 到 HDFS 的方式保持?jǐn)?shù)據(jù)更新，數(shù)據(jù)延遲和成本比較大；

計(jì)算邏輯需要分別在流批框架中實(shí)現(xiàn)和運(yùn)行，而在類似 Storm 的流計(jì)算框架和Hadoop MR 的批處理框架做 job 開發(fā)、調(diào)試、問題調(diào)查都是比較復(fù)雜的；

結(jié)果視圖需要支持低延遲的查詢分析，通常還需要將數(shù)據(jù)派生到列存分析系統(tǒng)，并保證成本可控。

流批融合的 Lambda 架構(gòu)

?

針對(duì) Lambda 架構(gòu)的問題3，計(jì)算邏輯需要分別在流批框架中實(shí)現(xiàn)和運(yùn)行的問題，不少計(jì)算引擎已經(jīng)開始往流批統(tǒng)一的方向去發(fā)展，例如 Spark 和 Flink，從而簡(jiǎn)化lambda 架構(gòu)中的計(jì)算部分。實(shí)現(xiàn)流批統(tǒng)一通常需要支持：

?

1.以相同的處理引擎來處理實(shí)時(shí)事件和歷史回放事件；

2.支持 exactly once 語義，保證有無故障情況下計(jì)算結(jié)果完全相同；

3.支持以事件發(fā)生時(shí)間而不是處理時(shí)間進(jìn)行窗口化。

?

Kappa架構(gòu)

?

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

?

圖2 Kappa大數(shù)據(jù)架構(gòu)

?

Kappa 方案通過精簡(jiǎn)鏈路解決了1數(shù)據(jù)寫入和3計(jì)算邏輯復(fù)雜的問題，但它依然沒有解決存儲(chǔ)和展示的問題，特別是在存儲(chǔ)上，使用類似 kafka 的消息隊(duì)列存儲(chǔ)長期日志數(shù)據(jù)，數(shù)據(jù)無法壓縮，存儲(chǔ)成本很大，繞過方案是使用支持?jǐn)?shù)據(jù)分層存儲(chǔ)的消息系統(tǒng)（如 Pulsar，支持將歷史消息存儲(chǔ)到云上存儲(chǔ)系統(tǒng)），但是分層存儲(chǔ)的歷史日志數(shù)據(jù)僅能用于 Kappa backfill 作業(yè)，數(shù)據(jù)的利用率依然很低。

?

Lambda 和 Kappa 的場(chǎng)景區(qū)別：

?

• Kappa 不是 Lambda 的替代架構(gòu)，而是其簡(jiǎn)化版本，Kappa 放棄了對(duì)批處理的支持，更擅長業(yè)務(wù)本身為 append-only 數(shù)據(jù)寫入場(chǎng)景的分析需求，例如各種時(shí)序數(shù)據(jù)場(chǎng)景，天然存在時(shí)間窗口的概念，流式計(jì)算直接滿足其實(shí)時(shí)計(jì)算和歷史補(bǔ)償任務(wù)需求；

• Lambda 直接支持批處理，因此更適合對(duì)歷史數(shù)據(jù)有很多 ad hoc 查詢的需求的場(chǎng)景，比如數(shù)據(jù)分析師需要按任意條件組合對(duì)歷史數(shù)據(jù)進(jìn)行探索性的分析，并且有一定的實(shí)時(shí)性需求，期望盡快得到分析結(jié)果，批處理可以更直接高效地滿足這些需求。

Kappa+

?

Kappa+是 Uber 提出流式數(shù)據(jù)處理架構(gòu)，它的核心思想是讓流計(jì)算框架直讀 HDFS類的數(shù)倉數(shù)據(jù)，一并實(shí)現(xiàn)實(shí)時(shí)計(jì)算和歷史數(shù)據(jù) backfill 計(jì)算，不需要為 backfill 作業(yè)長期保存日志或者把數(shù)據(jù)拷貝回消息隊(duì)列。Kappa+ 將數(shù)據(jù)任務(wù)分為無狀態(tài)任務(wù)和時(shí)間窗口任務(wù)，無狀態(tài)任務(wù)比較簡(jiǎn)單，根據(jù)吞吐速度合理并發(fā)掃描全量數(shù)據(jù)即可，時(shí)間窗口任務(wù)的原理是將數(shù)倉數(shù)據(jù)按照時(shí)間粒度進(jìn)行分區(qū)存儲(chǔ)，窗口任務(wù)按時(shí)間序一次計(jì)算一個(gè) partition 的數(shù)據(jù)，partition 內(nèi)亂序并發(fā)，所有分區(qū)文件全部讀取完畢后，所有 source 才進(jìn)入下個(gè) partition 消費(fèi)并更新 watermark。事實(shí)上，Uber 開發(fā)了Apache hudi 框架來存儲(chǔ)數(shù)倉數(shù)據(jù)，hudi 支持更新、刪除已有 parquet 數(shù)據(jù)，也支持增量消費(fèi)數(shù)據(jù)更新部分，從而系統(tǒng)性解決了問題2存儲(chǔ)的問題。下圖3是完整的Uber 大數(shù)據(jù)處理平臺(tái)，其中 Hadoop -> Spark -> Analytical data user 涵蓋了Kappa+ 數(shù)據(jù)處理架構(gòu)。

?

圖3 Uber圍繞Hadoop dataset的大數(shù)據(jù)架構(gòu)

?

混合分析系統(tǒng)的 Kappa 架構(gòu)

?

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

?

圖4 Kafka + Flink + ElasticSearch的混合分析系統(tǒng)

?

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

?

Lambda plus 是基于 Tablestore 和 Blink 打造的云上存在可以復(fù)用、簡(jiǎn)化的大數(shù)據(jù)架構(gòu)模式，架構(gòu)方案全 serverless 即開即用，易搭建免運(yùn)維。

表格存儲(chǔ)（Tablestore）是阿里云自研的 NoSQL 多模型數(shù)據(jù)庫，提供 PB 級(jí)結(jié)構(gòu)化數(shù)據(jù)存儲(chǔ)、千萬 TPS 以及毫秒級(jí)延遲的服務(wù)能力，表格存儲(chǔ)提供了通道服務(wù)（TunnelService）支持用戶以按序、流式地方式消費(fèi)寫入表格存儲(chǔ)的存量數(shù)據(jù)和實(shí)時(shí)數(shù)據(jù)，同時(shí)表格存儲(chǔ)還提供了多元索引功能，支持用戶對(duì)結(jié)果視圖進(jìn)行實(shí)時(shí)查詢和分析。

Blink 是阿里云在 Apache Flink 基礎(chǔ)上深度改進(jìn)的實(shí)時(shí)計(jì)算平臺(tái)，Blink 旨在將流處理和批處理統(tǒng)一，實(shí)現(xiàn)了全新的 Flink SQL 技術(shù)棧，在功能上，Blink 支持現(xiàn)在標(biāo)準(zhǔn) SQL 幾乎所有的語法和語義，在性能上，Blink 也比社區(qū)Flink更加強(qiáng)大。

在 TableStore + Blink 的云上 Lambda 架構(gòu)中，用戶可以同時(shí)使用表格存儲(chǔ)作為master dataset 和 batch&stream view，批處理引擎直讀表格存儲(chǔ)產(chǎn)生 batch view，同時(shí)流計(jì)算引擎通過 Tunnel Service 流式處理實(shí)時(shí)數(shù)據(jù)，持續(xù)生成 stream view。

?

圖5 Tablestore + Blink 的 Lambda plus 大數(shù)據(jù)架構(gòu)

?

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

?

• Tablestore 直接作為 master dataset，支持用戶直讀，配合 Tablestore 多元索引，用戶的線上服務(wù)直讀、ad-hoc 查詢 master dataset 并將結(jié)果返回給用戶；Blink 批處理任務(wù)向 Tablestore 下推 SQL 的查詢條件，直讀 Tablestore master dataset，計(jì)算 batch view，并將 batch view 重新寫回 Tablestore；

• Blink 流處理任務(wù)通過表格存儲(chǔ) TunnelService API 直讀 master dataset 中的實(shí)時(shí)數(shù)據(jù)，持續(xù)產(chǎn)生 stream view；Kappa 架構(gòu)的 backfill任務(wù)，可以通過建立全量類型數(shù)據(jù)通道，流式消費(fèi) master dataset 的存量數(shù)據(jù)，從新計(jì)算；

• 為存儲(chǔ) batch view 和 stream view 的 Tablestore 結(jié)果表建立全局二級(jí)索引和多元索引，業(yè)務(wù)可以低延遲、ad-hoc方式查詢；

• Lambda batch 層：

• Streaming 層：

• Serving 層：

?

圖6 Lambda plus的數(shù)據(jù)鏈路

?

針對(duì)上述 Lambda 架構(gòu)1-4的技術(shù)問題，Lambda plus 的解決思路：

?

針對(duì)數(shù)據(jù)寫入的問題，Lambda plus 數(shù)據(jù)只需要寫入表格存儲(chǔ)，Blink 流計(jì)算框架通過通道服務(wù) API 直讀表格存儲(chǔ)的實(shí)時(shí)數(shù)據(jù)，不需要用戶雙寫隊(duì)列或者自己實(shí)現(xiàn)數(shù)據(jù)同步；

存儲(chǔ)上，Lambda plus 直接使用表格存儲(chǔ)作為 master dataset，表格存儲(chǔ)支持用戶 tp 系統(tǒng)低延遲讀寫更新，同時(shí)也提供了索引功能 ad-hoc 查詢分析，數(shù)據(jù)利用率高，容量型表格存儲(chǔ)實(shí)例也可以保證數(shù)據(jù)存儲(chǔ)成本可控；

計(jì)算上，Lambda plus 利用 Blink 流批一體計(jì)算引擎，統(tǒng)一流批代碼；

展示層，表格存儲(chǔ)提供了多元索引和全局二級(jí)索引功能，用戶可以根據(jù)解決視圖的查詢需求和存儲(chǔ)體量，合理選擇索引方式。

?

總結(jié)，表格存儲(chǔ)實(shí)現(xiàn)了 batch view、master dataset 直接查詢、stream view 的功能全集，Blink 實(shí)現(xiàn)流批統(tǒng)一，Tablestore 加 Blink 的 Lambda plus 模式可以明顯簡(jiǎn)化 Lambda 架構(gòu)的組件數(shù)量，降低搭建和運(yùn)維難度，拓展用戶數(shù)據(jù)價(jià)值。

?

表格存儲(chǔ)是如何實(shí)現(xiàn)支持上述功能全集的

?

存儲(chǔ)引擎的高并發(fā)、低延遲特性：表格存儲(chǔ)面向在線業(yè)務(wù)提供高并發(fā)、低延遲的訪問，并且 tps 按分區(qū)水平擴(kuò)展，可以有效支持批處理和 Kappa backfill 的高吞吐數(shù)據(jù)掃描和流計(jì)算按分區(qū)粒度并發(fā)實(shí)時(shí)處理；

?

使用通道服務(wù)精簡(jiǎn)架構(gòu)：Tablestore 數(shù)據(jù)通道支持用戶以按序、流式地方式消費(fèi)寫入表格存儲(chǔ)的存量數(shù)據(jù)和實(shí)時(shí)數(shù)據(jù)，避免 Lambda 架構(gòu)引入消息隊(duì)列系統(tǒng)以及master dataset 和隊(duì)列的數(shù)據(jù)一致性問題；

?

二級(jí)索引和多元索引的靈活查詢能力：存儲(chǔ)在表格存儲(chǔ)的 batch view 和 real-time view 可以使用多元索引和二級(jí)索引實(shí)現(xiàn) ad-hoc 查詢，使用多元索引進(jìn)行聚合分析計(jì)算；同時(shí)展示層也可以利用二級(jí)索引和多元索引直接查詢表格存儲(chǔ) master dataset，不強(qiáng)依賴引擎計(jì)算結(jié)果。

?

Lambda plus 的適用場(chǎng)景

?

基于 Tablestore 和 Blink 的 Lambda plus 架構(gòu)，適用于基于分布式 NoSQL 數(shù)據(jù)庫存儲(chǔ)數(shù)據(jù)的大數(shù)據(jù)分析場(chǎng)景，如 IOT、時(shí)序數(shù)據(jù)、爬蟲數(shù)據(jù)、用戶行為日志數(shù)據(jù)存儲(chǔ)等，數(shù)據(jù)量以 TB 級(jí)為主。典型的業(yè)務(wù)場(chǎng)景如：

?

大數(shù)據(jù)輿情分析系統(tǒng)：

?

?

參考資料

[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

摘自 ：阿里技術(shù)

超強(qiáng)干貨來襲 云風(fēng)專訪：近40年碼齡，通宵達(dá)旦的技術(shù)人生

總結(jié)

以上是生活随笔為你收集整理的大数据架构如何做到流批一体？【对于Flink等流批一体的概念做了很好的澄清!】的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。