Polars 2.0: waarom joins hun rijvolgorde niet langer behouden

Wat deze video behandelt

• Het aanroepen van collect() op een lazy query gebruikt nu standaard de streaming engine, die de rijvolgorde voor join, group_by en unpivot niet garandeert.
• De migratiehandleiding stelt dat de volgorde niet langer de pre-2.0 volgorde is en niet gegarandeerd is; het adviseert een expliciete sortering als je erop vertrouwt.
• In onze test retourneerde een standaard inner join 'input order False'; maintain_order="left_right" op de join retourneerde 'True'. Eén machine, één run, één joinvorm.
• Out-of-core spilling is standaard ingeschakeld: het begint bij ongeveer 80% van het RAM, met een standaard schijfbudget van 64 GB. Out-of-core join en group_by staan op de roadmap.
• collect_schema() vangt een ontbrekende kolom op voordat er gegevens worden gelezen, maar een cast die faalt op slechts één waarde, faalt pas bij collect().
• De TPC-H- en TPC-DS-vergelijking is de eigen test van de leverancier op afgeleide gegevens, en de voetnoot vermeldt dat de resultaten niet vergelijkbaar zijn met officiële benchmarks.

Vertaald transcript

Vertaald vanuit de originele Engelse gesproken tekst. Beschikbare audio en ondertiteling worden beheerd door YouTube.

Waarom is de standaardvolgorde veranderd?

0:00 Je denkt dat een join je rijen teruggeeft in de volgorde waarin je ze hebt geschreven. Polars 2.0 is daarmee gestopt, standaard en expres. In deze video: waarom is de standaard gewijzigd? Wat heeft het opgeleverd? En welk van je scripts breekt het eerst? Dit is The Daily Diff, onder de motorkap. Polars is een open-source DataFrame-bibliotheek: een table engine die je aanroept vanuit Python,

0:20 met de kern geschreven in Rust. Het is gratis onder de MIT-licentie en je installeert het met pip install polars. Eerst één detail. De schakelaar die de oude volgorde terugbrengt, is een argument voor de join zelf. Ik kom er aan het einde op terug. Sinds 2.0 draait collect standaard de streaming engine. Streaming splitst de query in brokken die parallel worden uitgevoerd, en de brokken eindigen wanneer ze eindigen.

0:42 Voor join, group by en unpivot belooft de release geen volgorde. Wie wordt het eerst getroffen? Degene die de uitvoer rij voor rij vergelijkt met een opgeslagen bestand. Die test kan slagen op je laptop en mislukken op een andere machine. Vervolgens de migratiehandleiding.

Wat belooft de migratiehandleiding?

0:57 Deze zegt dat de exacte rijvolgorde zoals hierboven getoond niet gegarandeerd is. Dus als je afhankelijk bent van de volgorde, sorteer dan expliciet. Out-of-core is ook standaard ingeschakeld. Het begint met spillen naar schijf bij ongeveer tachtig procent van het RAM, met een budget van vierenzestig gigabyte. Sort, window functions en veel expressies kunnen nu spillen. Joins en group-bys komen eraan.

Is de benchmark een eerlijke strijd?

1:17 Polars zegt dat het DataFusion en DuckDB verslaat op de TPC-H en TPC-DS benchmarks. De cijfers komen van hun eigen tests, op afgeleide gegevens, en hun voetnoot zegt dat ze niet vergelijkbaar zijn met officiële resultaten. Hun eigen cijfers zeggen dat Polars ongeveer drie komma acht keer sneller wordt van zestien cores naar honderdnegenennegentig, op TPC-H. Ze zeggen ook dat de extra threads van de grote machine kleine queries vertragen.

Wat zien we als we het uitvoeren?

1:41 We hebben dezelfde join twee keer uitgevoerd op Polars 2.0.0. De standaard run schudt de rijen door elkaar. Met de vlag blijft de invoervolgorde behouden. Vind de joins die een test voeden. Elke join zonder een sortering erna is een rijvolgordebeslissing die je nooit hebt genomen. Polars 2.0 is strenger over typen.

Betekent strenger eerder?

1:58 De schemacontrole vangt een ontbrekende kolom op voordat er gegevens worden gelezen. Het kan geen cast opvangen die op één rij faalt, want die fout wacht op de gegevens. Nu de lus die ik opende.

Hoe krijg ik de oude volgorde terug?

2:08 De schakelaar zit op de join. Stel maintain order in op de join, of voeg er een sortering achteraan toe. De handleiding stelt de sortering voor. De join-vlag behield de volgorde in onze run, waarbij de volgorde van de linkerkant werd behouden als links, rechts. Oordeel, onder de motorkap: NEEDS REVIEW.

Wat is het oordeel?

2:22 Ik zou elke join beoordelen voordat ik upgrade. Heb je hier een vraag over? Zet het in de reacties. En dat is de diff voor vandaag. Ik ben Niko van Axrisi. Voeg verantwoordelijk samen.

Bronnen

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