1.7.Flink scala shell代碼調(diào)試
1.7.1.Flink scala shell代碼調(diào)試語法
1.8.Flink基本原理及應(yīng)用場(chǎng)景
1.8.1.Flink特點(diǎn)
1.8.2.Flink架構(gòu)圖
1.8.2.1.Flink集群的解剖
1.8.2.1.1.JobManager
1.8.2.1.2.TaskManagers
1.8.2.1.3.Tasks and Operator Chains
1.8.2.1.4.Task Slots 和 Resources
1.8.2.1.5.Flink Application Execution
1.8.2.1.6.Flink Session集群
1.8.2.1.7.Flink Job 集群
1.8.2.1.8.Flink Application集群
1.8.3.Flink基本組件介紹
1.8.4.Flink的流處理與批處理
1.8.5.三種數(shù)據(jù)傳輸模型
1.8.6.數(shù)據(jù)處理的模型
1.8.7.Flink應(yīng)用場(chǎng)景分析

1.7.Flink scala shell代碼調(diào)試

?針對(duì)初學(xué)者，開發(fā)的時(shí)候容易出錯(cuò)，如果每次都打包進(jìn)行調(diào)試，比較麻煩，并且也不好定位問題，可以在scala shell命令行下進(jìn)行調(diào)試

?scala shell方式支持流處理和批處理。當(dāng)啟動(dòng)shell命令行之后，兩個(gè)不同的ExecutionEnvironments會(huì)被自動(dòng)創(chuàng)建。使用senv(Stream)和benv(Batch)分別去處理流處理和批處理程序。(類似于spark-shell中sc變量)

?bin/start-scala-shell.sh [local|remote|yarn] [options]

scala> val text = benv.fromElements("hello you","hello world") scala> val counts = text.flatMap { _.toLowerCase.split("\\W+") }.map { (_, 1) }.groupBy(0).sum(1) scala> counts.print()

1.7.1.Flink scala shell代碼調(diào)試語法

1.8.Flink基本原理及應(yīng)用場(chǎng)景

?Apache Flink是一個(gè)開源的分布式，高性能，高可用，準(zhǔn)確的流處理框架。
?主要由Java代碼實(shí)現(xiàn)。
?支持實(shí)時(shí)流（stream）處理和批（batch）處理，批數(shù)據(jù)只是流數(shù)據(jù)的一個(gè)極限特例。
?Flink原生支持了迭代計(jì)算、內(nèi)存管理和程序優(yōu)化。

1.8.1.Flink特點(diǎn)

Flink的數(shù)據(jù)來源可以是：應(yīng)用（Applications）、傳感器和設(shè)備（Sensors & Devices）、文件系統(tǒng)和存儲(chǔ)（File Systems & Storage）、日志消息（Message Logs）
Flink的特點(diǎn)：流式優(yōu)先（Streaming-first）、連續(xù)處理（continuous processing）、容錯(cuò)（Fault-tolerant）、有狀態(tài)的計(jì)算（stateful computations）、可伸縮（Scalable）、可支持上千個(gè)節(jié)點(diǎn)（to 1000s of nodes and beyond）、性能（Performance）、高吞吐 低延遲（high throughput,low latency）。
Flink的數(shù)據(jù)下層位置: 應(yīng)用（Applications）、數(shù)據(jù)庫(kù)（Databases）、文件系統(tǒng)和存儲(chǔ)（File Systems & Storage）、日志消息（Message Logs）。

1.8.2.Flink架構(gòu)圖

Flink是一個(gè)分布式系統(tǒng)，需要對(duì)計(jì)算資源進(jìn)行有效的分配和管理，才能執(zhí)行流應(yīng)用程序。它集成了所有常見的集群資源管理器，如Hadoop YARN、Apache Mesos和Kubernetes，但也可以設(shè)置為作為獨(dú)立集群運(yùn)行，甚至作為庫(kù)運(yùn)行。

1.8.2.1.Flink集群的解剖

Flink運(yùn)行時(shí)由兩種類型的進(jìn)程組成：JobManager和一個(gè)或多個(gè)TaskManagers。

