Application Developer Days 2: Отчет Кудрявцева В.Б/Особенности масштабирования систем планирования и управления поставками

Ссылки сюда (2) →

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

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

• тип заказчика (крупные ритейл),
• близкий бизнес-процесс,
• похожий стек технологий.

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

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

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

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

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

• Крупнейшие retail-сети, как европейские, так и американские
• Особенность retail-бизнеса в том, что при высоком годовом обороте (до 100 миллиардов долларов в год для крупнейших сетей), чистая прибыль колеблется на уровне 1-4 % процента
• Поэтому точность определения спроса очень важна. Увеличение продаж на 1 % дает сотни миллионов долларов дополнительного дохода.

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

• Получать данные о продажах и остатках за определенный период времени (обычно сутки).
• Накапливать данные.
• Строить краткосрочные прогнозы продаж (эвристики — Data Mining).
• Строить долгосрочные планы (математическая статистика).
• Создавать заявки на перевозку товара со складов или заказы производителям.
• Мониторить продажи и вносить корректировки.

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

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

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

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

• Oracle 10g (используется RAC — Real Application Clustering, технология распределения работы с одной БД на несколько физический машин), на Linux
• Java 1.6, на Windows Server 2003 (Windows используется из-за того, что многие алгоритмы доступны только в виде нативных Windows dll).
• Собственный Cache/Grid Manager
• JSP, Struts, JavaScript (Ext.JS) для пользовательский интерфейсов
• Flash, также для пользовательских интерфейсов, с недавнего времени.

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

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

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

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

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

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

• Используется SQL*Loader для загрузки содержимого файла в БД, без дополнительной обработки. Используется, я так понял, режим Direct — прямая запись данных в файловую систему, минуя механизмы БД, что позволяет добиться очень высокой скорости обработки
• Перед загрузкой файл режется на части по несколько сот мегабайт, которые загружаются параллельно
• Иногда используется фича Oracle под названием External Tables — возможность подключить CSV файл как таблицу и делать к нему запросы. По сути, удобная обертка над SQL*Loader

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

• Активно используется партиционирование.
  • Соответственно, запросы стараются строить так, чтобы затрагивать только одну партицию

Давно пора попробовать в RMS

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

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

• Показывать TOP грузящих сервер запросов
• Показывать реальный план исполнения
• Показывать план в динамике — сколько данных уже зачитано на данный момент.

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

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

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

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

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

• никаких динамически получаемых сложных запросов!
• используется materizalized view
• агрегация заранее
• принудительная фильтрация

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

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