3 тонкости процессоров в NiFi, о которых вы не знали + 5 лучших практик конфигурирования

Автор Категория ,
3 тонкости процессоров в NiFi, о которых вы не знали + 5 лучших практик конфигурирования

Продолжая обучение дата-инженеров, сегодня рассмотрим, как сделать управление потоками данных в Apache NiFi эффективнее. Читайте далее, какие настройки позволят обойтись без процессора RetryFlowFile для повторных попыток, зачем менять GetFile на ListFile и FetchFile, когда использовать воронки и почему типичные настройки Linux не подходят для NiFi.

Неочевидные особенности готовых процессоров

Напомним, одно из главных достоинств Apache NiFi как инструмента управления потоками данных – это возможность автоматической генерации кода из результатов моделирования в пользовательском интерфейсе. Однако, как мы уже отмечали во вчерашней статье про Apache AirFlow, инженерия данных активно использует лучшие практики разработки ПО. В частности, одной из них считается применение шаблонов проектирования, которые можно использовать повторно, делать код более читаемым и простым в обслуживании. NiFi этот прием даже добавляет новые функциональные возможности.

Рассмотрим это утверждение на примере: поток данных потребляет сообщения из одного Kafka-кластера и публикует их в другом кластере. Иногда бывает, что некоторые сообщения не удается считать и/или записать. Для этого случая следует определить число повторных попыток. Начиная с версии 1.9.0, выпущенной в феврале 2019 года, можно использовать процессор RetryFlowFile [1].

Напомним, потоковые файлы, передаваемые процессору RetryFlowFile, имеют значение «Атрибут повтора» (Retry Attribute), сопоставленное с настроенным значением «Максимальное количество повторов» (Maximum Retries). Если текущее значение атрибута ниже настроенного максимума, повтор FlowFile игнорируется. Иначе, если значение атрибута повтора больше заданного максимума, FlowFile будет передавать отношение retries_exceeded. Когда входящий потоковый файл имеет нечисловое значение в настроенном атрибуте «Retry Attribute», оно будет сброшено на 1. Дополнительные динамические свойства могут быть определены для любых атрибутов потоковых файлов, передаваемых в связь retries_exceeded, с помощью языка выражения атрибутов. Отношение retries_exceeded не нужно передавать обратно на входной процессор, если потоковый файл превысил заданное максимальное количество повторов, чтобы завершить ограниченный цикл обратной связи [2].

Впрочем, для настройки повторных попыток можно обойтись и без процессора RetryFlowFile с его если сложными настройками, создав переменную максимального числа повторений в реестре переменных и установив для нее нужное значение. А на вкладке Advanced процессора UpdateAttribute определить правила [1]:

  • сброс счетчика повторных попыток до 1 в случае, если нужно снова передать обработанный ранее FlowFile;
  • увеличение счетчика повторных попыток для ранее обработанного FlowFile.

Таким образом, знание альтернативных процессоров вместо наиболее часто используемых упрощает работу дата-инженера в Apache NiFi. Аналогичный вывод можно сделать относительно особенностей процессора GetFile. Например, необходимо получить файлы в определенном каталоге. На первый взгляд, следует взять готовый процессор GetFile, создающий FlowFiles из файлов в каталоге, игнорируя те, для которых у NiFi нет прав хотя бы на чтение.

Однако, если установить политику выполнения GetFile на Primary-узел кластера, это может привести к тому, что он будет передавать большие файлы по сети другим узлам, что замедлит весь процесс. Обойти это поможет комбинация процессоров List и FetchFile, разделив процесс на два этапа [1]:

  • сперва ListFile выполняется на первичном узле извлекая метаданные файлов как FlowFiles. Этот процессор использует балансировку нагрузки для распределения файлов между узлами NiFi-кластера. ListFile также использует управление состоянием на основе кластера для хранения последней запрошенной метки времени, что актуально в случае сбоя Primary-узла;
  • FetchFile выполняется на всех узлах кластера, получая и извлекая файлы из потока.

Не отходя от процессоров, поговорим про воронку (Funnel) – компонент NiFi для объединения данных из нескольких подключений в одно, который предоставляет следующие преимущества [1]:

  • экономия свободного пространства на холсте в GUI, за счет визуального объединения множества соединений с одним и тем же местом назначения;
  • соединения можно настроить с помощью приоритетов потокового файла, направляя приоритизированные данные из нескольких подключений можно направлять в одно, вместо установки отдельных приоритетов для каждого подключения независимо.

