2016-06-21 12 views
5

Praca z ramkami danych Spark zaimportowana z Hive, czasami kończę na kilku kolumnach, których nie potrzebuję. Przypuśćmy, że nie chcę, aby filtrować jeWybierz konkretne kolumny w ramce danych PySpark, aby poprawić wydajność.

df = SqlContext.sql('select cols from mytable') 

a ja importowania całą tabelę z

df = SqlContext.table(mytable) 

robi select i późniejsze cache poprawia wykorzystanie pamięci wydajność/spadek, jak

df = df.select('col_1', 'col_2', 'col_3') 
df.cache() 
df.count() 

czy to strata czasu? Zrobię wiele operacji i manipulacji danymi na df, jak avg, withColumn itp

+0

Pamięć podręczna bardzo pomaga, więc poprawi wydajność. –

+0

Ale czy warto wcześniej dokonać selekcji? – Ivan

+0

Tak, jeśli nie potrzebujesz innych kolumn w poniższych krokach - będziesz potrzebować tylko kolumn w pamięci podręcznej – MaxU

Odpowiedz

1

IMO ma to sens, aby filtrować je wcześniej:

df = SqlContext.sql('select col_1, col_2, col_3 from mytable') 

więc nie marnować zasobów ...

Jeśli nie można zrobić to w ten sposób, to można to zrobić, jak to zrobił ...

0

z pewnością jest to dobra praktyka, ale jest to raczej mało prawdopodobne, aby doprowadzić do wzrostu wydajności, chyba spróbować przekazać dane thr ough Python RDD lub zrobić coś podobnego. Jeśli niektóre kolumny nie są wymagane do obliczenia, optymalizator wyjścia powinien automatycznie wnioskować prognozy i przesunąć je tak wcześnie, jak to możliwe w planie wykonania.

Warto również zauważyć, że używanie df.count() po df.cache() będzie bezużyteczne przez większość czasu (jeśli nie zawsze). W ogóle count jest przepisany przez optymalizator jak

SELECT SUM(1) FROM table 

więc to, co jest zazwyczaj wymagane od źródła jest:

SELECT 1 FROM table 

Krótko mówiąc nie ma nic użyteczne buforować tutaj.

+0

Jeszcze raz dziękuję, @ ​​zero323! Myślałem raczej o liniach liczenia zaraz po pamięci podręcznej, aby zatwierdzić operację pamięci podręcznej i sprawdzić kilka liczb jako produkt uboczny. Zauważyłem, że czasami wykonywanie 'select' powoduje pogorszenie wydajności * przed pamięcią podręczną. – Ivan

+0

Cóż, rozumowanie o pamięci podręcznej w Spark SQL jest stosunkowo trudne, a sztuczki takie jak 'cache' /' count' nie są najlepszym pomysłem. Możesz zauważyć pewne zwiększenie wydajności, które nie jest związane z buforowaniem Spark, gdy dane są na przykład mapowane w pamięci, ale IMHO jest bardziej rytuał niż wszystko inne. – zero323

Powiązane problemy