Максим Цепков - отчет об ADD-2011/Особенности масштабирования систем планирования и управления поставками
Системы управления поставками для крупных американских и некоторых европейских ритейлеров. Сырье — Вендор — Ритейлер — Покупатель. Товар вперед, по заказам. Без возвратной логистики. Очень интересный для меня доклад, поскольку наша компания, в числе прочего, занимается именно проектами управления снабжением магазинов для Спортмастера.
Сам доклад — очень удачный. Михаилу удалось в кратком докладе рассказать о бизнес-задаче управления цепочкой поставок, о технических сложностях ее решения и о методах оптимизации. Задача, по моему опыту, весьма сложная и то, что они деляют — впечатляет.
Бизнес-задача — снабжение магазинов на основании текущих остатков и прогнозов продаж.
- Содержание SCM
- demand planing — предсказание объема продаж,
- статистический долгосрочный прогноз
- эвристический краткосрочный прогноз
- order management — реальные заказы, опираясь на прогнозы
- transportation — транспортная логистика
- исполнение
- demand planing — предсказание объема продаж,
- Прибыль ритейлеров — 1-4 % от оборота даже в успешные годы. Поэтому очень важна точность прогнозов.
- Региональные центры дистрибуции, по 2 на штат. Заказ в магазины и пополнение центров дистрибуции. Тысячи магазинов, до 15 тыс. у одного европейского ритейлера
- Прогнозирование — data mining. Эвристики, которые дорабатываются по прецедентам в процессе эксплуатации. Оно живет, но неудачи — опасны.
Особенности работы с заказчиком.
- Процесс прогноза и заказа идет автоматом, но должны быть механизмы наблюдения, анализа и корректировки.
- Процессы у заказчика — медленные. Например, получить одну нужную колонку в данных — 4 месяца.
- Консервативность заказчика к технологиям. Поэтому Oracle + Java. Используют Groove для бизнес-логики не афишируя — все равно Java-платформа.
Система обеспечивает решение следующей задачи. Надо ежедневно получать данные о продажах, конвертировать, валидировать, загружать. Далее — обрабатывать, обеспечивая создание заказов и корректируя имеющиеся прогнозы, долгосрочный и краткосрочный. При этом время на обработку ограничено — после получения всех данных и до первой стадии бизнес-процесса обработки заказов, обычно на это 1-1.5 часа. А объемы данных большие, оценка — 2К маг * 50К товаров (продаж в день) * 500 дней = 50 млрд строк продаж. Реально 5-10 млрд.
Пользователей системы мало, десятки-сотни они эксперты в предметной области. И они наблюдают за процессом и тушат пожары. Обнаруживать и тушить надо быстро, для этого им надо быстро и наглядно представить данные.
Система работает для нескольких заказчиков. У них есть общее ядро и дальше — настройка на заказчика. При этом граница системы проходит по-разному, различна и степень вмешательства пользователей — в одних случаях пользователи подтверждают каждый заказ, в других работает почти автомат. Алгоритмы прогнозирования они делают сами, однако существует учебный режим, в котором пользователи формируют статистику для работы алгоритмов или тестируют. Но реальная проверка — все равно на боевых данных.
Технологии.
- Oracle 10g/11g RAC
- Java 1.6 Jboss AS 4.2. Jboss используется исторически и как общая платформа с другими проектами.
- Собственный Cache и grid-manager
- Клиент JSP, JavaScript.
- Для бизнес-логики используют Groove
Задачии оптимизации
- Хранение больших таблиц
- Быстрая загрузка
- Оптимизация запросов
- Оптимизация БД в целом
- Оптимизация интерфейса
- Оптимизация engines — расчетных частей
Большие таблицы — Partitioning. Если пара таблиц имеет одинаковый partitioning, то join это учитывает.
Загрузка — SQL*loader, с использованием различных ускоряющих приемов.
- direct mode, отключение индексов, constraint, редкие commit, увеличение буфера
- отключение redo-log,
- параллельная загрузка по внешних процессов
- Загрузка во временную таблицу, потом merge для разрешения ссылок. Разбивают на части.
- flat table — монтировать csv-файлы как таблицы
Оптимизация запросов по планам решения. Реально оптимизатор — улучшается. Сейчас они удаляют хинты, написанные 3-4 года назад.
Oracle Grid Control. Вкладки мониторинга запросов — он показывает еще и динамический план: сколько записей в запросе и столько он уже вытащил. И известный способ — трассировка sql_trace, tkprof.
Оптимизация пользовательского интерфейса
- materialized view, вынос в них тяжелых частей запроса, обновление по ночам или несколько раз в сутки
- обеспечивают отклик 5 сек.
- принудительная фильтрация ui как мера предосторожности — например, не показывать средние продажи по всему восточному побережью — запрос уйдет в БД и многим помешает.
Пакетная обработка — цепочка engines. Масштабы впечатляют — 10К одновременных тасков, 2M всего в таблице. И это — наиболее критичная задача.
- В каждом engines — параллельно запускаем задачи обработки, для чего выделяем группы данных, обрабатываемых.
- Oracle масштабировать дороже, чем Java/JBoss. Поэтому расчет на сервере приложений. 4-6 серверов Java на каждый сервер Oracle.
- Проблемы ввода-вывода на уровне базы данных
- Трафик между БД и Сервером приложений — меньше, чем проблема ввода-вывода самой БД — на сервер приложений идут агрегированные данные. Задержки по БД-app их не волнуют, потому что параллельно идет много задач, ограничение — целиком
- Железо — в datacenter, тестируют, предпочитают стандартное, так как легче масштабируется.
- Облака — использовать начинают. Но amazone — использует сервера общего назначения, а они — оптимизированные под БД. Так что пока осторожно.
- Пишут запросы вручную, не через ORM.
- Используют HP и др. storage device
- Используют flash памиять, Увеличивают размер памяти.
- В 11 Oracle используют сжатие данных на exologic и др — на storage