要了解一個(gè)系統(tǒng)，一般都是從架構(gòu)開始。我們關(guān)心的問題是：系統(tǒng)部署成功后各個(gè)節(jié)點(diǎn)都啟動(dòng)了哪些服務(wù)，各個(gè)服務(wù)之間又是怎么交互和協(xié)調(diào)的。下方是Flink集群?jiǎn)?dòng)后架構(gòu)圖。
圖 1 集群部署解析圖

客戶端（Client）不是運(yùn)行時(shí)和程序執(zhí)行的一部分，但用于準(zhǔn)備和發(fā)送dataflow到JobManager。之后，客戶端（Client）可以斷開連接(detached mode)，或者保持連接以接收進(jìn)度報(bào)告(attached mode)。客戶端要么作為觸發(fā)執(zhí)行的Java/Scala程序的一部分運(yùn)行，要么在命令行進(jìn)程中運(yùn)行。

JobManager和taskmanager可以以各種方式啟動(dòng):作為獨(dú)立集群( standalone cluster)直接在機(jī)器上啟動(dòng)，在容器中，或者由YARN或Mesos等資源框架管理。TaskManagers連接到JobManagers，宣布它們是可用的，并分配工作。

1.8.2.1.1.JobManager

JobManager有許多與協(xié)調(diào)Flink應(yīng)用程序的分布式執(zhí)行相關(guān)的職責(zé):它決定何時(shí)調(diào)度下一個(gè)任務(wù)(或一組任務(wù))，對(duì)已完成的任務(wù)或執(zhí)行失敗作出反應(yīng)，協(xié)調(diào)檢查點(diǎn)，協(xié)調(diào)失敗的恢復(fù)，等等。這個(gè)過程包括三個(gè)不同的組成部分:
?ResourceManager
ResourceManager負(fù)責(zé)Flink集群中的資源去/分配和供應(yīng)——它管理任務(wù)槽(task slots)，這些任務(wù)槽是Flink集群中的資源調(diào)度單元(請(qǐng)參閱TaskManagers)。Flink為不同的環(huán)境和資源提供者(如YARN、Mesos、Kubernetes和獨(dú)立部署(standalone deployments))實(shí)現(xiàn)了多個(gè)resourcemanager。在獨(dú)立部署中，ResourceManager只能分發(fā)可用的任務(wù)管理器的槽（slots），不能自己?jiǎn)?dòng)新的任務(wù)管理器。

?Dispatcher
Dispatcher提供一個(gè)REST接口來提交要執(zhí)行的Flink應(yīng)用程序，并為每個(gè)提交的作業(yè)啟動(dòng)一個(gè)新的JobMaster。它還運(yùn)行Flink WebUI來提供關(guān)于作業(yè)執(zhí)行的信息。

?JobMaster
JobMaster 負(fù)責(zé)管理單個(gè)JobGraph的執(zhí)行。多個(gè)作業(yè)可以在一個(gè)Flink集群中同時(shí)運(yùn)行，每個(gè)作業(yè)都有自己的作業(yè)管理器。

至始至終至少有一個(gè)JobManager。一個(gè)HA集群中可能有多個(gè)JobManager。在HA中，其中一個(gè)總是leader，另外的就是standby。

1.8.2.1.2.TaskManagers

TaskManagers (也稱為workers)執(zhí)行(dataflow)的任務(wù)，緩沖和交換data streams。

必須始終至少有一個(gè)TaskManager。TaskManager中資源調(diào)度的最小單元是一個(gè)task slot。任務(wù)管理器中的task slot的數(shù)量表示并發(fā)處理任務(wù)的數(shù)量。注意，多個(gè)operators可以在一個(gè)task slot中執(zhí)行(請(qǐng)參閱任務(wù)和操作符鏈（Tasks and Operator Chains）)。

1.8.2.1.3.Tasks and Operator Chains

