Рекомендации по обработке ошибок конвейера данных в Apache NiFi

В соответствии с McKinsey отчет: “лучшая аналитика ничего не стоит с плохими данными”. Сегодня, благодаря успеху облачных технологий, источники данных многочисленны и разнообразны. Конвейеры данных помогают нам консолидировать данные из этих различных источников и работать над ними. Однако мы должны обеспечить, чтобы используемые данные были хорошего качества.

К счастью, у нас есть такие инструменты, как Apache NiFi , которые позволяют нам проектировать наши конвейеры данных и управлять ими, сокращая объем программирования и повышая общую эффективность. Тем не менее, когда дело доходит до их создания, ключевым и часто игнорируемым аспектом является минимизация потенциальных ошибок.

Но каковы некоторые лучшие практики, которым мы можем следовать в этом отношении?

Хотя на конвейер данных NiFi влияет множество факторов, три важных из них: выбор правильных инструментов, минимизация технического обслуживания и следование передовым практикам.

Выбор инструментов, адаптированных к большим данным, является первым шагом на пути к эффективному конвейеру данных. Здесь важно рассмотреть базы данных NoSQL, такие как Apache Cassandra , которые специально разработаны для обеспечения доступности данных, интенсивной рабочей нагрузки при записи и отказоустойчивости. В результате многие проблемы с производительностью, масштабируемостью и пропускной способностью уже решены.

Как только у нас появятся нужные инструменты, давайте позаботимся о том, чтобы тратить минимум времени на шаблонный код и настройку инфраструктуры, поскольку это отвлекает нас от важного кода. В этом случае оптимальным будет бессерверный сервис передачи данных, который не требует настройки или операций с нашей стороны. Затем мы можем сосредоточиться на том, что для нас наиболее важно: на нашем конвейере NiFi, оставив другие технические аспекты экспертам.

Наконец, мы должны сосредоточиться на внедрении передовой практики. В нашем случае это означает использование проверенных методов для прогнозирования, обнаружения и устранения потенциальных проблем в нашем конвейере данных Apache NiFi. Это очень практическая область, где предыдущий опыт многому нас учит.

Эта статья посвящена этому последнему пункту и тому, чему автор научился за эти годы. Это дает вам несколько действенных стратегий, которые повысят вероятность того, что ваш конвейер данных Knife будет работать без нежелательных перерывов и с использованием качественных данных.

Apache NiFi – это комплексная платформа, которая позволяет нам собирать и обрабатывать наши данные в режиме реального времени. Его преимуществ много. От предоставления визуального интерфейса программирования на основе ориентированных графиков, который обеспечивает быструю разработку и тестирование, до возможности изменять наш конвейер NiFi во время выполнения, до функциональности источника данных, которая помогает нам отслеживать, что происходит с нашими данными от начала до конца. Как следствие, предприятия могут начать с простой модели, которая с самого начала обеспечивает понимание и результаты, и которая расширяется до всеобъемлющего конвейера данных NiFi.

Почему важна обработка ошибок в ваших конвейерах

Большие данные открывают новые возможности, но также и новые проблемы; а вместе с ними и преимущества планирования обработки ошибок нашего конвейера данных Apache NiFi.

По словам разработчиков Apache NiFi, некоторые из проблем высокого уровня, связанных с потоками данных , являются:

Системы выходят из строя: сети, диски, программное обеспечение несовершенны и иногда выходят из строя. Мы, люди, тоже совершаем ошибки.
Доступ к данным превышает потребляемую мощность: поступление данных может быть неравномерным, а иногда приводит к перегрузке пропускной способности нашего конвейера NiFi.
Граничные условия – это просто предположения: данные поступают во многих вариантах, в том числе слишком большие, слишком маленькие, слишком быстрые, слишком медленные, поврежденные, неправильные или в неправильном формате.
То, что в один прекрасный день является шумом, на следующий день становится сигналом: ценность данных быстро меняется, и мы должны это планировать.
Системы развиваются с разной скоростью: существуют конвейеры Apache NiFi для соединения распределенных компонентов, которые не были предназначены для совместной работы.
Соответствие требованиям и безопасность: постоянно развивающаяся область, оказывающая огромное влияние и в которой подотчетность за данные необходима для выживания бизнеса.
В производстве происходит непрерывное совершенствование: для успеха необходимы изменения, а вместе с ними и способность адаптироваться.

Все эти случаи являются источниками потенциальных проблем, и обработка ошибок может уменьшить их влияние на бизнес, приняв превентивные меры.

Унция предотвращения обработки ошибок превосходит фунт отладочного лечения