Например, каждый из процессоров GenerateFlowFile передает свои потоковые файлы в воронку, а затем в процессор PublishKafka. Если необходимо добавить для всех них общий атрибут, то в отсутствие воронки придется последовательно заменять место назначения всех этих очередей на процессор UpdateAttribute. А с Funnel можно просто изменить место назначения агрегирующей воронки.

Или, к примеру, требуется публиковать FlowFiles в Kafka в порядке их создания. Это довольно сложно сделать, если у каждого GenerateFlowFile своя очередь для процессора PublishKafka. Но с использованием воронки достаточно лишь добавить приоритет в одну очередь между воронкой и PublishKafka. В итоге каждый FlowFile передается в эту очередь, а затем упорядоченно отправляется в PublishKafka.

Впрочем, знание типовых и альтернативных процессоров NiFi – не единственный инструмент дата-инженера для повышения эффективности эксплуатации этого фреймворка. Как мы вчера упоминали на примере Apache AirFlow, важно также разбираться в особенностях окружения развернутой среды, что будет рассмотрено далее.

ТОП-5 рекомендаций по настройке Linux для Apache NiFi

Типичные настройки операционной системы Linux по умолчанию не всегда хорошо подходят для приложений с интенсивным вводом-выводом, таких как Apache NiFi. Улучшить эту ситуацию помогут лучшие практики конфигурирования [3]:

  • определить максимальное количество дескрипторов файлов. NiFi в любой момент времени потенциально может открыть очень большое количество дескрипторов файлов. Поэтому целесообразно увеличить лимит открытых файлов, отредактировав /etc/security/limits.conf. Например, добавить подобные строки

* hard nofile 50000

* soft nofile 50000

В данном примере это означает, что процесс может открыть за один раз 50 тысяч файлов, при этом soft-лимит может повышен вплоть до значения hard-лимита, который может быть только снижен.

  • Задать максимальное количество многопоточных процессов. NiFi может быть настроен на создание значительного количества потоков, лимит которых задается в файле /etc/security/limits.conf

* hard nproc 10000

* soft nproc 10000

Отдельные дистрибутивы Linux требуют также изменений в файле /etc/security/limits.d/90-nproc.conf – туда следует добавить  сведения о sofy-лимите* soft nproc 10000

  • Увеличить количество доступных портов сокетов TCP, что особенно важно, когда поток данных настраивает и отключает большое количество сокетов за небольшой промежуток времени: sudo sysctl -w net.ipv4.ip_local_port_range=”10000 65000″
  • определить, как долго сокеты остаются в состоянии TIMED_WAIT при закрытии, чтобы быстро настраивать и демонтировать новые сокеты.

sudo sysctl -w net.ipv4.netfilter.ip_conntrack_tcp_timeout_time_wait=”1″

  • отключить подкачку для NiFi, как для постоянно работающего приложения. Для этого нужно отредактировать файл /etc/sysctl.conf, добавив строку swappiness = 0

Для разделов, обрабатывающих различные репозитории NiFi, рекомендуется отключить atime, чтобы увеличить пропускную способность. Отредактируйте файл /etc/fstab, добавив для нужных разделов параметр noatime.

Как написать свой собственный процессор Apache NiFi, читайте в нашей новой статье. О полезных функциях нового релиза Apache NiFi 1.14.0, который вышел 14 июля 2021 года, читайте здесь. А еще больше деталей про администрирование и использование Apache NiFi для решения задач дата-инженерии вы узнаете на специализированных курсах для разработчиков, ИТ-архитекторов, инженеров данных, администраторов, Data Scientist’ов и аналитиков Big Data в нашем лицензированном учебном центре обучения и повышения квалификации в Москве:

Источники

  1. https://benyaakobi.medium.com/design-patterns-in-nifi-f9ad1cb02588
  2. https://nifi.apache.org/docs/nifi-docs/components/org.apache.nifi/nifi-standard-nar/1.13.2/org.apache.nifi.processors.standard.RetryFlowFile/index.html
  3. https://docs.cloudera.com/HDPDocuments/HDF3/HDF-3.4.0/nifi-configuration-best-practices/content/configuration-best-practices.html