作者 | 張志豪

數據工程領域當前遇到的挑戰

現代系統正變得越來越復雜，從單線程到多線程，從單體到微服務，從單節點到分布式，從本地到云端... … 復雜度使得程序產生預期的結果需要越來越多的必要條件，而每種條件都有其自身的成功概率，即使每種條件的成功概率都很高，根據墨菲定律，或早或晚一定會遇到不可預知的結果。

在數據工程領域，這個問題尤其突出，目前大數據領域幾乎都是分布式運行的任務、高可用的消息隊列、多備份的存儲、主從節點等等。在這樣的情況下，如何構建穩定、健壯的任務或服務成為了一個挑戰。而數據工程實踐中每日調度的任務成為了與各個復雜數據組件交互的最主要形式，所以本文我們將以數據工程的任務調度為例，利用混沌工程幫助我們找出系統薄弱點或脆弱性，引出我們沉淀的基于日志驅動的任務調度實踐。

什么是混沌工程？

混沌工程是在系統上進行實驗的學科, 目的是建立對系統抵御生產環境中失控條件的能力以及信心。(摘自：混沌工程原則)混沌工程通過以下四個步驟來找出系統中隱藏的“混沌”：

• 用系統在正常行為下的一些可測量的輸出來定義“穩定狀態”。
• 假設這個系統在控制組和實驗組都會繼續保持穩定狀態。
• 在實驗組中引入反映真實世界事件的變量，如服務器崩潰、硬盤故障、網絡連接斷開等。
• 通過控制組和實驗組之間的狀態差異來反駁穩定狀態的假說。

混沌工程實驗是通過向現有系統注入故障，從而發現系統的薄弱點，從而可以有針對性地提高整個系統的健壯性。

環境都是高可用的，應該很健壯啊

有些人可能會有疑問，“我們環境都是高可用的，應該很健壯啊”。這個問題還是要分開來看，健壯的系統能夠忠實執行程序邏輯并得到最終結果。但是如果程序邏輯就是有問題的呢？或者，即使程序邏輯沒有問題，由于程序本身的脆弱性，在系統從錯誤中恢復時可能沒有處理一些必要的邏輯，導致最終結果出現問題。因此，系統級別的高可用性或健壯性與程序級別的健壯性是兩回事，必須分開看待。二者缺一不可。在工程實踐中，我們往往會過于關注基礎設置是否具備高可用性，而忽略了程序邏輯的健壯性和錯誤恢復處理。

僅僅是冪等就足夠了嗎？

有些人認為他們的程序是冪等的，因此即使出錯了可以重跑，所以不需要考慮其他。這里先講一下冪等的定義：總能夠用同樣的參數重復執行，并得到相同的結果。

那我們可以按照混沌工程的四個步驟來模擬一個場景出來：

(1) 用系統在正常行為下的一些可測量的輸出來定義“穩定狀態”，這里嘗試定義“穩定狀態”為：

• ETL計算結果穩定且正確(冪等)
• 資源隊列占用合理，提交的任務不需要等待太久就可以運行
• 過去的數據不會被重復計算
• 同一時刻不發生重復計算

(2) 假設這個系統在控制組和實驗組都會繼續保持穩定狀態。

(3) 在實驗組中引入反映真實世界事件的變量：手動調度任務時頁面卡住了，習慣性多點了幾次，刷新頁面后發現調度起來了十幾個任務。

(4) 通過控制組和實驗組之間的狀態差異來反駁穩定狀態的假說：

• 資源隊列被打滿，新調度的任務都得排隊（不符合穩定狀態條件2）
• 重跑并覆蓋過去已經運行過的數據（計算資源浪費，不符合穩定狀態條件3）
• 計算同一天的數據幾十次，而最終只留了最后那份（計算資源浪費，不符合穩定狀態條件4）

通過上面的模擬實驗我們可以知道，雖然ETL是滿足冪等性（即穩定狀態條件1）的，但是由于沒有滿足其他幾個穩定狀態，所以我們可以說它仍然是存在脆弱性的。

反脆弱的任務調度應該是什么樣的？

圖片

對于一個每日運行的任務來說，理想情況下它應該每天都能成功完成，但實際情況下很可能會遇到失敗的情況。不同的調度引擎往往對失敗的情況有不同的處理方式。例如，有的調度引擎會忽略過去失敗的任務并繼續開啟下一個調度周期。比如跳過了2022年2月2日的任務，繼續運行2022年2月3日的任務。但當發現任務出現問題后，就需要手動補數據并重新運行2022年2月2日的任務，以便將數據完整地補齊。如果在這期間有報表使用了2022年2月2日的數據，那么這些報表的數據肯定是不準確的。