對(duì)于分布式執(zhí)行，Flink將操作子任務(wù)（subtasks）連接到一起，形成多個(gè)任務(wù)。每個(gè)任務(wù)由一個(gè)線程執(zhí)行。將operators鏈接到任務(wù)中是一種有用的優(yōu)化:它減少了線程到線程的切換和緩沖開銷，提高了總體吞吐量，同時(shí)減少了延遲。這個(gè)鏈的行為可以配置。

下圖中的樣例dataflow由5個(gè)子任務(wù)執(zhí)行，因此有5個(gè)并行線程（帶有3個(gè)Task的和2個(gè)thread的）。

1.8.2.1.4.Task Slots 和 Resources

每個(gè)worker (TaskManager)都是一個(gè)JVM進(jìn)程，并且可以在單獨(dú)的線程中執(zhí)行一個(gè)或多個(gè)子任務(wù)。為了控制TaskManager接受多少任務(wù)，它有所謂的任務(wù)槽(至少一個(gè))。

每個(gè)task slot表示TaskManager的一個(gè)固定資源子集。例如，一個(gè)有三個(gè)slot的TaskManager，會(huì)將其托管內(nèi)存的1/3分配給每個(gè)插slot。對(duì)資源進(jìn)行分段意味著子任務(wù)不會(huì)與其他作業(yè)的子任務(wù)爭(zhēng)奪托管內(nèi)存，而是擁有一定數(shù)量的保留托管內(nèi)存。注意，這里沒有發(fā)生CPU隔離;當(dāng)前slots 只分隔任務(wù)的托管內(nèi)存。

通過調(diào)整task slots的數(shù)量，用戶可以定義子任務(wù)如何相互隔離。每個(gè)TaskManager有一個(gè)槽意味著每個(gè)任務(wù)組在單獨(dú)的JVM中運(yùn)行(例如，JVM可以在單獨(dú)的容器中啟動(dòng))。擁有多個(gè)slots意味著更多子任務(wù)共享同一個(gè)JVM。相同JVM中的任務(wù)共享TCP連接(via multiplexing)和心跳消息。它們還可以共享數(shù)據(jù)集和數(shù)據(jù)結(jié)構(gòu)，從而減少每個(gè)任務(wù)的開銷。

默認(rèn)情況下，Flink允許子任務(wù)共享slots，即使它們是不同任務(wù)的子任務(wù)，只要它們來自相同的作業(yè)。結(jié)果是，一個(gè)slot可以容納作業(yè)的整個(gè)管道(pipeline)。允許這種slot共享有兩個(gè)主要好處:
?Flink集群需要的任務(wù)slot與作業(yè)中使用的最高并行度相同。不需要計(jì)算一個(gè)程序總共包含多少任務(wù)(具有不同的并行性)。
?更容易獲得更好的資源利用。如果沒有slot共享，非密集的source/map()子任務(wù)將阻塞和資源密集的窗口子任務(wù)一樣多的資源。使用slot共享，將示例中的基本并行性從2個(gè)增加到6個(gè)，可以充分利用有slot的資源，同時(shí)確保繁重的子任務(wù)在任務(wù)管理器中得到公平分配。

1.8.2.1.5.Flink Application Execution

Flink應(yīng)用程序是任何從main()方法生成一個(gè)或多個(gè)Flink作業(yè)的用戶程序。這些作業(yè)可以在本地JVM (LocalEnvironment)中執(zhí)行，也可以在帶有多臺(tái)機(jī)器的遠(yuǎn)程集群設(shè)置(RemoteEnvironment)上執(zhí)行。對(duì)于每個(gè)程序，ExecutionEnvironment提供了控制作業(yè)執(zhí)行(例如設(shè)置并行性)和與外部世界交互的方法(參見Flink程序的剖析)。

Flink應(yīng)用程序的作業(yè)可以提交給長(zhǎng)時(shí)間運(yùn)行的Flink session集群、專用的Flink作業(yè)集群或Flink應(yīng)用程序集群。這些選項(xiàng)之間的區(qū)別主要與集群的生命周期和資源隔離保證有關(guān)。

1.8.2.1.6.Flink Session集群

