流批一體架構(gòu)的必要性 | 滴普科技FastData系列解讀

上篇文章講解了大數(shù)據(jù)流處理架構(gòu)的技術(shù)迭代與演變歷程，重點(diǎn)提到Lambda架構(gòu)。但此架構(gòu)相當(dāng)復(fù)雜，整體存在三大特點(diǎn)：其一，流處理（speed）和批（batch）處理兩套代碼；其二，batch 與 speed存在計(jì)算結(jié)果不一致的情況；其三，兩套技術(shù)棧，增加運(yùn)維工作量。而Kappa架構(gòu)則可以很好地解決Lambda存在的問(wèn)題，實(shí)現(xiàn)了技術(shù)棧以及業(yè)務(wù)代碼的統(tǒng)一，但也帶來(lái)一些新問(wèn)題。

1. Kappa架構(gòu)面臨的新問(wèn)題

1.1數(shù)據(jù)重處理（re-processing data)

比較常見(jiàn)的情況是，處理算法或者Schema發(fā)生了變化，或者修了一個(gè)bug，這種情況下都需要把新版本的作業(yè)重新跑一遍，以獲得正確的結(jié)果。若只是重跑幾天的數(shù)據(jù)，也不是個(gè)大問(wèn)題。但如果需要重新運(yùn)行一年的數(shù)據(jù)，問(wèn)題就會(huì)變得復(fù)雜起來(lái)。

1.2數(shù)據(jù)亂序

這一問(wèn)題在移動(dòng)App和IoT場(chǎng)景中常見(jiàn)，主要原因是網(wǎng)絡(luò)延遲或者中斷導(dǎo)致數(shù)據(jù)被延遲送達(dá)。如何處理這些遲到的數(shù)據(jù)，是Kappa架構(gòu)要解決的問(wèn)題。

1.3計(jì)算成本增加

流式計(jì)算相比批計(jì)算，雖然開(kāi)發(fā)、維護(hù)成本和存儲(chǔ)成本降低了，但是可能會(huì)占用更多的計(jì)算資源，導(dǎo)致計(jì)算成本的增加。

1.4 難以支持復(fù)雜join

少量的join操作通常不會(huì)產(chǎn)生問(wèn)題，但如果join的維度表數(shù)量增加到幾十個(gè)的時(shí)候，使用Kappa就會(huì)讓開(kāi)發(fā)變得異常復(fù)雜。

總體上來(lái)說(shuō)，Kappa架構(gòu)也不是銀彈，無(wú)法粗野照搬，必須重新思考業(yè)務(wù)數(shù)據(jù)邏輯，結(jié)合周邊技術(shù)架構(gòu)等實(shí)際情況來(lái)分析和解決Kappa帶來(lái)的新問(wèn)題。

2. Kappa架構(gòu)新問(wèn)題的解決辦法

結(jié)合上節(jié)Kappa架構(gòu)的問(wèn)題，可以從架構(gòu)內(nèi)部、外部?jī)蓚€(gè)方面分析和解決問(wèn)題。Kappa架構(gòu)的核心特征是事件驅(qū)動(dòng)與實(shí)時(shí)，盡管周邊模塊會(huì)采用更適合自己的批處理模式或者其他編程模式去處理這些事件，并不一定強(qiáng)求使用流式處理。

在Kappa架構(gòu)實(shí)踐中，通常使用Apache Kafka作為核心部件實(shí)現(xiàn)。接下來(lái)，可以看一下Kafka社區(qū)如何解決這些問(wèn)題的：

2.1 數(shù)據(jù)保留（retention）：Compacted Topics, Tiered Storage

為解決數(shù)據(jù)重處理問(wèn)題，Kafka需要支持時(shí)間跨度長(zhǎng)的歷史事件的回放，其實(shí)就是log的存儲(chǔ)問(wèn)題。目前，社區(qū)有Topic合并方案（Compacted Topics）和Tiered Storage方案。其中，Tiered Storage被認(rèn)為是顛覆性的，可惜離發(fā)布還有一段時(shí)間，大家可參考KIP-405

2.2 數(shù)據(jù)一致性和可靠性: Exactly-once semantics

流處理引擎需要支持精確一次（Exactly-once）語(yǔ)義保證數(shù)據(jù)最終一致，同時(shí)在集群可控性上，需要支持跨數(shù)據(jù)中心的集群管理與數(shù)據(jù)同步。

2.3 處理遲到（late-arriving）數(shù)據(jù)

流處理引擎（Kafka官方提供了confluent流處理方案）需要完善的狀態(tài)管理以及配套的Sink，包括重新加載和重放事件的能力。當(dāng)然，除了Kafka配套的流處理引擎，其他引擎也可以與Kafka一起使用，如Apache Flink。

2.4 數(shù)據(jù)重處理（backfill）

數(shù)據(jù)重處理對(duì)Kafka集群的計(jì)算資源的要求是很高的，靈活的資源管理與調(diào)度系統(tǒng)是很有必要的。

2.5 Kappa架構(gòu)的擴(kuò)展模塊

Kappa架構(gòu)是以流式處理為基礎(chǔ)的，但也不意味著靠一個(gè)流處理平臺(tái)就能包打天下，還需要其他工具或數(shù)據(jù)庫(kù)的配合，以共同解決相關(guān)的問(wèn)題。使用合適的工具干合適的事情。例如，復(fù)雜SQL需要其他SQL引擎甚至數(shù)據(jù)庫(kù)處理。特別是由于Kafka集群管理功能現(xiàn)有的限制，更需要其他工具來(lái)配合完成。

到目前為止，我們簡(jiǎn)單描述了Kappa架構(gòu)“內(nèi)核”需要具備的能力，以及Kafka作為內(nèi)核之一要解決的問(wèn)題及技術(shù)方案。