Есть легкий путь и трудный путь. Самое сложное – найти легкий путь. Доктор Ллойд

Большинство проблем становятся немного более управляемыми, если применить некоторый предварительный анализ того, что может произойти во время выполнения. В случае модели трубопровода NiFi первая непосредственная граница задается самой моделью. Таким образом, мы можем начать с разделения проблем в соответствии с их происхождением в:

Внешние: эти проблемы находятся вне нашего контроля, поскольку они не возникают внутри модели. Примеры включают данные, не полученные моделью, и данные, отправленные с модели, но не дошедшие до адресата, например, из-за временного сбоя подключения к Интернету. Эта проблема рассматривается в стратегии 1 ниже.
Внутренний: эти проблемы возникают в рамках нашей модели NiFi и, следовательно, могут быть предсказаны и контролироваться.

Здесь мы можем расширить наш анализ, помня, что каждый подпроцесс состоит из входящих и исходящих данных и процесса как такового.

Рассматривая аспект данных, мы можем сразу определить два потенциальных источника проблем:

Изменение приема данных: например, внезапное увеличение количества записей, полученных из базы данных, которые модель не может обработать должным образом, что может привести к перегрузке данных или памяти. Эта проблема рассматривается в стратегии 2 ниже.
Качество данных: данные, полученные или сгенерированные внутри компании, находятся в плохом или ошибочном состоянии. Например, компонент JSON с поврежденной структурой или с отсутствующими обязательными данными. Эта проблема рассматривается в стратегии 3 ниже.

Процессы также могут быть источником ошибок. Однако не все эти проблемы могут быть решены самостоятельно. Например, неправильные конструкции компонентов и настройки в модели могут вызвать проблемы. Пример приведен в стратегии 4.

Практические решения для обработки ошибок для Apache Nifi

Если вы все оптимизируете, вы всегда будете несчастны. Дональд Кнут

Создание модели самовосстановления требует анализа и знаний. Чем сложнее модель, тем больше существует возможных источников проблем. Прогнозировать каждую отдельную потенциальную проблему, конечно, невозможно. Определение наиболее важных из них и предоставление самостоятельных решений могут значительно снизить эксплуатационную неопределенность нашего трубопровода NiFi и повысить его надежность .

Чтобы понять, как провести этот анализ, мы рассмотрим четыре возможные стратегии: одну внешнюю и три внутренние. Они, конечно, не охватывают все возможные сценарии ошибок, это всего лишь примеры, которые мы можем экстраполировать и применить к другим подобным ситуациям.

Стратегия обработки ошибок 1: Повторите попытку подхода

Внешние источники находятся вне нашего контроля. Поэтому мы не знаем первопричины проблемы и не можем попытаться ее решить. В результате лучший подход – спросить источник, вернулся ли он в нормальное состояние или нет. Мы будем называть это подходом повторной попытки .

Примером может служить ситуация, когда наша модель получает информацию из базы данных или службы API данных, расположенной в облаке, например DataStax Astra DB (который работает от Кассандры), и внезапно мы сталкиваемся с прерванным подключением к Интернету. Стратегия самостоятельного решения может включать использование повторной попытки, как показано на рисунке ниже:

Другим способом было бы создать счетчик, инициализировать его на единицу, а затем попробовать выполнить операцию. В случае успеха система продолжит процесс в обычном режиме. Если это не удается, система увеличивает счетчик на единицу, проверяет, достиг ли счетчик своего предела, и если нет, повторяет попытку. Если счетчик достиг своего предела, то система регистрирует ошибку для последующего ручного вмешательства.

Стратегия обработки ошибок 2: Использование обратного давления

Apache NiFi предоставляет механизм для управления потоком данных с именем обратное давление . Он состоит из двух пороговых значений, которые определяют максимальный объем данных, разрешенных для очереди в соединителе. Это позволяет Apache NiFi избежать перегрузки данными и памятью.

Противодавление определяется двумя различными значениями, а именно “Порог объекта противодавления” и “Порог размера”. Первый указывает максимальное количество файлов потока, которые могут находиться в очереди до активации обратного давления. Второй определяет максимальный объем данных (размер), которые могут быть поставлены в очередь до применения обратного давления. Оба значения можно задать в разделе настроек соединителя. Значения по умолчанию составляют 10000 объектов и 1 ГБ соответственно и определены в файле конфигурации nifi.properties.

Однако порог противодавления является гибкой настройкой. Это означает, что, например, если мы определили порог объекта как 10000, а очередь содержит 9000 объектов и получает 2000; она примет эти объекты, достигшие значения 11000, и активирует механизм обратного давления. Как только очередь выпустит достаточное количество сообщений, чтобы быть ниже порогового значения объекта, соединитель продолжит принимать больше потоковых файлов от исходного процессора.

