Зрізане / невідповідне ім'я лічильника Hadoop

На даний момент у мене є робота Hadoop, яка створює лічильники з досить відомим ім’ям.

Так , наприклад, наступний: stats.counters.server-name.job.job-name.mapper.site.site-name.qualifier.qualifier-name.super-long-string-which-is-not-within-standard-limits. Цей лічильник усічений у веб-інтерфейсі та під час getName()виклику методу. Я виявив, що Hadoop має обмеження на ім'я лічильника, і цей ідентифікатор налаштувань mapreduce.job.counters.counter.name.maxпризначений для налаштування цього обмеження. Тож я збільшив це до, 500і веб-інтерфейс тепер показує повне ім’я лічильника. Але getName()з лічильника все одно повертається усічене ім'я.

Чи може хтось, будь ласка, пояснити це чи вказати мені на мої помилки? Дякую.

РЕДАГУВАТИ 1

Моя конфігурація сервера Hadoop складається з єдиного сервера з HDFS, YARN та карто-зменшенням на ньому. Під час зменшення карти є кілька приростів лічильника, і після завершення завдання, ToolRunnerя отримую лічильники з використанням org.apache.hadoop.mapreduce.Job#getCounters.

РЕДАГУВАТИ 2

Версія Hadoop така:

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

Я провів додаткове розслідування, і, схоже, це питання описує ситуацію, подібну до моєї. Але це досить заплутано, бо я можу збільшити кількість лічильників, але не довжину імені лічильника ...

РЕДАГУВАТИ 3

Сьогодні я витратив досить багато часу на налагодження внутрішніх елементів Hadoop. Кілька цікавих речей:

1. org.apache.hadoop.mapred.ClientServiceDelegate#getJobCountersМетод повертає купу лічильників з пряжі з обрізаними іменами та ПОВНИМИ відображуваними іменами.
2. Не вдалося самостійно налагодити карти та редуктори, але за допомогою реєстрації здається, що org.apache.hadoop.mapreduce.Counter#getNameметод працює належним чином під час виконання редуктора.

У коді Hadoop немає нічого, що скорочує імена лічильників після його ініціалізації. Отже, як ви вже вказували, mapreduce.job.counters.counter.name.maxконтролює максимальну довжину імені лічильника (із значеннями за замовчуванням 64 символи ).

Це обмеження застосовується під час дзвінків на AbstractCounterGroup.addCounter/findCounter. Відповідний вихідний код такий :

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

і насправді :

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());
}

Як бачите, ім'я лічильника зберігається усіченим щодо mapreduce.job.counters.max . У свою чергу, у коді Hadoop є лише одне місце, де Limits.init(Configuration conf)виконується виклик до (викликається з LocalContainerLauncherкласу):

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);

Я вважаю, що вам потрібно виконати наступні кроки, щоб вирішити проблему назв лічильників, яку ви спостерігаєте:

1. Налаштуйте mapreduce.job.counters.counter.name.maxзначення конфігурації
2. Перезапустіть послугу YARN / MapReduce
3. Повторно виконайте свою роботу

Ви все ще побачите усічені назви лічильників для старих робіт, я думаю.

getName() здається застарілим

В якості альтернативи getUri()може використовуватися максимальна довжина за замовчуванням 255.

Посилання на документацію: getUri()

Не пробували особисто, але, здається, це можливе вирішення цієї проблеми.