本篇內(nèi)容主要講解“Flink數(shù)據(jù)架構(gòu)的演變是怎樣的”，感興趣的朋友不妨來看看。本文介紹的方法操作簡單快捷，實(shí)用性強(qiáng)。下面就讓小編來帶大家學(xué)習(xí)“Flink數(shù)據(jù)架構(gòu)的演變是怎樣的”吧!

為南丹等地區(qū)用戶提供了全套網(wǎng)頁設(shè)計(jì)制作服務(wù)，及南丹網(wǎng)站建設(shè)行業(yè)解決方案。主營業(yè)務(wù)為網(wǎng)站設(shè)計(jì)制作、成都網(wǎng)站制作、南丹網(wǎng)站設(shè)計(jì)，以傳統(tǒng)方式定制建設(shè)網(wǎng)站，并提供域名空間備案等一條龍服務(wù)，秉承以專業(yè)、用心的態(tài)度為用戶提供真誠的服務(wù)。我們深信只要達(dá)到每一位用戶的要求，就會(huì)得到認(rèn)可，從而選擇與我們長期合作。這樣，我們也可以走得更遠(yuǎn)！

01 傳統(tǒng)數(shù)據(jù)基礎(chǔ)架構(gòu)

如圖1-1所示，傳統(tǒng)單體數(shù)據(jù)架構(gòu)(Monolithic  Architecture)最大的特點(diǎn)便是集中式數(shù)據(jù)存儲(chǔ)，企業(yè)內(nèi)部可能有諸多的系統(tǒng)，例如Web業(yè)務(wù)系統(tǒng)、訂單系統(tǒng)、CRM系統(tǒng)、ERP系統(tǒng)、監(jiān)控系統(tǒng)等，這些系統(tǒng)的事務(wù)性數(shù)據(jù)主要基于集中式的關(guān)系性數(shù)據(jù)庫(DBMS)實(shí)現(xiàn)存儲(chǔ)，大多數(shù)將架構(gòu)分為計(jì)算層和存儲(chǔ)層。

存儲(chǔ)層負(fù)責(zé)企業(yè)內(nèi)系統(tǒng)的數(shù)據(jù)訪問，且具有最終數(shù)據(jù)一致性保障。這些數(shù)據(jù)反映了當(dāng)前的業(yè)務(wù)狀態(tài)，例如系統(tǒng)的訂單交易量、網(wǎng)站的活躍用戶數(shù)、每個(gè)用戶的交易額變化等，所有的更新操作均需要借助于同一套數(shù)據(jù)庫實(shí)現(xiàn)。

▲圖1-1 傳統(tǒng)數(shù)據(jù)結(jié)構(gòu)

單體架構(gòu)的初期效率很高，但是隨著時(shí)間的推移，業(yè)務(wù)越來越多，系統(tǒng)逐漸變得很大，越來越難以維護(hù)和升級(jí)，數(shù)據(jù)庫是唯一的準(zhǔn)確數(shù)據(jù)源，每個(gè)應(yīng)用都需要訪問數(shù)據(jù)庫來獲取對(duì)應(yīng)的數(shù)據(jù)，如果數(shù)據(jù)庫發(fā)生改變或者出現(xiàn)問題，則將對(duì)整個(gè)業(yè)務(wù)系統(tǒng)產(chǎn)生影響。

后來隨著微服務(wù)架構(gòu)(Microservices  Architecture)的出現(xiàn)，企業(yè)開始逐漸采用微服務(wù)作為企業(yè)業(yè)務(wù)系統(tǒng)的架構(gòu)體系。微服務(wù)架構(gòu)的核心思想是，一個(gè)應(yīng)用是由多個(gè)小的、相互獨(dú)立的微服務(wù)組成，這些服務(wù)運(yùn)行在自己的進(jìn)程中，開發(fā)和發(fā)布都沒有依賴。不同的服務(wù)能依據(jù)不同的業(yè)務(wù)需求，構(gòu)建的不同的技術(shù)架構(gòu)之上，能夠聚焦在有限的業(yè)務(wù)功能。

▲圖1-2 微服務(wù)架構(gòu)

如圖1-2所示，微服務(wù)架構(gòu)將系統(tǒng)拆解成不同的獨(dú)立服務(wù)模塊，每個(gè)模塊分別使用各自獨(dú)立的數(shù)據(jù)庫，這種模式解決了業(yè)務(wù)系統(tǒng)拓展的問題，但是也帶來了新的問題，那就是業(yè)務(wù)交易數(shù)據(jù)過于分散在不同的系統(tǒng)中，很難將數(shù)據(jù)進(jìn)行集中化管理。

