Мы уже писали про главные недостатки Apache NiFi как инструмента потоковой маршрутизации данных и организации ETL-процессов. Одним из них считается высокое потребление дискового пространства. Почему это случается и как с этим бороться: тонкости работы с потоковыми файлами на уровне жесткого диска — процессоры, очереди, сохранение и изменения FlowFile в Apache NiFi.
Потоковый ETL с Apache NiFi: ключевые концепции
Напомним, Apache NiFi NiFi основан на концепции потокового файла (FlowFile), который обрабатывается различными процессорами. Сам FlowFile состоит из 2-х компонентов:
- содержимое или контент (content), которое хранится на диске в составе одного или нескольких физических файлов. FlowFile указывает на физический файл на диске и смещение в нем, чтобы хранить в одном физическом файле данные нескольких потоковых файлов, не открывая слишком много курсоров в операционной системе.
- метаданные или атрибуты (attributes), описывающие FlowFile и хранящиеся в оперативной памяти как словарь (Map) из строковых ключей и значений. Также атрибуты записываются на диск с использованием журнала упреждающей записи (WAL, Write Ahead Log), обеспечивая стабильность состояния обработки.
Потоковые файлы обрабатываются с помощью готовых или самостоятельно написанных дата-инженеров обработчиков – процессоров, которые могут создавать контент (генераторы данных), получать его извне и производить вычисления. Для генераторов важно определить период запуска: если поставить значение по умолчанию 0 секунд, запросы к источнику данных будут выполняться непрерывно, что увеличивает нагрузку и может привести к сбою системы.
Другие процессоры получают данные из поступающего на вход потокового файла, изменяя его контент или атрибуты. Они запускаются только при наличии FlowFile во входящей очереди. Очередь связывает процессоры между собой и хранит файлы, в т.ч. их состояния относительно обработки процессорами, например, ожидает обработки, обрабатывается или отправлен на повторную обработку из-за ошибки. Период запуска для процессоров, которые не являются генераторами, может равняться 0 секунд, т.к. это расписание регулирует только максимальную частоту запусков при наличии файлов. Для оптимальной тонкой настройки пропускной способности всего потока обработки данных можно выравнивать движение FlowFile за счет периода запуска. Таким образом, Apache NiFi позволяет превратить большой объем данных в равномерно работающий поток.
Вспомнив основные принципы работы этого потокового маршрутизатора, перейдем к типовым проблемам, с которыми можно столкнуться на практике из-за его особенностей внутреннего устройства и принципов работы.
Высокое потребление дискового пространства для хранения контента
NiFi хранит в одном физическом файле множество данных о контенте разных FlowFile. Содержимое FlowFile хранится на диске и считывается в память JVM только при необходимости. Это позволяет NiFi обрабатывать крошечные и массивные объекты, не требуя, чтобы процессоры производителей и потребителей данных хранили полные объекты в памяти. Поэтому разделение, агрегирование и преобразование очень больших объектов можно выполнять без вреда для памяти. Тем не менее, на практике можно столкнуться с проблемами IOPS-операций, т.е. чрезмерного ввода-вывода, о чем мы писали здесь и здесь.
Репозиторий контента состоит из набора файлов на диске, которые объединены в контейнеры и разделы. Раздел — это подкаталог Контейнера – корневой директории. Репозиторий контента может состоять из множества контейнеров, чтобы NiFi мог параллельно использовать несколько физических разделов, достигая скорости передачи данных в сотни мегабайт или даже гигабайт в секунду пропускной способности диска на одном узле. Таким образом, используя один файл на диске для хранения содержимого нескольких FlowFile, NiFi дает высокую пропускную способность, близкую к максимальной скорости передачи данных, обеспечиваемой дисками.
На практике это работает так: когда появляется файл с контентом, он записывается на диск. Если размер файла не достиг границы, при появлении следующего файла контент добавится в тот же физический файл. Для удаления неиспользуемых физических файлов, на который не ссылается ни один Flow File, NiFi проверяет наличие ссылок на него в потоковых файлах. Это отлично работает при высокой скорости прохождения файлов по конвейеру.
Но при загрузке данных из источника, данных бывает слишком много и все они будут занимать место на диске, ожидая своей обработки. Поэтому свободное место на диске может быстро закончиться, даже если реально в потоке меньше данных, чем имеющийся объем для хранения контента. Поэтому не следует загружать в NiFi сразу слишком большой объем данных, лучше сократить держать в потоке только те данные, которые можно быстро обработать и освобождать поток от них лучше максимально быстро. Регулировать это можно через параметр конфигурации размера очередей. В частности, задав его равным 1 для всех процессоров в data pipeline, можно гарантировать, что в потоке одновременно будет небольшое количество файлов. Также можно задать значение 1 параметру nifi.content.claim.max.flow.files в значении 1 – тогда в один физический файл будет записываться содержимое только одного FlowFile.
Примечательно, что содержимое потокового файла никогда не изменяется после его записи. С одной строны, это плюс, поскольку при изменении контента FlowFile не происходит фрагментации памяти или перемещения данных. С другой стороны, каждый раз при внесении изменений NiFi записывает новый контент и привязывает его к потоковому файлу. Для некоторых случае это удобно, т.к. если надо разделить обработку на несколько очередей, к примеру, для записи в разные системы хранения, контент не дублируется: несколько потоковых файлов связаны с одним и тем же содержимым. Однако, даже при изменении всего одного байта в контенте потребуется его полная перезапись, что может негативно повлиять на производительность всего конвейера обработки данных. О других проблемах, связанных с потоковыми файлами в Apache NiFi и способах их решения читайте в нашей новой статье.
Узнайте больше про администрирование и эксплуатацию Apache NiFi для эффективной аналитики больших данных на специализированных курсах в нашем лицензированном учебном центре обучения и повышения квалификации для разработчиков, менеджеров, архитекторов, инженеров, администраторов, Data Scientist’ов и аналитиков Big Data в Москве:
Источники
