目錄

01 事件驅(qū)動(dòng)型應(yīng)用

02 數(shù)據(jù)分析型應(yīng)用

03 數(shù)據(jù)管道型應(yīng)用

Flink的應(yīng)用場(chǎng)景十分廣泛，下面介紹3種常見的應(yīng)用。

01 事件驅(qū)動(dòng)型應(yīng)用

在許多場(chǎng)景中，需要處理的數(shù)據(jù)往往來(lái)自事件。小到一些交互式的用戶行為，大到一些復(fù)雜的業(yè)務(wù)操作，它們都會(huì)被轉(zhuǎn)化成一條條數(shù)據(jù)，進(jìn)而形成數(shù)據(jù)流（事件流）。事件驅(qū)動(dòng)型應(yīng)用的特點(diǎn)在于，一些事件會(huì)觸發(fā)特定的計(jì)算或其他外部行為，其典型場(chǎng)景有異常檢測(cè)、反欺詐等。

在傳統(tǒng)架構(gòu)下，數(shù)據(jù)流通常會(huì)流入數(shù)據(jù)庫(kù)，隨后應(yīng)用系統(tǒng)讀取數(shù)據(jù)庫(kù)中的數(shù)據(jù)，根據(jù)數(shù)據(jù)觸發(fā)計(jì)算。在這種架構(gòu)下，數(shù)據(jù)和計(jì)算分離，而且在存取數(shù)據(jù)時(shí)需要進(jìn)行遠(yuǎn)程訪問(wèn)。與傳統(tǒng)架構(gòu)不同，F(xiàn)link利用有狀態(tài)的數(shù)據(jù)流來(lái)完成整個(gè)過(guò)程的處理，無(wú)須將數(shù)據(jù)先存入數(shù)據(jù)庫(kù)再讀取出來(lái)。數(shù)據(jù)流的狀態(tài)數(shù)據(jù)在本地(local)維護(hù)，并且會(huì)周期性地持久化以實(shí)現(xiàn)容錯(cuò)。下圖展示了傳統(tǒng)事務(wù)型應(yīng)用架構(gòu)與Flink事件驅(qū)動(dòng)型應(yīng)用架構(gòu)的區(qū)別。

傳統(tǒng)事務(wù)型應(yīng)用架構(gòu)與Flink事件驅(qū)動(dòng)型應(yīng)用架構(gòu)的區(qū)別

Flink事件驅(qū)動(dòng)型應(yīng)用架構(gòu)的優(yōu)勢(shì)在于，它的狀態(tài)數(shù)據(jù)在本地維護(hù)，不需要遠(yuǎn)程訪問(wèn)數(shù)據(jù)庫(kù)，由此獲得了更低的延遲、更高的吞吐量。同時(shí)，不像傳統(tǒng)架構(gòu)那樣多個(gè)應(yīng)用共享同一個(gè)數(shù)據(jù)庫(kù)，任何對(duì)數(shù)據(jù)庫(kù)的修改都需要謹(jǐn)慎協(xié)調(diào)，F(xiàn)link事件驅(qū)動(dòng)型應(yīng)用架構(gòu)中的每一個(gè)應(yīng)用都獨(dú)立地維護(hù)狀態(tài)，可以靈活地進(jìn)行擴(kuò)/縮容。

從上面的介紹可以了解到，實(shí)現(xiàn)事件驅(qū)動(dòng)型應(yīng)用的關(guān)鍵在于支持“有狀態(tài)的數(shù)據(jù)流”及容錯(cuò)機(jī)制。這是Flink最優(yōu)秀的設(shè)計(jì)之一。這部分內(nèi)容會(huì)在后文詳細(xì)分析。

02 數(shù)據(jù)分析型應(yīng)用

從歷史發(fā)展的角度來(lái)看，企業(yè)要處理的數(shù)據(jù)量是由小到大變化的，因此不妨從傳統(tǒng)企業(yè)的角度來(lái)看待數(shù)據(jù)分析型應(yīng)用的演變。

過(guò)去，傳統(tǒng)企業(yè)的數(shù)據(jù)分析型應(yīng)用往往就是商務(wù)智能(business intelligence, BI)系統(tǒng)。一個(gè)成熟的BI產(chǎn)品是一套集數(shù)據(jù)清洗、數(shù)據(jù)分析、數(shù)據(jù)挖掘、報(bào)表展示等功能于一體的完整解決方案。不過(guò)，當(dāng)數(shù)據(jù)量過(guò)大時(shí)傳統(tǒng)的BI系統(tǒng)會(huì)出現(xiàn)性能瓶頸，而且它的底層是基于關(guān)系數(shù)據(jù)庫(kù)的，處理非結(jié)構(gòu)化數(shù)據(jù)時(shí)會(huì)十分乏力。因此，當(dāng)今企業(yè)在進(jìn)行技術(shù)選型和架構(gòu)設(shè)計(jì)時(shí)，更傾向于選擇Hadoop生態(tài)系統(tǒng)組件及其相關(guān)架構(gòu)。

