最近在復(fù)盤我自己在 Apache Airflow 上的運(yùn)維經(jīng)驗(yàn)時，我發(fā)現(xiàn)一個規(guī)律：很多坑，其實(shí)書上都寫過，只是我們第一次做的時候沒太重視。今天這篇文章，我就結(jié)合《Airflow Ops: Development and Deployment》這一章的內(nèi)容，把我對 Airflow 開發(fā)與部署 的理解整理成一篇筆記式博客，既是給大家的參考，也算是我自己的總結(jié)。

一、前置要求

如果你要讀懂這一篇，建議你已經(jīng)具備以下基礎(chǔ)：

? 熟悉 Airflow 的基本概念和組件；

? 至少用過一種 CI/CD 工具（Jenkins / GitLab CI / GitHub Actions / Travis CI 等）；

? 對 Docker 或容器化應(yīng)用 有一定了解，知道怎么構(gòu)建和分發(fā)鏡像。

我不會寫具體的 CI/CD 實(shí)現(xiàn)細(xì)節(jié)，因?yàn)槊考夜镜募夹g(shù)棧不同，但我會總結(jié)一些常見模式，大家可以結(jié)合自己環(huán)境去落地。

二、DAG 部署方式

Airflow 的核心是 DAG（工作流），而在生產(chǎn)環(huán)境下，我們最常面對的問題就是：如何把 DAG 部署到運(yùn)行的 Airflow 集群。

主要有兩類模式：

1. Bundling（打包部署）

最直接的方法：把 DAG 和 Airflow 本身打包到同一個鏡像里。典型流程是：

? 在構(gòu)建鏡像時安裝 Airflow；

? 把 DAG 文件拷貝進(jìn)去；

? 打上 tag，然后分發(fā)。

優(yōu)點(diǎn)：

? 所有組件（Airflow、插件、DAG）版本完全一致，強(qiáng)一致性；

? 部署完就能跑，幾乎不會出現(xiàn)「某臺機(jī)器少了一個 DAG」的情況。

缺點(diǎn)：

? 鏡像大、構(gòu)建慢；

? 每次改 DAG 都要重啟所有服務(wù)，停機(jī)時間長。

?? 我的經(jīng)驗(yàn)：適合 初期 或者 快速試錯 階段，改 DAG 的頻率高但團(tuán)隊(duì)還沒完全穩(wěn)定時，可以用這個模式。

2. Decoupled DAG Delivery（解耦 DAG 交付）

這里把 Airflow 系統(tǒng) 和 DAG 分開管理。Airflow 鏡像本身比較穩(wěn)定，DAG 通過掛載 volume 的方式動態(tài)加載。

優(yōu)點(diǎn)：

? DAG 更新獨(dú)立，不用動整個 Airflow 部署；

? Airflow 本身作為長期運(yùn)行系統(tǒng)更穩(wěn)定。

缺點(diǎn)：

? 需要額外的文件分發(fā)機(jī)制（共享存儲、Git 同步等）；

? DAG 的依賴管理要自己控制。

在這個模式下，有兩種具體玩法：

? Push 模式：CI/CD 直接把 DAG 推到 Airflow 的共享文件系統(tǒng)。實(shí)現(xiàn)簡單，但災(zāi)難恢復(fù)時需要手動再觸發(fā)。

? Pull 模式：Airflow 自己拉取 DAG，比如用 git-sync[1] 定時拉取代碼庫。自動化程度高，更推薦。

?? 我的建議：前期用 Bundling，后期系統(tǒng)穩(wěn)定后切到 Pull 模式的解耦方案，這樣能兼顧效率和靈活性。

三、代碼庫結(jié)構(gòu)

看似是小事，其實(shí)非常關(guān)鍵。Airflow 項(xiàng)目的 repo 結(jié)構(gòu)決定了團(tuán)隊(duì)的協(xié)作模式。

1. Mono-repo（單倉庫）

所有東西放一個倉庫：Airflow 構(gòu)建腳本、插件、DAG 全都在里面。

優(yōu)點(diǎn)：

? 適合「Working at HEAD」模式，大家改的代碼隨時能看到；

? 協(xié)作簡單，依賴關(guān)系透明。

缺點(diǎn)：

? 倉庫大，CI/CD 流水線復(fù)雜；

? 多團(tuán)隊(duì)并行時容易打架。

2. Multi-repo（多倉庫）

