如何快速實現REST API集成以優化業務流程
最終，一個快速的歷史天氣 API 被構建出來，我希望它能簡化許多學生、學術研究人員和記者的工作，因為長時間序列的天氣數據很難找到。
這篇文章包括：
在學術領域工作時，學生們經常面臨一項挑戰：獲取歷史天氣數據來深入分析他們假設。隨著氣候變化和更極端的天氣模式，許多記者依靠測量來客觀評估當前的熱浪或干旱是否創下了新的記錄高點還是“僅僅是天氣”。
國家氣象服務（NWS）通常是獲取氣象數據的一個良好開端，因為它們已經運營了高質量的觀測站長達數十年。一些 NWS 會在開放數據服務器上提供 CSV 或科學數據格式的數據。其他 NWS 則甚至不會根據請求共享數據。
高質量的氣象站根據 WMO 標準測量天氣，其他一些則是最近才使用普通硬件安裝的，測量結果不太可靠，維護間隔不頻繁。質量、準確性和可靠性各不相同。
即使你找到了你國家的氣象站數據，也很可能沒有靠近你感興趣地點的氣象站，或者時間序列數據不完整或不一致。你可以通過結合多個來源的數據、填補空白、確保一致性和使用天氣模型來彌補站點之間的較大距離來解決這個問題，但這樣做需要時間。
許多研究人員在過去面臨這些問題，并開始研究“再分析”天氣數據集。原理是：
因此，再分析數據集可以提供全球一致的歷史天氣數據，受到物理模型的約束。再分析仍然依賴于測量數據，但空白和不一致可以更容易地被糾正。
最有聲望的再分析數據集之一是歐洲哥白尼計劃與 ECMWF 合作的 ERA5，它也用于 Open-Meteo 的歷史天氣 API。
ERA5 是歐盟公共資助的哥白尼計劃的第五個再分析天氣數據集，由 ECMWF 實施。ERA5 作為開放數據可用，你可以從氣候數據商店（CDS）下載。
它提供全球30公里分辨率和每小時值的天氣數據。有數百種天氣變量可用，其中一些在達到80公里高度的137個大氣層上。
數據自2019年起可用，但自2022年6月起，實時數據集現從1959年至今可用，延遲5-7天。
到目前為止，ERA5 是最受認可的歷史天氣數據集之一，被用于許多農業、能源和保險應用。
獲取 ERA5 很簡單。注冊一個賬戶，接受開放數據的許可條款，并使用 CDS 客戶端 Python 庫，你就可以開始下載了。然而，有一個缺點：ERA5非常龐大！
我沒有找到確切的數字，但數據大小必須超過1PB（1024TB）。即使你只對少數天氣變量感興趣，如溫度、降水和風，你很快就需要下載1TB或更多。對于 Open-Meteo 來說，有23個天氣變量，需要從 CDS 下載超過20TB的數據。而這些數據已經壓縮過了！
處理這么大量的數據很快就變成了一個計算機科學實踐，對于只需要幾個地點時間序列數據的研究者來說，這是一種痛苦。
“歷史天氣 API”已經存在。一些商業天氣提供商基于天氣模型或站點測量提供歷史數據。大多數只在他們最昂貴的“頂級”商業提供中提供，數據來源并不完全清楚。
為了彌補商業提供和花費數周下載 ERA5 之間的差距，Open-Meteo 現在提供一個免費的（非商業用途）ERA5 API。
新的歷史天氣 API 的工作方式完全像 Open-Meteo 預報 API，但你需要指定開始和結束日期。你可以直接選擇從1959年1月1日到現在的完整時間間隔。
獲取數據可能需要一段時間。特別是首次調用 API 獲取完整60年的數據需要幾秒鐘。API 以 JSON 格式的響應超過 8MB。
連續調用 API 更快，因為對同一數據的多次磁盤訪問被緩存（稍后會談到性能）。
通過集成的圖表，你可以快速探索數據，放大并更詳細地查看數據。或者選擇“下載XLSX”并在電子表格應用程序中繼續你的分析。
數據在全球任何陸地表面都可用，除了南極洲和遠北地區之外。這種限制是為了保持所需存儲要求較低而必要的。
盡管這些數據基于測量并通過天氣模型增強，但與本地測量仍存在顯著差異。
首先，歷史天氣 API 使用30公里分辨率的網格化數據，因此不能表示溫度、風或降水的非常小規模模式。即使相距不到100米的測量站也會測量出不同的溫度。
具有對流性降水（陣雨）的雷暴非常局部，雨量在幾公里內就有所不同。然而，像全國范圍的干旱這樣的大規模模式被相當好地捕獲。極端事件如個別的熱記錄也可能不準確，但溫度上升的總趨勢非常明顯。
如果你想使用這些數據進行自己的分析，請注意潛在的與實際本地測量的偏差。
處理大量數據并非易事。盡管只使用了 ERA5 的23個天氣變量，但從氣候數據商店（CDS）下載的數據量超過了20TB。
為了更好地理解為什么 ERA5 需要這么多數據存儲，讓我們看看數字：
47TB 的存儲容量聽起來令人印象深刻，也肯定是每個商業產品宣傳頁面的頭號數據。然而，數據壓縮技術的存在使得實際情況并非如此。
幸運的是，CDS API 已經使用壓縮（NetCDF 與 deflate）來減少所需空間的一半。
不用說，普通電腦無法存儲如此大量的數據并處理我這套臨時拼湊而成的數據集。因此，我不得不在家里改進了一下我的工作站。
為了獲得約 50TB 的可用存儲，我使用了 ZFS 文件系統來組合幾個大硬盤。此外，ZFS 還通過校驗和確保數據完整性。大多數硬盤的錯誤率為每 12TB 一個位錯誤。幾乎可以肯定，在下載的 ERA5 數據集中至少會有一個位錯誤。
此時，距離一個 API 還很遙遠。為了從下載的數據集中訪問連續的時間序列，所有數據必須被解壓縮以讀取單個位置。
因為 API 每次調用只返回一個位置的數據，我們旋轉維度來存儲時間序列，然后單獨壓縮每個時間序列。如果 API 讀取德國柏林的溫度序列，它只需要解壓縮一小部分。使用許多文件格式，如 zarr 或 NetCDF，可以輕松完成（NetCDF中的“塊維度”）。
不幸的是，壓縮效果并不好。使用 NetCDF，一些技巧可以提高壓縮效果：
使用長時間序列，縮放和增量編碼可以將壓縮提高2倍。代替22TB，大約需要10TB。
即使是10TB，對于運行一個簡單的 API 來說，由于這個大小仍然遠非理想。僅將這些數據存儲在 Amazon S3 上每月的成本就是250美元，而這還只是純粹的存儲。
現代壓縮算法，如 Zstd、Brotli 或 lz4 的性能略好于 NetCDF 數據格式中的默認 deflate 算法，大約提高20%，但壓縮后無法直接使用。
由于天氣變化緩慢，增量編碼保持值非常小，可以使用整數壓縮算法 Patched Frame of Reference (PFOR)。它的效果驚人地好，進一步將大小減少到 6TB。
天氣數據的另一個重要特性是空間連貫性。溫度圖顯示大面積的相似值。如果你比較相鄰位置，溫度數據幾乎相同。通常少于0.5°C。
類似于時間序列數據的增量編碼，可以計算 3×3（9）相鄰位置的增量。使用多維增量編碼進一步將存儲大小推低到剛剛不到 4TB。
作為最后的手段來使其更小，可以移除不太受歡迎的使用區域。在這種情況下，所有來自海洋、南極洲和非常偏遠的北方位置的 ERA5 數據都被移除。這一步相當激進，但剩下的只有 1.2TB，現在對于一個 API 來說是一個可管理的大小。如果有更大的興趣，也可以提供一個不受限制的版本。
作為最后一步，ERA5 現在被集成到與 Open-Meteo 天氣預報 API 相同的源代碼中，具有相同的 API 語法、格式和文檔，以便于使用。
所有這些壓縮、縮放、增量編碼和塊分割的層都對性能有相當大的影響。最終的 API 表現得相當好，主要受到硬盤速度的限制。未緩存的62年天氣數據讀取甚至可能需要幾秒鐘。連續調用通常在10毫秒以下。由于只緩存了磁盤訪問而不是整個JSON結果，10毫秒是解壓縮和解碼數據的總時間。
將 47TB 壓縮到 1.2TB 是一個不錯的挑戰，并且希望對尋找時間序列天氣數據的數據科學家有實際用途。
未來幾個月將集成更多新的天氣數據集。歐盟哥白尼計劃是一個很好的來源，不久將開始進行為期6個月的季節性預測和空氣質量數據的工作。
文章轉自微信公眾號@Clarmy吱聲
