Polars 2.0: 為什麼 JOIN 不再保留其行順序

本影片重點

• 現在，在惰性查詢上呼叫 collect() 預設使用串流引擎，這不保證 JOIN、GROUP BY 和 UNPIVOT 的行順序。
• 遷移指南指出，順序不再是 2.0 之前的順序，且不予保證；如果您依賴它，建議明確排序。
• 在我們的運行中，預設的內部 JOIN 返回輸入順序為 False；在 JOIN 上設定 maintain_order="left_right" 返回 True。一台機器，一次運行，一種 JOIN 形式。
• Out-of-core spilling 預設開啟：它在大約 80% 的 RAM 時開始溢出到磁碟，預設磁碟預算為 64 GB。Out-of-core JOIN 和 GROUP BY 正在開發中。
• collect_schema() 在讀取任何資料之前捕獲遺失的欄位，但僅在一個值上失敗的類型轉換只會在 collect() 時失敗。
• TPC-H 和 TPC-DS 比較是供應商自己在衍生資料上的運行，其註腳指出結果不可與官方基準測試相比較。

翻譯文字稿

譯自英文原版旁白。可用的音訊和字幕由 YouTube 控制。

為什麼預設順序會改變？

0:00 您認為 JOIN 會按照您寫入的順序返回您的行。 Polars 2.0 刻意停止預設保證這一點。 在此影片中：為什麼預設值會改變？ 它帶來了什麼好處？ 您的哪個腳本會最先出錯？ 這是 The Daily Diff，幕後探秘。 Polars 是一個開源 DataFrame 庫： 一個您可以從 Python 呼叫的表格引擎，

0:20 其核心是用 Rust 編寫的。 它在 MIT 許可證下是免費的，您可以使用 pip install polars 安裝它。 首先一個細節。 恢復舊順序的開關是 JOIN 本身的參數。 我會在最後回到這一點。 自 2.0 版以來，collect 預設執行串流引擎。 串流將查詢分成並行執行的區塊， 區塊完成時就完成。

0:42 對於 JOIN、GROUP BY 和 UNPIVOT，此版本不承諾順序。 誰會最先受到影響？ 任何逐行將輸出與儲存檔案進行比較的人。 該測試可能在您的筆記型電腦上通過，但在不同的機器上失敗。 接下來是遷移指南。

遷移指南承諾了什麼？

0:57 它表示上面顯示的確切行順序不予保證。 因此，如果您依賴順序，請明確排序。 Out-of-core 也預設開啟。 它在大約 80% 的 RAM 時開始溢出到磁碟， 預算為 64 GB。 排序、窗口函數和許多表達式現在可以溢出。 JOIN 和 GROUP BY 即將推出。

基準測試公平嗎？

1:17 Polars 表示它在 TPC-H 和 TPC-DS 基準測試中擊敗了 DataFusion 和 DuckDB。 這些數字來自他們自己在衍生資料上的運行， 其註腳指出它們不可與官方結果相比較。 他們自己的數字顯示，在 TPC-H 上，Polars 從十六個核心到一百九十二個核心，速度提升了大約 3.8 倍。 他們還表示，大型機器的額外執行緒會減慢小型查詢。 我們在 Polars 2.0.0 上運行了相同的 JOIN 兩次。

我們運行時看到了什麼？

1:41 預設運行會打亂行。 使用該標誌，輸入順序得以保留。 找到為測試提供資料的 JOIN。 任何 JOIN 後面沒有排序，都是您從未做出的行順序決定。 Polars 2.0 對類型更嚴格。 在讀取任何資料之前，架構檢查會捕獲遺失的欄位。

更嚴格意味著更早嗎？

1:58 它無法捕獲在單行上失敗的類型轉換，因為該錯誤會等待資料。 現在我打開的循環。 開關位於 JOIN 上。

如何恢復舊順序？

2:08 在 JOIN 上設定 maintain_order，或者在其後添加一個排序。 指南建議排序。 JOIN 標誌在我們的運行中保持了順序，左側的順序被保留為左、右。 判決，幕後探秘：NEEDS REVIEW。 我會在升級之前審查每個 JOIN。

判決是什麼？

2:22 對此有疑問嗎？ 將其寫在評論中。 這就是今天的差異。 我是 Axrisi 的 Niko。 負責地合併。 負責任地合併。

來源

1. Release of Polars 2.0Polars (pola.rs)
2. Polars 2.0 upgrade guidePolars documentation
3. Polars homepagePolars (pola.rs)
4. polars-2.0-benchmark repositoryPolars on GitHub
5. Release of Polars 2.0 (Hacker News discussion)Hacker News