對(duì)于企業(yè)內(nèi)部進(jìn)行數(shù)據(jù)分析或者數(shù)據(jù)挖掘之類的應(yīng)用，則需要通過從不同的數(shù)據(jù)庫中進(jìn)行數(shù)據(jù)抽取，將數(shù)據(jù)從數(shù)據(jù)庫中周期性地同步到數(shù)據(jù)倉庫中，然后在數(shù)據(jù)倉庫中進(jìn)行數(shù)據(jù)的抽取、轉(zhuǎn)換、加載(ETL)，從而構(gòu)建成不同的數(shù)據(jù)集市和應(yīng)用，提供給業(yè)務(wù)系統(tǒng)使用。

02 大數(shù)據(jù)數(shù)據(jù)架構(gòu)

起初數(shù)據(jù)倉庫主要還是構(gòu)建在關(guān)系型數(shù)據(jù)庫之上，例如Oracle、MySQL等數(shù)據(jù)庫，但是隨著企業(yè)數(shù)據(jù)量的增長，關(guān)系型數(shù)據(jù)庫已經(jīng)無法支撐大規(guī)模數(shù)據(jù)集的存儲(chǔ)和分析，因此越來越多的企業(yè)開始選擇基于Hadoop構(gòu)建企業(yè)級(jí)大數(shù)據(jù)平臺(tái)。

同時(shí)眾多Sql-On-Hadoop技術(shù)方案的提出，也讓企業(yè)在Hadoop上構(gòu)建不同類型的數(shù)據(jù)應(yīng)用變得簡單而高效，例如通過使用Apache  Hive進(jìn)行數(shù)據(jù)ETL處理，通過使用Apache Impala進(jìn)行實(shí)時(shí)交互性查詢等。

大數(shù)據(jù)技術(shù)的興起，讓企業(yè)能夠更加靈活高效地使用自己的業(yè)務(wù)數(shù)據(jù)，從數(shù)據(jù)中提取出更多重要的價(jià)值，并將數(shù)據(jù)分析和挖掘出來的結(jié)果應(yīng)用在企業(yè)的決策、營銷、管理等應(yīng)用領(lǐng)域。但不可避免的是，隨著越來越多新技術(shù)的引入與使用，企業(yè)內(nèi)部一套大數(shù)據(jù)管理平臺(tái)可能會(huì)借助眾多開源技術(shù)組件實(shí)現(xiàn)。

例如在構(gòu)建企業(yè)數(shù)據(jù)倉庫的過程中，數(shù)據(jù)往往都是周期性的從業(yè)務(wù)系統(tǒng)中同步到大數(shù)據(jù)平臺(tái)，完成一系列ETL轉(zhuǎn)換動(dòng)作之后，最終形成數(shù)據(jù)集市等應(yīng)用。但是對(duì)于一些時(shí)間要求比較高的應(yīng)用，例如實(shí)時(shí)報(bào)表統(tǒng)計(jì)，則必須有非常低的延時(shí)展示統(tǒng)計(jì)結(jié)果，為此業(yè)界提出一套Lambda架構(gòu)方案來處理不同類型的數(shù)據(jù)。

例圖1-3所示，大數(shù)據(jù)平臺(tái)中包含批量計(jì)算的Batch Layer和實(shí)時(shí)計(jì)算的Speed  Layer，通過在一套平臺(tái)中將批計(jì)算和流計(jì)算整合在一起，例如使用Hadoop MapReduce進(jìn)行批量數(shù)據(jù)的處理，使用Apache  Storm進(jìn)行實(shí)時(shí)數(shù)據(jù)的處理。

這種架構(gòu)在一定程度上解決了不同計(jì)算類型的問題，但是帶來的問題是框架太多會(huì)導(dǎo)致平臺(tái)復(fù)雜度過高、運(yùn)維成本高等。在一套資源管理平臺(tái)中管理不同類型的計(jì)算框架使用也是非常困難的事情?？偠灾?，Lambda架構(gòu)是構(gòu)建大數(shù)據(jù)應(yīng)用程序的一種很有效的解決方案，但是還不是最完美的方案。

▲圖1-3 大數(shù)據(jù)Lambada架構(gòu)