部署在yarn集群上的flink集群都是把資源的管理交給了yarn來管理。yarn session的部署模式就是先預(yù)先在yarn集群上啟動(dòng)一個(gè)flink集群，我們可以把我們寫好的flink任務(wù)直接提到這個(gè)集群上。
啟動(dòng)集群的命令如下：

${FLINK_HOME}/bin/yarn-session.sh

1：如果沒指定-d，這種情況集群會(huì)和客戶端一直保持著連接，客戶端退出之后，集群也會(huì)退出。

2:提交任務(wù)
往yarn session集群提交任務(wù)，只需要在相應(yīng)的客戶端機(jī)器上，通過${FLINK_HOME}/bin/flink run -d user.jar 這樣的命令就可以提交到session集群.

此外我們還可以通過web ui最后一項(xiàng)來提交任務(wù)

3：這種session模式一般適用于批任務(wù)，也就是執(zhí)行一段時(shí)間以后可以終止的任務(wù)，因?yàn)閷?duì)于這種短時(shí)間執(zhí)行的任務(wù)，可以避免在申請(qǐng)資源方面浪費(fèi)過多時(shí)間。

4：集群?jiǎn)?dòng)之后，是沒有給flink集群分配資源的，當(dāng)提交任務(wù)之后，yarn集群會(huì)根據(jù)請(qǐng)求再給任務(wù)分配資源，任務(wù)執(zhí)行完成之后，系統(tǒng)隔一段時(shí)間會(huì)釋放相應(yīng)的資源.(這個(gè)時(shí)間是可配置的，為了防止馬上有任務(wù)又來了，重新申請(qǐng)資源)

---

?集群生命周期:在Flink Session 集群中，客戶端連接到一個(gè)預(yù)先存在的長(zhǎng)時(shí)間運(yùn)行的集群，該集群可以接受多個(gè)作業(yè)提交。即使完成了所有作業(yè)，集群(和JobManager)仍將繼續(xù)運(yùn)行，直到手動(dòng)停止會(huì)話。因此，Flink session集群的生存期不綁定到任何Flink作業(yè)的生存期。
?資源隔離:任務(wù)管理器slots 由ResourceManager在作業(yè)提交時(shí)分配，并在作業(yè)完成后釋放。由于所有作業(yè)都共享同一個(gè)集群，因此集群資源(如提交作業(yè)階段的網(wǎng)絡(luò)帶寬)存在競(jìng)爭(zhēng)。這個(gè)共享設(shè)置的一個(gè)限制是，如果一個(gè)任務(wù)管理器崩潰，那么在這個(gè)任務(wù)管理器上運(yùn)行的所有任務(wù)都將失敗;同樣，如果JobManager上發(fā)生致命錯(cuò)誤，它將影響集群中運(yùn)行的所有作業(yè)。
?其他注意事項(xiàng):擁有一個(gè)預(yù)先存在的集群可以節(jié)省大量應(yīng)用資源和啟動(dòng)taskmanager的時(shí)間。在作業(yè)的執(zhí)行時(shí)間非常短且高啟動(dòng)時(shí)間會(huì)對(duì)端到端用戶體驗(yàn)產(chǎn)生負(fù)面影響的場(chǎng)景中，這一點(diǎn)非常重要——就像對(duì)短查詢進(jìn)行交互式分析的情況一樣，在這種情況下，作業(yè)可以使用現(xiàn)有資源快速執(zhí)行計(jì)算。

1.8.2.1.7.Flink Job 集群

1：上面講了session模式部署集群,這種模式可以在一個(gè)集群里跑很多的任務(wù)，這些任務(wù)共享了flink集群的資源，隔離性做的不是很好，所以flink還提供了另外一種執(zhí)行模式：yarn per job模式。
2：這種模式會(huì)在yarn上為每個(gè)flink任務(wù)都建立一個(gè)單獨(dú)的集群，優(yōu)勢(shì)就是每個(gè)任務(wù)單獨(dú)的進(jìn)行資源管理，和其他任務(wù)資源隔離。這種模式適用于對(duì)啟動(dòng)時(shí)間不太敏感，需要長(zhǎng)時(shí)間運(yùn)行的流任務(wù)。
3：啟動(dòng)命令

