Pinterest為何遷移到新的大資料處理工作流平臺Apache Airflow?
在這篇文章中,我們將解釋我們如何處理和設計將舊系統遷移到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 的混合解決方案增加的成本開銷是不小的。
方法和要求
我們的平臺已將我們的遷移要求定義為:
- 需要最少的使用者程式碼更改
- 遷移時不間斷地執行生產工作流程
- 為舊系統設定一個日期並完成棄用
鑑於這些,我們可以透過兩種主要方式進行此遷移:
- 請求工作流所有者在 Airflow DSL 中重寫他們的舊工作流,並在此過渡過程中為他們提供支援
- 平臺提供了直接進行 DSL 翻譯的工具
使用方法 1,它將減少我們和使用者的技術債務,並且平臺不必維護額外的基礎設施,但由於所有定製的使用者邏輯和依賴項都放入了傳統的 Pinball 作業,因此存在一些重大挑戰。即使沒有這些挑戰,我們也沒有在這個提案中得到客戶的支援,因為每個團隊的成本將是太多的工程時間。最後,這可能會推遲舊系統的棄用,因為我們需要依靠我們的客戶來完成工作,這使得它不可行。
因此,我們的方法被證明更接近方法 2——我們在 Airflow 排程程式中構建了一個遷移層,它在動態解析 dag 檔案期間將舊工作流系統中的工作流定義轉換為 Airflow 有向無環圖 (DAG)。這意味著不會有任何使用者程式碼更改和最少的使用者參與,為使用者提供透明的遷移體驗。舊工作流中的每個作業都被轉換為專門實施以支援工作流遷移用例的包裝器運算子型別。在執行期間,操作員啟動一個新的 k8s pod,該 pod 使用舊系統的映像啟動舊作業的實際邏輯。透過這種方式,我們可以為翻譯任務模擬遺留系統的執行環境。
相關文章
- 剖析大資料平臺的資料處理大資料
- Apache Wayang :跨平臺資料處理系統Apache
- 大資料處理平臺都有哪些?大資料
- [譯] Airflow: 一個工作流程管理平臺AI
- Spotify如何從Apache kafka遷移到雲平臺的pub/sub系統ApacheKafka
- 大資料平臺之大資料處理系統的架構大資料架構
- airflow 進行後端大資料中ETL處理(草稿)AI後端大資料
- Hadoop大資料平臺有何優勢?Hadoop大資料
- 為何我們前端從Vue 2遷移到Svelte?前端Vue
- 以企業級實時資料平臺為例,瞭解何為敏捷大資料敏捷大資料
- 22個大資料開發處理框架平臺和工具大資料框架
- 從圖森未來的資料處理平臺,看Serverless 工作流應用場景Server
- 從Hive遷移到SparkSQL,有讚的大資料實踐HiveSparkSQL大資料
- 平臺利用大資料割韭菜,消費者為何淪為砧板上的魚肉大資料
- 大資料技術 - Airflow大資料AI
- MySQL資料庫遷移到PostgresMySql資料庫
- RocketMQ Connect 構建流式資料處理平臺MQ
- 高效處理日均5000億+資料:58集團基於Apache SeaTunnel的資料整合平臺架構最佳化Apache架構
- 企業遷移到雲平臺是如何降低成本的?
- 不care工具,在大資料平臺中Hive能自動處理SQL大資料HiveSQL
- GoldenGate實時投遞資料到大資料平臺(7)– Apache HbaseGo大資料Apache
- 從微服務遷移到工作流的經驗之談微服務
- 資料平臺、大資料平臺、資料中臺……還分的清不?大資料
- Apache DolphinScheduler + OceanBase,搭建分散式大資料排程平臺的實踐Apache分散式大資料
- Apache Hop新執行資訊記錄平臺Apache
- 資料融合平臺,資料服務一站式處理
- 槓上Spark、Flink?Kafka為何轉型流資料平臺SparkKafka
- 槓上 Spark、Flink?Kafka 為何轉型流資料平臺SparkKafka
- 大資料處理的基本流程大資料
- 你的資料庫真的需要遷移到雲嗎?資料庫
- 恆訊科技分享:伺服器資料遷移到新的伺服器方法伺服器
- 使用記憶體NewSQL資料平臺來處理實時資料流的三個好處記憶體SQL
- java大資料處理:如何使用Java技術實現高效的大資料處理Java大資料
- 三種大資料流處理框架選擇比較:Apache Kafka流、Apache Spark流和Apache Flink - quora大資料框架ApacheKafkaSpark
- Apache Airflow 2.3.0 釋出ApacheAI
- 企業為何需要搭建大資料平臺大資料
- 如何實現CDH到雲原生大資料平臺的快速平滑遷移?大資料
- 數棧產品分享:基於StreamWorks構建實時大資料處理平臺大資料