Михаил Антонов, Magenta Development (Самара)

Для меня доклад оказался самым интересным на конференции — полное совпадение:

Компания, основной центр разработки которой находится в Тольятти, предоставляет услуги расчета планов поставок в розничные магазины ритейл-сети со складов (Distribution Center или РЦ в принятой у нас терминологии) или напрямую от поставщика.

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

Note.svg Кстати, очень хвалили специализированные аппаратные решения для Oracle, типа Exadata. Впрочем, сразу была оговорка об их недостатках — если что-то сломалось починить без дорогостоящих и редких специалистов сложно. В конечном итоге, я так понял, большая часть используемого железа — это все-таки конвенциональные сервера.

Note.svg На вопрос об облачных решениях ответил, что только начинают присматриваться, но уже вполне серьезно рассматривают такую возможность, в частности, Amazon,

Содержание

Кто их клиенты?

Какая задача системы?

Задача оперативного обеспечения отгрузок и перевозок решается системами клиента.

Note.svg В случае Спортмастера эта система как раз RMS. Получается, что мы с Magentа не конкурируем — мы не раз говорили о том, что мы, во всяком случае на данном этапе, не занимаемся Data Mining и Buisness Intelligence, а они не занимаются оперативным обеспечение поставок.

На чем сделано?

Крупные компании обычно очень консервативны, поэтому особого богатства выбора быть не может. В результате используются:

Что интересно — часть логики сервера приложений начали писать на Groovy.

Собственно, масштабирование

Докладчик выделил несколько типов задач, которые требуют быстрого выполнения, а значит оптимизации и масштабирования. Максимальное время исполнение ограничено циклом бизнес-процесса в retail-сети — для того, чтобы данные дня вчерашнего можно было учитывать в сегодняшних продажах, нужно уложится за 1.5-2 часа (остальное время занимает исполнение заявки системами клиента: корректировка заявок экспертами людьми, подготовка товара на складе, транспортировка до магазина)

Оценка объема данных: 2k магазинов * 50k товаров * 500 дней = 50 * 109 = 50 миллиардов фактов продаж в финансовый год (почему-то длительность взяли в 500 дней).

Загрузка больших объемов данных из внешних систем

Данные присылают ежедневно в виде упакованного csv-файла объемом порядка 10 Гб (сводные данные по сети).

Хранение данных. Построение запросов к огромным массивам данных

Note.svg Давно пора попробовать в RMS

Настройка и мониторинг в целом

Используется Oracle Grid Control (есть версия для одного сервера — Oracle Server Control). Что он умеет:

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

Оптимизация работы UI

Идеальная система управления поставками — это система, у которой нет пользователей, полный автомат. Но в жизни идеал недостежим, поэтому пользователи все-таки есть. Они обычно:

Поэтому все запросы с UI — максимально простые и предвычисленные.

Оптимизация механизмов предсказания

Тут все сделано за счет серьезного распараллеливания на сервере приложений. Докладчик сказал, что в Oracle параллелить проще, но слишком дорого — каждый новый instance Оракла стоит несколько десятков тысяч долларов.