前言
本文隸屬于專欄《1000個問題搞定大資料技術體系》，該專欄為筆者原創，參考請注明來源，不足和錯誤之處請在評論區幫忙指出，謝謝！
本專欄目錄結構和參考文獻請見1000個問題搞定大資料技術體系
正文
在專欄前面我們已經介紹過
可以通過window視窗來統計每一段時間或者每多少條資料的一些數值統計，
請參考我的這篇博客——一篇文章搞懂 Flink 的 Window
但是也存在另外一個問題，就是如果資料有延遲該如何解決，例如一個視窗定義的是每隔五分鐘統計一次，我們應該在上午九點至九點零五分這段時間統計一次資料的結果值，但是由于某一條資料由于網路延遲，資料產生時間是在九點零三分，資料到達我們的flink框架已經是在十點零三分了，這種問題怎么解決？
再例如：
原始日志如下：
日志自帶時間
2020-10-10 10:00:01,134 INFO executor.Executor: Finished task in state 0.0
資料進入flink框架時間：
這條資料進入Flink的時間是2020-10-10 20:00:00,102
資料被window視窗處理時間：
到達window處理的時間為2020-10-10 20:00:01,100
Time 三兄弟是什么？
為了解決這個問題，flink在實時處理當中，對資料當中的時間規劃為以下三個型別
針對stream資料中的時間，可以分為以下三種
?Event Time：事件產生的時間，它通常由事件中的時間戳描述，
?Ingestion time：事件進入Flink的時間
?Processing Time：事件被處理時當前系統的時間
可以參考我的這篇博客——什么是事件時間和處理時間？
1、EventTime詳解
- 事件生成時的時間，在進入Flink之前就已經存在，可以從event的欄位中抽取，
- 必須指定watermarks（水位線）的生成方式，
- 優勢：確定性，亂序、延時、或者資料重放等情況，都能給出正確的結果
- 弱點：處理無序事件時性能和延遲受到影響
2、IngestTime
- 事件進入flink的時間，即在source里獲取的當前系統的時間，后續操作統一使用該時間，
- 不需要指定watermarks的生成方式(自動生成)
- 弱點：不能處理無序事件和延遲資料
3、ProcessingTime
- 執行操作的機器的當前系統時間(每個算子都不一樣)
- 不需要流和機器之間的協調
- 優勢：最佳的性能和最低的延遲
- 弱點：不確定性 ，容易受到各種因素影像(event產生的速度、到達flink的速度、在算子之間傳輸速度等)，壓根就不管順序和延遲
4、三種時間的綜合比較
性能： ProcessingTime> IngestTime> EventTime
延遲： ProcessingTime< IngestTime< EventTime
確定性： EventTime> IngestTime> ProcessingTime
5、如何設定time型別
在我們創建StreamExecutionEnvironment的時候可以設定time型別，不設定time型別，默認是processingTime，如果設定time型別為eventTime，那么必須要在我們的source之后明確指定Timestamp Assigner & Watermark Generator
// 設定時間特性
val environment: StreamExecutionEnvironment = StreamExecutionEnvironment.getExecutionEnvironment
// 不設定Time 型別，默認是processingTime，
// 如果使用EventTime則需要在source之后明確指定Timestamp Assigner & Watermark Generator
environment.setStreamTimeCharacteristic(TimeCharacteristic.ProcessingTime)
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/294164.html
標籤：其他
上一篇：一篇文章搞懂 Flink 的 watermark 機制
下一篇：Flink 內核原理與實作-應用