Мы часто делимся полезными лайфхаками и лучшими практиками администрирования и эксплуатации технологий Big Data. Сегодня специально для обучения дата-инженеров рассмотрим, как лучше настроить репозитории Apache NiFi и параметры кластера, чтобы повысить производительность и надежность этого популярного ETL-маршрутизатора потока данных.
4 репозитория Apache NiFi
Репозиторий потоковых файлов содержит информацию обо всех имеющихся Flow File. Каждая запись содержит все атрибуты конкретного потокового файла, а также указатель на то, где в репозитории контента хранится фактическое содержимое потокового файла. По сути, это журнал с опережающей записью, WAL-лог метаданных потоковых файлов, которые существуют в системе, т.к. все изменения записываются в этот журнал до их применения. Этот репозиторий обеспечивает отказоустойчивость, необходимую для обработки перезапусков и сбоев системы.
В Apache NiFi потоковые файлы никогда не изменяются: исходный потоковый файл сохраняется при каждом его обновлении/модификации, а копия создается с обновленной версией. Этот прием помогает поддерживать надежное происхождение данных во всей системе. В идеале репозиторий FlowFile следует располагать на высокопроизводительном RAID-массиве, который не используется совместно с другими приложениями, где высока скорость ввода-вывода. Кроме того, не рекомендуется располагать репозиторий потоковых файлов на том же RAID-массиве, что и репозитории контента и происхождения (Provenance). Если репозиторий FlowFile будет поврежден или закончится место на диске, состояние потоковых файлов может быть безвозвратно утеряно. Подробнее об этом мы писали здесь и здесь.
Репозиторий базы данных содержит 2 экземпляра очень быстрой транзакционной базы данных H2:
- nifi-flow-audit.h2.db используется для отслеживания всех изменений конфигурации, сделанных в пользовательском интерфейсе;
- nifi-user-keys.h2.db используется только тогда, когда NiFi защищен, и содержит информацию о том, кто зашел в систему.
Примечательно, что H2 нельзя заменить на другую базу данных, это встроенное решение не подлежит модификации.
В репозитории контента хранится содержимое потоковых файлов, включая несколько исторические версии, если включено архивирование. Если содержимое Flow File больше не нужно, оно удаляется или архивируется, в зависимости от настроек в конфигурационном файле свойств. Рекомендуется перенести этот репозиторий на отдельный жесткий диск или RAID-массив. Дополнительный прирост производительности можно получить, определив несколько репозиториев контента для каждого экземпляра NiFi. Для этого следует закомментировать настройку nifi.content.repository.directory.default и добавить новую настройку для каждого репозитория контента. Например, nifi.content.repository.directory.contentS1R1=…, nifi.content.repository .directory.contentS1R2 = …, nifi.content.repository.directory.contentS1R3 = …. В этом примере S#R# представляет номер системы и номер репозитория соответственно. Разделив содержимое на несколько дисков, можно значительно повысить производительность ввода-вывода, а также увеличить надежность в случае сбоев.
Наконец, репозиторий происхождения данных содержит исторические записи для каждого Flow File. По сути, это линия передачи данных от момента создания потокового файла до момента завершения его обработки. Эта цепочка хранения содержит запись о каждой модификации Flow File. По умолчанию здесь используется группа из 16 лог-файлов происхождения данных для отслеживания событий и увеличения пропускной способности. Данные о происхождении хранятся в индексе Lucene, разбитом на несколько сегментов, и часто обновляются. Частое обновление проводит к большому количеству дисковых операций ввода-вывода, что мы отмечали в этой статье. Поэтому можно значительно повысить производительность и надежность, разделив Provenance-репозиторий на несколько репозиториев. Также рекомендуется обновить параметр nifi.provenance.repository.implementation в файле nifi.properties для использования org.apache.nifi.provenance.WriteAheadProvenanceRepository вместо PersistentProvenanceRepository по умолчанию.
Надежность и доступность: конфигурирование кластера
Кластеризация позволяет NiFi масштабироваться для достижения дополнительной пропускной способности, но не обеспечивает высокой доступности. В кластерной среде каждый узел отвечает за обработку своих собственных потоковых файлов и имеет свои собственные вышеописанные репозитории при использовании одной и той же конфигурации Flow File. Кластеризация осуществляется с помощью сервиса синхронизации метаданных Apache ZooKeeper, уже включенным в дистрибутив NiFi. Он предоставляет сервисы распределенной конфигурации, синхронизации и реестр имен для больших распределенных систем, а также отвечает за выбор основного узла. О том, как настроить встроенный Zookeeper для Apache NiFi, мы писали здесь.
Примечательно, что при выходе узла из строя, оставшиеся узлы НЕ берут на себя его нагрузку и не обрабатывают потоковые файлы, поскольку каждый узел отвечает только за обработку своего собственного набора данных. Тем не менее, когда отказавший узел возвращается в оперативный режим и присоединяется к кластеру, он возобновляет обработку своих собственных Flow File, если сбой не был катастрофическим, т.е. отсутствуют повреждения репозитория потоковых файлов и есть место на диске.
Высокая доступность в Apache NiFi средствами автоматического перехода на другой ресурс изначально не поддерживается, но ее можно настроить с помощью внешней системы для мониторинга узлов в кластере. А если один узел выйдет из строя, резервный узел может быть подключен к сети. Пока новый узел, подключенный к сети, ссылается на репозитории отказавшего узла и конфигурацию потокового файла, он должен иметь возможность присоединиться к кластеру.
Если узел выходит из строя или отключается от кластера и не может повторно присоединиться, причину следует искать в каталоге nifi-1.x.x/logs. Файл nifi-app.log регистрирует почти все действия, включая ошибки. В частности, там можно увидеть что, конфигурация файла потока узла устарела. Эта проблема в основном наблюдалась в более старых версиях фреймворка до 1.0.0. При этом следует просто удалить или переименовать файл flow.xml.gz в каталоге conf и перезапустить узел. Когда узел пытается подключиться, основной узел (координатор кластера) увидит, что у присоединяющегося узла нет шаблона файла потока, и предоставит ему самую последнюю версию.
Также администратору кластера NiFi следует убедиться, что регулярные heartbeat-сигналы отправляются координатору кластера. Если координатор кластера не получает регулярные контрольные сообщения с частотой интервала, настроенной в файле conf/nifi.properties, от отдельного узла, тот отключится. Координатор кластера будет ждать в 8 раз больше настроенного nifi.cluster.protocol.heartbeat.interval перед отключением узла. Это может произойти по многим причинам, таким как задержка в сети между узлом и координатором кластера или чрезмерная сборка мусора. Поэтому важно настроить достаточно памяти кучи JVM для каждого узла, что мы рассматривали в прошлый раз.
Узнайте больше про тонкости администрирования и эксплуатации Apache NiFi для построения эффективных ETL-конвейеров потоковой аналитики больших данных на специализированных курсах в нашем лицензированном учебном центре обучения и повышения квалификации для разработчиков, менеджеров, архитекторов, инженеров, администраторов, Data Scientist’ов и аналитиков Big Data в Москве:
Источники
