2016-09-27 3 views
4

Я разработал прототип прототипа NiFi для приема данных в HDFS. Теперь я хотел бы улучшить общие выступления, но, похоже, я не могу двигаться вперед. Проблемы настройки Apache NiFi

Поток принимает входные файлы csv (каждая строка содержит 80 полей), разделяет их на уровне строк, применяет некоторые преобразования к полям (используя 4 пользовательских процессора, выполняемых последовательно), буферизует новые строки в файлы csv , выводит их в HDFS. Я разработал процессоры таким образом, что содержимое файла потока доступно только один раз, когда каждая отдельная запись считывается, а ее поля перемещаются в атрибуты потока. Тесты выполнялись на экземпляре amazon EC2 m4.4xlarge (16-ядерный процессор, 64 ГБ оперативной памяти).

Это то, что я пытался до сих пор:

  • перемещена в хранилище flowfile и хранилище контента на разных дисках SSD
  • Перемещенные хранилище провенанс в памяти (Nifi не может идти в ногу с скорость событий)
  • Конфигурирование системы в соответствии с ​configuration best practices
  • Я попытался назначить несколько потоков для каждого из процессоров, чтобы достичь различных чисел от общего количества нитей
  • Я попытался увеличения nifi.queue.swap.threshold и установка противодавления никогда не достигнет предельного значения SWAP
  • Пробовал различные настройки виртуальной машины Java памяти от 8 до 32 Гб (в сочетании с G1GC)
  • Я уже пробовали увеличивать характеристики экземпляра, ничего не меняет

из мониторинга я выполнил это выглядит как диски не являются узким местом (они в основном на холостом ходу большую часть времени, показывая вычисление фактически выполняется в -memory), а средняя загрузка ЦП ниже 60%.

Больше всего я могу получить 215 тыс. Строк в минуту, что составляет 3,5 тыс. Строк в секунду.С точки зрения объема, это всего лишь 4,7 МБ/с. Я стремлюсь к чему-то определенно большему, чем это. Как и для сравнения, я создал поток, который читает файл, разбивает его по строкам, объединяет их в блоки и выходы на диске. Здесь я получаю 12 тыс. Строк в секунду или 17 МБ/с. Не слишком удивительно быстро, и позвольте мне подумать, что, вероятно, я делаю что-то неправильно. У кого-нибудь есть предложения по улучшению выступлений? Насколько я выиграю от запуска NiFi на кластере вместо того, чтобы расти с помощью спецификаций экземпляра? Спасибо всем

+0

Могут ли ваши пользовательские процессоры быть доступны в любом месте для оценки? С точки зрения потока, который вы установили, где пропускная способность падает? Предположительно, вы используете GetFile, за которым следует ваша цепочка. – apiri

+0

Да, конечно! https://drive.google.com/drive/folders/0BwYJl5zg1oWSbi1nbG9LQnY2ZWc?usp=sharing Моя пропускная способность падает с помощью настраиваемых процессоров. Я ожидал, что, поскольку они выполняют более сложные операции, чем встроенные. Но все же они просто получают доступ к атрибутам потока и создают новые. Назначение нескольких потоков для них, похоже, не сработает. Тем не менее, точкой последней части сообщения было то, что даже в обход их, и просто разбивая строки и объединяя их вместе, я получаю 12k строк/секунд. Должен ли я перейти на более высокий уровень и рассматривать партии строк как единицы работы? Спасибо за ваше время. – riccamini

+0

В среднем, каков профиль файловых файлов, с которыми вы работаете, с точки зрения размера? Один пункт, который выпрыгивает на меня, - это тот, который обрабатывает и усиливает это давление на кучу. Какую версию NiFi вы используете? С экземпляром класса m4 я предполагаю, что это EBS. Какой класс EBS? GP2? Предоставленные iOPS? – apiri

ответ

3

Оказалось, что плохие характеристики были комбинацией как разработанных пользовательских процессоров, так и встроенного процессора слияния. same question mirrored on the hortonworks community forum получил интересную обратную связь.

Что касается первой проблемы, предлагается добавить аннотацию SupportsBatching к процессорам. Это позволяет процессорам объединять несколько коммитов и позволяет пользователю NiFi поддерживать латентность или пропускную способность при выполнении процессора из меню конфигурации. Дополнительную информацию можно найти в документации here.

Другой вывод заключается в том, что встроенный процессор MergeContent, похоже, не имеет оптимальных характеристик, поэтому, если возможно, следует рассмотреть возможность изменения потока и избежать фазы слияния.

Смежные вопросы