Еще одним инструментом, дополняющим противодавление, является “Прогнозирование противодавления”. Эта функция позволяет системному администратору отслеживать очередь вручную. По умолчанию эта функция не активирована. Для этого мы должны установить значение “true” для analytics framework в файле конфигурации nifi.properties .

Чтобы следить за очередью, мы должны навести курсор на линию прокрутки на соединителе. Мы увидим два важных значения: прогнозируемую очередь и расчетное время до обратного давления. Первое значение дает расчетный процент использования очереди, а второе – прогнозируемое время до активации обратного давления. На рисунке ниже показан пример, в котором генерируются случайные файлы, и очередь достигает порогового значения объекта 10000.

По умолчанию в этой системе прогнозирования используется обычный метод наименьших квадратов и интервал частот 1 минута. Если нам нужны более частые прогнозы, мы можем установить другое значение для nifi.components.status.моментальный снимок.частота свойство в файле nifi.properties.

Стратегия обработки ошибок 3: Использование фильтров

В этом случае мы хотим проверить поступающие или сгенерированные данные и классифицировать их в соответствии с их качеством. Например, если мы подключим нашу базу данных Astra через API Stargate REST и мы получаем входящие данные в виде набора данных JSON, одна классификация может быть:

Хорошо: все поля заполнены и в ожидаемом формате.
Плохо: поврежден формат данных. Например, неправильные поля. Незавершенный: данные в правильном формате, но некоторые обязательные поля пусты.

В этом случае мы можем разработать стратегию, которая принимает разные решения в соответствии с каждым вариантом, например:

Хорошо: данные продолжают нормальный процесс.
Плохо: данные не позволяют продолжить обычный процесс, и проблема регистрируется. Неполный: данные не могут быть продолжены в обычном режиме, и они запрашиваются снова.

В Apache Nifi это можно смоделировать с использованием набора компонентов, аналогичных тем, что показаны на рисунке ниже. Данные JSON оцениваются в соответствии с определенными критериями (например, не являются нулевыми), определенными с использованием Языка выражений Apache NiFi , а затем перенаправляются на различные действия (атрибут LogAttribute в примере на рисунке ниже) в соответствии с результатом оценки.

Важное примечание: если данные были сгенерированы извне и получены системой, мы все равно можем считать это внутренней проблемой, поскольку данные теперь находятся в области модели.

Стратегия обработки ошибок 4: требуется ручное вмешательство!

В этом случае проблема нуждается в нашем вмешательстве. Примером может служить устаревшая настройка в одном из конвейерных процессоров Apache NiFi. Таким образом, лучшее решение – предупредить вашу команду и сохранить информацию об ошибках и данные, связанные с журналом, чтобы мы могли немедленно приступить к решению проблемы. Автоматизация рабочего процесса отслеживания проблем с помощью средства отслеживания проблем с использованием HTTP-процессоров Nifi может быть здесь очень полезной, как и интеграция с slack или pagerduty для критических эскалаций.

Вывод

Большинство улучшенных вещей можно улучшить. – Мококома Мохоноана

Использование больших объемов данных оказывается важным бизнес-активом. Это становится настолько важным, что Gartner прогнозирует, что “к 2022 году 30% CDO будут сотрудничать со своими финансовыми директорами, чтобы официально оценить информационные активы организации для улучшения управления информацией и получения преимуществ”.

Однако его использование поставило перед практикующими специалистами множество проблем; среди них управление его потоком посредством различных процессов и преобразований. Apache NiFi был разработан, чтобы сделать это проще.

Использование этого инструмента имеет много преимуществ. От чистого моделирования к более быстрой разработке и снижению сложности конвейера данных. Однако повышенная сложность имеет свои издержки: увеличение неизвестных. Поэтому разработчики должны анализировать предметную область модели и предвидеть потенциальные проблемы и самокорректирующиеся решения. Эта лучшая практика Apache NiFi называется обработкой ошибок.

Планирование обработки ошибок очень важно и становится все более важным по мере усложнения моделей. Apache NiFi предоставляет несколько инструментов, таких как параметры обратного давления и повторных попыток, и при правильном использовании может значительно снизить неопределенность производительности. Результаты очевидны: использование дисциплинированного подхода к управлению ошибками приводит к более быстрому восстановлению, меньшему времени, затрачиваемому на устранение неполадок, и устойчивой производительности.

Учить больше:

Оригинал: “https://dev.to/pieterhumphrey/best-practices-for-data-pipeline-error-handling-in-apache-nifi-co”