Pinterest為何遷移到新的大資料處理工作流平臺Apache Airflow?

banq發表於2022-03-01

在這篇文章中,我們將解釋我們如何處理和設計將舊系統遷移到Apache Airflow、以及與我們所有的工程師團隊協調以將 3000 多個工作流無縫遷移到 Airflow。
 
Pinterest 的理念始終以資料為中心。作為一家資料驅動的公司,這意味著所有攝取的資料都將被儲存以供進一步使用。這看起來像是每天600 TB的新資料,包含超過500 PB的總資料。在這種規模下,大資料工具在使我們公司能夠收集有意義的見解方面發揮著關鍵作用。這就是工作流團隊的用武之地。我們幫助促進了 4000 多個工作流,這些工作流平均每天產生 10,000 次流程執行和 38,000 次每日作業執行。
 
早在 2013 年,Pinterest 就構建了一個名為Pinball的內部排程程式框架。該解決方案適合當時公司的需求,但無法隨著需求的增加而擴大規模,從而為內部和外部的其他產品和服務提供服務。
 
2019 年,我們對 Spotify 的Luigi、LinkedIn 的Azkaban和一些替代方案進行了初步分析,但我們最終還是選擇了 Apache 的Airflow,原因如下:
  • 目標對齊:我們的使用者要求的功能要麼已經內建在 Airflow 中,要麼可以新增到當前的版本中。
  • 行業:它被許多組織廣泛採用,有一個活躍的社群承諾,促進大量討論,並有很好的文件供我們的使用者檢視。
  • DSL:它是基於 python 的,與我們之前的系統保持一致,我們的使用者將在這裡減少差異。
  • 程式碼:Airflow 是用模組編寫的,因此更容易使用單獨的元件來連線自定義部件。
  • 擴充套件性:它包含重啟可以恢復的無狀態元件,UI 從中央資料庫中提取,並允許我們為我們的 kubernetes 基礎設施和可分割槽排程程式插入主要部分。
  • 聲譽:總體而言,社群似乎對 Airflow 的產品感到滿意

 

按照我們的標準,成功遷移過程的關鍵是:
  • 瞭解並填補 Airflow 與我們之前擁有的內部工作流系統之間的差距。我們確定了功能差距、安全差異以及使用者習慣的術語。
  • 提供遷移工具,以低成本方式同時大規模遷移多個工作流並進行驗證。
  • 擁有清晰和持續的使用者溝通和入職材料,例如 wiki、培訓課程、積極的使用者支援和公告。
  • 啟用無狀態 UI 排程程式分割槽,並啟用 Kubernetes 整合以提供定製和可擴充套件的解決方案。
  • 擁有清晰的 CI/CD 管道,使系統保持一致、可靠和高效,以維護多個基礎架構分支。
  • 嚴格測試——單元測試和整合測試都在暫存環境中進行,以防止破壞性更改並採取謹慎的部署方法。
  • 維護執行狀況檢查和綜合指標,並在負載增加時發出警報以進行微調。

 
需要注意的最重要的一點包括:
  • 確保計劃在遷移前後保持一致。以前系統和 Spinner 系統的排程間隔並不總是一致,因為定義排程程式的方式不同(舊系統並非完全基於 cron)。因此,防止誤跑和超跑。
  • 為每個任務配置資源,例如記憶體設定,以防止任務在啟動前失敗。
  • Kubernetes pod 的預熱成本不是我們預期的。pod 啟動延遲確實有一個重要的成本,對於您的團隊用例來說,它必須是總體上可以接受的。
  • Kubernetes pod 冗餘邊車可能會因網路問題而增加延遲,並且可能會為您的工作流程增加排程延遲。
  • 對使用者教育和支援的投資可能很高。
  • 維護舊 DSL 和新 Airflow DSL 的混合解決方案增加的成本開銷是不小的。

 

方法和要求
我們的平臺已將我們的遷移要求定義為:

  1. 需要最少的使用者程式碼更改
  2. 遷移時不間斷地執行生產工作流程
  3. 為舊系統設定一個日期並完成棄用

鑑於這些,我們可以透過兩種主要方式進行此遷移:
  1. 請求工作流所有者在 Airflow DSL 中重寫他們的舊工作流,並在此過渡過程中為他們提供支援
  2. 平臺提供了直接進行 DSL 翻譯的工具

使用方法 1,它將減少我們和使用者的技術債務,並且平臺不必維護額外的基礎設施,但由於所有定製的使用者邏輯和依賴項都放入了傳統的 Pinball 作業,因此存在一些重大挑戰。即使沒有這些挑戰,我們也沒有在這個提案中得到客戶的支援,因為每個團隊的成本將是太多的工程時間。最後,這可能會推遲舊系統的棄用,因為我們需要依靠我們的客戶來完成工作,這使得它不可行。
因此,我們的方法被證明更接近方法 2——我們在 Airflow 排程程式中構建了一個遷移層,它在動態解析 dag 檔案期間將舊工作流系統中的工作流定義轉換為 Airflow 有向無環圖 (DAG)。這意味著不會有任何使用者程式碼更改和最少的使用者參與,為使用者提供透明的遷移體驗。舊工作流中的每個作業都被轉換為專門實施以支援工作流遷移用例的包裝器運算子型別。在執行期間,操作員啟動一個新的 k8s pod,該 pod 使用舊系統的映像啟動舊作業的實際邏輯。透過這種方式,我們可以為翻譯任務模擬遺留系統的執行環境。

相關文章