Важно: Данный раздел актуален для Платформы данных в Публичном облаке и On-Premise.
Наименование системы: RT.StreamingNiFi.
RT.StreamingNiFi – программное обеспечение, предназначенное для организации ETL-процессов в рамках экосистемы RT.DataLake (Hadoop).
Пользователи Системы должен обладать необходимыми и достаточными доступами, в том числе сетевыми, к предустановленным в рамках Системы компонентам.
Для получения паролей к учётным записям для проведения работ с Системой пользователю необходимо обращаться в подразделение, осуществляющее поддержку соответствующих систем (RT.StreamingNiFi).
В руководстве приведены сведения для пользователей RT.StreamingNiFi – поддержка браузеров, особенности терминологии, описание пользовательского интерфейса, создание потоков данных, настройка процессора, пользовательские свойства, а также описаны команды и принцип управления потоками данных.
RT.StreamingNiFi – система потоков данных, основанная на концепциях потокового программирования, которая поддерживает мощные и масштабируемые направленные графы маршрутизации данных, их преобразование и логичную системную медиацию. RT.StreamingNiFi имеет веб-интерфейс пользователя для работы с потоками данных по их проектированию, управлению, обратной связи и мониторингу.
Браузер | Версия браузера |
---|---|
Google Chrome | [текущая] и [текущая—1] |
Mozilla Firefox | [текущая] и [текущая—1] |
Microsoft Edge | [текущая] и [текущая—1] |
Apple Safari | [текущая] и [текущая—1] |
Версии [текущая] и [текущая—1] указывают, что пользовательский интерфейс поддерживается в текущей стабильной версии этого браузера и предыдущей. Например, если текущая стабильная версия — 45.X, то официально поддерживаемыми версиями будут 45.X и 44.X.
Для Safari, который выпускает основные версии гораздо реже, [текущая] и [текущая—1] просто обозначают два последних выпуска.
Поддерживаемые версии браузера определяются возможностями пользовательского интерфейса и зависимостями, которые он использует. Функции пользовательского интерфейса разрабатываются и поддерживаются в указанных браузерах.
Хотя пользовательский интерфейс может успешно работать в неподдерживаемых браузерах, он не тестируется в них активно. Кроме того, пользовательский интерфейс разработан для ПК и в настоящее время не поддерживается в мобильных браузерах.
В большинстве сред весь пользовательский интерфейс виден в вашем браузере. Однако пользовательский интерфейс имеет адаптивный дизайн, который позволяет прокручивать экраны по мере необходимости в браузерах меньшего размера или на планшетах.
В средах, где ширина вашего браузера менее 800 пикселей и высота менее 600 пикселей, части пользовательского интерфейса могут стать недоступными.
Пользовательский интерфейс RT.StreamingNiFi предоставляет механизмы для создания автоматизированных потоков данных (dataflows), а также визуализации, редактирования, мониторинга и администрирования этих потоков данных. Пользовательский интерфейс можно разбить на несколько сегментов, каждый из которых отвечает за разные функциональные возможности приложения. В этом разделе представлены скриншоты приложения и выделены различные сегменты пользовательского интерфейса. Каждый сегмент обсуждается более подробно далее в документе.
Когда приложение запускается, пользователь может перейти к пользовательскому интерфейсу, перейдя по адресу по умолчанию https://localhost:8443/nifi в веб-браузере. Конфигурация по умолчанию генерирует имя пользователя и пароль с полными правами системного администратора.
Когда DFM впервые переходит к пользовательскому интерфейсу, предоставляется пустая рабочая область, на которой можно построить поток данных:
Панель инструментов компонент Components Toolbar расположена в верхней левой части экрана. Она состоит из компонентов, которые можно перетащить на рабочую область для создания потока данных. Каждый компонент более подробно описан в п. 7. Создание потока данных.
Строка состояния (Status Bar) находится под панелью Components Toolbar. Status Bar предоставляет следующую информацию:
Панель управления (Operate Palette) расположена в левой части экрана. Она состоит из кнопок, которые используются DFM для управления потоком, а также администраторами, которые управляют доступом пользователей и настраивают системные свойства, например, сколько системных ресурсов должно быть предоставлено приложению.
В правой части рабочей области находятся поиск (Search) и глобальное меню (Global Menu). Глобальное меню содержит параметры, позволяющие манипулировать существующими компонентами, расположенных на рабочей области:
Кроме того, в пользовательском интерфейсе есть некоторые функции, которые позволяют легко перемещаться по рабочей области. Панель навигации (Navigate Palette) можно использовать для перемещения по рабочей области, а также для увеличения и уменьшения масштаба. «Птичий глаз» (Birds Eye View) потока данных обеспечивает верхнеуровневое представление потока данных и позволяет просматривать поток данных крупными блоками. Вы также можете найти навигационную цепочку (Breadcrumbs) в нижней части экрана. При перемещении между группами процессов Breadcrumbs показывают глубину потока. Каждая из групп процессов, перечисленных в навигационной цепочке, представляет собой ссылку, которая вернёт вас обратно на этот уровень потока.
Мультиарендная (мультитенантная) авторизация позволяет нескольким группам пользователей (арендаторов) управлять, контролировать и наблюдать за различными частями потока данных с разными уровнями авторизации. Когда аутентифицированный пользователь пытается просмотреть или изменить ресурс RT.StreamingNiFi, система проверяет, есть ли у пользователя права на выполнение этого действия. Эти привилегии определяются политиками, которые вы можете применять ко всей системе или к отдельным компонентам. С точки зрения Dataflow Manager это означает, что как только вы получите доступ к рабочей области RT.StreamingNiFi, вам будет виден и доступен ряд функций, в зависимости от назначенных вам привилегий.
Доступные глобальные политики доступа:
Политика | Привилегия |
---|---|
view the UI | Позволяет пользователям просматривать пользовательский интерфейс. |
access the controller | Позволяет пользователям просматривать и изменять контроллер, включая настройки Management Controller Services, Reporting Tasks, Flow Analysis Rules, Registry Clients, Parameter Providers, Reporting Tasks, Flow Analysis Rules, Registry Clients, Parameter Providers и ноды в кластере. |
query provenance | Позволяет пользователям отправлять поиск по источнику и запрашивать даже происхождение. |
access restricted components | Позволяет пользователям создавать/изменять компоненты с ограниченным доступом при условии, что других разрешений достаточно. Компоненты с ограниченным доступом могут указывать, какие конкретные разрешения требуются. Разрешения могут быть предоставлены для конкретных ограничений или предоставлены независимо от ограничений. Если разрешение предоставлено независимо от ограничений, пользователь может создавать/изменять все компоненты с ограниченным доступом. |
access all policies | Позволяет пользователям просматривать и изменять политики для всех компонентов. |
access users/groups | Позволяет пользователям просматривать и изменять пользователей и группы пользователей. |
retrieve site-to-site details | Позволяет другим инстансам RT.StreamingNiFi получать данные Site-To-Site. |
view system diagnostics | Позволяет пользователям просматривать диагностику системы. |
proxy user requests | Позволяет прокси-машинам отправлять запросы от имени других. |
access counters | Позволяет пользователям просматривать и изменять счётчики. |
Доступные политики доступа на уровне компонентов:
Политика | Привилегия |
---|---|
view the component | Позволяет пользователям просматривать детали конфигурации компонента. |
modify the component | Позволяет пользователям изменять детали конфигурации компонента. |
view provenance | Позволяет пользователям просматривать события источника, созданные этим компонентом. |
view the data | Позволяет пользователям просматривать метаданные и содержимое этого компонента в очередях FlowFile в исходящих соединениях и через события источника. |
modify the data | Позволяет пользователям очищать очереди FlowFile в исходящих соединениях и отправлять повторы через события источника. |
view the policies | Позволяет пользователям просматривать список пользователей, которые могут просматривать и изменять компонент. |
modify the policies | Позволяет пользователям изменять список пользователей, которые могут просматривать и изменять компонент. |
retrieve data via site-to-site | Позволяет порту получать данные от инстансов RT.StreamingNiFi. |
send data via site-to-site | Позволяет порту отправлять данные из инстансов RT.StreamingNiFi. |
Если вы не можете просмотреть или изменить ресурс RT.StreamingNiFi, обратитесь к своему системному администратору.
Если RT.StreamingNiFi настроен для безопасной работы, пользователи смогут запрашивать доступ к DataFlow. Если RT.StreamingNiFi поддерживает анонимный доступ, пользователям будет предоставлен соответствующий доступ и возможность войти в систему.
При нажатии на ссылку входа в систему откроется страница Log In. Если пользователь входит в систему под своим именем пользователя/паролем, ему будет представлена форма для этого. Если RT.StreamingNiFi не настроен на поддержку анонимного доступа и пользователь входит в систему под своим именем пользователя/паролем, он будет немедленно отправлен на форму входа в обход рабочей области.
DFM может создавать автоматизированный поток данных с помощью пользовательского интерфейса RT.StreamingNiFi. Просто перетащите компоненты с панели инструментов на рабочую область, настройте их в соответствии с потребностями и соедините компоненты вместе.
В п. 4 Пользовательский интерфейс RT.StreamingNiFi описаны различные сегменты пользовательского интерфейса и указана панель Components Toolbar. В этом разделе рассматривается каждый из компонентов на этой панели инструментов:
Processor (Процессор) является наиболее часто используемым компонентом, поскольку он отвечает за вход, выход, маршрутизацию и управление данными. Существует много различных типов Процессоров. Фактически, это очень распространённая точка расширения в RT.StreamingNiFi, а это означает, что многие вендоры могут внедрять свои собственные Процессоры для выполнения любых функций, необходимых для их варианта использования. Когда Процессор перетаскивается на рабочую область, пользователю открывается диалоговое окно, позволяющее выбрать, какой тип Процессора использовать:
В правом верхнем углу пользователь может фильтровать список по Processor Type (Типу процессора) или Tags (Тегам), связанным с Процессором. Разработчики процессоров имеют возможность добавлять Теги к своим Процессорам. Эти Теги используются в этом диалоговом окне для фильтрации и отображаются слева в Tag Cloud (Облаке тегов). Чем больше Процессоров существует с определённым Тегом, тем крупнее Тег отображается в Облаке тегов. Щёлкнув Тег в Облаке, вы отфильтруете доступные Процессоры, выбрав только те, которые содержат этот Тег. Если выбрано несколько Тегов, отображаются только те Процессоры, которые содержат все эти Теги. Например, если мы хотим показать только те Процессоры, которые позволяют нам принимать файлы, мы можем выбрать тег files и тег ingest:
Компоненты с ограниченным доступом будут отмечены значком Restricted (красным щитом) рядом с их именем. Это компоненты, которые могут использоваться для выполнения произвольного несанкционированного кода, предоставленного оператором через API/пользовательский интерфейс RT.StreamingNiFi REST, или могут использоваться для получения или изменения данных в хост-системе RT.StreamingNiFi с использованием учётных данных ОС RT.StreamingNiFi. Эти компоненты могут быть использованы авторизованным пользователем RT.StreamingNiFi для выхода за рамки предполагаемого использования приложения, повышения привилегий или раскрытия данных о внутренних компонентах процесса RT.StreamingNiFi или хост-системы. Все эти возможности следует считать привилегированными, и администраторы должны знать об этих возможностях и явно включать их для подмножества доверенных пользователей. Прежде чем пользователю будет разрешено создавать и изменять компоненты с ограниченным доступом, ему должен быть предоставлен доступ. При наведении курсора на значок Restricted отображаются конкретные разрешения, необходимые для компонента с ограниченным доступом. Разрешения можно назначать независимо от ограничений. В этом случае пользователь получит доступ ко всем компонентам с ограниченным доступом. Альтернативно, пользователям может быть предоставлен доступ к определённым ограничениям. Если пользователю предоставлен доступ ко всем ограничениям, которые требует компонент, он будет иметь доступ к этому компоненту при условии, что в противном случае у него будут достаточные разрешения. Дополнительные сведения см. в п. 5 Доступ к пользовательскому интерфейсу с помощью мультиарендной авторизации.
Нажатие кнопки Add или двойной щелчок по Processor Type добавит выбранный Процессор на рабочую область в то место, куда он был перенесен.
Примечание. Любой компонент, добавленный на рабочую область, можно выделить мышкой и переместить в любое место рабочей области. Кроме того, можно выбрать несколько элементов одновременно, удерживая клавишу Shift и выбирая каждый элемент, или удерживая клавишу Shift и перетаскивая рамку выбора вокруг нужных компонентов.
После того, как вы перетащили Процессор на рабочую область, вы можете взаимодействовать с ним, щёлкнув правой кнопкой мыши Процессор и выбрав параметр в контекстном меню. Параметры, доступные вам в контекстном меню, различаются в зависимости от назначенных вам привилегий.
Хотя параметры, доступные в контекстном меню, различаются, при наличии полных прав на работу с Процессором обычно доступны следующие параметры:
Примечание. Для Processors, Ports, Remote Process Groups, Connections и Labels можно открыть диалоговое окно конфигурации, дважды щёлкнув нужный компонент.
Input Port (Входной порт) обеспечивает механизм передачи данных в Process Groups (Группу процессов). Когда Входной порт перетаскивается на рабочую область, DFM предлагается назвать Порт. Все Порты в Группе процессов должны иметь уникальные имена.
Все компоненты существуют только внутри Группы процессов. Когда пользователь первоначально переходит на страницу RT.StreamingNiFi, он попадает в Root Process Group (Корневую группу процессов). Если Входной порт перетаскивается в Корневую группу процессов, Входной порт обеспечивает механизм получения данных от удалённых инстансов RT.StreamingNiFi через Site-to-Site. В этом случае Входной порт можно настроить для ограничения доступа соответствующим пользователям, если RT.StreamingNiFi настроен для безопасной работы. Информацию о настройке безопасной работы RT.StreamingNiFi см. в Инструкции администратора.
Output Port (Выходной порт) предоставляет механизм передачи данных из Process Groups (Группы процессов) в пункты назначения за пределами Группы процессов. Когда Выходной порт перетаскивается на рабочую область, DFM предлагается назвать Порт. Все Порты в Группе процессов должны иметь уникальные имена.
Если Выходной порт перетаскивается в Root Process Group (Корневую группу процессов), Выходной порт обеспечивает механизм для отправки данных в удалённые инстансы RT.StreamingNiFi через Site-to-Site. В этом случае Порт действует как очередь. Когда удалённые инстансы RT.StreamingNiFi извлекают данные из Порта, эти данные удаляются из очередей входящих Connections (Соединений). Если RT.StreamingNiFi настроен для безопасной работы, Выходной порт можно настроить для ограничения доступа соответствующим пользователям. Информацию о настройке безопасной работы RT.StreamingNiFi см. в Инструкции администратора.
Process Group (Группы процессов) можно использовать для логической группировки набора компонентов, чтобы облегчить понимание и обслуживание потока данных. Кроме того, Группы процессов используются как механизм группировки компонентов таким образом, чтобы они работали вместе как единое целое. Например, настроив Execution Engine или FlowFile Outbound Policy.
Когда Группа процессов перетаскивается на рабочую область, DFM предлагается назвать Группу процессов. Группа процессов будет вложена в эту родительскую группу.
После того как вы перетащили Группу процессов на рабочую область, вы можете взаимодействовать с ней, щёлкнув правой кнопкой мыши Группу процессов и выбрав параметр в контекстном меню. Параметры, доступные вам в контекстном меню, различаются в зависимости от назначенных вам привилегий.
Хотя параметры, доступные в контекстном меню, различаются, обычно при наличии полных прав на работу с Группой процессов доступны следующие параметры:
Примечание. Также можно дважды щёлкнуть Группу процессов, чтобы войти в неё.
Примечание. Если для Группы процессов с поддержкой версий выбрано Download flow definition, в выгрузке информация о версии будет отсутствовать. Т.е. результирующее содержимое файла JSON будет одинаковым независимо от того, существует ли версия Группы процессов или нет.
Remote Process Group (RPG, Группа удалённых процессов) выглядит и ведёт себя аналогично Process Group (Группе процессов). Однако Группа удалённых процессов ссылается на удалённый инстанс RT.StreamingNiFi. Когда Группа удалённых процессов перетаскивается на рабочую область, вместо запроса имени DFM запрашивает URL-адрес удалённого инстанса RT.StreamingNiFi. Если удалённый RT.StreamingNiFi является кластерным инстансом, рекомендуется добавить два или более URL-адресов нод кластера, чтобы можно было установить инициирующее соединение, даже если одна из нод недоступна. Несколько URL-адресов можно указать в формате, разделённом запятыми.
Когда данные передаются в кластерный инстанс RT.StreamingNiFi через Группу удалённых процессов, Группа удалённых процессов сначала подключается к удалённому инстансу, URL-адрес которого настроен для определения того, какие ноды находятся в кластере и насколько занята каждая нода. Эта информация затем используется для балансировки нагрузки данных, которые передаются на каждую ноду. Затем удалённые инстансы периодически опрашиваются для определения информации о любых нодах, которые были удалены из кластера или добавлены в него, а также для перерасчёта балансировки нагрузки на основе нагрузки каждой ноды.
После того как вы перетащили Группу удалённых процессов на рабочую область, вы можете взаимодействовать с ней, щёлкнув правой кнопкой мыши Группу удалённых процессов и выбрав параметр в контекстном меню. Опции, доступные вам в меню, различаются в зависимости от назначенных вам привилегий.
Следующие параметры обычно доступны, если у вас есть полные права для работы с Группой удалённых процессов:
Funnel (Воронка) используются для объединения данных из многих Connections (Соединений) в одно Соединение. Это имеет два преимущества. Во-первых, если создано множество Соединений с одним и тем же местом назначения, рабочая область может загромождаться, если этим Соединениям приходится охватывать большое пространство. Объединив Воронкой эти Соединения в одно соединение, оно не будет загромождать пространство. Во-вторых, Соединения можно настроить с помощью приоритетов FlowFile. Данные из нескольких Соединений могут быть объединены Воронкой в одно соединение, предоставляя возможность устанавливать приоритет всех данных в этом одном Соединении, а не устанавливать приоритет данных в каждом Соединении независимо.
Label (Метка) используется для предоставления информации о частях потока данных. Когда Метка перетаскивается на рабочую область, она создаётся размера по умолчанию. Затем размер Метки можно изменить, перетащив маркер в правом нижнем углу. При первоначальном создании Метка не имеет текста. Текст Метки можно добавить, щёлкнув её правой кнопкой мыши и выбрав Configure.
У вас есть доступ к информации о версии ваших Processors (Процессоров), Controller Services (Служб контроллеров), Reporting Tasks (Задач отчётности) и Flow Analysis Rules (Правил анализа потоков). Это особенно полезно, когда вы работаете в кластерной среде с несколькими инстансами RT.StreamingNiFi, на которых работают разные версии компонента, или если вы обновились до более новой версии Процессора. Диалоговые окна Add Processor, Add Controller Service, Add Reporting Task и Add Flow Analysis Rule содержат столбец, идентифицирующий версию компонента, а также имя компонента, организацию или группу, создавшую компонент, и пакет NAR, содержащий компонент.
Каждый компонент, отображаемый на рабочей области, также содержит эту информацию.
При добавлении компонента вы можете сортировать его по номеру версии или фильтровать по исходному источнику.
Для сортировки по версии щёлкните столбец версии для отображения в порядке возрастания или убывания версий.
Чтобы выполнить фильтрацию по группе источников, щёлкните раскрывающийся список источников в левом верхнем углу диалогового окна Add Component и выберите группу, которую вы хотите просмотреть.
Чтобы изменить версию компонента, выполните следующие действия.
1. Щёлкните правой кнопкой мыши компонент на рабочей области, чтобы отобразить параметры конфигурации.
2. Выберите Change version.
3. В диалоговом окне Component Version выберите версию, которую вы хотите запустить, в раскрывающемся списке Version.
При настройке компонента вы также можете просмотреть информацию о зависимостях версий.
1. Щёлкните правой кнопкой мыши свой компонент и выберите Configure, чтобы отобразить диалоговое окно Configure для вашего компонента.
2. Откройте вкладку Properties.
3. Щёлкните значок информации (?), чтобы просмотреть информацию о зависимости версий.
В следующем примере MyProcessor версии 1.0 настроен корректно со службой контроллера StandardMyService версии 1.0, т.е. версии соответствуют друг другу.
Если версия MyProcessor будет изменена на несовместимую версию (2.0), на процессоре будут отображаться ошибки валидации:
А в конфигурации службы контроллера процессора отобразится сообщение об ошибке, поскольку служба больше не действительна:
Чтобы настроить Processor (Процессор), щёлкните правой кнопкой мыши процессор и выберите пункт Configure в контекстном меню. Альтернативно, просто дважды щелкните Processor. Диалоговое окно конфигурации открывается с четырьмя различными вкладками, каждая из которых описывается ниже. После завершения настройки Процессора вы можете применить изменения, нажав Apply, или отменить все изменения, нажав Cancel.
Обратите внимание, что после запуска Процессора, в контекстном меню, отображаемом для Процессора, будет отсутствовать параметр Configure, но появится параметр View Configuration. Конфигурацию Процессора нельзя изменить во время его работы. Прежде чем снова внести изменения в конфигурацию Процессора, необходимо сначала остановить Процессор и дождаться завершения всех его активных задач.
Обратите внимание, что ввод определённых управляющих символов не поддерживается и будет автоматически отфильтрован при вводе. Следующие символы и любые непарные суррогатные коды Юникода не будут сохранены ни в одной конфигурации:
[#x0], [#x1], [#x2], [#x3], [#x4], [#x5], [#x6], [#x7], [#x8], [#xB], [#xC], [#xE], [#xF], [#x10], [#x11], [#x12], [#x13], [#x14],
[#x15], [#x16], [#x17], [#x18], [#x19], [#x1A], [#x1B], [#x1C], [#x1D], [#x1E], [#x1F], [#xFFFE], [#xFFFF]
Первая вкладка в диалоговом окне Processor Configuration — это вкладка Settings:
Эта вкладка содержит несколько различных элементов конфигурации. Во-первых, это позволяет DFM изменить имя Процессора. Имя Процессора (Name) по умолчанию совпадает с типом Процессора (Type). Рядом с именем Процессора находится флажок Enabled, указывающий, активен ли Процессор. Когда Процессор добавляется на рабочую область, он активируется автоматически. Если Процессор неактивен, его нельзя запустить. Неактивное состояние используется для указания того, что при запуске Process Group (Группы процессоров), например, когда DFM запускает всю Группу процессов, этот неактивный Процессор должен быть исключён.
Под конфигурацией имени отображается уникальный идентификатор Процессора (ID), а также тип Процессора (Type) и пакет NAR (Bundle). Эти значения не могут быть изменены.
Далее идут два поля для настройки продолжительности штрафа (Penalty Duration) и продолжительности временной остановки (Yield Duration). Во время обычного процесса обработки фрагмента данных (FlowFile) может произойти событие, указывающее, что данные не могут быть обработаны в данный момент, но данные могут быть обработаны позже. В этом случае Процессор может принять решение о штрафовании FlowFile. Это предотвратит обработку FlowFile в течение некоторого периода времени. Например, если Процессор должен отправить данные в удалённую службу, но у удалённой службы уже есть файл с тем же именем, что и имя файла, указанное Процессором, Процессор может наложить штраф на FlowFile. Penalty Duration позволяет DFM указать, как долго FlowFile должен быть оштрафован. Значение по умолчанию — 30 секунд (30 sec).
Аналогичным образом, Процессор может определить, что существует некоторая ситуация, в которой Процессор больше не может выполнять какие-либо действия, независимо от данных, которые он обрабатывает. Например, если Процессор должен отправить данные в удалённую службу, а эта служба не отвечает, Процессор не сможет добиться какого-либо прогресса. В результате Процессор должен «уступить», т.е. совершить временную остановку, что не позволит запустить Процессор по расписанию в течение некоторой продолжительности времени. Эта продолжительность временной остановки указывается в Yield Duration. Значение по умолчанию — 1 секунда (1 sec).
Последний настраиваемый параметр в левой части вкладки Settings — это Bulletin Level. Всякий раз, когда Процессор записывает события в свой лог, он также создаёт бюллетень. Этот параметр указывает самый низкий уровень бюллетеня, который должен отображаться в пользовательском интерфейсе. По умолчанию для Bulletin Level установлено значение WARN, что означает, что будут отображаться все бюллетени с предупреждениями и ошибками.
Вторая вкладка в диалоговом окне Processor Configuration — это вкладка Scheduling:
Первый вариант конфигурации — это Scheduling Strategy (Cтратегия планирования). Возможны следующие варианты планирования компонентов:
1. Timer driven (Управляемый таймером) — режим по умолчанию. Процессор будет запускаться через регулярные промежутки времени. Интервал запуска Процессора определяется опцией Run Schedule (см. ниже).
2. CRON driven (Управляемый CRON) — при использовании этого режима Процессор запускается периодически, режиму Timer driven. Однако режим CRON driven обеспечивает значительно большую гибкость настройки расписания запуска за счёт расширения конфигурации. Значение расписания запуска по режиму CRON driven представляет собой строку из шести обязательных полей и одного необязательного поля, каждое из которых разделено пробелом. Эти поля:
Поле | Допустимые значения |
---|---|
Секунды | 0-59 |
Минуты | 0-59 |
Часы | 0-23 |
День месяца | 1-31 |
Месяц | 1-12 или JAN-DEC |
День недели | 0-7 или SUN-SAT (0 или 7 — воскресенье) |
Используйте следующие способы указания значений:
Вы также должны знать о нескольких допустимых специальных символах:
Например:
Далее на вкладке Scheduling имеется параметр конфигурации под названием Concurrent Tasks (Параллельные задачи). Параметр контролирует, сколько потоков будет использовать Процессор. Другими словами, он контролирует, сколько FlowFiles должно обрабатываться этим Процессором одновременно. Увеличение этого значения обычно позволяет Процессору обрабатывать больше данных за тот же промежуток времени. Однако он делает это за счёт использования системных ресурсов, которые затем не могут использоваться другими Процессорами. По сути, параметр обеспечивает относительный вес Процессоров — он контролирует, какая часть ресурсов системы должна быть выделена этому Процессору, а не другим Процессорам. Это поле доступно для большинства Процессоров. Однако существуют некоторые типы Процессоров, которые можно запланировать только с одной Параллельной задачей.
Run Schedule (Расписание запуска) определяет, как часто следует планировать запуск Процессора. Допустимые значения этого поля зависят от выбранной Scheduling Strategy (Стратегии планирования) (см. выше). При использовании Стратегии планирования на основе Timer driven (Управляемый таймером) это значение представляет собой продолжительность времени, определяемую числом, за которым следует единица времени. Например, 1 second или 5 mins. Значение по умолчанию 0 sec означает, что Процессор должен запускаться как можно чаще, пока у него есть данные для обработки. Это работает для любой продолжительности времени, равной 0, независимо от единицы времени (например, 0 sec, 0 mins, 0 days). Объяснение значений, применимых для Стратегии планирования на основе CRON driven (Управляемый CRON), см. выше.
Параметр Execution (Выполнение) используется для определения того, на каких нодах будет запланировано выполнение Процессора. Выбор All Nodes приведёт к тому, что этот Процессор будет запланирован на каждой ноде кластера. Выбор Primary Node приведёт к тому, что этот Процессор будет запланирован только на основной ноде. Процессоры, настроенные для выполнения Primary Node, обозначаются буквой P рядом со значком Процессора:
Чтобы быстро идентифицировать Процессоры Primary Node, значок P также отображается на вкладке Processors на странице Summary:
В правой части вкладки Scheduling находится слайдер для выбора Run Duration (Продолжительность запуска). Параметр контролирует, как долго Процессор должен работать при каждом запуске. В левой части слайдера указано Lower latency (Низкая задержка), а в правой — Higher throughput (Более высокая производительность). Когда Процессор завершает работу, он должен обновить репозиторий, чтобы передать FlowFiles в следующее Connection (Соединение). Обновление репозитория является затратным по ресурсам, поэтому чем больше работы можно выполнить за один раз перед обновлением репозитория, тем больше работы сможет обработать Процессор (Higher throughput). Однако это означает, что следующий Процессор не сможет начать обработку этих FlowFiles, пока предыдущий Процесс не обновит этот репозиторий. В результате задержка будет больше (время, необходимое для обработки FlowFile от начала до конца, будет больше). В результате слайдер предоставляет спектр, из которого DFM может выбрать более Lower latency или Higher throughput.
Вкладка Properties предоставляет механизм настройки специфического поведения Процессора. Свойства по умолчанию отсутствуют. Каждый Тип Процессора определяет, какие свойства имеют смысл для его варианта использования. Ниже представлена вкладка Properties для Процессора RouteOnAttribute:
По умолчанию этот Процессор имеет только одно свойство: Routing Strategy (Стратегия маршрутизации). Значение по умолчанию — Route to Property name (Маршрутизация к имени свойства). Рядом с названием этого свойства находится символ вопросительного знака (?). Это символ справки, он отображается и в других местах пользовательского интерфейса и указывает на то, что доступна дополнительная информация. Наведя указатель мыши на этот символ, вы получите дополнительную информацию о свойстве и значении по умолчанию, а также исторические значения, которые были установлены для свойства.
Нажатие на значение свойства позволит DFM изменить это значение. В зависимости от значений, разрешённых для свойства, пользователю либо предоставляется раскрывающийся список, из которого можно выбрать значение, либо предоставляется текстовая область для ввода значения:
В правом верхнем углу вкладки находится кнопка добавления нового свойства. Нажатие этой кнопки откроет DFM диалоговое окно Add Property для ввода имени и значения нового свойства. Не все Процессоры поддерживают свойства, определяемые пользователем. В Процессорах, которые этого не допускают, Процессор становится невалидным, если к нему применены свойства, определяемые пользователем.
Выбранные Процессоры поддерживают конфигурирование статуса Sensitive Value (Чувствительное значение) для свойств, определяемых пользователем. Процессоры отображают поддержку настраиваемого статуса Sensitive Value в диалоговом окне, если она доступна.
Выбор Yes для параметра Sensitive Value указывает RT.StreamingNiFi обрабатывать значение свойства как чувствительное для сохранения конфигурации и операций фреймворка. RT.StreamingNiFi шифрует чувствительные значения при сохранении конфигурации потока и не включает чувствительные значения в экспортированные Flow Definitions (Определения потока).
RouteOnAttribute допускает использование свойств, определяемых пользователем, и не будет валидным, пока пользователь не добавит свойство.
Обратите внимание, что после добавления пользовательского свойства в правой части этой строки появится значок удаления. Нажатие на него приведёт к удалению пользовательского свойства из Процессора.
В некоторые Процессоры также встроен Advanced User Interface (Расширенный пользовательский интерфейс). Например, процессор UpdateAttribute имеет Расширенный пользовательский интерфейс. Чтобы получить доступ к Расширенному пользовательскому интерфейсу, нажмите кнопку Advanced, которая появляется в нижней части окна Configure Processor. Эта кнопка будет доступна только на Процессорах с Расширенным пользовательским интерфейсом.
Некоторые Процессоры имеют свойства, которые относятся к другим компонентам, таким как Controller Services (Службы контроллера), которые также необходимо сконфигурировать. Например, Процессор GetHTTP имеет свойство SSLContextService, которое ссылается на Службу контроллера StandardSSLContextService. Если DFM хочет настроить это свойство, но ещё не создал и не настроил Службу контроллера, у него есть возможность создать Службу на месте, как показано на рисунке ниже.
Вкладка Relationships содержит раздел Automatically Terminate/Retry Relationships (Автоматическое завершение/повторение связей). Здесь перечислены все Relationships, определённые Процессором, вместе с их описанием.
Чтобы Процессор считался валидным и работоспособным, каждая Relationship (Связь), определённая Процессором, должна быть либо подключена к нижестоящему компоненту, либо автоматически завершена. Если Связь автоматически завершается, любой FlowFile, направленный в эту Связь, будет удалён из потока, и его обработка будет считаться завершённой. Любая Связь, которая уже подключена к нижестоящему компоненту, не может быть автоматически прекращена. Связь необходимо сначала удалить из любого Соединения, которое её использует. Кроме того, для любой Связи, выбранной для автоматического завершения, статус автоматического завершения будет очищен (выключен), если Связь будет добавлена в соединение.
Пользователи также могут настроить, следует ли повторять попытку FlowFiles, направленных к данной Связи. Если FlowFile направляется в любую Связь, настроенную на повторную попытку, FlowFile будет повторно поставлен в очередь, и Процессор попытается обработать его снова. Если Процессор снова направляет FlowFile в повторяемую Связь (либо ту же самую Связь, либо другую, настроенную на повторную попытку), он снова будет поставлен в очередь столько раз, сколько указано пользователем. Если Процессор направляет FlowFile в повторяемую Связь после указанного количества повторов, FlowFile будет передан в Соединение(я), которые включают эту Связь, или будет автоматически прекращено, как настроено. Если Процессор направляет FlowFile в любую Связь, для которой не настроена повторная попытка, он будет немедленно перенаправлен в эту Связь.
Например, рассмотрим Процессор с двумя Связями: success и failure. Пользователь настраивает Связь failure на повторную попытку 10 раз, а также на автоматическое завершение. В этом случае, если входящий FlowFile перенаправляется в Связь failure, он будет повторен до 10 раз. Если после 10 попыток он снова будет направлен в failure, он будет автоматически прекращен. Однако, если в какой-то момент он будет перенаправлен в success, он будет немедленно передан в Соединение(я), включающее Связь success, и дальнейшие попытки не будут повторяться.
1. Number of Retry Attempts (Количество повторных попыток). Для Связей, настроенных на повторение, это число указывает, сколько раз FlowFile попытается выполнить повторную обработку, прежде чем он будет перенаправлен в другое место.
2. Retry Back Off Policy (Политика отключения повторной попытки). Когда FlowFile необходимо повторить, пользователь может настроить политику отсрочки с двумя вариантами:
3. Retry Maximum Back Off Period (Максимальный период ожидания повторной попытки). Инициирующие повторные попытки основаны на продолжительности штрафа/временной остановки, указанной на вкладке Settings. Время продолжительности многократно удваивается для каждой последующей повторной попытки. Это число указывает максимально допустимый период времени, прежде чем произойдет ещё одна повторная попытка.
Примечание. Если выбраны и завершение, и повторная попытка, сначала произойдет любая логика повторной попытки, а затем автоматическое завершение.
Последняя вкладка в диалоговом окне конфигурации Процессора — это вкладка Comments. Эта вкладка просто предоставляет пользователям возможность добавлять любые комментарии, подходящие для этого компонента. Использование вкладки Comments не является обязательным:
Вы можете получить доступ к дополнительной информации об использовании каждого Процессора, щёлкнув правой кнопкой мыши Процессор и выбрав Usage в контекстном меню. Либо выберите Help в Global Menu в правом верхнем углу пользовательского интерфейса, чтобы отобразить страницу Help со всей документацией, включая документацию по использованию для всех доступных Процессоров. Нажмите на нужный Процессор, чтобы просмотреть документацию по использованию.
Чтобы настроить Process Group (Группу процессов), щёлкните правой кнопкой мыши Группу процессов и выберите параметр Configure в контекстном меню. Диалоговое окно Configuration открывается с двумя вкладками: General и Controller Services.
Вкладка General содержит несколько различных элементов конфигурации. Во-первых, это Process Group Name (Имя Группы процессов). Name отображается в верхней части Группы процессов на рабочей области, а также в навигационных цепочках внизу пользовательского интерфейса. Для Root Process Group (Корневой группы процессов) (т.е. Группы самого высокого уровня) это также имя, которое отображается в качестве заголовка вкладки браузера. Обратите внимание, что эта информация видна любому другому инстансу RT.StreamingNiFi, который удалённо подключается к этому инстансу (с использованием Remote Process Groups (Удалённых групп процессов), т.е. Site-to-Site).
Следующим элементом конфигурации является Process Group Parameter Context, который используется для предоставления параметров компонентам потока. В этом раскрывающемся списке пользователь может выбрать, какой контекст параметров должен быть привязан к этой Группе процессов, и при необходимости может создать новый для привязки к Группе процессов.
В следующем разделе представлены элементы конфигурации для определения того, как следует запланировать запуск Группы процессов. RT.StreamingNiFi поддерживает два разных Execution Engines (Механизма выполнения): Traditional (Традиционный) и Stateless (Без сохранения состояния). Кроме того, Механизм выполнения может быть унаследован от родительской Группы процессов, что является поведением по умолчанию.
Следующие два элемента — Process Group FlowFile Concurrency (Параллелизм FlowFile Группы процессов) и Process Group Outbound Policy (Политика исходящего трафика Группы процессов) — описаны в следующих разделах.
FlowFile Concurrency (Параллелизм FlowFile) используется для управления тем, как данные передаются в Группу процессов. Доступны три варианта:
Если для параметра FlowFile Concurrency установлено значение Unbounded, Input Ports (Входные порты) в Группе процессов будут принимать данные настолько быстро, насколько это возможно, при условии, что обратное давление не помешает им сделать это.
Если для FlowFile Concurrency настроено значение Single FlowFile Per Node, Input Ports (Входные порты) будут пропускать одновременно только один FlowFile. Как только этот FlowFile войдет в Группу процессов, никакие дополнительные FlowFiles не будут добавлены до тех пор, пока все FlowFiles не покинут Группу процессов (либо путём удаления из системы/автоматического завершения, либо путём выхода через Output Port (Выходной порт)). Это часто приводит к снижению производительности, поскольку уменьшает распараллеливание, которое RT.StreamingNiFi использует для обработки данных. Однако существует несколько причин, по которым пользователь может захотеть использовать этот подход. Распространённым вариантом использования является случай, когда каждый входящий FlowFile содержит ссылки на несколько других элементов данных, например список файлов в каталоге. Пользователь может захотеть обработать весь список, прежде чем разрешить каким-либо другим данным войти в Группу процессов.
Когда FlowFile Concurrency настроен на Single Batch Per Node, Входные порты будут вести себя аналогично тому, как они ведут себя в режиме Single FlowFile Per Node, но когда FlowFile принимается, Входные порты будут продолжать принимать все данные до тех пор, пока не будут очищены все очереди, питающие Входные порты. В этот момент они больше не будут вносить данные в Группу процессов, пока все данные не завершат обработку и не покинут Группу процессов.
Примечание. Параметр FlowFile Concurrency контролирует только то, когда данные будут поступать в Группу процессов из Входного порта. Это не мешает Процессору в Группе процессов получать данные из-за пределов RT.StreamingNiFi.
В то время как FlowFile Concurrency определяет, как данные должны быть перенесены в Группу процессов, Outbound Policy (Политика исходящего трафика) контролирует поток данных из Группы процессов. Доступны два варианта:
Если Outbound Policy настроена на Stream When Available, данные, поступающие на Output Port (Выходной порт), немедленно передаются из Группы процессов, при условии, что обратное давление не применяется.
Когда Outbound Policy настроена на Batch Output, Выходные порты не будут передавать данные из Группы процессов до тех пор, пока все данные, находящиеся в Группе процессов, не будут поставлены в очередь на Выходном порту (т.е. никакие данные не покинут Группу процессов до тех пор, пока все данные не завершат обработку). Не имеет значения, поставлены ли все данные в очередь на один и тот же Выходной порт или некоторые данные поставлены в очередь на Выходной порт A, а другие данные — на Выходной порт Б. Оба эти условия считаются одинаковыми с точки зрения завершение обработки FlowFile.
Использование политики исходящего трафика Batch Output вместе с параллелизмом FlowFile Single FlowFile Per Node позволяет пользователю легко принимать один FlowFile (который сам по себе может представлять пакет данных), а затем ждать, пока вся обработка этого FlowFile завершится, прежде чем перейти к следующему шагу потока данных (т.е. к следующему компоненту за пределами Группы процессов). Кроме того, при использовании этого режима каждому FlowFile, передаваемому из Группы процессов, будет присвоен ряд атрибутов с именем batch.output.<Port Name> для каждого Выходного порта в Группе процессов. Значение будет равно количеству FlowFiles, которые были направлены на этот Выходной порт для этого пакета данных. Например, рассмотрим случай, когда один FlowFile разделён на 5 FlowFile: два FlowFile идут в Выходной порт A, один — в Выходной порт B, два — в Выходной порт C и ни один FlowFile не идёт в Выходной порт D. В этом случае , каждый FlowFile будет иметь атрибуты batch.output.A = 2, batch.output.B = 1, batch.output.C = 2, batch.output.D = 0.
Политика исходящего трафика Batch Output не даёт никаких преимуществ при использовании в сочетании с параллелизмом FlowFile Unbounded. В результате политика исходящего трафика игнорируется, если для параметра FlowFile Concurrency установлено значение Unbounded.
Обычным вариантом использования RT.StreamingNiFi является выполнение некоторого процесса с пакетом и только после его завершения выполнение другого процесса с тем же пакетом данных.
RT.StreamingNiFi делает это возможным, инкапсулируя каждый из этих процессов в отдельную Группу процессов. Outbound Policy первой Группы процессов должна быть настроена как Batch Output, а параллелизм FlowFile должен быть либо Single FlowFile Per Node, либо Single Batch Per Nod. При такой конфигурации первая Группа процессов будет обрабатывать весь пакет данных (который будет представлять собой либо один FlowFile, либо множество FlowFile в зависимости от параллелизма FlowFile) как связный пакет данных. После завершения обработки этого пакета данные будут храниться до тех пор, пока все FlowFiles не завершат обработку и не будут готовы покинуть Группу процессов. На этом этапе данные могут быть переданы из Группы процессов в виде пакета. Эта конфигурация — когда Группа процессов настроена с политикой исходящего трафика Batch Output, а Выходной порт подключён непосредственно к Входному порту Группы процессов с параллелизмом FlowFile Single Batch Per Node — рассматривается как особый случай. Принимающая Группа процессов будет принимать данные не только до тех пор, пока её входные очереди не опустеют, но и до тех пор, пока они не станут пустыми И исходная Группа процессов не перенесёт все данные из этого пакета из Группы процессов. Это позволяет передавать набор FlowFiles как один пакет данных между Группами процессов, даже если эти FlowFiles распределены по нескольким портам.
При использовании параллелизма FlowFile Single FlowFile Per Node необходимо учитывать несколько предостережений.
Во-первых, Входной порт может свободно передавать данные в Группу процессов, если в этой Группе процессов на той же ноде нет данных, поставленных в очередь. Это означает, что, например, в кластере из 5 нод одновременно может обрабатываться до 5 входящих FlowFiles. Кроме того, если соединение настроено на использование Load Balancing, оно может передавать данные на другую ноду кластера, позволяя данным попадать в Группу процессов, пока этот FlowFile все ещё обрабатывается. В результате не рекомендуется использовать Load-Balanced Connections (Соединения с балансировкой нагрузки) в Группе процессов, которая не настроена для параллелизма FlowFile Unbounded.
При использовании политики исходящего трафика Batch Output важно учитывать обратное давление. Рассмотрим случай, когда никакие данные не будут переданы из Группы процессов до тех пор, пока обработка всех данных не будет завершена. Также учтите, что для подключения к Выходному порту A порог обратного давления составляет 10 000 FlowFiles (по умолчанию). Если эта очередь достигнет порога в 10 000, вышестоящий Процессор больше не будет запускаться. В результате обработка данных не закончится, и поток завершится взаимоблокировкой, поскольку Выходной порт не заработает до завершения обработки, а Процессор не запустится до тех пор, пока не заработает Выходной порт. Чтобы избежать этого, если ожидается, что из одного входного FlowFile будет создано большое количество FlowFile, рекомендуется настроить обратное давление для Соединений, заканчивающихся Выходным портом, таким образом, чтобы обеспечить максимальное ожидаемое количество FlowFile или обратное давление для этих Соединений должно быть полностью отключено (установив порог обратного давления на 0).
Последние три элемента в диалоговом окне Configuration Группы процессов предназначены для настройки Default FlowFile Expiration (Срок действия FlowFile по умолчанию), Default Back Pressure Object Threshold (Порог объектов обратного давления по умолчанию) и Default Back Pressure Data Size Threshold (Порог размера данных обратного давления по умолчанию). Эти параметры настраивают значения по умолчанию при создании нового Соединения. Каждое Соединение представляет собой очередь, и каждая очередь должна иметь настройки срока действия FlowFile, количества объектов обратного давления и размера данных обратного давления. Указанные здесь настройки будут влиять на значения по умолчанию для всех новых Соединений, создаваемых в Группе процессов, но не повлияют на уже существующие Соединения. Дочерние Группы процессов, созданные в настроенной Группе процессов, унаследуют настройки родительской Группы процессов по умолчанию. Опять же, существующие Группы процессов не будут затронуты. Если эти параметры не переопределены, корневая Группа процессов получает настройки обратного давления по умолчанию из nifi.properties и имеет срок действия FlowFile по умолчанию 0 sec (т.е. не имеет срока действия).
Примечание. Если установить для параметра Default FlowFile Expiration значение, отличное от нуля, то может возникнуть потеря данных, т.к. при достижении установленного лимита срок действия FlowFile истечёт.
Последний элемент в диалоговом окне Configuration — Process Group Comments (Комментарии к Группе процессов). В этом поле можно добавить любую полезную информацию о Группе процессов.
Значения свойств в потоке, включая чувствительные свойства, можно параметризовать с помощью Parameters (Параметры). Параметры создаются и настраиваются в пользовательском интерфейсе RT.StreamingNiFi. Любое свойство можно настроить для ссылки на параметр со следующими условиями:
В пользовательском интерфейсе отображается информация, можно ли использовать Параметр для значения этого свойства.
Параметры создаются в Parameter Contexts (Контекстах параметров). Контексты параметров глобально определены/доступны для инстанса RT.StreamingNiFi. Для Контекстов параметров могут быть определены политики доступа, чтобы определить, какие пользователи могут их создавать. После создания также можно применять политики для чтения и записи для определённого Контекста параметров.
Чтобы создать Контекст параметра, выберите Parameter Context в Global Menu:
В диалоговом окне Parameter Contexts нажмите кнопку + в правом верхнем углу, и откроется окно Add Parameter Context. Окно имеет две вкладки: Settings (Настройки) и Parameters (Параметры).
На вкладке Settings добавьте Name (Имя) Контекста параметра и опционально Description (Описание). Щёлкните Apply, чтобы сохранить Контекст параметра, или выберите вкладку Parameters, чтобы добавить Параметры в Контекст.
Параметры можно добавлять во время создания Контекста параметров или позже, к уже существующим Контекстам параметров.
Во время создания Контекста параметра выберите вкладку Parameters. Нажмите кнопку +, откроется окно Add Parameter.
Чтобы добавить Параметры в уже созданный Контекст параметра, откройте окно Parameter Context и нажмите значок редактирования (карандаш) в строке нужного Контекста параметра.
На вкладке Parameters нажмите кнопку +, чтобы открыть окно Add Parameter.
Окно Add Parameter имеет следующие настройки:
После настройки этих параметров выберите Apply. В списке Referencing Components будут перечислены компоненты, на которые ссылается текущий Параметр. При необходимости добавьте дополнительные Параметры или отредактируйте любые существующие параметры.
Чтобы завершить процесс, выберите Apply в окне Parameter Context. Далее будут отображены операции, выполняющиеся для валидации всех компонентов, которые ссылаются на добавленные или изменённые Параметры: Stopping/Restarting affected Processors (Остановка/Перезапуск затронутых Процессоров), Disabling/Re-enabling affected Controller Services (Отключение/Повторное включение затронутых Служб контроллера), Updating Parameter Context (Обновление Контекста параметров).
В списке Referencing Components теперь перечислены все компоненты, на которые ссылается набор добавленных, изменённых или удалённых Параметров, сгруппированных по Группам процессов.
При добавлении Parameter (Параметра), использующего Expression Language (Язык выражений), важно понимать контекст, в котором будет оцениваться Язык выражений. Выражение всегда оценивается в контексте Processor (Процессора) или Controller Service (Службы процессора), которые ссылаются на Параметр. Возьмём, к примеру, сценарий, в котором добавляется Параметр с именем Time и значением ${now()}. Язык выражений приводит к вызову для определения системного времени при его оценке. При добавлении в качестве Параметра системное время оценивается не при добавлении параметра, а при оценке Выражения Процессором или Службой контроллера. То есть, если у Процессора есть Property (Свойство), для которого установлено значение #{Time}, он будет работать точно так же, как если бы значение Свойства было установлено ${now()}. При каждом обращении к Свойству создаётся другая временная метка.
Более того, некоторые Свойства не поддерживают Язык выражений, в то время как другие допускают Язык выражений, но не оценивают выражения по атрибутам FlowFile. Чтобы понять, как это работает, рассмотрим Параметр с именем File, значение которого равно ${filename}. Затем рассмотрим три разных Свойства, каждое из которых имеет разный Expression Language Scope (Объём языка выражений) и FlowFile с именем test.txt. Если для каждого из этих Свойств установлено значение #{File}, то результирующее значение показано в следующей таблице.
Configured Property Value (Настроенное значение свойства) | Expression Language Scope (Объём языка выражений) | Effective Property Value (Эффективное значение свойства) | Примечание |
---|---|---|---|
#{File} | Атрибуты FlowFile | test.txt | Имя файла определяется путём просмотра атрибута filename. |
#{File} | Среда | Пустая строка | Атрибуты FlowFile находятся вне объёма, и мы предполагаем, что на уровне JVM не определено ни системное свойство, ни переменная среды с именем filename. |
#{File} | — | ${filename} | Буквальный текст “${filename}” не будет оценён. |
Чтобы компонент мог ссылаться на Parameter (Параметр), его Process Group (Группе процессов) сначала должен быть назначен Parameter Context (Контекст параметра). После назначения Processors (Процессоры) и Controller services (Службы контроллера) в этой Группе процессов могут ссылаться на Параметры только в этом Контексте параметров.
Группе процессов может быть назначен только один Контекст параметров, в то время как данный Контекст параметров может быть назначен нескольким Группам процессов.
Примечание. Пользователь может установить в качестве Контекста параметра Группы процессов только один из Контекстов параметров, для которого у пользователя имеется политика чтения. Кроме того, чтобы установить Контекст параметра, у пользователя должна быть политика записи для Группы процессов.
Чтобы назначить Контекст параметра Группе процессов, щёлкните Configure либо на Operate Palette (Панели управления), либо в контекстном меню Группы процессов.
В окне Flow Configuration выберите вкладку General. В раскрывающемся меню Process Group Parameter Context выберите существующий Контекст параметра или создайте новый.
Выберите Apply, чтобы сохранить изменения конфигурации. Контекстное меню Группы процессов теперь будет включать опцию Parameters, которая обеспечивает быстрый доступ к окну Update Parameter Context для назначенного Контекста параметра.
Если Контекст параметра для Группы процессов изменён, все компоненты, которые ссылаются на какие-либо Параметры в этой Группе процессов, будут остановлены, провалидированы и перезапущены, при условии, что компоненты ранее работали и всё ещё валидны.
Примечание. Если Контекст параметра не установлен в Группе процессов, он НЕ наследует Контекст параметра от родительской Группы процессов. Вместо этого нельзя ссылаться ни на какие Параметры. Любой компонент, который уже ссылается на Параметр, станет невалидным.
Чтобы настроить подходящее Property (Свойство) для ссылки на Parameter (Параметр), используйте в начале символ #, а имя Параметра заключайте в фигурные скобки:
#{Parameter.Name}
Его можно экранировать, используя дополнительный символ # в начале. Чтобы проиллюстрировать это, предположим, что Параметр abc имеет значение xxx, а Параметр def имеет значение yyy. Затем следующие определяемые пользователем значения Свойств будут соответствовать этим эффективным значениям:
User-Entered Literal Property Value (Введённое пользователем литеральное значение свойства) | Effective Property Value (Эффективное значение свойства) | Примечание |
---|---|---|
#{abc} | xxx | Простая замена. |
#{abc}/data | xxx/data | Простая замена дополнительными литеральными данными. |
#{abc}/#{def} | xxx/yyy | Множественная замена дополнительными литеральными данными. |
#{abc | #{abc | Отсутствует { } для замены параметра. |
#abc | #abc | Отсутствует { } для замены параметра. |
##{abc} | #{abc} | Экранированный # для литеральной интерпретации. |
###{abc} | #xxx | Экранированный # для литеральной интерпретации, за которым следует простая замена. |
####{abc} | ##{abc} | Дважды экранированный # для литеральной интерпретации. |
#####{abc} | ##xxx | Дважды экранированный # для литеральной интерпретации, за которым следует простая замена. |
#{abc/data} | Исключение, возникающее при операции набора Свойств. | / недопустимый символ имени Параметра. |
При ссылке на Параметр из Expression Language сначала оценивается ссылка на Параметр. Например, чтобы заменить xxx на zzz для Параметра abc:
${ #{abc}:replace('xxx', 'zzz') }
На Parameters (Параметры) можно легко ссылаться или создавать их при настройке компонентов в потоке. Например, предположим, что Process Group (Группе процессов) назначен Parameter Context (Контекст параметра) Kafka Settings. Kafka Settings содержит Параметры kafka.broker и kafka.topic1.
Чтобы ссылаться на kafka.broker как на значение Свойства Kafka Brokers в Processor (Процессоре) PublishKafka, очистите значение по умолчанию и начните новую запись, начиная с разделителя #{. Затем используйте сочетание клавиш Control+Space, чтобы отобразить список доступных параметров:
Выберите kafka.broker и завершите запись закрывающей фигурной скобкой }.
Текст справки, описывающий этот процесс, отображается при наведении указателя мыши на индикаторы приемлемости Expression Language (Языка выражений) и Параметров.
Параметры также можно создавать «на лету». Например, чтобы создать Параметр для Свойства Topic Name, выберите значок Convert to Parameter (значок в виде стрелки вверх) в строке этого Свойства. Этот значок будет доступен только в том случае, если у пользователя есть соответствующие разрешения на изменение Контекста параметра.
Откроется диалоговое окно Add Parameter. Настройте новый Параметр по желанию.
Выберите Apply. Контекст параметра Группы процессов будет обновлён, и на новый Параметр будет ссылаться Свойство с автоматически применённым соответствующим синтаксисом.
Значения Свойств, которые можно выбирать, также могут ссылаться на Параметры. Помимо применения метода Convert to Parameter, описанного ранее, в раскрывающемся меню значений доступна опция Reference parameter….
При выборе Reference parameter… отобразится раскрывающийся список доступных Параметров, определяемых Контекстом параметра, назначенным Группе процессов компонента, и политиками доступа пользователя.
При наведении курсора на значок (?) отображается описание Параметра.
Sensitive Properties (Чувствительные свойства) могут ссылаться только на Sensitive Parameters (Чувствительные параметры). Это важно для версионных потоков. Само значение Чувствительного параметра НЕ будет отправлено в реестр потоков, а только тот факт, что Свойство ссылается на Чувствительный Параметр.
Значение Чувствительного свойства должно быть установлено в одной ссылке на Параметр. Например, значения #{password}123 и #{password}#{suffix} не допускаются. Отправка #{password}123 приведёт к раскрытию части значения Чувствительного свойства. В этом отличие от Нечувствительного свойства, для которого допустимо такое значение, как #{path}/child/file.txt.
Parameter Providers (Провайдеры параметров) позволяют хранить Параметры в источниках, внешних по отношению к RT.StreamingNiFi (например, HashiCorp Vault). Параметры Провайдеры параметров можно получить и применить ко всем ссылающимся Контекстам параметров.
Чтобы добавить Провайдера параметров, выберите Controller Settings в Global Menu.
Откроется окно NiFi Settings. Выберите вкладку Parameter Providers и нажмите кнопку + в правом верхнем углу, чтобы создать нового Провайдера параметров.
Откроется окно Add Parameter Provider. Это окно похоже на окно Add Processor. Он предоставляет список доступных Провайдеров параметров справа и облако тегов, показывающее наиболее распространённые теги категорий, используемые для Провайдеров параметров, слева. DFM может щёлкнуть любой тег в облаке тегов, чтобы сузить список Провайдеров параметров до тех, которые соответствуют желаемым категориям. DFM также может использовать поле Filter (Фильтр) в правом верхнем углу окна для поиска нужного Провайдера параметров или использовать раскрывающийся список Source (Источник) в левом верхнем углу для фильтрации списка по группе, которая их создала. Выбрав Провайдера параметров из списка, DFM увидит описание Провайдера ниже. Выберите нужного Провайдера параметров и нажмите Add или просто дважды щёлкните имя Провайдера, чтобы добавить его.
После добавления Провайдера параметров DFM может настроить его, нажав кнопку Edit в крайнем правом столбце. Другие кнопки в этом столбце включают Fetch Parameters (Получить параметры), Remove (Удалить) и Access Policies (Политики доступа).
Вы можете получить информацию о Провайдерах параметров, нажав кнопки View Details (Просмотреть подробности), Usage (Использование) и Alerts (Оповещения).
Когда DFM нажимает кнопку Edit, открывается окно Configure Parameter Provider. Он имеет три вкладки: Settings (Настройки), Properties (Свойства) и Comments (Комментарии). Это окно похоже на окно Configure Processor. Вкладка Settings позволяет DFM опционально присвоить Провайдеру параметров уникальное имя (Name). Он также перечисляет информацию Id, Type (Тип) и Bundle (Пакет) для Провайдера и отображает список других компонентов (например, Parameter Context), которые ссылаются на Провайдера параметров. DFM может навести указатель мыши на значок (?), чтобы просмотреть дополнительную информацию о каждой настройке.
На вкладке Properties перечислены различные свойства, которые можно настроить для Провайдера параметров. DFM может навести указатель мыши на значок (?), чтобы просмотреть дополнительную информацию о каждом свойстве.
Вкладка Comments представляет собой просто поле с открытым текстом, в которое DFM может включать комментарии о Провайдере. После настройки Провайдера параметров нажмите Apply, чтобы сохранить конфигурацию и закрыть окно, или нажмите Cancel, чтобы отменить изменения и закрыть окно.
Если вы хотите получить параметры от Провайдера параметров, нажмите кнопку Fetch (значок со стрелкой вниз).
Права пользователей на доступ к Parameters (Параметрам) управляются с помощью политик доступа на следующих уровнях:
Чтобы пользователь мог видеть Контексты параметров, их необходимо добавить либо в политику на чтение access the controller, либо в политику на чтение access parameter contexts. Чтобы пользователь мог изменять Контексты параметров, их также необходимо добавить в соответствующие политики на запись. Доступ к этим политикам осуществляется через Policies в Global Menu.
Примечание. Политики access parameter contexts наследуются от политик access the controlle, если они не переопределены.
Политики на чтение и запись также можно установить для отдельных Контекстов параметров, чтобы определить, какие пользователи могут просматривать или добавлять Параметры в Контекст. Выберите Parameter Contexts в Global Menu. Для управления этими политиками выберите кнопку Access Policies (значок ключа) в строке нужного Контекста параметра.
Пользователь может установить в качестве Контекста параметра Группы процессов только один из Контекстов параметров, для которого у пользователя есть политика на чтение. Кроме того, чтобы установить Контекст параметра, у пользователя должна быть политика на запись для Группы процессов. Политикой доступа Группы процессов можно управлять, выделив Группу процессов и выбрав кнопку Access Policies (значок ключа) на Operate Palette.
Чтобы ссылаться на Параметры или преобразовать Свойства в Параметр в Компоненте, пользователю необходимо иметь политики на чтение и запись для Компонента. Эти политики наследуются, если пользователь имеет политики на чтение и запись для Группы процессов Компонента, но эти политики можно переопределить на уровне Компонента.
Чтобы изменить Параметр, пользователь должен иметь политики на чтение и запись для всех Компонентов, которые ссылаются на этот Параметр. Это необходимо, поскольку изменение Параметра требует остановки/запуска Компонентов, а также потому что, выполняя это действие, пользователь изменяет поведение Компонента.