Персональные инструменты
 

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

Материал из CustisWiki

Перейти к: навигация, поиск

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

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

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

  • Содержание 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