早期大數(shù)據(jù)場(chǎng)景下的數(shù)據(jù)分析型應(yīng)用架構(gòu)如圖所示。

早期大數(shù)據(jù)場(chǎng)景下的數(shù)據(jù)分析型應(yīng)用架構(gòu)

上圖充分體現(xiàn)了數(shù)據(jù)分析型應(yīng)用的核心設(shè)計(jì)思想，即業(yè)務(wù)系統(tǒng)與分析系統(tǒng)分離。業(yè)務(wù)系統(tǒng)的數(shù)據(jù)周期性地轉(zhuǎn)換并加載到數(shù)據(jù)倉(cāng)庫(kù)中，在數(shù)據(jù)倉(cāng)庫(kù)內(nèi)部經(jīng)過(guò)分層處理，最終標(biāo)準(zhǔn)化的數(shù)據(jù)被提供給其他應(yīng)用使用。這種架構(gòu)與BI系統(tǒng)的主要區(qū)別就是整個(gè)流程不再有完整的解決方案，而需要技術(shù)人員自己選擇工具進(jìn)行開發(fā)和組合。

流式架構(gòu)

從傳統(tǒng)的BI系統(tǒng)到早期大數(shù)據(jù)場(chǎng)景下的數(shù)據(jù)分析型應(yīng)用架構(gòu)，始終存在著一個(gè)問(wèn)題，那就是整個(gè)過(guò)程中所有的抽取、轉(zhuǎn)換、加載(Extract-Transform-Load, ETL)邏輯都是離線進(jìn)行的，導(dǎo)致整個(gè)分析流程具有較高的延遲。由此，流式架構(gòu)便應(yīng)運(yùn)而生。

流式架構(gòu)的目的是在不丟失數(shù)據(jù)的前提下保證整個(gè)分析流程的低延遲，如上圖圖所示。

上圖所示的整個(gè)流程少了ETL，直接將數(shù)據(jù)攝入流處理引擎，經(jīng)過(guò)業(yè)務(wù)處理后輸出給其他應(yīng)用使用。在早期的技術(shù)儲(chǔ)備條件下，想要保證低延遲，通常就難以保證結(jié)果的準(zhǔn)確性，因此流式架構(gòu)僅適用于那些對(duì)數(shù)據(jù)準(zhǔn)確性要求不高，而對(duì)數(shù)據(jù)實(shí)時(shí)性要求極高的場(chǎng)景。

那么，在早期的技術(shù)儲(chǔ)備條件下，能否通過(guò)架構(gòu)的演進(jìn)，既保證數(shù)據(jù)的實(shí)時(shí)性，又兼顧數(shù)據(jù)的準(zhǔn)確性呢？開源框架Storm的創(chuàng)始人Nathan Marz提出了Lambda架構(gòu)，有效地解決了這一問(wèn)題。

Lambda架構(gòu)的核心思想是實(shí)時(shí)處理和離線處理共存，實(shí)時(shí)處理如流處理一般保證數(shù)據(jù)的實(shí)時(shí)性，離線處理通過(guò)周期性地合并數(shù)據(jù)來(lái)保證數(shù)據(jù)的最終一致性。Lambda架構(gòu)如圖所示。

Lambda架構(gòu)

在Lambda架構(gòu)下，批處理層將準(zhǔn)確結(jié)果寫入批處理表，流處理層則將數(shù)據(jù)實(shí)時(shí)地寫入速度表，批處理表的結(jié)果會(huì)定期與速度表中的數(shù)據(jù)合并以保證其準(zhǔn)確性。數(shù)據(jù)應(yīng)用則根據(jù)需求進(jìn)行查詢。

顯而易見，雖然Lambda架構(gòu)在一定程度上同時(shí)保證了數(shù)據(jù)的準(zhǔn)確性與實(shí)時(shí)性，但它需要開發(fā)和維護(hù)兩套系統(tǒng)，這實(shí)在是一筆不小的開銷。由此，Kafka的核心成員之一Jay Kreps在Lambda架構(gòu)的基礎(chǔ)上提出了Kappa架構(gòu)，解決了“兩套代碼實(shí)現(xiàn)一套業(yè)務(wù)邏輯”的問(wèn)題。Kappa架構(gòu)舍棄了批處理層，只保留了流處理層。與流式架構(gòu)不同的是，Kappa架構(gòu)需要讓業(yè)務(wù)數(shù)據(jù)先進(jìn)入支持?jǐn)?shù)據(jù)重播的消息隊(duì)列（如Kafka）。如果數(shù)據(jù)出現(xiàn)錯(cuò)誤，那么再執(zhí)行一個(gè)流處理作業(yè)，以對(duì)歷史數(shù)據(jù)進(jìn)行重新計(jì)算。當(dāng)新啟動(dòng)的作業(yè)消費(fèi)到最新的數(shù)據(jù)時(shí)，讓外部應(yīng)用訪問(wèn)新的服務(wù)數(shù)據(jù)庫(kù)，完成服務(wù)的切換。Kappa架構(gòu)如圖所示。

