第1章 Flink 基礎(chǔ)概念
1.1、Flink基礎(chǔ)概念
1.1.1、Flink是什么
Apache Flink是一個框架和分布式處理引擎，用于對無界和有界數(shù)據(jù)流進(jìn)行有狀態(tài)計算，它的核心目標(biāo)是“數(shù)據(jù)流上的有狀態(tài)計算”（Stateful Computations over Data Streams）。
1.1.2、大數(shù)據(jù)發(fā)展史
大數(shù)據(jù)的飛速發(fā)展，出現(xiàn)了很多熱門的開源社區(qū)，其中著名的有 Hadoop、Storm、Spark 以及 Flink，他們都有著各自專注的應(yīng)用場景。
Spark 掀開了內(nèi)存計算的先河，也以內(nèi)存為賭注，贏得了內(nèi)存計算的飛速發(fā)展。
第1代--Hadoop MapReduce
首先第一代的計算引擎，無疑就是 Hadoop 承載的 MapReduce。它將計算分為兩個階段，分別為 Map 和 Reduce。對于上層應(yīng)用來說，就不得不想方設(shè)法去拆分算法，甚至于不得不在上層應(yīng)用實現(xiàn)多個 Job 的串聯(lián)，以完成一個完整的算法，例如迭代計算。
主要關(guān)鍵詞：批處理、Mapper、Reducer
第2代--DAG框架（Tez） + MapReduce
由于這樣的弊端，催生了支持 DAG 框架的產(chǎn)生。因此，支持 DAG 的框架被劃分為第二代計算引擎。如 Tez 以及更上層的 Oozie。這里我們不去細(xì)究各種 DAG 實現(xiàn)之間的區(qū)別，不過對于當(dāng)時的 Tez 和 Oozie 來說，大多還是批處理的任務(wù)。
主要關(guān)鍵詞：批處理、1個 Tez = MR(1) + MR(2) + ... + MR(n)、相比 MR 效率有所提升
第3代--Spark
接下來就是以 Spark 為代表的第三代的計算引擎。第三代計算引擎的特點主要是 Job 內(nèi)部的 DAG 支持（不跨越 ?Job），以及強調(diào)的實時計算，其實 Spark Streaming 是以微批（micro-batch）方式對流式數(shù)據(jù)進(jìn)行處理。
主要關(guān)鍵詞：micro-batch、SQL 高層 API 支持、自帶 DAG、內(nèi)存迭代計算、性能較之前大幅提升
第4代--Flink，Structured Streaming
隨著第三代計算引擎的出現(xiàn)，促進(jìn)了上層應(yīng)用快速發(fā)展，例如各種迭代計算的性能以及對流計算和 SQL 等的支持。Flink 的誕生就被歸在了第四代。這應(yīng)該主要表現(xiàn)在 Flink 對流計算的支持，以及更一步的實時性上面。當(dāng)然 Flink 也可以支持 Batch 的任務(wù)，以及 DAG 的運算。流批一體是當(dāng)前最流行的處理方式，兩套邏輯只需要執(zhí)行一套代碼。
Flink 最重要的特性 Checkpoint 是基于 Chandy-Lamport 算法實現(xiàn)了一個分布式的一致性的快照（Distributed Snapshot），從而提供了一致性的語義。而 Spark 的 Structured Streaming 的 Continuous Processing Mode 的容錯處理也是是這個算法。所以用 Spark Streaming 和 Flink 對比是不太恰當(dāng)?shù)模琒tructured Streaming 才是合適的參照。在筆者看來，Structured Streaming ?和 Flink 的原理都差不多，不過基于阿里強大的生態(tài)及大力推廣，國內(nèi)市場用 Flink 的比例比較高。
主要關(guān)鍵詞：流批一體、SQL 高層 API 支持、自帶 DAG、流式計算性能更高、可靠性更高
1.1.3、有界流和無界流
離線批計算和流式計算，本質(zhì)上就是對有界流和無界流的計算。
無界數(shù)據(jù)流
有定義流的開始，但沒有定義流的結(jié)束
它們會無休止的產(chǎn)生數(shù)據(jù)
無界流的數(shù)據(jù)必須持續(xù)處理，并輸出“當(dāng)時”的計算結(jié)果，因此計算結(jié)果也不會是一個一次性的最終結(jié)果，而是源源不斷的無界結(jié)果流。
無界流處理通常被稱為流式處理
有界數(shù)據(jù)流
有定義流的開始，也有定義流的結(jié)束；
有界流可以在攝取所有數(shù)據(jù)后再進(jìn)行計算；
有界流所有數(shù)據(jù)可以被排序，所以并不需要有序攝取；
有界流處理通常被稱為批處理
1.1.4、流處理和批處理
批處理（Batch analytics）
批處理的處理流程是：統(tǒng)一收集數(shù)據(jù) --> 對數(shù)據(jù)進(jìn)行批量處理 --> 數(shù)據(jù)存儲或生成報表。就是傳統(tǒng)意義上使用類似于 Map Reduce、Hive、Spark Batch 等，對作業(yè)進(jìn)行分析、處理、生成離線報表。
流處理（Streaming analytics）
流處理的處理流程是：源源不斷的實時數(shù)據(jù) --> 持續(xù)不斷的處理 --> 不斷更新的結(jié)果。應(yīng)用較多的場景比如實時大屏、實時報表等。
傳輸模型標(biāo)準(zhǔn)
對于一個批處理系統(tǒng)，其節(jié)點間數(shù)據(jù)傳輸?shù)臉?biāo)準(zhǔn)模型是：當(dāng)一條數(shù)據(jù)被處理完成后，序列化到緩存中，并不會立刻通過網(wǎng)絡(luò)傳輸?shù)较乱粋€節(jié)點，當(dāng)緩存寫滿，就持久化到本地硬盤上，當(dāng)所有數(shù)據(jù)都被處理完成后，才開始將處理后的數(shù)據(jù)通過網(wǎng)絡(luò)傳輸?shù)较乱粋€節(jié)點。
對于一個流處理系統(tǒng)，其節(jié)點間數(shù)據(jù)傳輸?shù)臉?biāo)準(zhǔn)模型是：當(dāng)一條數(shù)據(jù)被處理完成后，序列化到緩存中，然后立刻通過網(wǎng)絡(luò)傳輸?shù)较乱粋€節(jié)點，由下一個節(jié)點繼續(xù)處理
這兩種數(shù)據(jù)傳輸模式是兩個極端，對應(yīng)的是流處理系統(tǒng)對低延遲的要求和批處理系統(tǒng)對高吞吐量的要求。
1.1.5、流批一體
流批一體的執(zhí)行引擎采用了一種十分靈活的方式，同時支持了這兩種數(shù)據(jù)傳輸模型，以 Flink 為例，F(xiàn)link 以緩存塊為單位進(jìn)行網(wǎng)絡(luò)數(shù)據(jù)傳輸,用戶可以設(shè)置緩存塊超時時間和緩存塊大小來控制緩沖塊傳輸時機,從而控制 Flink 的延遲性和吞吐量。
Flink 以固定的緩存塊為單位進(jìn)行網(wǎng)絡(luò)數(shù)據(jù)傳輸，用戶可以通過設(shè)置緩存塊超時值指定緩存塊的傳輸時機；
如果緩存塊的超時值為 0，則 Flink 的數(shù)據(jù)傳輸方式類似上文所提到流處理系統(tǒng)的標(biāo)準(zhǔn)模型，此時系統(tǒng)可以獲得最低的處理延遲；
如果緩存塊的超時值為無限大，則 Flink 的數(shù)據(jù)傳輸方式類似上文所提到批處理系統(tǒng)的標(biāo)準(zhǔn)模型，此時系統(tǒng)可以獲得最高的吞吐量；
同時緩存塊的超時值也可以設(shè)置為 0 到無限大之間的任意值。緩存塊的超時閾值越小，則 Flink 流處理執(zhí)行引擎的數(shù)據(jù)處理延遲越低，但吞吐量也會降低，反之亦然。通過調(diào)整緩存塊的超時閾值，用戶可根據(jù)需求靈活地權(quán)衡系統(tǒng)延遲和吞吐量；
默認(rèn)情況下，流中的元素并不會一個一個的在網(wǎng)絡(luò)中傳輸，而是緩存起來伺機一起發(fā)送(默認(rèn)為 32KB，通過taskmanager.memory.segment-size設(shè)置),這樣可以避免導(dǎo)致頻繁的網(wǎng)絡(luò)傳輸,提高吞吐量，但如果數(shù)據(jù)源輸入不夠快的話會導(dǎo)致后續(xù)的數(shù)據(jù)處理延遲，所以可以使用 env.setBufferTimeout(默認(rèn)100ms)，來為緩存填入設(shè)置一個最大等待時間。等待時間到了之后，即使緩存還未填滿，緩存中的數(shù)據(jù)也會自動發(fā)送；
ltimeoutMillis > 0 表示最長等待 timeoutMillis 時間，就會 flush；
ltimeoutMillis = 0 表示每條數(shù)據(jù)都會觸發(fā) flush，直接將數(shù)據(jù)發(fā)送到下游，相當(dāng)于沒有 Buffer 了(避免設(shè)置為 0，可能導(dǎo)致性能下降)；
ltimeoutMillis = -1 表示只有等到 buffer滿了或 CheckPoint 的時候，才會 flush。相當(dāng)于取消了 timeout 策略。
1.1.6、有狀態(tài)流處理
狀態(tài)是計算過程之中需要存儲的數(shù)據(jù)，可能是數(shù)據(jù)本身也可能是計算結(jié)果。狀態(tài)在內(nèi)存中速度快但可靠性差，在分布式系統(tǒng)中則相反。
有狀態(tài)的流處理就是把流處理需要的額外數(shù)據(jù)保存成一個“狀態(tài)”，然后針對這條數(shù)據(jù)進(jìn)行處理，并且更新狀態(tài)。
1.2、Flink的運行模式
1.2.1、Local模式
Flink中的Local-cluster(本地集群)模式,單節(jié)點運行，主要用于測試, 學(xué)習(xí)。
1.2.2、Standalone模式
獨立集群模式是獨立運行的，由Flink自身提供計算資源，不依賴任何外部的資源管理平臺。當(dāng)然獨立也是有代價的，如果資源不足，或者出現(xiàn)故障，沒有自動擴展或重分配資源的保證，必須手動處理。所以獨立 模式一般只用在開發(fā)測試或作業(yè)非常少的場景下。
1.2.3、Yarn模式
YARN 上部署的過程是客戶端把 Flink 應(yīng)用提交給 Yarn 的 ResourceManager，Yarn 的 ResourceManager 會 向 Yarn 的 NodeManager 申 請 容 器 。 在 這 些 容 器 上 ， Flink 會 部 署 JobManager 和 TaskManager 的實例，從而啟動集群。Flink 會根據(jù)運行在 JobManger 上的作業(yè) 所需要的 Slot 數(shù)量動態(tài)分配 TaskManager 資源。
在yarn模式下，啟動flink集群之前要啟動yarn和hadoop，以Yarn模式部署Flink任務(wù)時，要求Flink有Hadoop支持的版本。Flink1.10要求Hadoop環(huán)境需要保證版本在2.2以上，并且集群中安裝有HDFS服務(wù)。
1.2.4、K8S 運行模式
容器化部署是如今業(yè)界流行的一項技術(shù)，基于 Docker 鏡像運行能夠讓用戶更加方便地對 應(yīng)用進(jìn)行管理和運維。容器管理工具中最為流行的就是 Kubernetes（k8s），而 Flink 也在最近 的版本中支持了 k8s 部署模式?；驹砼c YARN 是類似的。
1.3、Flink特性
1.3.1、自帶狀態(tài)管理機制
Flink 應(yīng)用程序的狀態(tài)訪問都在本地進(jìn)行，因為這有助于其提高吞吐量和降低延遲。通常情況下 Flink 應(yīng)用程序都是將狀態(tài)存儲在 JVM 堆上，但如果狀態(tài)太大，我們也可以選擇將其以結(jié)構(gòu)化數(shù)據(jù)格式存儲在高速磁盤中。
通過狀態(tài)快照實現(xiàn)的容錯，通過狀態(tài)快照和流重放兩種方式的組合，F(xiàn)link 能夠提供可容錯的，精確一次計算的語義。這些狀態(tài)快照在執(zhí)行時會獲取并存儲分布式 pipeline 中整體的狀態(tài)，它會將數(shù)據(jù)源中消費數(shù)據(jù)的偏移量記錄下來，并將整個 job graph 中算子獲取到該數(shù)據(jù)（記錄的偏移量對應(yīng)的數(shù)據(jù)）時的狀態(tài)記錄并存儲下來。當(dāng)發(fā)生故障時，F(xiàn)link 作業(yè)會恢復(fù)上次存儲的狀態(tài)，重置數(shù)據(jù)源從狀態(tài)中記錄的上次消費的偏移量開始重新進(jìn)行消費處理。而且狀態(tài)快照在執(zhí)行時會異步獲取狀態(tài)并存儲，并不會阻塞正在進(jìn)行的數(shù)據(jù)處理邏輯。
Flink 為什么要參與狀態(tài)管理？
在 Flink 不參與管理狀態(tài)的情況下，我們的應(yīng)用也可以使用狀態(tài)，但 Flink 為其管理狀態(tài)提供了一些引人注目的特性：
本地性: Flink 狀態(tài)是存儲在使用它的機器本地的，并且可以以內(nèi)存訪問速度來獲取
持久性: Flink 狀態(tài)是容錯的，例如，它可以自動按一定的時間間隔產(chǎn)生 checkpoint，并且在任務(wù)失敗后進(jìn)行恢復(fù)
縱向可擴展性: Flink 狀態(tài)可以存儲在集成的 RocksDB 實例中，這種方式下可以通過增加本地磁盤來擴展空間
橫向可擴展性: Flink 狀態(tài)可以隨著集群的擴縮容重新分布
可查詢性: Flink 狀態(tài)可以通過使用 狀態(tài)查詢 API 從外部進(jìn)行查詢。
1.3.2、強大的準(zhǔn)確性保證
exactly-once 狀態(tài)一致性
事件時間處理
在流式計算領(lǐng)域中，窗口計算的地位舉足輕重，但目前大多數(shù)框架窗口計算采用的都是系統(tǒng)時間(Process Time)，也就是事件傳輸?shù)接嬎憧蚣芴幚頃r，系統(tǒng)主機的當(dāng)前時間。Flink 能夠支持基于事件時間(Event Time)語義進(jìn)行窗口計算，這種基于事件驅(qū)動的機制使得事件即使亂序到達(dá)甚至延遲到達(dá)，流系統(tǒng)也能夠計算出精確的結(jié)果，保持了事件原本產(chǎn)生時的時序性，盡可能避免網(wǎng)絡(luò)傳輸或硬件系統(tǒng)的影響
專業(yè)的遲到數(shù)據(jù)處理
1.3.3、靈活豐富的多層API
越頂層越抽象，表達(dá)含義越簡明，使用越方便
越底層越具體，表達(dá)能力越豐富，使用越靈活
Stateful Stream Processing（有狀態(tài)流處理）
通過底層API（處理函數(shù)），對最原始數(shù)據(jù)加工處理。底層API與DataStream API相集成，可以處理復(fù)雜的計算。
DataStream/DataSet API（流處理/批處理）
封裝了底層處理函數(shù)，提供了通用的模塊，比如轉(zhuǎn)換（transformations，包括 map、flatmap等），連接（joins），聚合（aggregations），窗口（windows）操作等。
Flink1.12以后，DataStream API已經(jīng)實現(xiàn) 真正的流批一體，所以DataSet API已經(jīng)過時。
Table API
是以表為中心的聲明式編程，其中表可能會動態(tài)變化。Table API遵循關(guān)系模型：表有二維數(shù)據(jù)結(jié)構(gòu)，類似于關(guān)系數(shù)據(jù)庫 中的表；同時API提供可比較的操作，例如select、project、join、group-by、aggregate等。我們可以在表與 DataStream/DataSet 之間無縫 切換，以允許程序?qū)?Table API 與 DataStream 以及 DataSet 混合使用。
SQL
這一層在語法與表達(dá)能力上與 Table API 類似，但是是以SQL查詢表達(dá)式的形式表現(xiàn)程序。SQL抽象與Table API交互密切，同 時SQL查詢可以直接在Table API定義的表上執(zhí)行。 ?
1.3.4、規(guī)模彈性擴展
可擴展的分布式架構(gòu)
集群級別的資源規(guī)模靈活配置，算子粒度的獨立并行度靈活配置
支持超大狀態(tài)管理
增量 checkpoint 機制
1.3.5、強大的運維能力
彈性實施部署機制
高可用配置
本身高可用的設(shè)置，加上與K8s，YARN 和 Mesos 的緊密集成，再加上從故障中 快速恢復(fù)和動態(tài)擴展任務(wù)的能力，F(xiàn)link 能做到以極少的停機時間 7×24 全天候運
保存點恢復(fù)機制
Flink 通過 SavePoints 技術(shù)將任務(wù)執(zhí)行的快照保存在存儲介質(zhì)上，當(dāng)任務(wù)重啟的時候，可以從事先保存的 SavePoints 恢復(fù)原有的計算狀態(tài)。Flink 保存點提供了一個狀態(tài)化的版本機制，使得能以無丟失狀態(tài)和最短停機時間的方式更新應(yīng)用或者回退歷史數(shù)據(jù)。
1.3.6、優(yōu)秀的性能
低延遲 、高吞吐
在處理大量數(shù)據(jù)的基礎(chǔ)上同時能快速返回計算的結(jié)果每秒處理數(shù)百萬個事件，毫秒級延遲
內(nèi)存計算
Flink 實現(xiàn)了基于 JVM 的自身管理內(nèi)存的機制，通過使用散列、索引、緩存和排序有效地進(jìn)行內(nèi)存管理，通過序列化/反序列化機制將所有的數(shù)據(jù)對象轉(zhuǎn)換成二進(jìn)制在內(nèi)存中存儲，降低數(shù)據(jù)存儲大小的同時，更加有效的利用空間。使其獨立于 Java 的默認(rèn)垃圾收集器，盡可能減少 JVM GC 對系統(tǒng)的影響
1.4、應(yīng)用場景
1.4.1、數(shù)據(jù)分析（Data Analytics Applications）
數(shù)據(jù)分析任務(wù)需要從原始數(shù)據(jù)中提取有價值的信息和指標(biāo)，Data Analytics Applications 包含 Batch analytics(批處理分析)和Streaming analytics(流處理分析)：
Batch analytics 可以理解為周期性查詢，Batch Analytics 就是傳統(tǒng)意義上使用類似于Map Reduce、Hive、Spark Batch 等，對作業(yè)進(jìn)行分析、處理、生成離線報表。比如Flink應(yīng)用凌晨從Recorded Events中讀取昨天的數(shù)據(jù)，然后做周期查詢運算，最后將數(shù)據(jù)寫入Database 或者 HDFS，或者直接將數(shù)據(jù)生成報表供公司上層領(lǐng)導(dǎo)決策使用。 Streaming analytics 可以理解為連續(xù)性查詢：比如實時展示雙十一天貓銷售 GMV(Gross Merchandise Volume成交總額)，用戶下單數(shù)據(jù)需要實時寫入消息隊列，F(xiàn)link 應(yīng)用源源不斷讀取數(shù)據(jù)做實時計算，然后不斷的將數(shù)據(jù)更新至 Database 或者 K-VStore，最后做大屏實時展示。
典型實例
電信網(wǎng)絡(luò)質(zhì)量監(jiān)控
移動應(yīng)用中的產(chǎn)品更新及實驗評估分析
消費者技術(shù)中的實時數(shù)據(jù)即席分析
大規(guī)模圖分析
1.4.2、數(shù)據(jù)管道（Data Pipeline Applications）
什么是數(shù)據(jù)管道？提取-轉(zhuǎn)換-加載(ETL)是一種在存儲系統(tǒng)之間進(jìn)行數(shù)據(jù)轉(zhuǎn)換和遷移的常用方法。ETL 作業(yè)通常會周期性地觸發(fā)，將數(shù)據(jù)從事務(wù)型數(shù)據(jù)庫拷貝到分析型數(shù)據(jù)庫或數(shù)據(jù)倉庫。數(shù)據(jù)管道和 ETL 作業(yè)的用途相似，都可以轉(zhuǎn)換、豐富數(shù)據(jù)，并將其從某個存儲系統(tǒng)移動到另一個。但數(shù)據(jù)管道是以持續(xù)流模式運行，而非周期性觸發(fā)。因此數(shù)據(jù)管道支持從一個不斷生成數(shù)據(jù)的源頭讀取記錄，并將它們以低延遲移動到終點。
? ?例如：數(shù)據(jù)管道可以用來監(jiān)控文件系統(tǒng)目錄中的新文件，并將其數(shù)據(jù)寫入事件日志；另一個應(yīng)用可能會將事件流物化到數(shù)據(jù)庫或增量構(gòu)建和優(yōu)化查詢索引。和周期性 ETL 作業(yè)相比，持續(xù)數(shù)據(jù)管道可以明顯降低將數(shù)據(jù)移動到目的端的延遲。此外，由于它能夠持續(xù)消費和發(fā)送數(shù)據(jù)，因此用途更廣，支持用例更多。
下圖描述了周期性 ETL 作業(yè)和持續(xù)數(shù)據(jù)管道的差異：
Periodic ETL：比如每天凌晨周期性的啟動一個Flink ETL Job，讀取傳統(tǒng)數(shù)據(jù)庫中的數(shù)據(jù)，然后做ETL，最后寫入數(shù)據(jù)庫和文件系統(tǒng)。
? ?Data Pipeline：比如啟動一個Flink 實時應(yīng)用，數(shù)據(jù)源(比如數(shù)據(jù)庫、Kafka)中的數(shù)據(jù)不斷的通過Flink Data Pipeline流入或者追加到數(shù)據(jù)倉庫(數(shù)據(jù)庫或者文件系統(tǒng))，或者Kafka消息隊列。
Data Pipeline 的核心場景類似于數(shù)據(jù)搬運并在搬運的過程中進(jìn)行部分?jǐn)?shù)據(jù)清洗或者處理，而整個業(yè)務(wù)架構(gòu)是 Periodic ETL，它提供了流式 ETL 或者實時 ETL，能夠訂閱消息隊列的消息并進(jìn)行處理，清洗完成后實時寫入到下游的 Database 或 File system 中。
典型實例
電子商務(wù)中的持續(xù) ETL(實時數(shù)倉)：
當(dāng)下游要構(gòu)建實時數(shù)倉時，上游則可能需要實時的 Stream ETL。這個過程會進(jìn)行實時清洗或擴展數(shù)據(jù)，清洗完成后寫入到下游的實時數(shù)倉的整個鏈路中，可保證數(shù)據(jù)查詢的時效性，形成實時數(shù)據(jù)采集、實時數(shù)據(jù)處理以及下游的實時查詢。
電子商務(wù)中的實時查詢索引構(gòu)建(搜索引擎推薦)：
搜索引擎這塊以淘寶為例，當(dāng)賣家上線新商品時，后臺會實時產(chǎn)生消息流，該消息流經(jīng)過 Flink 系統(tǒng)時會進(jìn)行數(shù)據(jù)的處理、擴展。然后將處理及擴展后的數(shù)據(jù)生成實時索引，寫入到搜索引擎中。這樣當(dāng)淘寶賣家上線新商品時，能在秒級或者分鐘級實現(xiàn)搜索引擎的搜索。
1.4.3、事件驅(qū)動（Event-driven Applications）
? ? ? ?事件驅(qū)動型應(yīng)用是一類具有狀態(tài)的應(yīng)用，它從一個或多個事件流提取數(shù)據(jù)，并根據(jù)到來的事件觸發(fā)計算、狀態(tài)更新或其他外部動作。事件驅(qū)動型應(yīng)用是在計算存儲分離的傳統(tǒng)應(yīng)用基礎(chǔ)上進(jìn)化而來。在傳統(tǒng)架構(gòu)中，應(yīng)用需要讀寫遠(yuǎn)程事務(wù)型數(shù)據(jù)庫。相反，事件驅(qū)動型應(yīng)用是基于狀態(tài)化流處理來完成。在該設(shè)計中，數(shù)據(jù)和計算不會分離，應(yīng)用只需訪問本地(內(nèi)存或磁盤)即可獲取數(shù)據(jù)。系統(tǒng)容錯性的實現(xiàn)依賴于定期向遠(yuǎn)程持久化存儲寫入 checkpoint。下圖描述了傳統(tǒng)應(yīng)用和事件驅(qū)動型應(yīng)用架構(gòu)的區(qū)別：
從某種程度上來說，所有的實時的數(shù)據(jù)處理或者是流式數(shù)據(jù)處理都應(yīng)該是屬于 Data Driven，流計算本質(zhì)上是 Data Driven 計算。應(yīng)用較多的如風(fēng)控系統(tǒng)，當(dāng)風(fēng)控系統(tǒng)需要處理各種各樣復(fù)雜的規(guī)則時，Data Driven 就會把處理的規(guī)則和邏輯寫入到Datastream 的API 或者是 ProcessFunction 的API 中，然后將邏輯抽象到整個 Flink 引擎，當(dāng)外面的數(shù)據(jù)流或者是事件進(jìn)入就會觸發(fā)相應(yīng)的規(guī)則，這就是 Data Driven 的原理。在觸發(fā)某些規(guī)則后，Data Driven 會進(jìn)行處理或者是進(jìn)行預(yù)警，這些預(yù)警會發(fā)到下游產(chǎn)生業(yè)務(wù)通知，這是 Data Driven 的應(yīng)用場景，Data Driven 在應(yīng)用上更多應(yīng)用于復(fù)雜事件的處理。預(yù)警的流程如下圖：
典型實例
欺詐檢測(Fraud detection)
異常檢測(Anomaly detection)
基于規(guī)則的告警(Rule-based alerting)
業(yè)務(wù)流程監(jiān)控(Business process monitoring)
