Hadoop obcięta / niespójna nazwa licznika

79

Na razie mam zadanie Hadoop, które tworzy liczniki o dość dużej nazwie.

Na przykład, na następujący: stats.counters.server-name.job.job-name.mapper.site.site-name.qualifier.qualifier-name.super-long-string-which-is-not-within-standard-limits. Ten licznik jest obcinany w interfejsie WWW i getName()wywołaniu metody. Dowiedziałem się, że Hadoop ma ograniczenia dotyczące nazwy maksymalnej licznika i ten identyfikator ustawień mapreduce.job.counters.counter.name.maxsłuży do konfigurowania tego limitu. Więc zwiększyłem to do 500i interfejs sieciowy pokazuje teraz pełną nazwę licznika. Ale getName()licznik nadal zwraca obciętą nazwę.

Czy ktoś mógłby to wyjaśnić lub wskazać mi moje błędy? Dziękuję Ci.

EDYCJA 1

Moja konfiguracja serwera Hadoop składa się z jednego serwera z HDFS, YARN i map-Redred. Podczas zmniejszania mapy jest kilka przyrostów liczników, a po zakończeniu zadania ToolRunnerpobieram liczniki za pomocą org.apache.hadoop.mapreduce.Job#getCounters.

EDYCJA 2

Wersja Hadoop jest następująca:

Hadoop 2.6.0-cdh5.8.0
Subversion http://github.com/cloudera/hadoop -r 042da8b868a212c843bcbf3594519dd26e816e79 
Compiled by jenkins on 2016-07-12T22:55Z
Compiled with protoc 2.5.0
From source with checksum 2b6c319ecc19f118d6e1c823175717b5
This command was run using /usr/lib/hadoop/hadoop-common-2.6.0-cdh5.8.0.jar

Zrobiłem dodatkowe dochodzenie i wydaje się, że ten problem dotyczy sytuacji podobnej do mojej. Ale to dość zagmatwane, ponieważ jestem w stanie zwiększyć liczbę liczników, ale nie długość nazwy licznika ...

EDYCJA 3

Dzisiaj spędziłem dużo czasu na debugowaniu wewnętrznych elementów Hadoop. Kilka interesujących rzeczy:

  1. org.apache.hadoop.mapred.ClientServiceDelegate#getJobCountersMetoda zwraca kilka liczników z przędzy ze ściętego nazw i PEŁNYCH nazw wyświetlanych.
  2. Nie był w stanie samodzielnie debugować map i reduktorów, ale przy pomocy logowania wydaje się, że org.apache.hadoop.mapreduce.Counter#getNamemetoda działa poprawnie podczas wykonywania reduktora.
pan nic
źródło
2
Czy możesz podać więcej szczegółów na temat getName()połączenia, które nadal zwraca skróconą nazwę? Czy jest to iteracja liczników zwróconych Job#getCounters()przez klienta przesyłającego po oczekiwaniu na zakończenie zadania, czy jest to oddzielna aplikacja odpytująca liczniki z serwera historii zadań, czy też coś zupełnie innego? Spodziewałbym się, że twoja konfiguracja będzie wystarczająca. Interfejs użytkownika sieci Web używa tego samego getName()wywołania. (Nie naprawiłoby to jednak z mocą wsteczną skróconych nazw liczników z zadań przesłanych przed zmianą konfiguracji.)
Chris Nauroth
@ChrisNauroth, konfiguracja jest dość prosta, mam jeden serwer z hadoopem i całe to dodatkowe oprogramowanie na nim zainstalowane. Przepływ liczników w mojej mapie-redukuj: 1. Zwiększaj liczniki w reduktorach (pobierane z kontekstu) 2. Pobierz z zadania # getCounters (). Dziękuję za zainteresowanie i przepraszam za opóźnioną odpowiedź.
pan nic
1
@ChrisNauroth, przeprowadziłem dodatkowe dochodzenie i wygląda na to, że znalazłem coś ... uh, interesujące. Mamy zainstalowany hadoop 2.6.0 i wygląda na to, że ten problem issue.apache.org/jira/browse/MAPREDUCE-5875 opisuje sytuację podobną do mojej. Ale to dość zagmatwane, ponieważ jestem w stanie zwiększyć liczbę liczników, ale nie długość nazwy licznika… Myślisz, że może to być problem?
pan nic
Czy mógłbyś podać mi dokładną nazwę (skróconą), którą otrzymujesz, wywołując funkcję getName () dla licznikastats.counters.server-name.job.job-name.mapper.site.site-name.qualifier.qualifier-name.super-long-string-which-is-not-within-standard-limits
maxmithun
@DennisJaheruddin niestety odszedłem z tej pracy i nie miałem innego wyboru, jak zastosować pewne tymczasowe rozwiązania, aby obejść ten problem, ponieważ w hadoop jira nie podano opinii. Ten problem nie został rozwiązany do dnia, w którym odszedłem z pracy.
pan nic

