以下是「向現有 DataFrame 添加雜湊」的任務如何從花費幾天時間到消耗幾乎整個衝刺的過程。
2022 年第二季度,我開始開發一個資料管道,該管道從 REST 服務獲取市場資料並將其儲存在 BigQuery 表中。這是管道的高級解釋。有趣的部分是如何查詢數據,將其轉換為 DataFrame,然後使用 AirFlow 的 GCSToBigQueryOperator 上傳 BigQuery 表。
最初,看起來寫起來很簡單,但 Airflow 的「冪等」原理給它增加了一些挑戰。從該 REST 服務獲取的內容由另一個表決定,即使 JOB 是冪等的,它用作參考的表也可能在兩次運行之間發生變化。經過額外的時間,與資料工程師的溝通管道已於 2022 年第三季末準備就緒。
快轉到 2024 年第一季。此時,我們有更多用戶存取數據,我們意識到我們的查詢模式沒有正確使用分區。或者更確切地說,我們想要基於字串列存取數據,但無法在 BigQuery 中對字串列進行分區。這導致掃描大量數據並經常達到每日配額。
這促使我們考慮如何根據字串列對資料進行分區。我們的資料工程師建議使用 FarmHash 並附加類比運算將該字串列轉換為整數。在概念驗證中,這減少了近 90% 的掃描,查詢效能提高了 3-5 倍。我們決定繼續將此作為最終解決方案。我們所需要的只是:
為了在 Python 中計算 FarmHash 指紋,有一個 pyfarmhash 模組。我安裝了該模組並使用下面的程式碼來計算哈希值,並且在本地一切都按預期工作。
def get_hash(val: str) -> int: return additonal_logic(pyfarmhash.fingerprint64(...)) df[‘hash’] = df[‘Col’].apply(get_hash)
隨著所有測試的通過,現在是時候將程式碼推送到 Airflow 並運行它了。我沒想到在這個階段會出現任何問題。事實上,我很高興一切都按計劃並在預計的時間內進行。
懷著愉快的心情和充滿信心,我推動了我的改變,開始了工作,然後等待了 10-15 分鐘讓它完成。同時,我切換到另一項任務。很快,我收到了一封來自 Airflow 的意外失敗電子郵件。我查看了日誌,並驚訝地發現安裝 pyfarmhash 模組時失敗了!
為了幫助您理解問題,我需要解釋一下作業的結構。作業有以下步驟:
在這個過程中,下載資料的task-1是一個單獨的Python模組。為了運行它,我使用了 Airflow 中的 PythonVirtualenvOperator。此操作符可讓您根據需要指定套件,然後將它們安裝在新建立的虛擬環境中。安裝套件後,它的所有依賴項也會安裝,您就可以開始使用了。
我加入了 pyfarmhash 作為下載資料的模組的依賴項,其他一切保持不變。但它失敗了!為什麼?
pyfarmhash 是一個用 C/C++ 實作的雜湊函式庫。安裝後,它需要 GCC 來編譯軟體包,而 Airflow 主機上不存在該軟體包。在 Airflow 主機上不安裝 GCC 是有道理的,但不幸的是,這對我來說是一個障礙。
我尋找了 pyfarmhash 套件的純 Python 實現,但沒有。然後,我尋找車輪包裝,但同樣沒有。我考慮過建造輪子包並推動它們,但這將導致在內部提供輪子包的長期責任。我想避免額外的、類似解決方法的步驟。我探索了所有選項,並與維護 Airflow 的團隊進行了討論。他們建議建立一個 Docker 映像並在 KubernetesPodOperator 中運行它。這是一個不錯的選擇,因為我可以控制環境並包含所需的任何內容,而無需依賴外部環境。此外,該解決方案沒有解決方法。唯一的短期缺點是需要更多時間來實施。
在開始使用基於 Docker 的解決方案之前,我已經在這項任務上花費了大約 16-20 個小時。對於基於 Docker 的解決方案,我還需要:
由於我不再在 Airflow 中使用 PythonVirtualEnvOperator,我決定完全刪除它並改進工作流程。我必須更改 python 套件以具有開始下載和清除邏輯的入口點
我又花了 30-36 個小時才準備好了 Docker 映像的最終解決方案,這需要 6-7 個工作日,加上最初的 2 天,它變成了一項漫長的衝刺任務。
我回顧這一點並想知道,我不得不放棄工作解決方案,更改模組結構,創建 docker 映像,更改 10 多個 AirFlow 作業以使用 Docker 映像執行任務,處理這個現實並克服最初的挫敗感。所有這一切只是因為,「單一 python 模組需要「gcc」來編譯!」
以上是估計編碼任務:可能會出現什麼問題?的詳細內容。更多資訊請關注PHP中文網其他相關文章!