Сегодня вспомним, какие процессоры есть в Apache NiFi для работы с HTTP-запросами, зачем их так много, чем они отличаются и в каких случаях использовать каждый из них. Разница между HandleHttpRequest, HandleHttpResponse, GetHTTP, PostHTTP, InvokeHTTP и ListenHTTP.
Мы с Тамарой ходим парой: совместное использование процессоров HandleHttpRequest и HandleHttpResponse
На первый взгляд может показаться, что все HTTP-процессоры, которые есть Apache NiFi имеют общую цель: обработку HTTP-запросов и отличаются лишь нюансами. Это не совсем так. Например, процессор HandleHttpRequest запускает HTTP-сервер и прослушивает HTTP-запросы, для каждого из них создавая отдельный FlowFile, который передается в отношение success. Этот процессор предназначен для использования вместе с процессором HandleHttpResponse для создания веб-сервиса. В случае составного запроса для каждой части создается один потоковый файл.
Таким образом, процессор HandleHttpRequest вместе с процессором HandleHttpResponse позволяет дата-инженеру использовать NiFi для визуального построения веб-сервера, который может выполнять любые функции, доступные через существующие процессоры. В частности, можно создать веб-интерфейс для SFTP-сервера, создав поток из нескольких процессоров, например, HandleHttpRequest -> PutSFTP -> HandleHttpResponse.
Процессор HandleHttpResponse отправляет HTTP-ответ запрашивающей стороне, сгенерировавшей FlowFile. Этот процессор должен быть настроен с той же службой <HTTP Context Map>, что и соответствующий процессор HandleHttpRequest. Иначе все файлы потока будут перенаправляться в отношение failure.
Процессор HandleHttpRequest имеет несколько свойств для настройки поддерживаемых методов, поддерживаемых путей и конфигурации SSL. Для обработки запросов с Content-Type: multipart/form-data, содержащим несколько частей, необходимо настроить атрибуты для каждого FlowFile, который генерирует часть. В каждый из этих файлов потока записываются специальные атрибуты: http.context.identifier, http.multipart.fragments.sequence.number и http.multipart.fragments.total.number. Эти атрибуты можно использовать для реализации механизма блокировки процессора HandleHttpResponse в ожидании обработки потоковых файлов с порядковым номером http.multipart.fragments.sequence.number до тех пор, пока не будет обработано до http.multipart.fragments.total.number потоковых файлов, принадлежащий тому же http.context.identifier, который уникален для запроса.
Универсальный InvokeHTTP вместо GetHTTP и PostHTTP
Процессор GetHTTP извлекает данные из URL-адреса HTTP или HTTPS и записывает данные в содержимое FlowFile. После извлечения содержимого запоминаются даты ETag и Last Modified, если их поддерживает веб-сервер. Это позволяет процессору извлекать новые данные только в том случае, если удаленные данные изменились или пока состояние не будет очищено. Это означает, что после того, как содержимое было получено с заданного URL-адреса, оно не будет извлекаться снова, пока контент файла потока на удаленном сервере не изменится. Из-за ограничений на управление состоянием сохраненные поля ETag и Last Modified не имеют срока действия. Если URL-адрес в процессоре GetHTTP использует неограниченный язык выражений Apache NiFi, есть риск нехватки памяти, т.е. возникновения OOM-ошибок (Out-Of-Memory).
Однако, процессор GetHTTP сегодня имеет статус deprecated и будет удален в будущих выпусках NiFi. Вместо него дата-инженеру предлагается использовать процессор InvokeHTTP. Аналогичное замечание в официальной документации Apache NiFi касается и процессора PostHTTP, который выполняет публикацию HTTP с содержимым FlowFile. При этом он использует пул с максимальным числом соединений, равным числу возможных конечных точек, умноженному на конфигурацию параллельных задач.
Универсальный процессор InvokeHTTP представляет собой HTTP-клиент, который может взаимодействовать с настраиваемой конечной точкой. Для настройки конечной точки можно задать целевой URL-адрес и HTTP-метод. Атрибуты FlowFile преобразуются в заголовки HTTP-запроса, а содержимое включается в тело запроса, если используется HTTP-методы PUT, POST или PATCH.
Помимо официальной версии этого процессора я нашла на Github пользовательскую реализацию InvokeHTTP с аутентификацией NTLM. Этот проект создает копию стандартного процессора InvokHTTP, но добавляет возможность повторной проверки подлинности NTLM, когда нужно связаться, например, со службой SOAP SharePoint. NTLM (NT LAN Manager) представляет собой протокол сетевой аутентификации, разработанный Microsoft для Windows NT на основе LANMAN, одного из форматов хранения пользовательских паролей длиной менее 15 символов. Этот протокол проверки подлинности запроса и ответа использует 3 сообщения для аутентификации клиента в среде, ориентированной на соединение и четвертое дополнительное сообщение, если требуется проверка целостности. Протокол NTLM использует одно или оба значения хешированных паролей, оба из них хранятся на сервере или контроллере домена, которые из-за отсутствия привязки эквивалентны паролю. Поэтому хешированное значение с сервера может быть использовано для аутентификации без фактического знания пароля. Проверка подлинности NTLM по-прежнему поддерживается и обязательна для использования на системах, работающих под управлением Windows NT Server 4.0 и ранее, а также для компьютеров в рабочей группе. Проверка подлинности NTLM также используется для проверки подлинности при аутентификации на изолированных системах. Однако, сегодня проверка подлинности с помощью защищенного протокола Kerberos версии 5 более предпочтительна для сред Active Directory. Подробнее о безопасном использовании процессора InvokeHTTP читайте в нашей прошлой статье.
Процессор ListenHTTP в Apache NiFI
Процессор ListenHTTP запускает HTTP-сервер и прослушивает заданный базовый путь для преобразования входящих запросов в файлы потока. URI-адрес сервиса по умолчанию будет таким: http://{hostname}:{port}/contentListener. Примечательно, что этот процессор поддерживает только HTTP-запросы HEAD и POST. А запросы GET, PUT и DELETE приведут к ошибке с кодом HTTP-ответа 405. GET-запрос поддерживается на конечной точке /healthcheck. Если сервис доступен, он возвращает HTTP-ответ со статусом 200 с содержимым ОК. Функцию проверки работоспособности можно настроить так, чтобы она была доступна через другой порт. На процессоре можно включить свойство «Считыватель записей» (Record Reader) и «Средство записи» (Record Writer) для обработки входящих запросов в виде записей. Обработка записи не разрешена для составных запросов и запросов в формате FlowFileV3 (minifi).
Чтобы резюмировать отличия между всеми рассмотренными HTTP-процессорами Apache NiFI, визуализируем их в табличном виде.
|
Процессор |
Принцип работы |
Вариант использования |
|
HandleHttpRequest |
запускает HTTP-сервер и прослушивает HTTP-запросы, для каждого из них создавая отдельный FlowFile |
Совместно с процессором HandleHttpResponse используются для создания веб-сервиса. Должны быть настроены с одной и той же службой <HTTP Context Map> |
|
HandleHttpResponse |
отправляет HTTP-ответ запрашивающей стороне, сгенерировавшей FlowFile |
|
|
GetHTTP |
извлекает данные из URL-адреса HTTP или HTTPS и записывает данные в содержимое FlowFile |
Не рекомендуется использовать, устарел и заменяется на InvokeHTTP |
|
PostHTTP |
выполняет публикацию HTTP с содержимым FlowFile |
|
|
InvokeHTTP |
HTTP-клиент, который может взаимодействовать с настраиваемой конечной точкой |
Для отправки данных к конечной точке в заголовке или теле HTTP-запроса. Атрибуты FlowFile преобразуются в заголовки HTTP-запроса, а содержимое включается в тело запроса для HTTP-методов PUT, POST или PATCH |
|
ListenHTTP |
запускает HTTP-сервер и прослушивает заданный базовый путь для преобразования входящих запросов в файлы потока |
Используется для получения метаданных HTTP-сервиса через запрос HEAD и отправку данных методом POST. Запросы GET, PUT и DELETE приведут к ошибке 405 |
Узнайте больше про использование Apache NiFi для построения эффективных ETL-конвейеров потоковой аналитики больших данных на специализированных курсах в нашем лицензированном учебном центре обучения и повышения квалификации для разработчиков, менеджеров, архитекторов, инженеров, администраторов, Data Scientist’ов и аналитиков Big Data в Москве:
Источники
- https://nifi.apache.org/docs/nifi-docs/components/org.apache.nifi/nifi-standard-nar/1.21.1/org.apache.nifi.processors.standard.HandleHttpRequest/
- https://nifi.apache.org/docs/nifi-docs/components/org.apache.nifi/nifi-standard-nar/1.21.1/org.apache.nifi.processors.standard.HandleHttpResponse/index.html
- https://nifi.apache.org/docs/nifi-docs/components/org.apache.nifi/nifi-standard-nar/1.21.1/org.apache.nifi.processors.standard.GetHTTP/
- https://nifi.apache.org/docs/nifi-docs/components/org.apache.nifi/nifi-standard-nar/1.21.1/org.apache.nifi.processors.standard.PostHTTP/
- https://nifi.apache.org/docs/nifi-docs/components/org.apache.nifi/nifi-standard-nar/1.21.1/org.apache.nifi.processors.standard.InvokeHTTP/index.html
- https://nifi.apache.org/docs/nifi-docs/components/org.apache.nifi/nifi-standard-nar/1.21.1/org.apache.nifi.processors.standard.ListenHTTP/
- https://github.com/peetkes/nifi-http-processor
- https://ru.wikipedia.org/wiki/NTLM