Kappa架構(gòu)

Kappa架構(gòu)雖然不需要開發(fā)兩套代碼，但是仍然需要維護(hù)兩套環(huán)境。而且，它所能處理的歷史數(shù)據(jù)會(huì)受到消息隊(duì)列存儲(chǔ)策略的限制。

從Lambda架構(gòu)和Kappa架構(gòu)的提出者的技術(shù)背景可以了解到，他們提出的架構(gòu)方案都是以他們熟悉的組件特性為基礎(chǔ)的。Storm無(wú)法很好地保證數(shù)據(jù)的準(zhǔn)確性，因此需要利用批處理層來(lái)保證數(shù)據(jù)的最終一致性。Kafka支持?jǐn)?shù)據(jù)重播，因此可以只開發(fā)流處理層，在必要的時(shí)候?qū)?shù)據(jù)進(jìn)行重播，從而保證數(shù)據(jù)的準(zhǔn)確性。

Kappa架構(gòu)之所以需要在兩套環(huán)境中來(lái)回切換，主要是因?yàn)檫^(guò)去的流處理引擎無(wú)法保證數(shù)據(jù)的準(zhǔn)確性，所以需要頻繁地重新計(jì)算。如果流處理引擎能夠像批處理引擎一樣保證端到端的數(shù)據(jù)的最終一致性，從理論上來(lái)說(shuō)就意味著一套環(huán)境可以解決所有問(wèn)題。Flink完美地解決了這一問(wèn)題。

以Flink作為流處理引擎，其架構(gòu)如圖所示。

link流式分析架構(gòu)

Flink內(nèi)部維護(hù)了數(shù)據(jù)流的狀態(tài)，并以容錯(cuò)機(jī)制、窗口機(jī)制等特性作為支持，可以保證精確地實(shí)現(xiàn)端到端的數(shù)據(jù)的最終一致性。同時(shí)，F(xiàn)link提供了從SQL到底層API的多層接口，使分析工作變得十分容易。因?yàn)镕link本身也能夠進(jìn)行批處理，所以Flink流式分析架構(gòu)可以很容易地被轉(zhuǎn)換成批處理架構(gòu)。

對(duì)Kappa架構(gòu)來(lái)說(shuō)，可以直接選用Flink作為其中的流處理引擎，但此時(shí)設(shè)計(jì)兩套環(huán)境的主要目的不再是保證數(shù)據(jù)的準(zhǔn)確性，而是當(dāng)Flink業(yè)務(wù)代碼發(fā)生變動(dòng)時(shí)可以執(zhí)行新的作業(yè)，待數(shù)據(jù)消費(fèi)到相同位置時(shí)及時(shí)完成服務(wù)的切換。

03 數(shù)據(jù)管道型應(yīng)用

數(shù)據(jù)管道型應(yīng)用也常常作為傳統(tǒng)ETL流程的替代流程，與傳統(tǒng)的ETL流程相比，其優(yōu)勢(shì)在于實(shí)時(shí)性高。Flink以流式的方式處理數(shù)據(jù)，無(wú)須像傳統(tǒng)ETL流程一樣進(jìn)行周期性的離線處理。數(shù)據(jù)分析型應(yīng)用實(shí)際上包含數(shù)據(jù)管道型應(yīng)用，與數(shù)據(jù)分析型應(yīng)用不同的是，數(shù)據(jù)管道型應(yīng)用的側(cè)重點(diǎn)在于數(shù)據(jù)的流轉(zhuǎn)。在數(shù)據(jù)管道型應(yīng)用中，數(shù)據(jù)可能僅僅是從一個(gè)消息隊(duì)列流轉(zhuǎn)到另一個(gè)消息隊(duì)列。文章來(lái)源地址http://www.zghlxwxcb.cn/news/detail-795584.html

到了這里，關(guān)于Flink 內(nèi)容分享(二十)：這三種場(chǎng)景，建議使用Flink的文章就介紹完了。如果您還想了解更多內(nèi)容，請(qǐng)?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！