把 Airflow 系統(tǒng)、插件、各團(tuán)隊(duì)的 DAG 分開維護(hù)，互相獨(dú)立。

優(yōu)點(diǎn)：

? 各團(tuán)隊(duì)能獨(dú)立開發(fā)和部署；

? CI/CD 更輕量。

缺點(diǎn)：

? 協(xié)調(diào)成本高，容易出現(xiàn)版本不一致；

? 需要更強(qiáng)的集成測試。

?? 我的實(shí)踐：推薦 混合模式：

? 一個 核心 mono-repo 放 Airflow 鏡像和內(nèi)部插件；

? 各團(tuán)隊(duì)自己維護(hù) DAG 的 repo，依賴核心鏡像做本地測試。

這樣既能保證穩(wěn)定性，也能讓團(tuán)隊(duì)靈活。

四、連接與變量管理

Airflow 的 Connection 和 Variable 是 DAG 運(yùn)行的關(guān)鍵參數(shù)，很多時候里面還會包含敏感信息。

? 環(huán)境變量：可以直接用 AIRFLOW_VAR_XXX 或 AIRFLOW_CONN_XXX 注入。但不太安全，一般要配合 外部密鑰管理系統(tǒng)。

? Secrets Backend：Airflow 原生支持 AWS Secrets Manager、GCP Secret Manager、HashiCorp Vault、Azure Key Vault 等。推薦在生產(chǎn)環(huán)境使用。

?? 建議：和安全團(tuán)隊(duì)溝通好，統(tǒng)一走 密鑰管理系統(tǒng)，不要在 WebUI 里手工點(diǎn)配置。

五、Airflow 部署方式

根據(jù)團(tuán)隊(duì)基礎(chǔ)設(shè)施的成熟度，可以選擇不同的部署方式：

? Kubernetes：官方 Helm Chart 非常成熟，推薦優(yōu)先選擇。

? 虛擬機(jī) / 裸機(jī)：除非已有歷史包袱，否則不建議自建，太重。

? 托管服務(wù)：比如 Astronomer、MWAA（AWS Managed Workflows for Apache Airflow）、Google Composer，能大大降低運(yùn)維成本，但會有一定廠商鎖定。

六、本地開發(fā)環(huán)境

要寫 DAG，最重要的就是 快速試錯。常見的本地環(huán)境有三種：

? Python venv：輕量，適合入門，但和生產(chǎn)環(huán)境差異大。

? Docker Compose：能模擬多組件，更接近生產(chǎn)，但需要多一些本地資源。

? 云開發(fā)環(huán)境：彈性最好，但搭建門檻高。

?? 我個人偏愛 Docker Compose，既能跑出一個小型 Airflow 集群，又不會太重。

七、測試策略

Airflow 的測試很容易被忽視。我的體會是：測試不在于多，而在于「能不能讓我們少掉坑」。

常見的測試層級：

? DAG 測試

Smoke Test：檢查 DAG 合法性（能不能 import）。

Unit Test：單元測試 DAG 中的自定義函數(shù)。

Functional Test：驗(yàn)證 DAG 在特定數(shù)據(jù)下的行為。

Performance Test：檢查性能指標(biāo)（時延、內(nèi)存、CPU 等）。

? Provider 測試

          Smoke Test：能否安裝。

         Unit Test：用 Mock 框架模擬外部服務(wù)。

         Integration Test：和真實(shí)服務(wù)打通。

        Airflow 本身不建議自己測，交給社區(qū)維護(hù)者就好，除非你改了 Airflow 源碼。

八、總結(jié)

這篇筆記大致涵蓋了 Airflow 部署和開發(fā)的一整套流程：

1. 選擇合適的 DAG 部署模式（前期 bundling，后期 decoupled + pull）。

2. 設(shè)計(jì)合理的 repo 結(jié)構(gòu)（核心 mono-repo + 多個 DAG repo）。

3. 用 secrets backend 管理敏感信息。

4. 根據(jù)團(tuán)隊(duì)情況選擇部署方式（K8s / VM / 托管服務(wù)）。

5. 給開發(fā)者提供本地或云端環(huán)境，保證迭代效率。

6. 制定合理的測試分層方案，保證穩(wěn)定性。

寫到這里，感覺這篇筆記算是把 Airflow 部署的「必修課」梳理了一遍。對我自己來說，最大收獲是：別想著一步到位，要根據(jù)團(tuán)隊(duì)階段選擇最合適的模式。