Spark partitionBy znacznie wolniej niż bez niego

Testowałem piśmie:Spark partitionBy znacznie wolniej niż bez niego

df.write.partitionBy("id", "name") 
    .mode(SaveMode.Append) 
    .parquet(filePath)

Jednak jeśli pominąć partycjonowanie: (!)

df.write 
    .mode(SaveMode.Append) 
    .parquet(filePath)

Wykonuje 100x szybciej.

Czy zapisanie partycji jest normalne, aby ta sama ilość danych zajęła 100x więcej czasu?

Istnieje 10 i 3000 unikatowych wartości kolumn id i . Obiekt DataFrame ma 10 dodatkowych kolumn całkowitych.

Źródło

2015-10-01 BAR

Czy to powoduje przetasowanie? – Gillespie

Ile danych dotyczy? Może to być wszystko pasuje do jednej partycji, zanim zmusisz ją do podziału na partycje. –

@Gillespie jak mogę się dowiedzieć? – BAR

Pierwszy fragment kodu zapisze plik parkietu na partycję do systemu plików (lokalny lub HDFS). Oznacza to, że jeśli masz 10 różnych identyfikatorów i 3000 różnych nazw, ten kod utworzy 30000 plików. Podejrzewam, że narzut tworzenia plików, pisania metadanych z parkietu itp. Jest dość duży (oprócz tasowania).

Spark nie jest najlepszym silnikiem baz danych, jeśli twój zestaw danych pasuje do pamięci, sugeruję użycie relacyjnej bazy danych. Praca z nim będzie szybsza i łatwiejsza.

Źródło

2015-10-05 12:59:10 kostya

Czy uważasz, że parkiet nie jest najlepszym przechowywanie db? Przygotowuję jdbc do postgres, aby przetestować wydajność. Nie sądzę, że dane muszą pasować do pamięci. Czy to nie jest punkt za iskrą? – BAR

Format pliku parkietowego jest całkiem niezły, jednak jeśli Spark jest właściwym narzędziem do tego zadania, zależy to w dużej mierze od twojego przypadku użycia. Spark jest zoptymalizowany do równoległego przetwarzania dużej ilości danych. Jeśli masz kilka lub nawet 100 gigabajtów danych, baza danych, taka jak PostgreSQL prawdopodobnie będzie lepszym wyborem. Chociaż nie znając swojego przypadku użycia, trudno jest podać jakiekolwiek zalecenia. – kostya

Spark jest używany przez niektórych do obsługi PBs danych. Wierzę, że Spark może przetwarzać dane z dowolnego obsługiwanego źródła równolegle, w tym z JDBC. Mam około 250 GB do przetworzenia, które można podzielić na pliki o rozmiarze około 1 GB, aby działały równolegle. – BAR

Spark partitionBy znacznie wolniej niż bez niego

Odpowiedz

Powiązane problemy