Skośne połączenie świni z dużą tabelą powoduje "Przekroczony rozmiar metadanych przekroczył 10000000"

Mamy połączenie świni pomiędzy małym (16-rzędowym) odrębnym stołem i dużym (6-rzędowym) skośnym stołem. Regularne dołączanie kończy się po 2 godzinach (po kilku poprawkach). Wypróbowaliśmy using skewed i mogliśmy poprawić wydajność do 20 minut.Skośne połączenie świni z dużą tabelą powoduje "Przekroczony rozmiar metadanych przekroczył 10000000"

jednak, gdy staramy większy stół skośny (19b wierszach), otrzymujemy komunikat z pracy Sampler:

Split metadata size exceeded 10000000. Aborting job job_201305151351_21573 [ScriptRunner] 
at org.apache.hadoop.mapreduce.split.SplitMetaInfoReader.readSplitMetaInfo(SplitMetaInfoReader.java:48) 
at org.apache.hadoop.mapred.JobInProgress.createSplits(JobInProgress.java:817) [ScriptRunner]

To jest powtarzalny za każdym razem staramy using skewed i nie stanie, gdy użyjemy regularne dołączanie.

próbowaliśmy ustawić mapreduce.jobtracker.split.metainfo.maxsize=-1 i widzimy, że jest tam w pliku job.xml, ale nic nie zmienia!

Co się tutaj dzieje? Czy jest to błąd z próbką dystrybucji utworzoną przez using skewed? Dlaczego nie pomaga zmiana parametru na -1?

Źródło

2013-06-18 ihadanny

zdecydował się zgłosić błąd jira: https://issues.apache.org/jira/browse/PIG-3411, zaktualizuje – ihadanny

stwierdziliśmy, że zmiana mapreduce.jobtracker.split.metainfo. maxsize jest znany z tego, że nie działa na poziomie zadania, tylko na poziomie jobTracker, zobacz tutaj: https://groups.google.com/a/cloudera.org/forum/#!topic/cdh-user/UWBMKplvGkg – ihadanny

kiedykolwiek znajdziesz rozwiązanie tego problemu? Mamy podobny problem. – KennethJ

Mały stolik o wielkości 1 MB jest na tyle mały, że mieści się w pamięci, spróbuj zreplikowane sprzężenie. Łączenie replikowane jest tylko mapą, nie powoduje zmniejszenia stopnia jako innych typów łączenia, w związku z czym jest odporne na pochylenie w klawiszach łączenia. Powinno być szybkie.

big = LOAD 'big_data' AS (b1,b2,b3); 
tiny = LOAD 'tiny_data' AS (t1,t2,t3); 
mini = LOAD 'mini_data' AS (m1,m2,m3); 
C = JOIN big BY b1, tiny BY t1, mini BY m1 USING 'replicated';

Duży stół jest zawsze pierwszy w zestawieniu.

UPDATE 1: Jeśli stolik w swojej pierwotnej formie nie pasuje do pamięci, niż jako pracę wokół ciebie musiałyby podzielić swój stolik na partycje, które są wystarczająco małe, aby zmieścić się w pamięci, niż zastosować takie samo partycjonowanie do dużej tabeli, mam nadzieję, że możesz dodać ten sam algorytm partycjonowania do systemu, który tworzy dużą tabelę, abyś nie tracił czasu na jej ponowne dzielenie na partycje. Po partycjonowaniu można użyć zreplikowanego sprzężenia, ale będzie to wymagało uruchomienia skryptu świni dla każdej partycji oddzielnie.

Źródło

2013-06-18 09:16:01 alexeipab

fajny pomysł, ale mały stół nie jest 1 MB (edytowane pytanie) i nie zmieści się w pamięci podręcznej hadoop (wypróbowany) – ihadanny

Zaktualizowano odpowiedź. Zobacz Aktualizacja 1. – alexeipab

Jeszcze raz dziękuję, ale szukam wyjaśnienia pierwotnego problemu. To jest świetne obejście, ale nie zamierzam tego robić, dopóki nie zrozumiem, co jest nie tak z konwencjonalnym złączem. – ihadanny

W nowszych wersjach Hadoop (> = 2.4.0, ale może nawet wcześniej), powinieneś być w stanie ustawić maksymalny rozmiar podzielonego na poziomie pracy za pomocą następującą właściwość konfiguracji:

mapreduce.job.split .metainfo.maxsize = -1

Źródło

2014-09-29 14:11:36

Skośne połączenie świni z dużą tabelą powoduje "Przekroczony rozmiar metadanych przekroczył 10000000"

Odpowiedz

Powiązane problemy