${FLINK_HOME}/bin/flink run -d -p 4 -ys 2 -m yarn-cluster -c com.example.Test userjar.jar arg1 arg2

-d 采用分離模式
-p 程序的并行度
-ys 每個(gè)taskmanager有幾個(gè)slot,我們可以簡(jiǎn)單的理解為flink會(huì)把taskmanager的內(nèi)存分成幾份，在某些條件下，程序可以共用slot，提高效率，至于slot的概念，我們后續(xù)再講，今天就不多說了。用并行度除以這個(gè)值，然后就會(huì)得到flink會(huì)啟動(dòng)幾個(gè)taskmanager
，所以為了避免有多余的slot，我們最好設(shè)置并行度除以這個(gè)ys值能整除。
-c 程序的入口類，我們可以在程序打包的時(shí)候指定入口類，如果沒有指定或者程序中有很多類，我們就需要通過這個(gè)-c參數(shù)來指定入口類了。
在命令行最后的參數(shù)是用戶jar包的參數(shù).
停止命令
第一，我們可以在flink的頁面上通過停止flink的任務(wù)來停止集群，在我們停止了flink任務(wù)之后，yarn會(huì)自動(dòng)釋放相應(yīng)的資源。

第二，通過命令行來停止：

${FLINK_HOME}/bin/flink stop -m yarn-cluster -yid application_1592386606716_0005 c8ee546129e8480809ee62a4ce7dd91d

這個(gè)時(shí)候需要指定yarn applicationId和flink job id
第三，通過程序來停止

https://blog.csdn.net/zhangjun5965/article/details/106820591

如果做了一個(gè)實(shí)時(shí)平臺(tái)這樣的系統(tǒng)，就不能手工通過命令行來停止了，可以調(diào)用相應(yīng)的api來停止任務(wù).

啟動(dòng)流程
當(dāng)執(zhí)行完相應(yīng)的命令之后，系統(tǒng)會(huì)把flink的jar、相關(guān)的配置文件、用戶的jar都上傳到hdfs
的一個(gè)臨時(shí)目錄，默認(rèn)是/user/{USER}/.flink/{applicationId},
然后再構(gòu)建flink集群的時(shí)候，再去找個(gè)目錄去獲取，程序部署成功之后，刪除相應(yīng)的臨時(shí)目錄

---

?集群生命周期:在Flink作業(yè)集群中，可用的集群管理器(如YARN或Kubernetes)用于為每個(gè)提交的作業(yè)啟動(dòng)一個(gè)集群，該集群僅對(duì)該作業(yè)可用。在這里,客戶端首先請(qǐng)求資源從集群管理器啟動(dòng)JobManager并提交作業(yè)調(diào)度程序運(yùn)行在這個(gè)過程。TaskManagers然后lazily 地分配資源需求的基礎(chǔ)上工作。一旦任務(wù)完成，Flink任務(wù)集群將被拆除。
?資源隔離:JobManager中的致命錯(cuò)誤只會(huì)影響在該Flink作業(yè)集群中運(yùn)行的一個(gè)作業(yè)。
?其他注意事項(xiàng):因?yàn)镽esourceManager申請(qǐng),等待外部資源管理組件啟動(dòng)TaskManager流程和分配資源,集群Flink工作更適合大型長(zhǎng)期的工作,有高要求,不敏感,再啟動(dòng)時(shí)間。

1.8.2.1.8.Flink Application集群

這種模式是在flink 1.11 版本中提供的，flink的yarn per job模式啟動(dòng)的時(shí)候會(huì)把本地的flink的jar和用戶的jar都上傳到hdfs，這個(gè)過程非常的消耗網(wǎng)絡(luò)的帶寬，如果同時(shí)有多個(gè)人提交任務(wù)的話，那么對(duì)網(wǎng)絡(luò)的影響就更大，此外，每次提交任務(wù)的時(shí)候flink的jar包是一樣的，也不用每次都拷來拷去的，所以flink提供了一種新的application模式，可以把flink的jar和用戶的jar都預(yù)先放到hdfs上，這樣就能省去yarn per job模式提交任務(wù)的jar包拷貝工作，節(jié)省了帶寬，加快了提交任務(wù)的速度。

