Вручную установить «состояние компонента» в процессоре GenerateTableFetch

#javascript #ecmascript-6 #apache-nifi

#javascript #ecmascript-6 #apache-nifi

Вопрос:

Я использую «состояние компонента» в процессоре GenerateTableFetch, чтобы убедиться, что не запрашивать одни и те же данные дважды из базы данных. Из-за миграции поток пришлось снова развернуть, потеряв его состояние во время процесса. Как я могу установить «состояние компонента» этого процессора вручную? Я попытался использовать автономный процессор executeScript (с использованием ECMAScript) для обновления состояния. Сначала я попытался прочитать состояние с помощью

 var Scope = Java.type('org.apache.nifi.components.state.Scope');
var map = context.stateManager.getState(Scope.LOCAL).toMap();
  

Но я не получаю обратно циклическую карту. Чего я не понимаю, так это как я выбираю процессор GenerateTableFetch для установки состояния.

Ответ №1:

StateManager предоставляет компоненту доступ только для изменения его собственного состояния, а не состояния другого компонента, в противном случае любой компонент может неправильно изменить состояние другого компонента.

За кулисами состояние сохраняется с использованием UUID компонента. Если вы находитесь в кластере, то он хранится в ZooKeeper, и вы можете вручную изменить данные в ZooKeeper, используя ZK CLI. Если вы находитесь в автономном режиме, то оно сохраняется в состоянии записи с опережением записи / локальном, и я не уверен, что есть хороший способ изменить это вручную.

Кроме того, при переносе потока в новый кластер предпочтительным механизмом является использование ZK state migrator из nifi toolkit:

https://nifi.apache.org/docs/nifi-docs/html/administration-guide.html#zookeeper_migrator

Если вы выполняли миграцию между автономными экземплярами, просто скопируйте state / local из исходного кластера в новый кластер.

Комментарии:

1. Как вы копируете состояние? Я не могу изменить его вручную.

2. @pfnuesel это может помочь docs.cloudera.com/cfm/2.0.1/hdf-migration/topics /…