В этой статье для обучения дата-инженеров рассмотрим, почему в потоковых конвейерах обработки данных на базе Apache NiFi случаются ошибки, и какие популярные стратегии и инструменты помогут идентифицировать эти проблемы, а также решить их.
Проблемы конвейеров обработки данных на Apache NiFi
Конвейеры данных помогают консолидировать информацию из разных источников, чтобы получить ценные бизнес-инсайты. Поэтому дата-инженеру важно убедиться, что используемые данные имеют хорошее качество, включая соответствующий формат, размер и тип. Это особенно важно в таких инструментах как Apache NiFi, который позволяют проектировать конвейеры данных и управлять ими практически без разработки кода. Однако, эта идея Low Code/No Code не гарантирует отсутствие ошибок в потоковых конвейерах данных на Apache NiFi.
Чаще всего разработчики конвейеров обработки данных на Apache NiFi сталкиваются со следующими проблемами:
- системы выходят из строя из-за программных или аппаратных сбоев, включая недостаточную пропускную способность сети и нехватку места на жестком диске;
- доступ к данным превышает возможности потребления – неравномерный прием данных приводит к перегрузке пропускной способности конвейера NiFi;
- разный характер данных, которые могут быть слишком большими, слишком маленькими, слишком быстрыми или слишком медленными, поврежденными или неверными;
- изменчивость данных;
- разная скорость работы систем, которые входят в состав конвейеров Apache NiFi.
Все эти случаи являются источниками потенциальных проблем, и обработка ошибок может уменьшить их влияние на бизнес за счет принятия превентивных мер. Большинство указанных проблем становятся более управляемыми благодаря предварительному анализу того, что может произойти во время выполнения. В случае конвейера NiFi первая непосредственная граница задается самой моделью. Можно начать с разделения проблем по их происхождению на:
- внешние, которые находятся вне контроля, поскольку они не возникают внутри модели. Например, данные, не полученные моделью, и данные, отправленные моделью, но не достигшие места назначения из-за временного сбоя подключения к Интернету.
- внутренние, которые возникают в рамках модели NiFi, а потому могут быть предсказаны и контролируемы.
Каждый подпроцесс NiFi состоит из входящих и исходящих данных и промежуточных процессов. Со входящими данными проблемы могут возникнуть в следующих областях:
- вариация приема данных, например, внезапное увеличение количества записей, полученных из базы данных, которые модель не может правильно обработать, что приводит к перегрузке данных или памяти.
- качество полученных или сгенерированных данных, например, компонент JSON с поврежденной структурой или с отсутствующими обязательными данными.
Процессы также могут быть источником ошибок, не все из которых можно решить самостоятельно. Тем не менее, дата-инженеры выработали набор лучших практик по обработке ошибок Apache NiFi, которые можно сгруппировать в стратегии. Наиболее популярные стратегии мы рассмотрим далее.
ТОП-4 стратегии обработки ошибок
Одной из стратегий является повторный опрос внешнего источника данных, с которым возникли проблемы. Например, при получении информации из базы данных или внешнего сервиса API, расположенного в облаке, возник сетевой сбой с прерванным подключением к Интернету. Самый простой способ устранить этот сбой – обратиться к источнику данных повторно вручную. Чтобы автоматизировать повторные попытки, можно создать счетчик, инициализировать его, а повторить операцию. В случае успеха система продолжит процесс в обычном режиме. Если это не удается, инкрементируется счетчик повторных попыток и, если он не достиг своего предела, операция повторяется вновь. Если счетчик достиг предела, система регистрирует ошибку для последующего ручного вмешательства.
Apache NiFi предоставляет механизм управления потоком данных, который называется обратным давлением. Он состоит из двух порогов, которые определяют максимальный объем данных, разрешенный для очереди в коннектора. Это позволяет Apache NiFi избегать перегрузки данных и памяти.
Противодавление определяется двумя разными значениями:
- Back Pressure Object Threshold — количество файлов FlowFile, которые могут находиться в очереди до того, как будет применено противодавление. Этот параметр можно настроить гибко. К примеру, если он определен как 10000, а очередь имеет 9000 объектов и получает 2000, будут приняты объекты, достигшие значения 11000, и активируется механизм обратного давления. Как только очередь освободит достаточно сообщений, чтобы их количество было ниже порога объекта, коннектор продолжит принимать больше потоковых файлов от исходного процессора.
- Size Threshold – максимальный объем данных по размеру, которые могут быть помещены в очередь, прежде чем будет применено противодавление. Это значение настраивается путем ввода числа, за которым следует размер данных (B для байтов, KB для килобайтов, MB для мегабайтов, GB для гигабайтов или TB для терабайтов).
Оба значения можно установить в разделе настроек коннектора. Значения по умолчанию составляют 10000 объектов и 1 ГБ соответственно и определяются в файле конфигурации nifi.properties. Это означает, что каждое новое добавленное подключение будет иметь пороговое значение объекта обратного давления по умолчанию, равное 10 000 объектов, и пороговое значение размера данных обратного давления, равное 1 ГБ.
Когда противодавление включено, на метке подключения появляются небольшие индикаторы выполнения, поэтому диспетчер потока данных (DFM, DataFlow Manager), пользователь NiFi, у которого есть разрешения на добавление, удаление и изменение компонентов потока данных NiFi, может сразу увидеть это в GUI. Индикаторы выполнения меняют цвет в зависимости от процента очереди: зеленый (0-60%), желтый (61-85%) и красный (86-100%).
Еще одним инструментом, дополняющим противодавление, является функция Back Pressure Prediction, которая позволяет системному администратору контролировать очередь вручную. По умолчанию эта функция не активирована. Чтобы включить ее, следует настроить аналитическую структуру nifi.analytics.predict в файле конфигурации nifi.properties.
Модель, используемая по умолчанию для прогнозирования, представляет собой обычную линейную регрессию методом наименьших квадратов. Она использует недавние наблюдения из очереди (количество объектов или размер контента с течением времени) и вычисляет линию регрессии для этих данных. Затем уравнение линии используется для определения следующего значения, которое будет достигнуто в течение заданного интервала времени, например, количество объектов в очереди в течение следующих 5 минут.
Для создания прогнозов запрашивается история моментальных снимков локального состояния, чтобы получить достаточно данных для создания модели. По умолчанию моментальные снимки состояния компонентов создаются каждую минуту. Для создания прогноза внутренним моделям требуется как минимум 2 или более наблюдений, поэтому для того, чтобы прогнозы стали доступны по умолчанию, может потребоваться до 2 или более минут. Если прогнозы необходимы раньше, чем предусмотрено по умолчанию, время моментальных снимков можно настроить с помощью значения nifi.components.status.snapshot.frequency в nifi.properties.
NiFi оценивает эффективность модели перед отправкой прогнозной информации, используя показатель R-квадрата модели по умолчанию. Одно важное замечание: R-квадрат — это мера того, насколько близко линия регрессии соответствует данным наблюдения по сравнению с тем, насколько точным будет прогноз; поэтому может быть некоторая мера ошибки. Если показатель R-квадрат для рассчитанной модели соответствует настроенному порогу, определенном в nifi.analytics.connection.model.score.threshold, модель будет использоваться для прогнозирования. Иначе модель не будет использоваться, и прогнозы будут недоступны до тех пор, пока не будет сгенерирована модель с оценкой, превышающей пороговое значение. Пороговое значение R-квадрата по умолчанию равно 0,90, но его можно настроить в соответствии с требованиями прогнозирования.
Интервал прогнозирования nifi.analytics.predict.interval можно настроить так, чтобы он проецировался дальше, когда возникнет противодавление. Интервал запроса прогнозирования nifi.analytics.query.interval также можно настроить, чтобы определить, насколько далеко назад следует запрашивать прошлые наблюдения для создания модели. Корректировка этих параметров может потребовать настройки порогового значения оценки модели, чтобы выбрать оценку, которая может предложить разумные прогнозы.
По умолчанию эта структура прогнозирования использует обычный метод наименьших квадратов и частотный интервал в 1 минуту. Если нужны более частые прогнозы, мы можем установить другое значение для свойства nifi.components.status.snapshot.frequency в файле nifi.properties.
Еще одной стратегией обработки ошибок является использование фильтров, чтобы проверить входящие или сгенерированные данные и классифицировать их по качеству. В Apache NiFi это можно смоделировать с помощью набора компонентов. Например, данные JSON оцениваются в соответствии с критериями, определенными с помощью языка выражений Apache NiFi, а затем направляются на различные действия по результатам оценки.
Наконец, последней стратегией обработки ошибок является ручное вмешательство, когда приходится иметь дело с исключениями, например, при разработке собственного процессора. Как это сделать, мы рассмотрим в следующей статье.
Освойте практику администрирования и эксплуатации Apache NiFi для построения эффективных ETL-конвейеров потоковой аналитики больших данных на специализированных курсах в нашем лицензированном учебном центре обучения и повышения квалификации для разработчиков, менеджеров, архитекторов, инженеров, администраторов, Data Scientist’ов и аналитиков Big Data в Москве:
Источники
