兩者都提供了廣泛的工具和優勢，這可能會讓我們在某些​​時候懷疑選擇兩者中的哪一個。這並不是要改變公司的所有流程，以便他們開始使用 Polars 或 Pandas「死亡」（這不會在不久的將來發生）。這是關於了解其他可以幫助我們降低流程成本和時間、獲得相同或更好結果的工具。

當我們使用雲端服務時，我們會優先考慮某些因素，包括它們的成本。我用於此過程的服務是帶有 Python 3.10 運行時的 AWS Lambda 和用於儲存原始檔案和 parquet 轉換檔案的 S3。

目的是獲取 CSV 文件作為原始數據，並使用 pandas 和 Polar 對其進行處理，以驗證這兩個庫中的哪一個可以為我們提供更好的資源優化，例如內存和結果文件的重量。

貓熊
它是一個專門用於資料操作和分析的 Python 函式庫，以 C 語言編寫，首次發佈於 2008 年。

*極地*
它是一個專門從事資料操作和分析的 Python 和 Rust 函式庫，允許並行處理，主要用 Rust 編寫，於 2022 年發布。

流程架構：

這個專案有點簡單，如架構所示：使用者將CSV 檔案存入work/pandas 或work/porlas 中，並自動啟動s3 觸發器來處理該文件，將其轉換為parquet 並將其存入Processed 。

在這個小專案中使用兩個具有以下配置的 lambda：
記憶體：2 GB
臨時記憶體：2 GB
續航時間：600秒

要求
Lambda 與 pandas：Pandas、Numpy 與 Pyarrow
帶有極座標的 Lambda：極座標

用於比較的資料集可以在 kaggle 上以「Rotten Tomatoes Movie Reviews – 1.44M rows」的名稱找到，或者可以從此處下載。

完整的儲存庫可在 GitHub 上找到，並且可以在此處複製。

尺寸或重量
Pandas 使用的 lambda 需要另外兩個外掛程式來建立 parquet 文件，在本例中是 PyArrow 和我使用的 Pandas 版本的特定版本的 numpy。結果，我們獲得了一個權重或大小為 74.4 MB 的 lambda，非常接近 AWS 允許的 lambda 權重限制。

帶有 Polars 的 lambda 不需要像 PyArrow 這樣的其他插件，這使生活變得更簡單，並將 lambda 的大小減少到一半以下。因此，與第一個 lambda 相比，我們的 lambda 的權重或大小為 30.6 MB，為我們提供了安裝轉換過程可能需要的其他依賴項的空間。

表現

在第一個版本之後，帶有 Pandas 的 lambda 被優化為使用壓縮，但是，也分析了其行為。
貓熊
與其他版本相比，處理資料集花費了 18 秒，並使用了 1894 MB 記憶體來處理 CSV 文件並產生 Parquet 文件，這是使用最多時間和資源的版本。

Pandas 壓縮
添加一行程式碼使我們比之前的版本（Pandas）有了一點改進，處理資料集花了17 秒，使用了1837 MB，這並不代表處理和計算時間的顯著改進，而是大小的顯著改進。產生的文件。

極地
處理相同的資料集花了 12 秒，我只使用了 1462 MB，與前兩者相比，它節省了 44.44% 的時間並降低了記憶體消耗。

輸出檔案大小

貓熊
未建立壓縮過程的 lambda 產生了 177.4 MB 的 parquet 檔案。

Pandas 壓縮
在 lambda 中配置壓縮時，我不會產生 121.1 MB 的 parquet 檔案。一小行或一個選項幫助我們將檔案大小減少了 31.74%。考慮到這不是一個重大的程式碼更改，這是一個非常好的選擇。

極地
Polars 產生了一個 105.8 MB 的文件，與 Pandas 第一版一起購買時，與經過壓縮的 Pandas 版本相比，該文件分別節省了 40.36% 和 12.63%。

結論
沒有必要改變所有使用Pandas 的內部流程，以便它們現在使用Polars，但是，重要的是要考慮到，如果我們談論數千或數百萬個lambda 執行，使用Polars 不僅會幫助我們進行部署時間，但由於AWS 為Lambda 等無伺服器服務提供基於時間的收費，因此也將幫助我們降低成本。
同樣，當我們將 40.36% 轉換為數百萬個檔案時，我們談論的是 GB 或 TB，這會對 Datalake 或 Dataware house 甚至冷檔案儲存產生重大影響。

Polars 的減少不僅限於這兩個因素，因為它會極大地影響 AWS 的資料和/或物件的輸出，因為它是一項確實有成本的服務。