Hadoop obcięta / niespójna nazwa licznika

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.

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ń.

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.