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（版本），時間戳擴充字段的小技巧，以幫助使用者在生産環境中提升實時資料故障修複效率以及可用性。

公衆号(mangodata)裡回複 flink 關鍵字可以擷取 flink 的學習資料以及視訊。