РАЗРАБОТКА ПОДХОДА К АВТОМАТИЗАЦИИ КОНТРОЛЯ КАЧЕСТВА ДАННЫХ В БИЗНЕС-ПРОЦЕССАХ ФОРМИРОВАНИЯ ТОВАРНЫХ ОТЧЁТОВ

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

Ключевые слова: качество данных, товарные отчёты, ненормализованная номенклатура, валидация, электронная коммерция, Elasticsearch, неинвазивный контроль.

ВВЕДЕНИЕ

Качество товарных данных напрямую влияет на отчётность, поиск, фильтрацию и аналитику ассортимента в системах электронной коммерции. Однако на практике товарные каталоги часто содержат неполные значения, разные варианты названий одних и тех же атрибутов и неодинаковый состав полей в разных категориях.

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

Цель работы – описать подход к автоматизированному контролю качества данных при формировании товарных отчётов, который позволит выявлять типовые ошибки без изменения схемы хранения и без вмешательства в действующую логику.

1. ПОСТАНОВКА ЗАДАЧИ ИССЛЕДОВАНИЯ

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

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

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

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

2. АКТУАЛЬНОСТЬ ТЕМЫ И СТЕПЕНЬ ЕЁ ИЗУЧЕННОСТИ

Качество товарных данных влияет на отчётность, поиск, фильтрацию и аналитику ассортимента в системах электронной коммерции. На практике товарные каталоги часто содержат неполные значения, разные варианты названий одних и тех же атрибутов и неодинаковый состав полей в разных категориях. Из-за этого классическая валидация по фиксированной схеме работает ограниченно.

Проблематика качества данных рассматривается в стандартах и научной литературе. В ГОСТ Р ИСО/МЭК 25012–2015 выделены характеристики полноты, точности и согласованности данных [1]. В работах по управлению качеством данных описаны методы профилирования, мониторинга и очистки информации [2–4]. Исследования слабоструктурированных данных показывают, что документно-ориентированные хранилища и поисковые системы подходят для работы с переменным составом полей [5–7].

На предыдущем этапе было установлено, что существующие решения в основном ориентированы либо на структурированные данные с заранее заданной схемой, либо на отдельные процедуры очистки. В рассматриваемом случае нужен контроль, который работает рядом с текущим процессом формирования отчёта и не меняет его. Именно эта особенность определяет практическую значимость исследования.

3. ЗАДАЧИ И ЛОГИКА ИССЛЕДОВАНИЯ

На теоретическом этапе решаются следующие задачи:

• Описать действующий процесс формирования товарных отчётов;

• Построить классификатор типовых дефектов товарных данных;

• Сформулировать функциональные и нефункциональные требования;

• Определить архитектурные ограничения;

• Разработать концептуальную модель подхода;

• Предложить архитектурное решение и обосновать выбор классов программных средств.

Практический этап предполагает реализацию прототипа на базе ООО «Нотиссимус», проверку подхода на размеченной выборке товарных позиций, уточнение модели и подготовку рекомендаций.

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

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

4. ТЕОРЕТИЧЕСКИЕ РЕЗУЛЬТАТЫ ИССЛЕДОВАНИЯ

4.1. Анализ бизнес-процессов и классификатор дефектов данных

Анализ процесса формирования товарных отчётов в ООО «Нотиссимус» показал, что данные товарных позиций проходят через сервис агрегации, сервис выборки и хранилище товаров. После этого менеджер формирует итоговый отчёт. Атрибуты товаров хранятся в реляционной СУБД в XML-полях. Поэтому схема базы данных не задаёт обязательный набор атрибутов и не контролирует состав полей для отдельных товарных категорий.

На основе данных системы управления товарами ООО «Нотиссимус» были выделены три группы дефектов.

Таблица 1.

Классификатор типовых дефектов данных в ненормализованной товарной номенклатуре

