# Polars 2.0: защо джойновете вече не запазват реда на редовете си

Published: 2026-10-08

Polars 2.0 изпълнява collect по подразбиране на стрийминг енджин. За join, group\_by и unpivot, версията вече не гарантира реда на входните редове, освен ако изрично не зададете maintain\_order или sort. В нашето изпълнение на polars 2.0.0, вътрешен join от 2 000 000 реда върна редове извън входния ред по подразбиране и запази реда със зададен maintain\_order. Версията също така включва изхвърляне извън паметта (out-of-core spilling) и прави твърденията за бенчмарка собствени на доставчика.

Canonical: https://thedailydiff.dev/bg/video/polars-2-row-order/

## Какво обхваща този видеоклип

- Извикването на collect() при мързелива заявка вече използва стрийминг енджина по подразбиране, което не гарантира реда на редовете за join, group\_by и unpivot.
- Ръководството за миграция казва, че редът вече не е редът преди 2.0 и не е гарантиран; препоръчва изрично сортиране, ако разчитате на него.
- В нашето изпълнение, стандартен вътрешен join върна входен ред False; maintain\_order="left\_right" при join върна True. Една машина, едно изпълнение, една форма на join.
- Изхвърлянето извън паметта (Out-of-core spilling) е включено по подразбиране: започва при около 80 % от RAM, с бюджет от 64 GB на диска по подразбиране. Изхвърляне извън паметта за join и group\_by са в пътната карта.
- collect\_schema() хваща липсваща колона преди да бъдат прочетени каквито и да е данни, но cast, който се проваля само на една стойност, се проваля само при collect().
- Сравнението TPC-H и TPC-DS е собствено изпълнение на доставчика върху производни данни, а бележката под линия казва, че резултатите не са сравними с официалните бенчмаркове.

## Глави

- 0:00 Защо се промени стандартният ред?
- 0:56 Какво обещава ръководството за миграция?
- 1:17 Честна ли е бенчмарк битката?
- 1:41 Какво виждаме, когато го стартираме?
- 1:56 По-стриктно означава ли по-рано?
- 2:07 Как да върна стария ред?
- 2:20 Каква е присъдата?

## Преведен препис

Преведено от оригиналния английски разказ. Наличните аудио и субтитри се контролират от YouTube.

### Защо се промени стандартният ред?

0:00 Мислите си, че джойн ви връща редовете в реда, в който сте ги написали. 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) също е включено по подразбиране. Започва да изхвърля на диск при около осемдесет процента от RAM, с бюджет от шестдесет и четири гигабайта. Сортиране, прозоречни функции и много изрази вече могат да изхвърлят. Джойновете и group-by-овете предстоят.

### Честна ли е бенчмарк битката?

1:17 Polars казва, че побеждава DataFusion и DuckDB на TPC-H и TPC-DS бенчмаркове. Числата идват от техните собствени изпълнения, върху производни данни, и тяхната бележка под линия казва, че те не са сравними с официалните резултати. Техните собствени числа казват, че Polars става около три цяло и осем десети пъти по-бърз от шестнадесет ядра до сто деветдесет и две, на TPC-H. Те също така казват, че допълнителните нишки на голямата машина забавят малките заявки.

### Какво виждаме, когато го стартираме?

1:41 Изпълнихме същия join два пъти на Polars 2.0.0. Стандартното изпълнение разбърква редовете. С флага, входният ред се запазва. Намерете джойновете, които захранват тест. Всеки join без сортиране след него е решение за реда на редовете, което никога не сте вземали. Polars 2.0 е по-стриктен относно типовете.

### По-стриктно означава ли по-рано?

1:58 Проверката на схемата хваща липсваща колона преди да бъдат прочетени каквито и да е данни. Не може да хване cast, който се проваля на един ред, защото тази грешка чака данните. Сега цикъла, който отворих.

### Как да върна стария ред?

2:08 Превключвателят е на join. Задайте maintain\_order на join или добавете сортиране след него. Ръководството предлага сортиране. Флагът за join запази реда в нашето изпълнение, като редът на лявата страна се запази като ляво, дясно. Присъда, под капака: НУЖДАЕ СЕ ОТ ПРЕГЛЕД (NEEDS REVIEW).

### Каква е присъдата?

2:22 Бих прегледал всеки join преди да надстроя. Имате въпрос относно това? Поставете го в коментарите. И това е различното за днес. Аз съм Нико от Axrisi. Обединявайте отговорно.

## Източници

- [Release of Polars 2.0](https://pola.rs/posts/release-polars-2/) — Polars (pola.rs)
- [Polars 2.0 upgrade guide](https://docs.pola.rs/releases/upgrade/2/) — Polars documentation
- [Polars homepage](https://pola.rs/) — Polars (pola.rs)
- [polars-2.0-benchmark repository](https://github.com/pola-rs/polars-2.0-benchmark) — Polars on GitHub
- [Release of Polars 2.0 (Hacker News discussion)](https://news.ycombinator.com/item?id=49977177) — Hacker News