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

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

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

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

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

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

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

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

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

  • Профилирование некорректных записей (флаг). Если опция включена, операция гарантированно завершится успехом даже при наличии ошибок в данных или в коде обработки. Все ошибки логируются: либо в отдельные таблицы в БД, либо в логах backend. При отключенной опции (по умолчанию) операция прерывается при первой ошибке.

  • Границы профилей в процентах от объема самой тяжелой записи (поле ввода). Список границ для категоризации записей по их удельному весу. Задаются через запятую в процентах (например, 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}.

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

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

  • 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 байтам.

Обработка некорректных записей

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

Таблицы исключений

В базе данных создаются таблицы:

  • profile_data_exceptions_{operationId} — для записей,

  • profile_classifications_exceptions_{operationId} — для классификаций (если профилирование классификаций включено).

Структура таблиц:

Поле

Тип

Описание

id

string

Etalon ID записи. Значение, которое в нормальном случае попало бы в profile_data_{id}.

cause

text

Краткое сообщение об ошибке (например, текст исключения или "Запись не обработана").

stack_trace

text

Опционально - полный stack trace ошибки (если ошибка возникла в коде и есть трассировка).

Кейсы обработки ошибок

  1. Блок данных корректен - все записи попадают в основные таблицы profile_data_{id} и profile_classifications_{id}. Таблицы исключений остаются пустыми.

  2. Ошибка в коде обработки - система дробит блок на подблоки, пытаясь выделить "проблемную" запись. Если обработка подблока успешна, его записи сохраняются в основные таблицы. Записи, которые вызывают ошибку, попадают в таблицы исключений с указанием причины и stack trace. Операция продолжается до полного завершения.

  3. Отсутствуют обязательные компоненты записи (etalon, origin или vistory) - запись не может быть профилирована, но ошибки в коде не возникают. Такая запись не учитывается в статистике, а ее etalon ID заносится в таблицу исключений с причиной "Запись не обработана операцией профилирования". Связи или классификации с недостающими компонентами игнорируются при подсчете статистики для самой записи.

  4. Ошибка подключения к БД - при попытке сохранить ошибку в таблицу исключений также возникает ошибка. В этом случае в лог backend выводится сообщение, а операция профилирования продолжается.

Ограничения и производительность

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

  • Время работы операции при включенной опции увеличивается:

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

    • если много записей и они вызывают ошибки в коде, увеличенный размер блока может замедлить поиск проблемной записи.

  • Статистика по поврежденным связям/классификациям не собирается - они просто исключаются из подсчёта для соответствующих записей.

Оптимизация и мониторинг

  • Исправлена работа с большими объемами данных при количестве шардов (org.unidata.mdm.data.shards) больше 1 - запросы оптимизированы, что предотвращает падение производительности в многошардовых конфигурациях.

  • Добавлено ограничение максимального количества параллельных потоков на всем кластере – параметр com.universe.mdm.hpe.job.profile.data.max.cluster.threads позволяет ограничить суммарную нагрузку на базу данных со всех узлов. Существующий параметр com.universe.mdm.hpe.job.profile.data.threads ограничивает потоки на одном узле. Оба параметра можно изменять без перезапуска приложения.

  • Расширено логирование для упрощения мониторинга и диагностики:

  • Логируются начало и завершение всей операции с указанием ее ID и статуса.

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

  • Логируется начало и завершение шага агрегации данных.

  • Периодически (каждые 10 секунд) выводится прогресс выполнения шага сбора данных в процентах (количество завершенных блоков / общее число блоков).

  • Исправлен пропуск колонки description у vistory-записей, связей и классификаций в результатах профилирования.