Операция переприменения данных (reapplyDataJob)¶
Операция переприменяет правила качества данных к записям, запускает правила, индексирует и сохраняет в БД результаты. Применяется при обновлении модели данных, добавлении новых атрибутов, а также при создании новых правил качества или изменении существующих.
Параметры операции выбирают, на каких объектах модели (реестрах/справочниках) какие наборы правил качества запускать. Например, если набор правил X настроен на реестры 1 и 2, а в параметрах операции выбраны набор X и только реестр 1, то переприменяться будут только правила набора X для данных реестра 1.
Параметры операции¶
Имя пользователя (поле ввода). Логин учетной записи. Определяет, от имени какого пользователя фиксируются изменения - пишутся аудит и штампы в индексе и БД. Отчет о выполнении приходит пользователю, запустившему операцию. Проверка прав не происходит.
Наборы правил (выпадающий список). Перечень наборов правил качества, созданных в разделе "Качество данных".
Переприменить для объектов модели (выпадающий список). Перечень реестров/справочников, для которых будет применена операция.
Размер блока (поле ввода). Размер блока загружаемых данных. По умолчанию 1024.
Примечания:
Операция не проводит ремаппинг модели данных;
Не может запускаться повторно в случае возникновения ошибок;
Не инициирует сопоставление записей;
Отчет о выполнении не содержит информацию о количестве обработанных записей.
Взаимосвязь с потоками выполнения¶
Операция переприменения имеет собственные потоки выполнения: [BATCH_RECORD_UPSERT_START]${reapply-records-bulk-pipeline} (общий массовый поток) и [RECORD_UPSERT_START]${reapply-records-worker-pipeline} (поток, определяющий действия с каждой записью отдельно).
Для корректной работы с наборами правил, настроенными на фазу ETALON, необходимо добавить сегмент типа Point - RECORD_UPSERT_QUALITY_ETALON в поток {reapply-records-worker-pipeline}.
Операция не применяется для работы с наборами правил, настроенными на фазу ORIGIN.
Механизм работы параметра "Размер блока" (blockSize)¶
Все количество обрабатываемых записей делится на части по blockSize записей.
Затем в каждой части обрабатывается одним тредом по com.unidata.mdm.job.reapply.data.commit.interval записей (в памяти держится информация по этому количеству записей, при переходе к следующим записям память очищается), пока не кончатся записи.
Параметр com.unidata.mdm.job.reapply.data.commit.interval как правило, не нуждается в редактировании. Рекомендуемого значения 1024 достаточно для большинства задач. Чем больше этот параметр, тем больше памяти может быть занято в один момент времени. Если этот параметр больше, чем blockSize, то фактически этот параметр будет равен blockSize.
org.unidata.mdm.job.reapply.data.threads - количество одновременно обрабатываемых тредов.
Параметры com.unidata.mdm.job.reapply.data.commit.interval и org.unidata.mdm.job.reapply.data.threads задаются в backend.properties.
Таким образом, следует выбирать org.unidata.mdm.job.reapply.data.threads по количеству логических ядер процессора (использовать равное или меньшее число, в зависимости от наличия другой нагрузки на процессор).
При указании небольшого blockSize легче отслеживать прогресс операции через UI (менеджер запусков > выбрать запуск > количество выполненных шагов). С точки зрения производительности лучше использовать достаточно большой blockSize, чтобы количество мигрируемых записей было примерно равно N * blockSize * com.unidata.mdm.job.reapply.data.threads, где N – не слишком большое натуральное число, например, 1.
Если blockSize слишком большой (например, 500000), то часть данных может не записаться, но при этом операция завершится успешно.
Настройка blockSize необходима для баланса между объемом обрабатываемых данных и количеством потоков. Плохо, когда создается очень много потоков, и так же плохо когда 1 поток обрабатывает слишком много данных сразу. Поэтому желательно выбирать средние значения исходя из доступных ресурсов сервера.
Также blockSize необходимо выбирать в соответствии с общим количеством данных чтобы количество партиций не было слишком большим. На таких больших данных, как в справочнике с адресами, оптимальным вариантом является 500-2000 партиций.
Обработка данных происходит последовательно: записи > связи > классификаторы > бизнес-процессы > матчинг. Сначала завершается обработка одного типа данных, затем происходит переход к другому. Обрабатываются те типы данных, которые есть в наличии.