Что такое кластеризация с нулевым лидером, чем координатор отличается от основного узла, каким образом устроен механизм выбора лидера, зачем нужна изоляция процессоров и как ее реализовать, а также другие особенности кластера Apache NiFi.
Ключевые компоненты кластера Apache NiFi
Хотя Apache NiFi можно запустить на локальной машине, чтобы он выполнялся как процесс JVM в операционной системе хоста, распределенный режим позволяет обрабатывать большие потоки данных намного быстрее, что актуально для Big Data систем. Начиная с версии 1.0 в NiFi используется парадигма кластеризации с нулевым лидером. Каждый узел в кластере NiFi выполняет одни и те же задачи с данными, но каждый работает со своим набором данных. Внешний (по отношению к NiFi) сервис синхронизации метаданных Apache ZooKeeper выбирает один узел в качестве координатора кластера, и автоматически обрабатывает отказоустойчивость. Все узлы кластера сообщают информацию о своем состоянии координатору кластера, периодически отправляя тактовый сигнал сердцебиения (heartbeat).
Координатор кластера отвечает за отключение и подключение узлов. Помимо координатора, в каждом кластере есть один основной узел, также выбранный ZooKeeper. Однако, взаимодействовать с кластером NiFi можно через пользовательский интерфейс (UI) любого узла: любое изменение потока данных реплицируется на все узлы в кластере, что позволяет использовать несколько точек входа. Таким образом, каждый узел в кластере имеет идентичный поток и выполняет одни и те же задачи с данными, но каждый узел работает со своим набором данных. Кластер автоматически распределяет данные по всем активным узлам.
Координатор кластера отвечает за отключение узлов, которые не отправляют heartbeat-сигнал в течение некоторого времени (по умолчанию каждые 5 секунд). Когда новый узел присоединяется присоединиться к кластеру NiFi, он должен сначала подключиться к координатору, чтобы получить самую последнюю информацию о потоке. Координатор кластера разрешает новому узлу присоединиться, предоставляя ему текущий поток, и узел присоединяется к кластеру, если копия потока узла совпадает с копией, предоставленной координатором кластера. Если версия конфигурации потока узла отличается от версии координатора кластера, узел не присоединится к кластеру.
Если одного экземпляра NiFi на одном сервере недостаточно для обработки имеющегося у них объема данных, можно запустить один и тот же поток данных на нескольких серверах NiFi. Однако это создает проблему управления, поскольку каждый раз при изменении или обновлении потока данных придется вносить эти изменения на каждом сервере, а затем отслеживать его отдельно. Объединив серверы NiFi в кластер, можно увеличить возможности обработки вместе с единым интерфейсом, через который можно вносить изменения в поток данных и отслеживать поток данных. Кластеризация позволяет вносить каждое изменение только один раз, после чего оно реплицируется на все узлы кластера. Через единый интерфейс дата-инженер может контролировать работоспособность и статус всех узлов.
Основной узел и изолированные процессоры
Каждый кластер NiFi имеет один основной (primary) узел. Основной узел выбирается на основе алгоритма выбора лидера (leader election algorithm). При запуске кластера первым узлом становится основной (primary) узел. Затем, при добавлении новых узлов в кластер, они проходят процесс выбора нового основного узла. За выбор лидера в NiFi отвечает Apache ZooKeeper, используя алгоритм на основе избирательных узлов (leader election algorithm based on elector nodes).
Когда узел NiFi запускается в режиме кластера, он регистрирует себя в ZooKeeper и участвует в выборе основного узла. ZooKeeper отслеживает доступность узлов и автоматически выбирает нового основного узла, если прежний становится недоступным. При первом запуске кластера NiFi должен определить, на каком из узлов установлена корректная версия потока. Это делается путем голосования по потокам, которые есть у каждого из узлов. Когда узел пытается подключиться к кластеру, он предоставляет копию своего локального потока координатору кластера. Если ни один поток еще не был выбран «правильным», поток узла сравнивается с потоками каждого из других узлов. Если поток другого узла совпадает с этим потоком, за этот поток подается голос. Если ни один другой узел еще не сообщил о таком же потоке, этот поток будет добавлен в пул возможных выбранных потоков с одним голосом.
По прошествии времени, которое настраивается путем установки свойства nifi.cluster.flow.election.max.wait.time или за поток проголосовало количество узлов, заданное в свойстве nifi.cluster.flow.election.max.candidates, этот поток считается «правильная» версией. Любой узел, поток данных, пользователи, группы и политики которого конфликтуют с выбранными, создаст резервную копию любых конфликтующих ресурсов и заменит локальные ресурсы ресурсами из кластера. Способ выполнения резервного копирования зависит от настроенного поставщика политики доступа и поставщика групп пользователей. Для поставщиков политик доступа на основе файлов резервная копия будет записана в тот же каталог, что и существующий файл, например, $NIFI_HOME/conf, и будет иметь то же имя, но с суффиксом «.» и метка времени.
Например, если сам поток конфликтует с потоком кластера в 12:05:03 1 января 2020 года, файл узла flow.json.gzбудет скопирован в flow.json.gz.2020-01-01-12-05-03, а поток кластера будет записан в flow.json.gz. Аналогично это произойдет для файлов users.xml и authorizations.xml, чтобы при необходимости вручную отменить поток, например, переименовав файл резервной копии. Перед тем, как наследовать выбранный поток, NiFi сначала прочитает репозиторий FlowFile и любые файлы подкачки, чтобы определить, какие очереди в потоке данных в настоящее время содержат данные. Если в потоке данных существует какая-либо очередь, содержащая FlowFile, эта очередь также должна существовать в выбранном потоке данных. Если эта очередь не существует в выбранном потоке данных, узел не унаследует поток данных, пользователей, группы и политики. Вместо этого NiFi будет регистрировать ошибки по этому поводу и не сможет запуститься. Это гарантирует, что даже если на узле есть данные, хранящиеся в подключении, а поток данных кластера отличается, перезапуск узла не приведет к потере данных.
Таким образом, выбор основного узла в NiFi важен для обеспечения целостности и надежности кластера. Основной узел отвечает за координацию работы других узлов, управление распределенными ресурсами и принятие решений о выполнении определенных операций, таких как изменение конфигурации или управление потоками данных. В частности, на основном узле можно запустить изолированные процессоры, когда не нужно, чтобы каждый процессор потока данных работал на каждом узле кластера. По умолчанию в кластере NiFi один и тот же поток данных работает на всех узлах, и каждый компонент в потоке выполняется на каждом узле. Но иногда требуется настроить отдельно взятые процессоры локально, т.е. чтобы они выполнялись не на всех узлах кластера, а только на определенных. В частности, такая ситуация может возникнуть, когда используется процессор, который взаимодействует с внешним сервисом по плохо масштабируемому протоколу. Например, процессор GetSFTP извлекает файлы с SFTP-сервера из удаленного каталога, используя SFTP-протокол и создает из них файлы потока. Если процессор GetSFTP работает на каждом узле в кластере и пытается одновременно получать данные из одного и того же удаленного каталога, может возникнуть состояние гонки — ошибка проектирования многопоточной системы, когда ее работа зависит от порядка выполнения кода. Избежать этого можно, настроив процессор GetSFTP на основном узле для изолированной, т.е. локальной, работы только на этом конкретном узле. Можно настроить конфигурацию потока данных так, чтобы процессор GetSFTP извлекал данные и распределял их нагрузку между остальными узлами в кластере. Впрочем, можно просто использовать автономный экземпляр NiFi для извлечения данных и передачи их в кластер. Выбор вариант настройки зависит от доступных ресурсов и параметров настройки кластера, заданных администратором.
Узнайте больше про администрирование и использование Apache NiFi для построения эффективных ETL-конвейеров потоковой аналитики больших данных на специализированных курсах в нашем лицензированном учебном центре обучения и повышения квалификации для разработчиков, менеджеров, архитекторов, инженеров, администраторов, Data Scientist’ов и аналитиков Big Data в Москве:
Источники
