HBase
 sql >> Baza danych >  >> NoSQL >> HBase

6 najlepszych technik optymalizacji pracy MapReduce

Dostrajanie wydajności pomoże zoptymalizować Hadoop występ. W tym blogu omówimy wszystkie te techniki optymalizacji zadań MapReduce.

W tym samouczku MapReduce przedstawimy 6 ważnych wskazówek dotyczących optymalizacji zadań MapReduce, takich jak właściwa konfiguracja klastra, użycie kompresji LZO, prawidłowe dostrojenie liczby zadań MapReduce itp.

Wskazówki dotyczące optymalizacji zadań MapReduce

Poniżej znajdziesz kilka technik optymalizacji zadań MapReduce, które pomogą Ci zoptymalizować wydajność zadań MapReduce.

1. Właściwa konfiguracja Twojego klastra

  • Z -noatime Opcja Dfs i MapReduce są montowane. Spowoduje to wyłączenie czasu dostępu. W ten sposób poprawia wydajność we/wy.
  • Staraj się unikać RAID na maszynach TaskTracker i datanode. To generalnie zmniejsza wydajność.
  • Upewnij się, że skonfigurowałeś mapred.local.dir i dfs.data.dir aby wskazać jeden katalog na każdym z twoich dysków. Ma to na celu zapewnienie wykorzystania całej przepustowości we/wy.
  • Powinieneś monitorować wykres użycia wymiany i użycia sieci za pomocą oprogramowania. Jeśli zauważysz, że używana jest zamiana, powinieneś zmniejszyć ilość pamięci RAM przydzielonej do każdego zadania w mapred.child.java.opts .
  • Upewnij się, że masz inteligentne monitorowanie stanu dysków twardych. To jedna z ważnych praktyk dotyczących dostrajania wydajności MapReduce.

2. Użycie kompresji LZO

W przypadku danych pośrednich jest to zawsze dobry pomysł. Każde zadanie Hadoop, które generuje znaczną ilość danych wyjściowych mapy, skorzysta na pośredniej kompresji danych za pomocą LZO.

Chociaż LZO nieco obciąża procesor, oszczędza czas, zmniejszając ilość operacji we/wy dysku podczas odtwarzania losowego.

Ustaw mapred.compress.map.output do true, aby włączyć kompresję LZO

3. Właściwe dostrojenie liczby zadań MapReduce

  • W zadaniu MapReduce, jeśli każde zadanie zajmie 30-40 sekund lub więcej, liczba zadań zostanie zmniejszona. Twórca map lub reduktor  Proces obejmuje następujące rzeczy:po pierwsze, musisz uruchomić JVM (JVM załadowaną do pamięci). Następnie musisz zainicjować JVM. A po przetworzeniu (mapper/reducer) musisz odinicjalizować JVM. A te zadania JVM są bardzo kosztowne. Załóżmy przypadek, w którym maper uruchamia zadanie tylko przez 20-30 sekund. W tym celu musimy uruchomić/zainicjować/zatrzymać JVM. Może to zająć dużo czasu. Dlatego zdecydowanie zaleca się uruchomienie zadania przez co najmniej 1 minutę.
  • Jeśli zadanie ma więcej niż 1 TB danych wejściowych. Następnie powinieneś rozważyć zwiększenie rozmiaru bloku wejściowego zestawu danych do 256M lub nawet 512M. Tak więc liczba zadań będzie mniejsza. Możesz zmienić rozmiar bloku za pomocą polecenia Hadoop distcp –Hdfs.block.size=$[256*1024*1024] /ścieżka/do/inputdata /ścieżka/do/inputdata-with-largeblocks
  • Ponieważ wiemy, że każde zadanie działa przez co najmniej 30-40 sekund. Powinieneś zwiększyć liczbę zadań mapowania do pewnej wielokrotności liczby miejsc mapowania w klastrze.
  • Nie uruchamiaj zbyt wielu zadań redukcyjnych — w przypadku większości zadań. Liczba zadań redukcji równa lub nieco mniejsza niż liczba miejsc redukcji w klastrze.

4. Łącznik między maperem a reduktorem

Jeśli algorytm obejmuje obliczanie dowolnego rodzaju agregatów, powinniśmy użyć kombinacji . Combiner wykonuje pewną agregację, zanim dane trafią do reduktora.

Uruchomienia platformy Hadoop MapReduce łączą się inteligentnie, aby zmniejszyć ilość danych do zapisania na dysku. Dane te muszą być przesyłane między etapami obliczeń Map i Reduce.

5. Użycie najbardziej odpowiedniego i kompaktowego typu zapisywalnego dla danych

Użytkownicy Big Data niepotrzebnie używają typu zapisywalnego tekstu, aby przełączyć się z Hadoop Streaming na Java MapReduce. Tekst może być wygodny. Konwersja danych liczbowych do i z ciągów UTF8 jest nieefektywna. I faktycznie może nadrobić znaczną część czasu procesora.

6. Ponowne wykorzystanie zapisywalnych

Wielu użytkowników MapReduce popełnia jeden bardzo częsty błąd, który polega na przydzieleniu nowego obiektu Writable dla każdego wyjścia z programu mapującego/reduktora. Załóżmy, na przykład, implementację mapowania liczby słów w następujący sposób:

public void map(...) {
...
for (String word: words) {
output.collect(new Text(word), new IntWritable(1));
}

Ta implementacja powoduje alokację tysięcy krótko żyjących obiektów. Chociaż garbage collector w Javie radzi sobie z tym rozsądnie, bardziej efektywne jest napisanie:

class MyMapper ... {
Text wordText = new Text();
IntWritable one = new IntWritable(1);
public void map(...) {
... for (String word: words)
{
wordText.set(word);
output.collect(word, one); }
}
}

Wniosek

Dlatego istnieją różne techniki optymalizacji zadań MapReduce, które pomagają w optymalizacji zadania MapReduce. Podobnie jak w przypadku używania sumatora między maperem i Reducerem, przez użycie kompresji LZO, odpowiednie dostrojenie liczby zadań MapReduce, ponowne użycie zapisywalnych.

Jeśli znajdziesz inną technikę optymalizacji pracy MapReduce, daj nam znać w sekcji komentarzy podanej poniżej.


  1. Redis
  2.   
  3. MongoDB
  4.   
  5. Memcached
  6.   
  7. HBase
  8.   
  9. CouchDB
  1. Przegląd replikacji Apache HBase

  2. Dostrajanie wydajności w MapReduce w celu poprawy wydajności

  3. Wewnątrz architektury Santander do przetwarzania danych w czasie zbliżonym do rzeczywistego

  4. Cloudera Impala:zapytania w czasie rzeczywistym w Apache Hadoop, na serio

  5. Co to jest Hadoop OutputFormat w MapReduce?