后來隨著Apache  Spark的分布式內(nèi)存處理框架的出現(xiàn)，提出了將數(shù)據(jù)切分成微批的處理模式進(jìn)行流式數(shù)據(jù)處理，從而能夠在一套計(jì)算框架內(nèi)完成批量計(jì)算和流式計(jì)算。

但因?yàn)镾park本身是基于批處理模式的原因，并不能完美且高效地處理原生的數(shù)據(jù)流，因此對(duì)流式計(jì)算支持的相對(duì)較弱，可以說Spark的出現(xiàn)本質(zhì)上是在一定程度上對(duì)Hadoop架構(gòu)進(jìn)行了一定的升級(jí)和優(yōu)化。

03 有狀態(tài)流計(jì)算架構(gòu)

數(shù)據(jù)產(chǎn)生的本質(zhì)，其實(shí)是一條條真實(shí)存在的事件，前面提到的不同的架構(gòu)其實(shí)都是在一定程度違背了這種本質(zhì)，需要通過在一定時(shí)延的情況下對(duì)業(yè)務(wù)數(shù)據(jù)進(jìn)行處理，然后得到基于業(yè)務(wù)數(shù)據(jù)統(tǒng)計(jì)的準(zhǔn)確結(jié)果。

實(shí)際上，基于流式計(jì)算技術(shù)局限性，我們很難在數(shù)據(jù)產(chǎn)生的過程中進(jìn)行計(jì)算并直接產(chǎn)生統(tǒng)計(jì)結(jié)果，因?yàn)檫@不僅對(duì)系統(tǒng)有非常高的要求，還必須要滿足高性能、高吞吐、低延時(shí)等眾多目標(biāo)。

而有狀態(tài)流計(jì)算架構(gòu)(如圖1-4所示)的提出，從一定程度上滿足了企業(yè)的這種需求，企業(yè)基于實(shí)時(shí)的流式數(shù)據(jù)，維護(hù)所有計(jì)算過程的狀態(tài)，所謂狀態(tài)就是計(jì)算過程中產(chǎn)生的中間計(jì)算結(jié)果，每次計(jì)算新的數(shù)據(jù)進(jìn)入到流式系統(tǒng)中都是基于中間狀態(tài)結(jié)果的基礎(chǔ)上進(jìn)行運(yùn)算，最終產(chǎn)生正確的統(tǒng)計(jì)結(jié)果。

基于有狀態(tài)計(jì)算的方式最大的優(yōu)勢是不需要將原始數(shù)據(jù)重新從外部存儲(chǔ)中拿出來，從而進(jìn)行全量計(jì)算，因?yàn)檫@種計(jì)算方式的代價(jià)可能是非常高的。從另一個(gè)角度講，用戶無須通過調(diào)度和協(xié)調(diào)各種批量計(jì)算工具，從數(shù)據(jù)倉庫中獲取數(shù)據(jù)統(tǒng)計(jì)結(jié)果，然后再落地存儲(chǔ)，這些操作全部都可以基于流式計(jì)算完成，可以極大地減輕系統(tǒng)對(duì)其他框架的依賴，減少數(shù)據(jù)計(jì)算過程中的時(shí)間損耗以及硬件存儲(chǔ)。

▲圖1-4 有狀態(tài)計(jì)算架構(gòu)

如果計(jì)算的結(jié)果能保持一致，實(shí)時(shí)計(jì)算在很短的時(shí)間內(nèi)統(tǒng)計(jì)出結(jié)果，批量計(jì)算則需要等待一定時(shí)間才能得出，相信大多數(shù)用戶會(huì)更加傾向于選擇使用有狀態(tài)流進(jìn)行大數(shù)據(jù)處理。

04 為什么會(huì)是Flink

可以看出有狀態(tài)流計(jì)算將會(huì)逐步成為企業(yè)作為構(gòu)建數(shù)據(jù)平臺(tái)的架構(gòu)模式，而目前從社區(qū)來看，能夠滿足的只有Apache Flink。Flink通過實(shí)現(xiàn)Google  Dataflow流式計(jì)算模型實(shí)現(xiàn)了高吞吐、低延遲、高性能兼具實(shí)時(shí)流式計(jì)算框架。

同時(shí)Flink支持高度容錯(cuò)的狀態(tài)管理，防止?fàn)顟B(tài)在計(jì)算過程中因?yàn)橄到y(tǒng)異常而出現(xiàn)丟失，F(xiàn)link周期性地通過分布式快照技術(shù)Checkpoints實(shí)現(xiàn)狀態(tài)的持久化維護(hù)，使得即使在系統(tǒng)停機(jī)或者異常的情況下都能計(jì)算出正確的結(jié)果。