擴(kuò)展模塊包括應(yīng)用、數(shù)據(jù)存儲(chǔ)以及分析平臺(tái)：

• 數(shù)據(jù)消費(fèi)組件: 從流處理平臺(tái)消費(fèi)數(shù)據(jù)，需要支持不同類型的消費(fèi)速率，實(shí)時(shí)、近實(shí)時(shí)和批量。
• 存儲(chǔ)組件: 內(nèi)置或者通過(guò)社區(qū)提供不同的存儲(chǔ)組件（內(nèi)存數(shù)據(jù)庫(kù)、關(guān)系數(shù)據(jù)庫(kù)、NoSQL等）Sink連接器，并且根據(jù)業(yè)務(wù)要求，需要支持流式接口（changelog）或者批量接口。
• 數(shù)據(jù)處理: Kappa流處理平臺(tái)需要支持各種流應(yīng)用，需要指出的是，對(duì)于計(jì)算資源要求特別多的工作負(fù)載，可能還是需要求助批處理引擎。Flink提供流式處理和批處理兩種模式，可以滿足不同工作負(fù)載的需要。

基于與多個(gè)同行的交流，實(shí)時(shí)流式普遍有需求，而且認(rèn)為Kappa架構(gòu)在架構(gòu)上優(yōu)于Lambda架構(gòu)。然而，實(shí)踐中部署Kappa架構(gòu)在國(guó)內(nèi)還是比較少。

造成這種叫好不叫座的局面，這里存在技術(shù)推廣周期的因素，但也有技術(shù)問(wèn)題未解決，有兩個(gè)原因：其一，在缺少長(zhǎng)遠(yuǎn)規(guī)劃的前提下，在批處理基礎(chǔ)上加上流處理的應(yīng)用快速推出流式應(yīng)用，這是比較保險(xiǎn)的做法；其二，Kafka在這個(gè)解決方案中也存在相關(guān)未解決的問(wèn)題。

3. Kappa架構(gòu)的擴(kuò)展性與成本

本文接下來(lái)的篇幅就著重描述它的幾個(gè)重要問(wèn)題，以及我們的一些觀點(diǎn)。

3.1 擴(kuò)展性與成本問(wèn)題

將大規(guī)模的數(shù)據(jù)保存到Kafka中是有很大問(wèn)題的，在PB級(jí)的時(shí)候存在成本與可擴(kuò)展性問(wèn)題：

在存儲(chǔ)成本方面，與數(shù)據(jù)湖方案或者私有化環(huán)境上的HDFS都差很多，特別是在公有云上，云服務(wù)提供商（例如AWS S3，阿里OSS）提供的對(duì)象存儲(chǔ)方案成本優(yōu)勢(shì)非常明顯，估計(jì)成本相差5倍以上；

Kafka在存儲(chǔ)擴(kuò)展方面也是非常繁瑣，這里的技術(shù)原因是當(dāng)前版本的存儲(chǔ)與計(jì)算是耦合的。

上文提到過(guò)采用Topic Compaction的方法壓縮數(shù)據(jù)，從而減少存儲(chǔ)空間。但此方法限制比較大，且在擴(kuò)展能力方面無(wú)法滿足要求，因?yàn)榇蟛糠秩讼Ｍ氖莍nstant elastic能力，現(xiàn)有的擴(kuò)容機(jī)制在數(shù)據(jù)量大的時(shí)候需要等待很長(zhǎng)時(shí)間，這個(gè)期間系統(tǒng)可能無(wú)法提供服務(wù)，流計(jì)算對(duì)此通常是無(wú)法容忍的。

為了徹底解決上述問(wèn)題，Kafka社區(qū)也在抓緊開(kāi)發(fā)Tiered Storage特性。Tiered Storage采用存儲(chǔ)與計(jì)算分離的架構(gòu)，社區(qū)對(duì)這個(gè)特性非常期待。需要指出的是，Kafka的競(jìng)品Pulsar已經(jīng)實(shí)現(xiàn)了存算分離，但為什么Kappa架構(gòu)沒(méi)有真正流行起來(lái)呢？也許還有其他原因。

3.2 需要更多計(jì)算資源

這個(gè)問(wèn)題的本質(zhì)是流式計(jì)算引起的，也是為“實(shí)時(shí)”付出的代價(jià)。然而，在企業(yè)中并不是所有的業(yè)務(wù)都是需要實(shí)時(shí)處理的。

合適的工具干合適的活，下面這個(gè)圖來(lái)自Uber，該方案把Kappa的使用局限在數(shù)據(jù)集成部分，這在一定程度上解決了計(jì)算資源的問(wèn)題，同時(shí)也是一種架構(gòu)演進(jìn)的思路。

雖然業(yè)界也在解決Kappa架構(gòu)中Kafka固有的一些問(wèn)題，但在實(shí)踐中，大部分人把Kappa的實(shí)現(xiàn)局限在數(shù)據(jù)集成這一環(huán)節(jié)的。導(dǎo)致這一結(jié)果的原因就是所謂天下沒(méi)有免費(fèi)的午餐，所有環(huán)節(jié)使用流處理是不切實(shí)際的，畢竟流式計(jì)算需要的計(jì)算資源會(huì)比較多。

因此，使用流批一體的計(jì)算引擎綜合兩種不同業(yè)務(wù)需求，是比較自然的做法。滴普科技構(gòu)建的一站式云原生數(shù)據(jù)智能平臺(tái)Fastdata，在流批一體相關(guān)功能特性上已經(jīng)做了嘗試，關(guān)于流批一體的具體方案我們?cè)诤罄m(xù)的文章中展現(xiàn)給大家。