Версия сайта для слабовидящих
В рамках обучения дата-инженеров, сегодня рассмотрим проблему роста числа операций ввода-вывода в секунду (IOPS) при обработке большого количества данных в потоках Apache NiFi и способы ее решения. Читайте далее, как перемещение репозиториев NiFi с жесткого диска в оперативную память снижает IOPS, а также зачем при этом в Big Data систему добавлять Apache Kafka с Logstash.
Больше данных – больше затрат: проблема IOPS в Apache NiFi
Apache NiFi – простой, но мощный инструмент для обработки и маршрутизации потоков данных из различных источников в разные места назначения. Он позволяет постоянно передавать гигабайты и терабайты данных, создавая несколько «тяжелых» или тысячи более легковесных потоков. Для гарантии надежности передачи данных и обеспечения ее мониторинга, в NiFi есть репозиторий Provenance. Каждый раз, когда процессор заканчивает обработку потокового файла, он создает событие Provenance, логгируя операции с обработанным потоковым файлом: был ли он отправлен внешнему процессу, клонирован в другой потоковый файл, изменялось ли его содержимое и пр. Чтобы сформировать отчет о таких событиях используется специальные задачи, например, SiteToSiteProvenanceReportingTask [1].
SiteToSiteProvenanceReportingTask позволяет пользователю публиковать все события происхождения из экземпляра NiFi обратно в него же или другой экземпляр NiFi с использованием всех доступных обработчиков (процессоров). Рекомендуется отправлять данные Provenance в экземпляр NiFi, отличный от того, на котором выполняется сама задача отчетности, чтобы исключить генерируемые при этом события. По умолчанию 1000 событий группируется в пакет и при публикации в экземпляре NiFi отправляются в виде массива JSON [2].
Таким образом с помощью SiteToSiteProvenanceReportingTask можно организовать мониториниг событий с потоковыми данными, запустив задачу отчетности на другом экземпляре NiFi, чтобы не путать статистику по основным операциям на основном кластере, который ежедневно ТБ данных. При этом каждый из множества процессоров читает, изменяет и записывает содержимое потоковых файлов, выполняя тысячи операций ввода-вывода в секунду (Input-Output operations per second, IOPS). А в случае использования сетевой файловой системы (Network File System, NFS) и запуска NiFi поверх Kubernetes, показатели IOPS зависят от возможностей сети для каждого диска. В результате рост IOPS ведет к повышению расходов на hardware и общему увеличению затрат из-за того, что требуется обрабатывать больше данных. Решить эту проблему поможет знание внутренней архитектуры Apache NiFi, о чем мы поговорим далее.
Память или диск: где разместить репозиторий
Напомним, архитектура Apache NiFi включает 3 репозитория [3]:
- репозиторий FlowFile, где отслеживается состояние активного потокового файла (FlowFile). По умолчанию это WAL в определенном разделе жесткого диска;
- репозиторий контента (Content), где находятся фактические байты содержимого FlowFile. По умолчанию — это блоки данных в файловой системе. Можно настроить различные варианты, указав более одного места хранения на разных физических разделах, чтобы уменьшить количество конфликтов на одном томе.
- репозиторий Provenance, где хранятся все данные о событиях с потоковыми файлами, которые индексируются и доступны для поиска. По умолчанию это один или несколько томов физического жесткого диска.
Чаще всего основная IOPS-проблема заключается в Content-репозитории, где хранится содержимое каждого потокового файла. Этот репозиторий можно настроить как для постоянного (на жестком диске), так и для временного хранения (в ОЗУ) в файле свойств nifi.properties в разделе nifi.content.repository.implementation. Изменив значение по умолчанию FileSystemRepository на VolatileContentRepository можно существенно оптимизировать занимаемое место, чтобы не хранить метаданные уже устаревшего и удаленного контента.
Эксплуатация Apache NIFI
Код курса
NIFI3
Ближайшая дата курса
13 мая, 2024
Продолжительность
24 ак.часов
Стоимость обучения
72 000 руб.
Однако, при этом возникают новые проблемы: ошибка Content Repository из-за нехватки места, т.к. объем RAM обычно меньше жесткого диска, JavaHeapSpace и пр. Поэтому при использовании VolatileContentRepository следует настроить 2 новых свойства в соответствии с ресурсами кластера NiFi [1]:
- volatile.content.repository.max.size – максимальный размер контент-репозитория в памяти, по умолчанию равный 100 МБ;
- nifi.volatile.content.repository.block.size – размер блока контент-репозитория, по умолчанию равный — 32 КБ.
Таким образом, простое изменение места хранения контента с диска на RAM резко снижает количество IOPS, вызываемых NiFi, и в целом повышает производительность потоков данных, т.к. операции с RAM выполняются намного быстрее, чем с дисками. Это справедливо даже при работе с Docker-контейнерами и Kubernetes. Обратной стороной такого роста производительности будет повышение затрат: оперативная память стоит дороже SSD и любого жесткого диска. Впрочем, если не нужные данные будут удаляться из контент-репозитория, требуемый объем оперативной памяти будет меньше дисковой альтернативы. Более того, в этом случае уменьшается потребность в ЦП. Например, подобная замена позволяет развернуть NiFI на Kubernetes вместо кластера с 7 узлами по 500 ГБ HDD, 32 ГБ RAM и 12 ядрами ЦП, всего на 3 узлах с 50 ГБ HDD, 50 ГБ RAM и 8 ядрами ЦП. При этом количество IOPS снижается в 20 раз: с 8000 на узел до 400. Наконец, помимо экономии затрат на вычислительные ресурсы, такое решение повышает общую производительность потоков данных, позволяя кластеру NiFi ежедневно обрабатывать примерно в 5 раз больше данных.
Однако, предложенный вариант не решает проблему IOPS для репозитория Provenance, которая теперь включает 2 сложности [1]:
- снижение надежности NiFi – при сбое узла NiFi данные контент-репозитория, размещенные в ОЗУ, будут удалены;
- если основной кластер обрабатывает больше данных в секунду, он производит еще больше событий Provenance, поэтому число IOPS возрастает на втором кластере, ответственном за мониторинг.
Как решить обе эти проблемы, мы рассмотрим далее.
Комбо Apache Kafka + Logstash для оптимизации NiFi кластера
Решить проблему с надежность кластера NiFi поможет дополнительное хранилище потоковых данных, такое как Apache Kafka. Используя топики Kafka в качестве «промежуточного» хранилища позволит «переупаковать» потоковые данные в случае отказа одного из узлов NiFi, в памяти которого расположен контент-репозиторий. Сохранение потоковых данных в топики Kafka от источников и до NiFi позволит не потерять данные, а повторно считать их из Kafka при случайном сбое. Таким образом, нужно только один раз написать и один раз прочитать каждое сообщение, а остальная часть потока обработки будет приходиться на Volatile Content NiFi, что немного увеличивает количество IOPS, но не так критично, как раньше.
Ограничение на количество IOPS для «отслеживающего» кластера NiFi с высокой надежностью Provenance Events тоже решается с помощью Apache Kafka. Написав новую задачу отчетности, которая использует события Provenance и публикует их по топикам Kafka, можно добиться высокой надежности всей Big Data системы с низким числом IOPS. Это реализуется довольно просто через объединение задачи ProvenanceSiteToSiteReportingTask с процессором PublishKafka.
Когда события Provenance публикуются в Kafka, их можно использовать в любом другом конвейере данных или системах CI/CD и отправлять их в любую место назначение. Особенно удобно применять для этого Logstash — компонент ELK-стека, который позволяет «слушать» Kafka, фильтруя нужные события. Благодаря бесшовной интеграции компонентов ELK друг с другом, результат из Logstash в виде JSON можно отправить в ElasticSearch. При этом Logstash практически не вызывает IOPS, т.к. данные проходят через оперативную память. Также Logstash довольно прост и удобен в установке и обслуживании, в т.ч. при работе с Kubernetes [1].
Эксплуатация Apache NIFI
Код курса
NIFI3
Ближайшая дата курса
13 мая, 2024
Продолжительность
24 ак.часов
Стоимость обучения
72 000 руб.
Узнайте больше про применение Apache NiFi и Kafka для разработки сложных потоковых конвейеров и распределенных приложений аналитики больших данных на специализированных курсах в нашем лицензированном учебном центре обучения и повышения квалификации для разработчиков, менеджеров, архитекторов, инженеров, администраторов, Data Scientist’ов и аналитиков Big Data в Москве:
Источники
