1.流式處理flink介紹

實時服務依賴流式處理:

flink優點:

• 高性能
• 豐富的特性：
  
  構建flink的4個基礎：
  
  Streaming:
  
• 流是有序的事件
• 業務數據總是一個流：有界流 或無界流
• 對于flink,批處理僅是一個特殊的場景,在流運行時
  
  The job Graph(Topology):
  • 運行中的flink 應用稱作job
  • 運行中的flink應用（job)以及通過數據管道處理稱作JobGraph(工作圖)
  • Job Graph是一個有向圖（DAG）,數據流從source流向sink,被operator處理
    

Stream processing:

• Parallel:是由于分隔事件流成并行sub-stream,各自可以獨立處理
  

• Forward：重定向一個事件流，優化上下游銜接非常有效

• Repartition（分隔）
  

• Rebalance： rebalance非常昂貴，就像網絡抖動一樣，需要序列化每個事件，并且使用網絡
  

• broadcasting :廣播數據到分布式系統集群

Stream processing with SQL：

2.Flink SQL介紹

例子:


Flink SQL的特點：


append-only 、insert-only

Flink SQL 模式：
1. Streaming and Batch

2. Streaming only模式

3.Batch only 模式:

通過docker運行flink SQL CLI

• 安裝dockerdesktop

• 執行 docker compose version

• 克隆 flink練習代碼倉：https://github.com/confluentinc/learn-apache-flink-101-exercises.git

• 進入本地clone項目的根目錄，執行構建docker compose命令：
  

• 運行sql-client
  docker compose run sql-client

• 但sql-client啟動成功，可以看到flink SQL CLi提示

  Flink SQL>
  

• 然后可以進行 Flink SQL的一些操作

3. Flink Runtime

運行時架構（runtime Architecture）

Flink streaming VS Batch

Streaming	Batch
Bounded or unbounded streams	only bounded streams
Entrie pipeline must always be running	Execution proceeds in stages,running as needed
Input must be processed as it arrives	Input may be pre-sorted by time and key
Results are reported as they become ready	Results are repored at the end of the job
Failure recovery resumes from a recent snapshot	Failure recovery does a reset and full restart
Flink guarantees effectively exactly-once result ,despite out-of-order data and restarts due to failures.	Effectively exactly-once gurantees are more straightforward

flink task有三種狀態：

1. idle
2. busy
3. backpressured:the task is unable to send output downstream because the downstream task is busy

總結

streaming 提供了立刻響應的場景，如下：

• 監控告警
• 欺詐檢測（fraud detection）

Batch processing 更好，因為它效率更高效

4.使用flink集成kafka

kafka主要組件

kafka架構

kafka事件結構：

flink table 與topic的映射關系

映射kafka topics成flink table

flink format

flink需要知道協作的kafka topic的數據格式是什么

Flink可以作為kafka,實時應用、流水線的計算層

5.使用Flink SQL進行有狀態流處理

6.Event time & Watermarks

Time

out-of-order event time

watermarks

kafka source operator 從kafka partition 讀取



waermarkark就是分區的最小值，如：1:05

一旦watermark被生成，source會發送它到下游

flink job不產生結果的原因分析以及解決方法:



水印的使用（watermark):

7. flink Checkpoints & recovery

1.checkpoint

• checkpoint就是flink自動產生的快照，主要用于失敗恢復
• savepoint是一種手動創建的快照，主要為了運維的目的，如：有狀態的升級->升級flink到最新的版本

flink使用Chandy-Lamport 分布式快照算法解決以下問題：

• flink生成不是期望的結果
• flink生成重復
  
  
  2.故障恢復(recovery)
  
  
  水印衡量著無序流中事件時間的進度