具體的命令如下：

./bin/flink run-application -p 1 -d -t yarn-application -yD yarn.provided.lib.dirs="hdfs://localhost/data/flink/libs/" hdfs://localhost/data/flink/user-lib/TopSpeedWindowing.jar

-yD yarn.provided.lib.dirs ：用來指定存放flink jar的目錄
最后一個(gè)參數(shù)是用戶的jar在hdfs上的路徑.

---

?集群生命周期:Flink應(yīng)用程序集群是一個(gè)專用的Flink集群，它只執(zhí)行來自一個(gè)Flink應(yīng)用程序的作業(yè)，并且main()方法在集群上運(yùn)行，而不是在客戶機(jī)上運(yùn)行。作業(yè)提交是一個(gè)一步完成的過程:您不需要首先啟動(dòng)Flink集群，然后將作業(yè)提交到現(xiàn)有的集群會(huì)話;相反，您可以將應(yīng)用程序邏輯和依賴關(guān)系打包到一個(gè)可執(zhí)行作業(yè)JAR中，而集群入口點(diǎn)(ApplicationClusterEntryPoint)負(fù)責(zé)調(diào)用main()方法來提取JobGraph。例如，這允許您像部署Kubernetes上的任何其他應(yīng)用程序一樣部署Flink應(yīng)用程序。因此，Flink應(yīng)用程序集群的生存期綁定到Flink應(yīng)用程序的生存期。
?資源隔離:在Flink應(yīng)用程序集群中，ResourceManager和Dispatcher作用域被限定為單個(gè)Flink應(yīng)用程序，這提供了比Flink會(huì)話集群更好的關(guān)注點(diǎn)隔離。

1.8.3.Flink基本組件介紹

Data Source
Transformations
Data Sink

1.8.4.Flink的流處理與批處理

?在大數(shù)據(jù)處理領(lǐng)域，批處理任務(wù)與流處理任務(wù)一般被認(rèn)為是兩種不同的任務(wù)，一個(gè)大數(shù)據(jù)框架一般會(huì)被設(shè)計(jì)為只能處理其中一種任務(wù)。
例如：Storm只支持流處理任務(wù)，而MapReduce、Spark支持批處理任務(wù)。Spark Streaming是Apache Spark之上支持流處理任務(wù)的子系統(tǒng)，看似是一個(gè)特例，其實(shí)并不是——Spark Streaming采用了一種micro-batch的架構(gòu)，即把輸入的數(shù)據(jù)流切分成細(xì)粒度的batch，并為每一種batch數(shù)據(jù)提交一個(gè)批處理的Spark任務(wù)，所以Spark Streaming本質(zhì)上還是基于Spark批處理系統(tǒng)對(duì)流式數(shù)據(jù)進(jìn)行處理，和Storm完全流式的數(shù)據(jù)處理方式完全不同。

