Для чего нашему заказчику нужны данные?

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

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

Некоторые поставщики предоставляют API для загрузки данных. Благодаря интеграции с такими API SourceESB может показывать информацию о ценах и наличии в реальном времени.

Развитие продукта идет по двум основным направлениям:

1. Подключение новых производителей и поставщиков, ускорение процесса подготовки данных, расширение данных о компонентах — так происходит наполнение системы данными;
2. Привлечение пользователей — реклама, средства поиска, SEO.

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

Архитектура, которую мы выбрали

Начнем изучение продукта с верхнеуровневой архитектуры. В системе можно выделить 3 слоя работы с данными.

Слой первый — сбор данных. Это набор внешних интерфейсов, которые позволяют вводить данные в систему. Одни сервисы позволяют представителям производителей и поставщиков загружать каталоги через интерфейс администратора, загрузку файлов на FTP-сервер или отправку email. Другие сервисы работают с API поставщиков для извлечения данных.

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

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

Что происходит с собранными данными

Рассмотрим внимательно процесс подготовки данных.

1. Собранные из разных источников данные хранятся на сетевом диске EC2 инстанса, пока не будут обработаны.
2. Сервисы обработки данных по графику начинают поочередно забирать данные из временного хранилища.
3. Сервис создает временные таблицы для подготовки новых данных, чтобы не влиять на работоспособность системы и целостность данных, представляемых пользователям.
4. Начинаем обрабатывать данные — фильтруем, оставляя лишь те, что удовлетворяют обязательным критериям. На этом шаге мы отсеиваем некорректную и бесполезную информацию, чтобы не захламлять систему. Работа с данными на этом этапе происходит во временных таблицах.
5. Объединяем данные — выявляем совпадения компонент у разных поставщиков, собираем максимум информации, для новых записей конфликты решаем в пользу более полных (длинных) значений. Для уже редактированных вручную отдаем предпочтение установленным данным.
6. Удаляем из базы компоненты, информация по которым не поступала более 30 дней.
7. На основе обновленных данных заполняем отдельные таблицы агрегированными значениями для отображения статистики.
8. Переключаем приложение на данные из временных таблиц — они готовы к использованию.
9. Создаем новый поисковый индекс каждый день и отдаем данные из него. Устаревшие индексы хранятся 5 дней для обеспечения возможности отката.
10. Очищаем кэш и «прогреваем» его — наполняем наиболее часто встречающимися запросами.

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

Инфраструктура AWS

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

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

AWS Simple Email Service (SES) принимает письма с вложенными файлами инвентаризации и отправляет уведомления и предупреждения. Принятые вложения хранятся в специальной папке сервиса S3.
Центральное хранилище реализовано на MS SQL. Поиск на AWS OpenSearch.

Выводы

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

Развертывание в облаке дает возможность уйти от необходимости создания собственного дата-центра и оперативно масштабировать ресурсы системы