Odpowiedzi:

2

W kodzie Hadoop nie ma nic, co obcinałoby nazwy liczników po ich zainicjowaniu. Tak więc, jak już zauważyłeś, mapreduce.job.counters.counter.name.maxkontroluje maksymalną długość nazwy licznika (z 64 symbolami jako wartością domyślną ).

Ten limit jest stosowany podczas połączeń do AbstractCounterGroup.addCounter/findCounter. Odpowiedni kod źródłowy jest następujący :

@Override
public synchronized T addCounter(String counterName, String displayName,
                                 long value) {
  String saveName = Limits.filterCounterName(counterName);
  ...

a właściwie :

public static String filterName(String name, int maxLen) {
  return name.length() > maxLen ? name.substring(0, maxLen - 1) : name;
}

public static String filterCounterName(String name) {
  return filterName(name, getCounterNameMax());
}

Jak widać, nazwa licznika jest zapisywana obcięta w stosunku do mapreduce.job.counters.max. Z kolei w kodzie Hadoop jest tylko jedno miejsce, w którym Limits.init(Configuration conf)wykonywane jest wywołanie (wywołanie z LocalContainerLauncherklasy):

class YarnChild {

  private static final Logger LOG = LoggerFactory.getLogger(YarnChild.class);

  static volatile TaskAttemptID taskid = null;

  public static void main(String[] args) throws Throwable {
    Thread.setDefaultUncaughtExceptionHandler(new YarnUncaughtExceptionHandler());
    LOG.debug("Child starting");

    final JobConf job = new JobConf(MRJobConfig.JOB_CONF_FILE);
    // Initing with our JobConf allows us to avoid loading confs twice
    Limits.init(job);

Uważam, że musisz wykonać następujące kroki, aby naprawić zaobserwowany problem z nazwami liczników:

  1. Dostosuj mapreduce.job.counters.counter.name.maxwartość konfiguracji
  2. Uruchom ponownie usługę YARN / MapReduce
  3. Uruchom ponownie swoją pracę

Myślę, że nadal będziesz widzieć skrócone nazwy liczników dla starych zadań.

morsik
źródło
Chociaż jestem w stanie sprawdzić to powinna ona być bardzo pomocny i objaśniający dla osób, które mają ten problem (według upvotes Istnieje wiele takich osób)
mr.nothing
1

getName() wydaje się być przestarzała

Alternatywnie getUri()można użyć domyślnej maksymalnej długości 255.

Link do dokumentacji: getUri()

Nie próbowałem tego osobiście, ale wydaje się, że jest to możliwe rozwiązanie tego problemu.

Akash G.
źródło
Nie jestem pewien, czy problem został rozwiązany poprawnie. Mówisz o org.apache.hadoop.fs.FileSystem#getNametym, ale ten temat dotyczy org.apache.hadoop.mapreduce.Counter#getNamei jego zachowania.
mr. Nic