Flink具有先進(jìn)的架構(gòu)理念、諸多的優(yōu)秀特性，以及完善的編程接口，而Flink也在每一次的Release版本中，不斷推出新的特性，例如Queryable  State功能的提出，容許用戶通過遠(yuǎn)程的方式直接獲取流式計(jì)算任務(wù)的狀態(tài)信息，數(shù)據(jù)不需要落地?cái)?shù)據(jù)庫就能直接從Flink流式應(yīng)用中查詢。對(duì)于實(shí)時(shí)交互式的查詢業(yè)務(wù)可以直接從Flink的狀態(tài)中查詢最新的結(jié)果。

在未來，F(xiàn)link將不僅作為實(shí)時(shí)流式處理的框架，更多的可能會(huì)成為一套實(shí)時(shí)的狀態(tài)存儲(chǔ)引擎，讓更多的用戶從有狀態(tài)計(jì)算的技術(shù)中獲益。

Flink的具體優(yōu)勢有以下幾點(diǎn)。

1. 同時(shí)支持高吞吐、低延遲、高性能

Flink是目前開源社區(qū)中唯一一套集高吞吐、低延遲、高性能三者于一身的分布式流式數(shù)據(jù)處理框架。像Apache  Spark也只能兼顧高吞吐和高性能特性，主要因?yàn)樵赟park Streaming流式計(jì)算中無法做到低延遲保障;而流式計(jì)算框架Apache  Storm只能支持低延遲和高性能特性，但是無法滿足高吞吐的要求。而滿足高吞吐、低延遲、高性能這三個(gè)目標(biāo)對(duì)分布式流式計(jì)算框架來說是非常重要的。

2. 支持事件時(shí)間(Event Time)概念

在流式計(jì)算領(lǐng)域中，窗口計(jì)算的地位舉足輕重，但目前大多數(shù)框架窗口計(jì)算采用的都是系統(tǒng)時(shí)間(Process  Time)，也是事件傳輸?shù)接?jì)算框架處理時(shí)，系統(tǒng)主機(jī)的當(dāng)前時(shí)間。

Flink能夠支持基于事件時(shí)間(Event  Time)語義進(jìn)行窗口計(jì)算，也就是使用事件產(chǎn)生的時(shí)間，這種基于事件驅(qū)動(dòng)的機(jī)制使得事件即使亂序到達(dá)，流系統(tǒng)也能夠計(jì)算出精確的結(jié)果，保持了事件原本產(chǎn)生時(shí)的時(shí)序性，盡可能避免網(wǎng)絡(luò)傳輸或硬件系統(tǒng)的影響。

3. 支持有狀態(tài)計(jì)算

Flink在1.4版本中實(shí)現(xiàn)了狀態(tài)管理，所謂狀態(tài)就是在流式計(jì)算過程中將算子的中間結(jié)果數(shù)據(jù)保存在內(nèi)存或者文件系統(tǒng)中，等下一個(gè)事件進(jìn)入算子后可以從之前的狀態(tài)中獲取中間結(jié)果中計(jì)算當(dāng)前的結(jié)果，從而無須每次都基于全部的原始數(shù)據(jù)來統(tǒng)計(jì)結(jié)果，這種方式極大地提升了系統(tǒng)的性能，并降低了數(shù)據(jù)計(jì)算過程的資源消耗。

對(duì)于數(shù)據(jù)量大且運(yùn)算邏輯非常復(fù)雜的流式計(jì)算場景，有狀態(tài)計(jì)算發(fā)揮了非常重要的作用。

4. 支持高度靈活的窗口(Window)操作

在流處理應(yīng)用中，數(shù)據(jù)是連續(xù)不斷的，需要通過窗口的方式對(duì)流數(shù)據(jù)進(jìn)行一定范圍的聚合計(jì)算，例如統(tǒng)計(jì)在過去的1分鐘內(nèi)有多少用戶點(diǎn)擊某一網(wǎng)頁，在這種情況下，我們必須定義一個(gè)窗口，用來收集最近一分鐘內(nèi)的數(shù)據(jù)，并對(duì)這個(gè)窗口內(nèi)的數(shù)據(jù)進(jìn)行再計(jì)算。

Flink將窗口劃分為基于Time、Count、Session，以及Data-driven等類型的窗口操作，窗口可以用靈活的觸發(fā)條件定制化來達(dá)到對(duì)復(fù)雜的流傳輸模式的支持，用戶可以定義不同的窗口觸發(fā)機(jī)制來滿足不同的需求。

