Операция переприменения данных (reapplyDataJob)

Операция предназначена для массового повторного применения правил качества данных (валидации, обогащения, классификации) к уже существующим записям в реестрах и справочниках. Ее основная цель — обеспечить соответствие данных актуальным бизнес-правилам и поддерживать целостность поисковых индексов после изменений в логике обработки данных.

Операция последовательно запускает выбранные наборы правил качества. Результаты применения правил (статусы валидации, ошибки) индексируются в поисковом сервисе, а ревизии атрибутов, измененные в процессе обогащения или преобразования, фиксируются в базе данных. Это ключевой инструмент администратора для поддержания качества данных при эволюции модели и бизнес-требований.

Параметры операции

• Имя пользователя (поле ввода). Определяет, с правами какой учетной записи будет запускаться операция. Если поле пустое, то:

  • Операция выполняется от имени пользователя, фактически запустившего операцию, но если при запущенной без указания пользователя операции произошел выход из системы (случайный или принудительный при потере соединения), то операция завершится с ошибкой.

  • При запуске по Cron-выражению у операции будут полные права на любой реестр/справочник; при запуске через интерфейс у операции будут права текущей учетной записи. Для учетной записи оператора данных может понадобиться настроить права на реестры/справочники. Если логин не указан, то операция запуститься от имени пользователя, который ее запустил.

• Наборы правил (выпадающий список). Перечень наборов правил качества, созданных в разделе "Качество данных".

• Переприменить для объектов модели (выпадающий список). Перечень реестров/справочников, для которых будет применена операция.

• Размер блока (поле ввода). Размер блока загружаемых данных. По умолчанию 1024.

Примечания:

• Операция не проводит ремаппинг модели данных;

• Повторный запуск при наличии ошибок может привести к непредсказуемым результатам, поэтому рекомендуется сначала устранить причины сбоев;

• Не инициирует сопоставление записей;

• Отчет о выполнении не содержит информацию о количестве обработанных записей.

Внутренние механизмы

1. Подготовка и фильтрация: Система определяет целевые записи на основе параметров операции: выбранных объектов модели (реестров/справочников) и наборов правил качества. Правила применяются только к пересечению этих множеств.

2. Параллельная обработка блоками: Все отобранные записи делятся на блоки размером blockSize. Каждый блок обрабатывается в отдельном потоке. Внутри потока записи обрабатываются порциями, заданными параметром com.unidata.mdm.job.reapply.data.commit.interval, для контроля за использованием оперативной памяти.

3. Последовательность обработки сущностей: В рамках каждого блока данные обрабатываются в строгом порядке: сначала записи, затем связи, классификаторы, бизнес-процессы и в конце — матчинг. Обработка переходит к следующему типу сущностей только после завершения предыдущего.

4. Применение правил и индексация: К каждой записи применяются логика выбранных наборов правил качества. После обработки данные индексируются (происходит реиндексация поверх существующих индексов, что позволяет системе оставаться доступной для поиска, но может снижать общую производительность).

5. Фиксация результатов: Результаты работы правил (статусы, ошибки, обогащенные значения) сохраняются в базу данных и становятся видны в карточках записей.

Параметры системы

• com.unidata.mdm.job.reapply.data.commit.interval - определяет размер порции данных в записях, которая удерживается в памяти одного потока перед фиксацией. Влияние: Увеличение значения может повысить скорость обработки за счет большего использования RAM. Слишком высокое значение при большом числе потоков может привести к чрезмерному потреблению памяти. Рекомендуемое значение - 1024.

• org.unidata.mdm.job.reapply.data.threads - задает максимальное количество потоков (тредов) для параллельной обработки блоков данных. Влияние: Оптимальное значение зависит от количества логических ядер CPU и общей нагрузки на сервер. Рекомендуется устанавливать значение, равное или меньшее числа логических ядер. Изменение параметра требует перезапуска сервера.

Важно знать/Ограничения

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

• Выбор данных: Операция применяет правила только к пересечению выбранных наборов правил и выбранных объектов модели. Например, если набор правил X настроен на реестры 1 и 2, а в параметрах операции выбраны набор X и только реестр 1, то правила будут применены только к реестру 1.

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

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

• Производительность и настройка blockSize:

  • Слишком маленький blockSize (например, 10) создаст много задач для потоков и может замедлить обработку из-за накладных расходов.

  • Слишком большой blockSize (например, 500 000) может привести к чрезмерному потреблению памяти и, в редких случаях, к неполной записи результатов при успешном статусе завершения операции.

  • Рекомендация: Выбирайте значение, исходя из общего объема данных и ресурсов сервера. Оптимальное количество партиций (общее количество записей / blockSize) для больших массивов данных — в диапазоне от 500 до 2000.

Результат работы операции

После успешного выполнения операции:

• К данным выбранных реестров/справочников будут повторно применены выбранные наборы правил качества.

• Записи, которые не прошли проверку по правилам с критичностью RED, не удаляются и не блокируются. Их статус будет отмечен ошибкой, которая отобразится в интерфейсе карточки записи.

• Поисковые индексы для обработанных записей будут обновлены (реиндексированы).

• Результаты применения правил (новые вычисленные значения, флаги ошибок) сохраняются в базу данных и становятся доступны для поиска и отображения.