Tips | Flink sink schema 字段設計小技巧
公衆号(mangodata)裡回複 flink 關鍵字可以擷取 flink 的學習資料以及視訊。
本系列每篇文章都比較短小,不定期更新,從一些實際的 case 出發抛磚引玉,提高小夥伴的姿♂勢水準。本文介紹 Flink sink schema 字段設計小技巧,閱讀時長大概 2 分鐘,話不多說,直接進入正文!
sink schema 中添加 version 版本字段
如 title,直接上實踐案例和使用方式。
實踐案例及使用方式
- 非故障場景下産出的每條記錄的 version 字段值為 1
- 故障場景下,可以在同一 sink 中産出 version > 1(非 1)的資料,代表故障修複資料提供給下遊消費
可應對的故障場景
上遊 flink 任務 A 發生故障導緻産出髒資料至 kafka X,并且下遊消費方可以按照下面兩類進行劃分:
- 下遊為 flink 任務:flink 任務 B 消費 kafka X 中的髒資料,結果計算并産出錯誤資料
- 下遊為 OLAP 引擎以及 BI 看闆:結果導緻看闆展示資料異常
首先介紹下避免以及處理上述問題的整體思路:
- 1.優化邏輯,保障上遊任務穩定性:首先通過一些優化手段,盡可能保證上遊 flink 任務 A 不出現故障
- 2.配置作業監控報警:針對整條鍊路配置對應的監控報警等,以及時發現和定位問題
- 3.制定故障處理、修複預案:需要制定對應的故障處理、修複預案,一旦出現故障,需要有可處理故障的能力
- 4.下遊針對資料源特性改進消費和處理方式:保障即使消費了髒資料也不會對業務邏輯産生影響
下文主要介紹第 2 點,出現上述故障時修複的方案,針對以上場景,目前有如下 3 種可選方案修複資料:
- 方案 1 - 離線方式修複:通過離線方式産出修複資料,對髒資料進行覆寫操作。缺點是故障修複延遲較高,需要切換離線、實時資料源,人工操作成本較高
- 方案 2 - 實時方式修複:重跑修數邏輯,産出修複資料至 kafka X-fix,下遊 flink 任務 B 重新從 kafka X-fix 中的指定 offset 開始消費,計算并産出正确的資料。此方案對下遊 flink 任務 B 來說,需要改動代碼邏輯,存在修數 topic 和原 topic 切換邏輯,修複邏輯較為複雜
- 方案 3 - 實時方式修複(本小節 version 字段方案):為避免下遊産生資料源切換操作帶來的高成本操作,可在原有 kafka topic 中産出修複資料,通過 version 字段區分正常産出資料以及修複資料,相對方案 1 和 2 的優點在于,不存在資料源切換邏輯,下遊通過控制 version 字段值就可消費到對應的修複資料,明顯降低人工操作成本,且修複邏輯相對簡單
Note: 方案 3 需要對 Kafka X 預留一定的 buffer,否則在産出修複資料時,由于寫入或讀出 Kafka X 的 QPS 過高,會影響正常産出資料的任務。
sink schema 中添加時間戳字段
實踐案例及使用方式
有視窗場景中,sink schema 中可添加以下字段:
- flink_process_start_time(long):代表 flink 視窗開始邏輯處理的時間戳
- flink_process_end_time(long):代表 flink 視窗結束邏輯處理的時間戳
- window_start(long):代表 flink 視窗開始時間戳
- window_end(long):代表 flink 視窗結束時間戳
生産實踐案例
- flink_process_start_time,flink_process_end_time 在開發、測試、驗數階段可幫助使用者定位資料偏差原因
- window_start,window_end 可以幫助使用者定位每個視窗處理是否有丢數,及每個視窗處理的具體資料
總結
本文主要介紹了在 sink schema 中添加 version(版本),時間戳擴充字段的小技巧,以幫助使用者在生産環境中提升實時資料故障修複效率以及可用性。