然而，完全依賴任務調度工具有一些缺點。首先，它完全依賴于調度工具的任務歷史記錄。如果沒有配置失敗通知機制，那么需要一個個去查看哪個任務掛掉了。其次，如果允許失敗任務之后的任務繼續運行，可能會導致對順序有要求的場景出現問題。比如，假設2月3日的數據在MySQL中進行了upsert操作，而2月2日的數據在重新運行失敗任務后又執行了一次，那么就會導致用舊的數據覆蓋新的數據的問題等等。

雖然一些調度框架在適當的配置時可以解決上述問題，但無法保證所有調度框架都能解決這些問題，或者你的項目對調度框架沒有自由選擇的余地。因此，在實踐中，我們需要在ETL任務和實際調度框架（如Airflow等）中引入“日志驅動”的這一層抽象隔離，以便為任務運行添加一層統一的邏輯處理。這樣做可以使得ETL任務在不同的調度框架下表現一致，更加符合大家的預期，也不局限于某一個特定的調度框架。這樣我們就得以擺脫特定框架的局限，而不是讓每個人都要熟悉常見、不常見的調度框架。

數據工程的任務調度實踐

前述問題的一個難點在于在處理重復提交的任務時如何隔離不同調度系統的具體實現。

我認為數據工程的任務調度應該以“日志驅動”作為解決方案。而日志驅動的重要部分“日志解耦”正是處理這個問題的利器：我們需要判斷是不是有任務已經提交過了，對不對？同時要考慮到隔離不同調度系統，所以方案自然是需要一個單獨的地方保存這些調度日志，以便在調度任務時檢查是否需要調度（是否有相同任務在運行或者這個任務是否已經運行過等），從而解耦不同具體組件的日志。

注意這里的“日志”并不是任務運行的日志，而是調度任務的日志，記錄的是那個任務在哪個時間調度，狀態是什么等等。應用“日志驅動”所帶來的的好處，遠不止于此，因為留存了任務調度日志的記錄，在這個基礎上很多事情變得可能。其實“日志驅動”和“斷點續傳”這個概念很像，只不過沒有應用在下載文件上，而是應用到了任務調度。日志驅動有幾個核心要點：

• 自行記錄任務運行歷史，而不依賴與調度框架的功能。這樣就做到了與不同調度框架解綁；
• 調度是有序的，上個周期任務失敗了，不會跳過它運行下個周期的任務，每次調度還是會先執行之前失敗的任務，直到它成功；

日志驅動也帶來了幾點好處：

• 可以解決重復調度的問題，當任務運行后發現有相同任務在運行或者已經運行過了，當前任務可以直接退出或者kill掉之前的任務
• 補數據操作更加容易實現且靈活而不容易出錯
• 更加靈活的任務依賴配置（任務上下游不一定是同頻率或者必須在一個dag里面）
• 更加靈活的調度起始設置，例如對于kafka offset和自增主鍵的支持
• 更加統一且容易的運維操作（不同的項目、不同的調度引擎，都可以基于日志驅動(的表)來進行運維操作）
• 可以記錄更加詳細的任務狀態，比如讀到多少條數據，寫了多少條數據等等（特指結構化記錄，而不是普通的執行日志），方便做統計查看
• 可以自行選擇事務級別，或者說可以讓用戶選擇是否要“臟讀”數據
• 還有一些其他好處，篇幅有限就不在此展開了

圖片

回到現實場景，任務失敗的情況大致可以分為兩種：

• 重試就可以成功（網絡閃崩，排隊超時等）
• 代碼、環境有問題需要人工介入的

對于重試就可以成功的情況，往往在下一次調度就可以自動補上之前失敗的任務的數據；如果不想等到下一個周期，可以人工馬上調度一次。

對于無法重試成功的情況，往往每次調度都會掛掉，但是只會嘗試最開始的那天的任務，因為前置的任務沒有成功，只是在每天重試 2022-02-02 的任務；無法重試成功的任務，仍然需要人工介入，修復（環境、邏輯、上游數據等問題）之后，自動（按順序）補上之前掛掉的任務的數據；

總結

通過混沌工程的虛擬實驗我們知道常規的任務調度并不足夠健壯，而日志驅動的加入可以讓ETL任務更加穩定。同時日志驅動也帶來了諸多好處，不僅僅解決了混沌工程的穩定性問題，也更加豐富了數據工程實踐。