Разработать и реализовать архитектуру хранилища данных bigdata проекта

Цена договорная • наличный расчёт, безналичный расчёт, электронные деньги
08 октября 2015, 15:26 • 10 откликов • 94 просмотра
Есть рабочий проект по сбору и анализу прайс-листов организаций некоторой отрасли. Задача состоит в регулярной загрузке обновленных данных прайс-листов и их обработка для последующего поиска в реальном времени (по последним данным) и проведении аналитических исследований (на исторических данных). Хранение и работа с товарами осуществляется после их обработки и приведения к эталонному виду, получение значения отдельных характеристик (цвет, размер и т.д.). По сути проект представляет из себя Яндекс.Маркет для внутреннего пользования.

Описание работы

Загружаемые “сырые” данные представляют собой плоские таблицы с произвольным числом колонок и строк. Есть обязательныес столбцы (товар, единица измерения, количество, цена), а есть все остальные (описание, цвет, размер и т.д.). При этом “все остальные” столбцы разные для разных товаров, организаций и т.д..

Получаемые данные ложатся в БД “как есть” и используются для дальшей обработки. Обработка заключается во-первых в приведении “сырых” назватий товаров к эталонному виду, а во-вторых к группировке товаров. Таким образом получаются “обработанные” данные.

“Обработанные” данные используются конечными пользователями для поиска, построения исторических отчетов и т.д.

Схему прикрепить не могу, поэтому вышлю по требованию на почту.

Техническое описание и объемы информации

Сейчас архитектура системы построена на базе mysql для плоских данных и mongodb для остальных. Поиск осуществляется с помощью sphinx.

В настоящий момент в месяц загружается 700-1000 файлов, планируется довести этот показатель до 1.5-2 тысяч. Среднее количество записей в файле около 1000 (от 1 до 100000 записей). Объем данных 250-400 Мб/месяц. Таким образом за год выходит около 3-5Гб “сырых” данных. Планируется хранить данные до 5 лет. То есть общий объем будет не менее 15Гб. “Сырые” данные не удаляются после обработки.

Обработка заключается в сопоставлении “сырых” названий товаров с эталонными из каталога. Объем эталонного каталога сейчас 200к записей. Планируется довести количество до 1М.

После обработки делается срез последних данных (по компаниям и городам) и формирование поиского индекса для возможности гибкого поиска. Формирование списка актуальных данных занимает 20 минут, формирование поискового индекса около 25 минут.

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

Для поиска в срезе актуальной информации сейчас используется sphinx. Сейчас строится два индекса - один по всему списку данных и один по сгруппированному списку. При работе с индексом используется “натуральная” сортировка по названию, “умный” поиск по названию (названия товаров специфические, поэтому стандартная морфология русского языка не используется), отбор по промежутку числовых данных, выборка по нескольким значениям словарных значений, отбор по параметрам и т.д.

Проблемы и пожелания по их исправлению

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

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

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

Прочее
Помимо подсистемы хранения есть проблема с разработкой архитектуры эталонного каталога товаров с учетом их характеристик. В доработке нуждается и механизм распознавания “сырых” названий товаров и сопоставления их с эталонными значениями.

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

Задача-максимум сделать эталонный каталог, механизм распознавания товаров и, возможно, интерфейс.

Наработки и примеры работ приветствуются (и скорее даже необходимы). Подробную информацию и примеры данных будут при предметном обсуждении.

Если готовы взяться, то просьба сразу писать решения на которых работаете и какие планируете использовать, чтобы было понятно в какую сторону общаться.

Техническое обеспечение

  1. ОС Linux (debian, centos …)


  2. БД - на ваш выбор (сейчас mysql, mongodb, sphinx)


  3. Интерфейс на php + yii, поэтому необходимо наличие драйвера для выбранной БД


  4. Язык разработки - perl/python, возможно java