Максим Цепков - отчет об ADD-2011/Особенности масштабирования систем планирования и управления поставками

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

Системы управления поставками для крупных американских и некоторых европейских ритейлеров. Сырье — Вендор — Ритейлер — Покупатель. Товар вперед, по заказам. Без возвратной логистики. Очень интересный для меня доклад, поскольку наша компания, в числе прочего, занимается именно проектами управления снабжением магазинов для Спортмастера.

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

Бизнес-задача — снабжение магазинов на основании текущих остатков и прогнозов продаж.

• Содержание SCM
  • demand planing — предсказание объема продаж,
    • статистический долгосрочный прогноз
    • эвристический краткосрочный прогноз
  • order management — реальные заказы, опираясь на прогнозы
  • transportation — транспортная логистика
  • исполнение
• Прибыль ритейлеров — 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