30 天挑戰就這樣默默過了一半呢！在第二階段，我們把資料工程中重要的排程設計，透過軟體工程的角度切入探討。

在過去的六篇文章中，我們探討了如何將程式碼模組化、工作流程編排、任務相依性設計，並讓 Airflow 的 backfill 可以確保資料有可重現性。最後以 Docker 來運行 Airflow，確保開發環境配置的一致性以及協作上的效率。這些概念都在資料工程中扮演了關鍵角色。這篇總回顧將綜合這些概念，重新梳理它們在軟體工程與資料工程中的應用與重要性。

Key Takeaways | 軟體工程設計錦囊

在 Day 10 ，透過將程式碼切割成獨立模組，我們可以將複雜的邏輯簡化，並降低重複性。這不僅讓開發者能快速定位與修改錯誤，亦提升了團隊協作的效率。程式碼模組化是軟體工程中提升程式碼可維護性與複用性的基礎。對於資料工程師來說，程式碼模組化可運用在資料管道設計上，確保每個流程都能獨立測試與維護。

Day 11 討論的工作流程編排工具 Airflow 提供了任務編排能力，讓我們能夠以 DAG (有向無環圖) 的方式設計並管理資料工程任務。Airflow 的優勢是讓工作流程視覺化，在設計複雜的 data pipeline 上很有助益。

基於 Airflow 的 Best Practice：讓 DAG 盡量單純地控管線性的任務串，Day 12 的主題任務相依性設計提到了 sensor, trigger, dataset 三種設計方式。透過清楚的相依設計，確保各項工作在合適的時間點被觸發，避免資料轉換不如預期或流程中斷。在軟體開發裏面也有類似的概念，特別是在多層架構或微服務中，各元件間的運作連動關係。

Day 13 在探討可重現性時對資料工程的影響。在資料工程中，每次運行 DAG 或進行資料回溯時，結果都應該是一致的。資料不應該被操作者的差異，或是操作時間的差異所改變，這也正是 data pipeline 設計上需要謹慎之處。此外，我們也說明了資料工程上談的可重現性和軟體工程所述冪等性的差異。

最後兩篇 Day 14、Day 15 都在談論開發環境建置。我們利用 Docker 容器化技術來確保開發者之間開發環境一致，創造了多人協作的可能性。運用 Airflow 編排資料工作流程，提升了 data pipeline 的可擴展性。

小回顧｜和合作夥伴的關係

Q1：資料分析師也需要瞭解軟體工程的概念嗎？

A：
程式碼模組化是一個非常實用的概念，即便是資料分析的流程，透過模組化的方式編寫分析的程式碼，在進行分析版本的迭代 (根據商業需求調整分析邏輯的反覆過程) 比較容易找出問題的核心進而修正，不會在 spaghetti code 裏迷失。

Q2：後端工程師也需要用上 Airflow 嗎？

A：
Airflow 的本質是「排程器」，所以問題應該調整成「後端工程上有任何需要排程的功能嗎？」舉例：我們做一個網購系統，想固定在每個星期一午夜發送優惠券給特定消費特徵的顧客，那就需要排程囉！
Airflow 只是在資料工程上常用的排程工具而已，理由是它的視覺化做得很好，對於複雜流程管控很有幫助，不用在黑畫面裡苦思無解。它的另個特性是適合批量導向工作流程，也就是一次性地處理多筆資料，而非即時處理單筆資料，這恰好也是 OLAP 與 OLTP 的性質差異了。

Catalogue | 給你的快速連結

[09/29] 《資料與程式碼的交鋒》Day 15 - 用 Docker 運行 Airflow
[09/28] 《資料與程式碼的交鋒》Day 14 - 開發環境
[09/27] 《資料與程式碼的交鋒》Day 13 - 可重現性
[09/26] 《資料與程式碼的交鋒》Day 12 - 任務相依性設計
[09/25] 《資料與程式碼的交鋒》Day 11 - 工作流程編排工具 Airflow
[09/24] 《資料與程式碼的交鋒》Day 10 - 程式碼模組化