?Flink通過靈活的執(zhí)行引擎，能夠同時(shí)支持批處理任務(wù)與流處理任務(wù)
A:在執(zhí)行引擎這一層，流處理系統(tǒng)與批處理系統(tǒng)最大不同在于節(jié)點(diǎn)間的數(shù)據(jù)傳輸方式。
B:對(duì)于一個(gè)流處理系統(tǒng)，其節(jié)點(diǎn)間數(shù)據(jù)傳輸?shù)臉?biāo)準(zhǔn)模型是：當(dāng)一條數(shù)據(jù)被處理完成后，序列化到緩存中，然后立刻通過網(wǎng)絡(luò)傳輸?shù)较乱粋€(gè)節(jié)點(diǎn)，由下一個(gè)節(jié)點(diǎn)繼續(xù)處理。
C:而對(duì)于一個(gè)批處理系統(tǒng)，其節(jié)點(diǎn)間數(shù)據(jù)傳輸?shù)臉?biāo)準(zhǔn)模型是：當(dāng)一條數(shù)據(jù)被處理完成后，序列化到緩存中，并不會(huì)立刻通過網(wǎng)絡(luò)傳輸?shù)较乱粋€(gè)節(jié)點(diǎn)，當(dāng)緩存寫滿，就持久化到本地硬盤上，當(dāng)所有數(shù)據(jù)都被處理完成后，才開始將處理后的數(shù)據(jù)通過網(wǎng)絡(luò)傳輸?shù)较乱粋€(gè)節(jié)點(diǎn)。
D:這兩種數(shù)據(jù)傳輸模式是兩個(gè)極端，對(duì)應(yīng)的是流處理系統(tǒng)對(duì)低延遲的要求和批處理系統(tǒng)對(duì)高吞吐量的要求。
E:Flink的執(zhí)行引擎采用了一種十分靈活的方式，同時(shí)支持了這兩種數(shù)據(jù)傳輸模型。
F:Flink以固定的緩存塊為單位進(jìn)行網(wǎng)絡(luò)數(shù)據(jù)傳輸，用戶可以通過設(shè)置緩存塊超時(shí)值指定緩存塊的傳輸時(shí)機(jī)。如果緩存塊的超時(shí)值為0，則Flink的數(shù)據(jù)傳輸方式類似上文所提到流處理系統(tǒng)的標(biāo)準(zhǔn)模型，此時(shí)系統(tǒng)可以獲得最低的處理延遲。
G:如果緩存塊的超時(shí)值為無限大，則Flink的數(shù)據(jù)傳輸方式類似上文所提到批處理系統(tǒng)的標(biāo)準(zhǔn)模型，此時(shí)系統(tǒng)可以獲得最高的吞吐量。
H:同時(shí)緩存塊的超時(shí)值也可以設(shè)置為0到無限大之間的任意值。緩存塊的超時(shí)閾值越小，則Flink流處理執(zhí)行引擎的數(shù)據(jù)處理延遲越低，但吞吐量也會(huì)降低，反之亦然。通過調(diào)整緩存塊的超時(shí)閾值，用戶可根據(jù)需求靈活地權(quán)衡系統(tǒng)延遲和吞吐量。

1.8.5.三種數(shù)據(jù)傳輸模型

1.8.6.數(shù)據(jù)處理的模型

流處理模型

批處理模型

Flink處理模型

1.8.7.Flink應(yīng)用場(chǎng)景分析

?優(yōu)化電商網(wǎng)站的實(shí)時(shí)搜索結(jié)果
阿里巴巴的所有基礎(chǔ)設(shè)施團(tuán)隊(duì)使用flink實(shí)時(shí)更新產(chǎn)品細(xì)節(jié)和庫(kù)存信息（Blink）
?針對(duì)數(shù)據(jù)分析團(tuán)隊(duì)提供實(shí)時(shí)流處理服務(wù)
通過flink數(shù)據(jù)分析平臺(tái)提供實(shí)時(shí)數(shù)據(jù)分析服務(wù)，及時(shí)發(fā)現(xiàn)問題。
?網(wǎng)絡(luò)/傳感器檢測(cè)和錯(cuò)誤檢查
Bouygues電信公司，是發(fā)過最大的電信供應(yīng)商之一，使用fink監(jiān)控其優(yōu)先和無線網(wǎng)絡(luò)，實(shí)現(xiàn)快速故障響應(yīng)。
?商業(yè)智能分析ETL
Zalando使用flink轉(zhuǎn)換數(shù)據(jù)以便于加載到數(shù)據(jù)倉(cāng)庫(kù)，將復(fù)雜的轉(zhuǎn)換操作轉(zhuǎn)化為相對(duì)簡(jiǎn)單的并確保分析終端用戶可以更快的訪問數(shù)據(jù)(實(shí)時(shí)ETL)

總結(jié)

以上是生活随笔為你收集整理的07/08_flink shell,基本原理及应用场景、特点、架构图、集群解剖、JobManager、TaskManagers、tasks和操作链、Session/job集群、组件介绍等、应用场景的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

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