Операция профилирования данных (profiledataJob)

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

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

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

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

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

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

• Хранить только последние запуски в количестве (поле ввода). Если указано число N, то детальные таблицы (profile_data_{operation_id}, profile_classifications_{operation_id}) за все, кроме последних N запусков операции, будут автоматически удалены из базы данных.

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

• Границы профилей в процентах от объема самой тяжелой записи (поле ввода). Список границ для категоризации записей по их удельному весу. Задаются через запятую в процентах (например, 0,25,50,75,100). Система создаст профили: 0-25%, 25-50% и т.д., от объема самой «тяжелой» записи в системе.

• Границы профилей по количеству связей (поле ввода). Список границ для категоризации записей по числу исходящих связей. Задаются через запятую (например, 0,5,10,20,50). Будут созданы профили: 0-5 связей, 6-10 связей и т.д.

• Границы профилей по количеству классификаций (поле ввода). Список границ для категоризации записей по числу активных классификаций. Задаются через запятую (например, 0,5,10,20,50). Будут созданы соответствующие профили. Если модуль классификаций не включен в сборку, этот подсчет выполняться не будет.

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

Операция выполняется в два основных этапа:

1. Сбор детальных метрик по записям: Система выполняет запросы к основным таблицам БД (record_etalons, relation, classification), чтобы для каждого эталона записи подсчитать:

• Объем данных (в байтах) самой записи.

• Количество и общий объем данных всех ее исходящих связей.

• Количество и общий объем данных всех ее активных классификаций. Эти детальные данные сохраняются во временные таблицы profile_data_{operation_id} и profile_classifications_{operation_id}.

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

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

• com.universe.mdm.hpe.job.profile.data.threads — определяет количество потоков (тредов) для параллельного выполнения операции. Влияние: Увеличение числа потоков может ускорить выполнение на мощных серверах, но создаст большую нагрузку на БД и CPU. Рекомендуемое значение по умолчанию — 2. Управление распределением задач между потоками и нодами кластера осуществляется через Hazelcast.

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

• Повторный запуск после ошибки: Если операция завершилась с ошибкой, ее повторный запуск начнет сбор статистики заново. Результаты предыдущего неудачного выполнения не будут использованы.

• Зависимость от модулей: Сбор статистики по классификациям является опциональным. Если соответствующий функциональный модуль не входит в сборку системы, эта часть метрик рассчитываться не будет.

• Хранение детальных данных: Детальные таблицы (profile_data_{operation_id}) могут занимать значительное место. Рекомендуется использовать параметр "Хранить только последние запуски в количестве" для их автоматической очистки.

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

Рекомендации по настройке и использованию:

• Настройте фильтры: В параметре "Профилировать объекты модели" указывайте только те реестры/справочники, которые действительно нужны для анализа. Это сократит время выполнения и нагрузку.

• Используйте многопоточность: Для ускорения обработки больших объемов данных настройте количество потоков в файле backend.properties через параметр com.universe.mdm.hpe.job.profile.data.threads. Рекомендуемое значение по умолчанию — 2, его можно увеличить на мощных серверах, соблюдая баланс с нагрузкой на CPU и БД.

• Следите за производительностью: Запускайте операцию в периоды минимальной нагрузки на систему и следите за потреблением ресурсов (CPU, память, I/O базы данных) во время ее выполнения.

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

Основным результатом являются две таблицы в схеме БД com_universe_mdm_hpe_job_profile_data:

• profile_execution: Фиксирует факт каждого запуска операции.

• profile_digest: Содержит агрегированные метрики, привязанные к execution_id. Для каждого профиля по каждому разрезу (records, relations, classifications) указывается:

  • indicator_name: Тип объекта (записи, связи, классификации).

  • from_bound, to_bound: Границы профиля.

  • items_count: Количество записей, попавших в данный профиль.

  • volume: Доля (от 0 до 1) от общего объема данных по этому разрезу во всей системе, которую составляют записи этого профиля.

  • total_size: Абсолютный объем в байтах, который составляют данные этого профиля.

Пример записи в profile_digest и ее интерпретация:

execution_id	indicator_name	from_bound	to_bound	items_count	volume	total_size
70	records	0	25	15	0.00015	6985
70	relations	11	20	112	0.10224	807520
70	classifications	11	20	16	0.03997	101152

Интерпретация результатов:

• Записи (records): 15 записей имеют вес от 0% до 25% от самой "тяжелой" записи в системе. Их совокупный объем составляет 0.015% (0.00015) от общего веса всех записей, что равно 6 985 байтам.

• Связи (relations): 112 записей имеют от 11 до 20 исходящих связей. Общий объем данных этих связей составляет 10.224% (0.10224) от веса всех связей в системе, что равно 807 520 байтам.

• Классификации (classifications): 16 записей имеют от 11 до 20 активных классификаций. Общий объем данных этих классификаций составляет 3.997% (0.03997) от веса всех классификаций, что равно 101 152 байтам.