FLink底層引擎是一個(gè)流式引擎，支持流處理和批處理龄糊，而window是streaming到batch的橋梁奴曙。因?yàn)榱魈幚磉^程中，數(shù)據(jù)是源源不斷流進(jìn)來的邓厕，需要對數(shù)據(jù)進(jìn)行實(shí)時(shí)處理的話逝嚎，可以通過來一個(gè)消息處理一個(gè)的方式，也可以通過把一段時(shí)間內(nèi)的數(shù)據(jù)聚合之后详恼，再一起處理的形式补君，此時(shí)需要定義一個(gè)窗口來收集過去那段時(shí)間內(nèi)的數(shù)據(jù)再進(jìn)行處理。
Flink 提出了三種時(shí)間的概念昧互，分別是event time（事件時(shí)間：事件發(fā)生時(shí)的時(shí)間）挽铁，ingestion time（攝取時(shí)間：事件進(jìn)入流處理系統(tǒng)的時(shí)間）伟桅，processing time（處理時(shí)間：消息被計(jì)算處理的時(shí)間）。
窗口類型
窗口可以是時(shí)間驅(qū)動的（Time Window叽掘，例如：每30秒鐘）楣铁，也可以是數(shù)據(jù)驅(qū)動的（Count Window，例如：每一百個(gè)元素）够掠。一種經(jīng)典的窗口分類為：
- Tumbling window （滾動窗口民褂，無重疊）
- sliding window （滑動窗口相叁，時(shí)間有重疊）
滑動窗口分配器將元素分配給固定長度的窗口遵绰。類似于滾動窗口分配器，窗口的大小由窗口大小參數(shù)配置增淹。另外一個(gè)參數(shù)控制滑動窗口的啟動頻率椿访。因此，如果頻率小于窗口尺寸虑润，滑動窗可以重疊成玫。在這種情況下，元素被分配到多個(gè)窗口拳喻。
例如哭当，使用大小為10分鐘的窗口，滑過5分鐘冗澈。如下圖所示钦勘。
- session window（會話窗口，無重疊）
會話窗口通過活動會話分配組元素亚亲。與滾動窗口和滑動窗口相比彻采，會話窗口不重疊，沒有固定的開始和結(jié)束時(shí)間捌归。相反颊亮，當(dāng)會話窗口在一段時(shí)間內(nèi)沒有接收到元素時(shí)，即當(dāng)發(fā)生不活動的間隙時(shí)關(guān)閉陨溅。會話窗口分配器配置有會話間隙，定義所需的不活動時(shí)間長度绍在。當(dāng)此時(shí)間段到期時(shí)门扇，當(dāng)前會話關(guān)閉雹有，后續(xù)元素被分配到新的會話窗口。
還可以分別結(jié)合以時(shí)間驅(qū)動或者數(shù)據(jù)驅(qū)動臼寄，如：sliding time window,tumbling count window霸奕。
窗口常用的組件：
Window Assigner ：決定某個(gè)元素被分配到哪個(gè)/哪些窗口中去。
Trigger ： 觸發(fā)器吉拳，進(jìn)行窗口的處理或清除质帅，每個(gè)窗口都會擁有一個(gè)的Trigger。
Evictor ： “驅(qū)逐者”留攒，類似filter作用煤惩。在Trigger觸發(fā)之后，window被處理前炼邀，EVictor用來處理窗口中無用的元素魄揉。
窗口應(yīng)用在join操作
由以上可以得知，若要對兩條數(shù)據(jù)流進(jìn)行join操作拭宁，則一定是基于window形式的洛退，同樣的還有和join操作類似的CoGroupedStreams〗鼙辏可以發(fā)現(xiàn)兵怯，F(xiàn)link中joinStream會通過調(diào)用windowStream來實(shí)現(xiàn)。如圖腔剂。
接下來媒区，對join的一個(gè)實(shí)現(xiàn)類WindowJoin進(jìn)行分析⊥靶基本思想為在一個(gè)時(shí)間窗內(nèi)對兩條數(shù)據(jù)結(jié)構(gòu)為鍵值對數(shù)據(jù)流進(jìn)行inner join操作驻仅。
重要參數(shù)配置：根據(jù)Flink的時(shí)間概念，時(shí)間屬性時(shí)間選為ingestion time登渣，并設(shè)置了窗口大小和數(shù)據(jù)傳輸速率噪服。
函數(shù)調(diào)用
where（）:給兩條數(shù)據(jù)流指定各自的keySelector，獲取key的類型
equal（）判斷key是否相同
-
window（）:制作一個(gè)ID標(biāo)識符胜茧，配置窗口中的
- 輸入流DataStream粘优、keySelector、key type等元數(shù)據(jù)
- 窗口組件window assigner呻顽、Trigger雹顺、EVictor
image.png apply（）：配置join操作方法
最后通過execute（）執(zhí)行inner join操作
問題
join 窗口的雙流數(shù)據(jù)都是被緩存在內(nèi)存中的，也就是說如果某個(gè)key上的窗口數(shù)據(jù)太多就會導(dǎo)致 JVM OOM廊遍。雙流join的難點(diǎn)也正是在這里嬉愧。例如可以借鑒Flink在批處理join中的優(yōu)化方案，也可以像HDFS對中間結(jié)果的操作那樣喉前，當(dāng)數(shù)據(jù)超過閾值時(shí)能spill到硬盤没酣。
