+− THE DAILY DIFFdev & AI news
NEEDS REVIEW

Polars 2.0: dlaczego łączenia (joins) nie zachowują już kolejności wierszy

Polars 2.0 domyślnie uruchamia kolekcję na silniku strumieniowym.

Polars 2.0 domyślnie uruchamia kolekcję na silniku strumieniowym. W przypadku operacji join, group_by i unpivot, wydanie nie gwarantuje już kolejności wierszy wejściowych, chyba że jawnie ustawisz maintain_order lub sort. W naszym teście na polars 2.0.0, wewnętrzne połączenie (inner join) na 2 000 000 wierszy domyślnie zwróciło wiersze poza kolejnością wejściową i zachowało kolejność po ustawieniu maintain_order. Wydanie włącza również "spilling" poza rdzeniem i przypisuje roszczenia dotyczące benchmarków dostawcy.

Przeczytaj wydanie pisemne (angielski) ↗

Co obejmuje ten film

  • Wywołanie collect() na leniwym zapytaniu domyślnie używa teraz silnika strumieniowego, który nie gwarantuje kolejności wierszy dla operacji join, group_by i unpivot.
  • Przewodnik migracji mówi, że kolejność nie jest już kolejnością sprzed wersji 2.0 i nie jest gwarantowana; zaleca jawne sortowanie, jeśli na niej polegasz.
  • W naszym teście, domyślne wewnętrzne połączenie (inner join) zwróciło input order False; maintain_order="left_right" przy połączeniu zwróciło True. Jedna maszyna, jedno uruchomienie, jeden kształt połączenia.
  • Spilling poza rdzeniem jest domyślnie włączony: zaczyna się przy około 80% pamięci RAM, z domyślnym budżetem dysku 64 GB. Połączenia i grupowania poza rdzeniem są w planach.
  • collect_schema() wykrywa brakującą kolumnę przed odczytem jakichkolwiek danych, ale rzutowanie, które zawodzi tylko na jednej wartości, zawodzi dopiero przy collect().
  • Porównanie TPC-H i TPC-DS to własne uruchomienie dostawcy na danych pochodnych, a jego przypis mówi, że wyniki nie są porównywalne z oficjalnymi benchmarkami.

Przetłumaczona transkrypcja

Przetłumaczono z oryginalnej narracji angielskiej. Dostępne audio i napisy są kontrolowane przez YouTube.

Dlaczego domyślna kolejność się zmieniła?

0:00 Myślisz, że połączenie zwraca wiersze w kolejności, w jakiej je napisałeś. Polars 2.0 celowo przestał to obiecywać, domyślnie. W tym filmie: dlaczego domyślne zachowanie się zmieniło? Co to dało? I który z Twoich skryptów zepsuje się jako pierwszy? To jest The Daily Diff, pod maską. Polars to biblioteka DataFrame o otwartym kodzie źródłowym: silnik tabelaryczny, który wywołujesz z Pythona,

0:20 z rdzeniem napisanym w Rust. Jest darmowy na licencji MIT, a instalujesz go za pomocą pip install polars. Jeden szczegół na początek. Przełącznik, który przywraca starą kolejność, jest argumentem samego połączenia. Wrócę do tego na końcu. Od wersji 2.0 collect domyślnie uruchamia silnik strumieniowy. Strumieniowanie dzieli zapytanie na fragmenty, które działają równolegle, a fragmenty kończą się, kiedy się skończą.

0:42 W przypadku operacji join, group by i unpivot, wydanie nie obiecuje konkretnej kolejności. Kto oberwie pierwszy? Kto porównuje wyniki z zapisanym plikiem, wiersz po wierszu. Ten test może przejść na Twoim laptopie i zawieść na innej maszynie. Dalej, przewodnik migracji.

Co obiecuje przewodnik migracji?

0:57 Mówi, że dokładna kolejność wierszy pokazana powyżej nie jest gwarantowana. Więc jeśli polegasz na kolejności, sortuj jawnie. Spilling poza rdzeniem jest również domyślnie włączony. Zaczyna zrzucać dane na dysk przy około osiemdziesięciu procentach pamięci RAM, z budżetem sześćdziesięciu czterech gigabajtów. Sortowanie, funkcje okienkowe i wiele wyrażeń mogą teraz "spillować". Połączenia i grupowania są w drodze.

Czy benchmark jest uczciwą walką?

1:17 Polars twierdzi, że bije DataFusion i DuckDB w benchmarkach TPC-H i TPC-DS. Liczby pochodzą z ich własnych testów, na danych pochodnych, a ich przypis mówi, że nie są porównywalne z oficjalnymi wynikami. Ich własne liczby mówią, że Polars jest około trzy i osiem dziesiątych razy szybszy od szesnastu rdzeni do stu dziewięćdziesięciu dwóch, w TPC-H. Mówią również, że dodatkowe wątki dużej maszyny spowalniają małe zapytania.

Co widzimy, gdy go uruchomimy?

1:41 Uruchomiliśmy to samo połączenie dwukrotnie na Polars 2.0.0. Domyślne uruchomienie tasuje wiersze. Z flagą, kolejność wejściowa zostaje zachowana. Znajdź połączenia, które zasilają test. Każde połączenie bez sortowania po nim to decyzja o kolejności wierszy, której nigdy nie podjąłeś. Polars 2.0 jest bardziej rygorystyczny w kwestii typów.

Czy bardziej rygorystyczne oznacza wcześniejsze?

1:58 Sprawdzanie schematu wykrywa brakującą kolumnę przed odczytem jakichkolwiek danych. Nie może wychwycić rzutowania, które zawodzi w jednym wierszu, ponieważ ten błąd czeka na dane. Teraz pętla, którą otworzyłem.

Jak odzyskać starą kolejność?

2:08 Przełącznik znajduje się przy połączeniu. Ustaw maintain_order na połączeniu lub dodaj sortowanie po nim. Przewodnik sugeruje sortowanie. Flaga połączenia zachowała kolejność w naszym teście, z zachowaniem kolejności lewej strony jako lewej, prawej. Werdykt, pod maską: NEEDS REVIEW.

Jaki jest werdykt?

2:22 Przejrzałbym każde połączenie przed aktualizacją. Masz pytanie na ten temat? Zadaj je w komentarzach. I to jest dzisiejszy The Daily Diff. Jestem Niko z Axrisi. Łącz odpowiedzialnie.

Źródła

  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

Powiązane filmy