Такое разделение важно для архитектуры, поскольку каждый тип дефекта требует собственной вспомогательной структуры и отдельной логики проверки. Классификатор ограничен дефектами атрибутного состава. Дубликаты, нарушения ссылочной целостности и временные аномалии в рамках данного этапа не рассматриваются.

4.2. Требования к подходу

Требования сформированы на основе двух групп факторов: принципа невмешательства в действующий процесс и типов дефектов, выявленных при анализе данных. Также учтены характеристики качества данных по ГОСТ Р ИСО/МЭК 25012: полнота, согласованность и точность.

Таблица 2.

Требования к подходу

Главное архитектурное свойство подхода – неинвазивность. Контроль выполняется параллельно с исходным процессом и не блокирует формирование отчёта.

4.3. Концептуальная модель подхода

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

Рисунок 1. Диаграмма компонентов подхода

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

Анализатор товарной позиции выполняет три проверки. Структурная проверка сопоставляет атрибуты позиции с эталонным набором для категории. Содержательная проверка ищет неинформативные значения. Согласовательная проверка сопоставляет названия атрибутов со словарём синонимов. Эталонные наборы атрибутов формируются на основе существующих карточек товаров и экспертной проверки менеджеров.

Результат анализа – запись о дефекте. Минимальный набор полей включает идентификатор товарной позиции, категорию товара, имя атрибута, тип дефекта, время обнаружения и идентификатор события или отчёта.

Хранилище результатов контроля сохраняет записи о дефектах и обеспечивает поиск, фильтрацию и агрегирование. Средство визуализации показывает распределение дефектов по категориям, динамику во времени и список наиболее проблемных атрибутов или товарных групп.

Проверка выполняется асинхронно относительно основного процесса. Если компонент контроля временно недоступен, формирование отчёта продолжается.

4.4. Архитектурное решение

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

Таблица 3.

Сопоставление классов программных средств для хранилища результатов контроля

Реляционная СУБД может использоваться для такой задачи, но потребует дополнительной настройки и промежуточных структур. Хранилище «ключ – значение» хорошо подходит для простого сохранения записей, но ограничено в поиске и аналитике. Документно-поисковое хранилище лучше соответствует требованиям: оно естественно работает с переменным набором полей и поддерживает полнотекстовый поиск и агрегирующие запросы.

Для рассматриваемого сценария в качестве типового решения выбран Elasticsearch. Возможные альтернативы – OpenSearch, Apache Solr или MongoDB, если требования к полнотекстовой аналитике ниже.

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

Практический вариант реализации: перехватчик событий приложения, сервис анализа, Elasticsearch и Kibana.

5. ВЫВОДЫ ПО ТЕКУЩЕМУ ЭТАПУ ИССЛЕДОВАНИЯ

На втором этапе НИР был обоснован подход к автоматизации контроля качества данных в процессе формирования товарных отчётов.

Получены следующие результаты:

• Сформирован классификатор дефектов атрибутного состава товарных данных;

• Определены функциональные и нефункциональные требования;

• Описаны архитектурные ограничения;

• Разработана концептуальная модель подхода;

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

Эти результаты могут быть использованы для реализации прототипа в ООО «Нотиссимус». При необходимости подход можно адаптировать для других систем электронной коммерции, где товарные данные имеют переменный состав атрибутов.

6. ПЛАН ПРАКТИЧЕСКОЙ АПРОБАЦИИ

Апробация будет проводиться на базе ООО «Нотиссимус» в тестовом контуре действующей информационной системы. Цель – реализовать прототип и проверить, насколько предложенное решение подходит для выявления дефектов товарных данных на размеченной выборке.

План работ:

• Подготовить тестовую инфраструктуру для хранения и визуализации результатов;

• Сформировать эталонные наборы атрибутов по категориям товаров;

• Подготовить словарь недопустимых значений и словарь синонимов атрибутов;

• Реализовать прототип сервиса анализа дефектов;

• Провести тестовые запуски на размеченной выборке товаров;

• Оценить качество выявления дефектов.

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

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

Ориентировочная продолжительность апробации — 10 недель.