5. 基于輕量級(jí)分布式快照(Snapshot)實(shí)現(xiàn)的容錯(cuò)

Flink能夠分布式運(yùn)行在上千個(gè)節(jié)點(diǎn)上，將一個(gè)大型計(jì)算任務(wù)的流程拆解成小的計(jì)算過程，然后將tesk分布到并行節(jié)點(diǎn)上進(jìn)行處理。在任務(wù)執(zhí)行過程中，能夠自動(dòng)發(fā)現(xiàn)事件處理過程中的錯(cuò)誤而導(dǎo)致數(shù)據(jù)不一致的問題，比如：節(jié)點(diǎn)宕機(jī)、網(wǎng)路傳輸問題，或是由于用戶因?yàn)樯?jí)或修復(fù)問題而導(dǎo)致計(jì)算服務(wù)重啟等。

在這些情況下，通過基于分布式快照技術(shù)的Checkpoints，將執(zhí)行過程中的狀態(tài)信息進(jìn)行持久化存儲(chǔ)，一旦任務(wù)出現(xiàn)異常停止，F(xiàn)link就能夠從Checkpoints中進(jìn)行任務(wù)的自動(dòng)恢復(fù)，以確保數(shù)據(jù)在處理過程中的一致性。

6. 基于JVM實(shí)現(xiàn)獨(dú)立的內(nèi)存管理

內(nèi)存管理是所有計(jì)算框架需要重點(diǎn)考慮的部分，尤其對(duì)于計(jì)算量比較大的計(jì)算場景，數(shù)據(jù)在內(nèi)存中該如何進(jìn)行管理顯得至關(guān)重要。針對(duì)內(nèi)存管理，F(xiàn)link實(shí)現(xiàn)了自身管理內(nèi)存的機(jī)制，盡可能減少JVM  GC對(duì)系統(tǒng)的影響。

另外，F(xiàn)link通過序列化/反序列化方法將所有的數(shù)據(jù)對(duì)象轉(zhuǎn)換成二進(jìn)制在內(nèi)存中存儲(chǔ)，降低數(shù)據(jù)存儲(chǔ)的大小的同時(shí)，能夠更加有效地對(duì)內(nèi)存空間進(jìn)行利用，降低GC帶來的性能下降或任務(wù)異常的風(fēng)險(xiǎn)，因此Flink較其他分布式處理的框架會(huì)顯得更加穩(wěn)定，不會(huì)因?yàn)镴VM  GC等問題而影響整個(gè)應(yīng)用的運(yùn)行。

7. Save Points(保存點(diǎn))

對(duì)于7*24小時(shí)運(yùn)行的流式應(yīng)用，數(shù)據(jù)源源不斷地接入，在一段時(shí)間內(nèi)應(yīng)用的終止有可能導(dǎo)致數(shù)據(jù)的丟失或者計(jì)算結(jié)果的不準(zhǔn)確，例如進(jìn)行集群版本的升級(jí)、停機(jī)運(yùn)維操作等操作。

值得一提的是，F(xiàn)link通過Save Points技術(shù)將任務(wù)執(zhí)行的快照保存在存儲(chǔ)介質(zhì)上，當(dāng)任務(wù)重啟的時(shí)候可以直接從事先保存的Save  Points恢復(fù)原有的計(jì)算狀態(tài)，使得任務(wù)繼續(xù)按照停機(jī)之前的狀態(tài)運(yùn)行，Save Points技術(shù)可以讓用戶更好地管理和運(yùn)維實(shí)時(shí)流式應(yīng)用。

到此，相信大家對(duì)“Flink數(shù)據(jù)架構(gòu)的演變是怎樣的”有了更深的了解，不妨來實(shí)際操作一番吧！這里是創(chuàng)新互聯(lián)網(wǎng)站，更多相關(guān)內(nèi)容可以進(jìn)入相關(guān)頻道進(jìn)行查詢，關(guān)注我們，繼續(xù)學(xué)習(xí)！

分享題目：Flink數(shù)據(jù)架構(gòu)的演變是怎樣的
文章分享：http://www.rwnh.cn/article16/gcgidg.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供品牌網(wǎng)站建設(shè)、網(wǎng)站收錄、網(wǎng)站建設(shè)、網(wǎng)站排名、域名注冊、服務(wù)器托管

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來源： 創(chuàng)新互聯(lián)