Polars 2.0: Bakit Hindi na Nagpapanatili ng Pagkakasunod-sunod ng Row ang mga Join

Ang sakop ng video na ito

• Ang pagtawag sa collect() sa isang lazy query ay gumagamit na ngayon ng streaming engine bilang default, na hindi ginagarantiya ang pagkakasunod-sunod ng row para sa join, group_by, at unpivot.
• Sinasabi ng migration guide na ang pagkakasunod-sunod ay hindi na ang pagkakasunod-sunod bago ang 2.0 at hindi ginagarantiya; inirerekomenda nito ang isang tahasang sort kung umaasa ka dito.
• Sa aming pagtakbo, ang isang default na inner join ay nagbalik ng input order False; ang maintain_order="left_right" sa join ay nagbalik ng True. Isang makina, isang pagtakbo, isang join shape.
• Ang out-of-core spilling ay naka-on bilang default: nagsisimula ito sa humigit-kumulang 80% ng RAM, na may 64 GB na default na badyet ng disk. Ang out-of-core join at group_by ay nasa roadmap.
• Nahuhuli ng collect_schema() ang isang nawawalang column bago basahin ang anumang data, ngunit ang isang cast na nabigo sa isang halaga lamang ay nabibigo sa collect().
• Ang paghahambing ng TPC-H at TPC-DS ay sariling pagtakbo ng vendor sa derived data, at sinasabi ng footnote nito na ang mga resulta ay hindi maihahambing sa mga opisyal na benchmark.

Isinaling transcript

Isinalin mula sa orihinal na salaysay sa English. Ang available na audio at mga caption ay kinokontrol ng YouTube.

Bakit nagbago ang default na pagkakasunod-sunod?

0:00 Iniisip mong ibinabalik ng isang join ang iyong mga row sa pagkakasunod-sunod ng iyong pagsulat sa kanila. Sadyang hindi na ipinapangako iyon ng Polars 2.0, bilang default. Sa video na ito: bakit nagbago ang default? Ano ang nakuha nito? At alin sa iyong mga script ang unang masisira? Ito ang The Daily Diff, sa ilalim ng hood. Ang Polars ay isang open-source DataFrame library: isang table engine na tinatawag mo mula sa Python,

0:20 na ang core ay nakasulat sa Rust. Ito ay libre sa ilalim ng lisensya ng MIT, at ini-install mo ito gamit ang pip install polars. Isang detalye muna. Ang switch na nagbabalik ng lumang pagkakasunod-sunod ay isang argumento sa join mismo. Babalikan ko ito sa huli. Mula nang 2.0, pinapatakbo ng collect ang streaming engine bilang default. Hinahati ng streaming ang query sa mga chunk na tumatakbo nang magkatulad, at ang mga chunk ay natatapos kapag natapos na sila.

0:42 Para sa join, group by at unpivot, hindi ipinapangako ng release ang isang pagkakasunod-sunod. Sino ang unang tinamaan? Sinuman ang naghahambing ng output sa isang nai-save na file, row by row. Ang pagsubok na iyon ay maaaring pumasa sa iyong laptop at mabigo sa ibang makina. Susunod, ang migration guide.

Ano ang ipinapangako ng migration guide?

0:57 Sinasabi nito na ang eksaktong pagkakasunod-sunod ng row na ipinapakita sa itaas ay hindi ginagarantiya. Kaya kung umaasa ka sa pagkakasunod-sunod, sort nang tahasan. Naka-on din ang out-of-core bilang default. Nagsisimula itong mag-spill sa disk sa humigit-kumulang walumpu't porsyento ng RAM, na may badyet na animnapu't apat na gigabyte. Sort, window functions at maraming expression ay maaaring mag-spill na ngayon. Ang mga join at group-by ay darating.

Patas ba ang laban ng benchmark?

1:17 Sinasabi ng Polars na tinalo nito ang DataFusion at DuckDB sa mga benchmark ng TPC-H at TPC-DS. Ang mga numero ay nagmula sa kanilang sariling mga pagtakbo, sa derived data, at sinasabi ng kanilang footnote na hindi sila maihahambing sa mga opisyal na resulta. Ang kanilang sariling mga numero ay nagsasabi na ang Polars ay nagiging humigit-kumulang tatlong punto walong beses na mas mabilis mula sa labing-anim na core hanggang isang daan siyamnapu't dalawa, sa TPC-H. Sinasabi din nila na pinapabagal ng karagdagang mga thread ng malaking makina ang maliliit na query.

Ano ang nakikita natin kapag pinapatakbo natin ito?

1:41 Pinatakbo namin ang parehong join nang dalawang beses sa Polars 2.0.0. Ang default na pagtakbo ay nagsasaayos ng mga row. Sa flag, nananatili ang pagkakasunod-sunod ng input. Hanapin ang mga join na nagbibigay ng input sa isang pagsubok. Ang anumang join na walang sort pagkatapos nito ay isang desisyon sa pagkakasunod-sunod ng row na hindi mo kailanman ginawa. Mas mahigpit ang Polars 2.0 tungkol sa mga uri.

Ang mas mahigpit ba ay nangangahulugang mas maaga?

1:58 Nahuhuli ng schema check ang isang nawawalang column bago basahin ang anumang data. Hindi nito mahuhuli ang isang cast na nabigo sa isang row, dahil ang error na iyon ay naghihintay para sa data. Ngayon ang loop na binuksan ko.

Paano ko maibabalik ang lumang pagkakasunod-sunod?

2:08 Ang switch ay nabubuhay sa join. Itakda ang maintain order sa join, o magdagdag ng sort pagkatapos nito. Iminumungkahi ng gabay ang sort. Pinanatili ng join flag ang pagkakasunod-sunod sa aming pagtakbo, na ang pagkakasunod-sunod ng kaliwang bahagi ay pinananatili bilang kaliwa, kanan. Hatol, sa ilalim ng hood: KAILANGAN NG REVIEW.

Ano ang hatol?

2:22 Irerepaso ko ang bawat join bago mag-upgrade. May tanong tungkol dito? Ilagay ito sa mga komento. At iyan ang diff para sa araw na ito. Ako si Niko mula sa Axrisi. Magsama nang may pananagutan.

Mga Pinagmulan

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