NiFi — получить идентификатор записи для вставки в качестве внешнего ключа

#foreign-keys #apache-nifi

#внешние ключи #apache-nifi

Вопрос:

У меня есть источник данных с таблицей пользователей name age и role столбцами. Теперь мне нужно создать из него две таблицы и поместить их в новую базу данных. Таблицы — это user и role . Итак, сначала я сбрасываю данные в user таблицу, а role столбец, который мне нужно вставить в role таблицу, помещаю ID в role столбец user таблицы. Я должен сделать то же самое для каждой записи. Проверьте, есть ли уже запись роли, если да, верните ID или создайте новую запись и верните вставленную ID .

Пример исходных данных:

 Name,age,role

David,35,admin

Tay,23,user

John,27,user
  

Ожидаемые выходные данные:

  • Пользовательская таблица:
 David,35,1

Tay,23,2

John,27,2
  
  • Таблица ролей:
 1,admin

2,user
  

Пожалуйста, помогите мне достичь этого с помощью NiFi

Ответ №1:

Попробуйте LookupRecord с SimpleDatabaseLookupService помощью . Служба будет настроена на поиск role столбца и возврат id значения (или любого другого, который вызывается в таблице ролей). Для LookupRecord установки значения Routing Strategy Route to 'matched' or 'unmatched' .

Для каждой записи во входных данных, если роль найдена в таблице, эти записи будут перенаправлены на matched связь, а выходной потоковый файл должен быть готов PutDatabaseRecord к помещению в пользовательскую таблицу. Если роль не найдена в таблице, эти записи будут перенаправлены на unmatched связь.

Для несопоставимых записей вы можете дублировать файл потока, отправляя одну через Wait процессор, который затем подключается обратно к LookupRecord процессору, а другую QueryRecord — с запросом чего-то вроде SELECT DISTINCT(role) AS role FROM FLOWFILE . Это должно дать вам потоковый файл, который вы можете отправить в a PutDatabaseRecord для вставки в таблицу ролей (при условии, что у вас есть id столбец с автоматическим добавлением). Затем вы можете отправить его на Notify процессор, чтобы вернуть исходный потоковый файл обратно LookupRecord . В этот момент поиск должен найти роль в таблице ролей и перенаправить все записи на matched связь.

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

1. Спасибо @mattyb. Это сработало действительно здорово. У меня есть еще один вопрос. В некоторых случаях role будет иметь значение null для нескольких или всех записей. В этом случае запись поиска не должна выполняться. Я не могу использовать splitjson, потому что это может создать проблемы с производительностью, поскольку SELECT DISTINCT(…) в этом случае не предоставляет все записи. Не могли бы вы помочь мне, как я могу этого добиться? Примечание: у меня есть несколько поисковых запросов. Пример: роль, страна, подразделение и т.д.. Итак, у меня будет несколько записей поиска одна за другой.

2. Я использую два процессора EvaluateJsonPath для маршрутизации значений null и not null