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

Особенности масштабирования систем планирования и управления поставками (Михаил Антонов, ADD-2011)

Материал из CustisWiki

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

Аннотация

Докладчик
Михаил Антонов

В задачах масштабирования можно выделить несколько типов нагруженных систем. Один из них, про которые многие наслышаны, это масштабирование сайтов c огромным количеством пользователей (Google, Facebook, Amazon, eBay). Михаил расскажет о менее известном — масштабирование различных систем планирования и управления заказами и прогнозами продаж — на примере решения, которое было разработано для одного из крупных ритейлеров США.

Будут кратко описаны:

  • Предметная область — что вообще такое Supply Chain Management и зачем он кому-то нужен (в каких отраслях используется, какими компаниями, с какими проблемами сталкиваются разработчики этих систем)
  • Основные компоненты SCM-системы для розничной торговли — хранилище данных, интеграция с инфраструктурой клиента, модуль анализа поступающих данных, интерфейс пользователя

И подробно рассмотрены вопросы:

  • Специфика масштабирования SCM-системы для ритейла «вообще»:
    • Пользователей мало — данных для анализа много
    • Интеграция с узлами Supply Chain
    • Откуда возникают ресурсоемкость и временные ограничения на обработку
    • Особенности пользовательского интерфейса
  • Какой стек технологий мы использовали и почему
  • Собственно масштабирование
    • Как хранить большие таблицы (>5 млрд записей) и индексы
    • Как быстро и надежно загружать ежедневно приходящие данные
    • Как параллельно обрабатывать большие объемы клиентских данных
    • Отзывчивовость интерфейса, работающего с большими объемами данных
    • Мониторинг производительности, принципы и инструменты.
    • JProfiler, Explain Plan, Oracle Grig Control. Где же в итоге тратятся ресурсы?

В завершение — в чем сходство и различия по сравнению с масштабированием нагруженных сайтов?

Видео

Скачать
http://ftp.linux.kiev.ua/pub/conference/peers/addconf/2011/2a6-scaling-systems-for-planning-and-supply-chain-management-antonov.avs.avi


Для этого доклада нужен подкаст (аудиозапись)?

  •  Да, многое понятно и без видео части, есть смысл его прослушать.
  •  Нет, аудиозапись бесполезна (не понять без видео или вообще мало смысла в докладе).

Презентация

Особенности масштабирования систем планирования и управления поставками (Михаил Антонов, ADD-2011).pdf Особенности масштабирования систем планирования и управления поставками (Михаил Антонов, ADD-2011).pdf Особенности масштабирования систем планирования и управления поставками (Михаил Антонов, ADD-2011).pdf Особенности масштабирования систем планирования и управления поставками (Михаил Антонов, ADD-2011).pdf Особенности масштабирования систем планирования и управления поставками (Михаил Антонов, ADD-2011).pdf Особенности масштабирования систем планирования и управления поставками (Михаил Антонов, ADD-2011).pdf Особенности масштабирования систем планирования и управления поставками (Михаил Антонов, ADD-2011).pdf Особенности масштабирования систем планирования и управления поставками (Михаил Антонов, ADD-2011).pdf Особенности масштабирования систем планирования и управления поставками (Михаил Антонов, ADD-2011).pdf Особенности масштабирования систем планирования и управления поставками (Михаил Антонов, ADD-2011).pdf Особенности масштабирования систем планирования и управления поставками (Михаил Антонов, ADD-2011).pdf Особенности масштабирования систем планирования и управления поставками (Михаил Антонов, ADD-2011).pdf Особенности масштабирования систем планирования и управления поставками (Михаил Антонов, ADD-2011).pdf Особенности масштабирования систем планирования и управления поставками (Михаил Антонов, ADD-2011).pdf Особенности масштабирования систем планирования и управления поставками (Михаил Антонов, ADD-2011).pdf Особенности масштабирования систем планирования и управления поставками (Михаил Антонов, ADD-2011).pdf Особенности масштабирования систем планирования и управления поставками (Михаил Антонов, ADD-2011).pdf Особенности масштабирования систем планирования и управления поставками (Михаил Антонов, ADD-2011).pdf Особенности масштабирования систем планирования и управления поставками (Михаил Антонов, ADD-2011).pdf Особенности масштабирования систем планирования и управления поставками (Михаил Антонов, ADD-2011).pdf Особенности масштабирования систем планирования и управления поставками (Михаил Антонов, ADD-2011).pdf Особенности масштабирования систем планирования и управления поставками (Михаил Антонов, ADD-2011).pdf Особенности масштабирования систем планирования и управления поставками (Михаил Антонов, ADD-2011).pdf Особенности масштабирования систем планирования и управления поставками (Михаил Антонов, ADD-2011).pdf Особенности масштабирования систем планирования и управления поставками (Михаил Антонов, ADD-2011).pdf Особенности масштабирования систем планирования и управления поставками (Михаил Антонов, ADD-2011).pdf Особенности масштабирования систем планирования и управления поставками (Михаил Антонов, ADD-2011).pdf Особенности масштабирования систем планирования и управления поставками (Михаил Антонов, ADD-2011).pdf

Примечания и отзывы

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

Что было? Было внимание ко мне и тому, что я говорил, со стороны присутствующих в зале, не было (кажется :)) людей, сидящих в первом ряду и втыкающих в нетбуки, айфоны и айпэды, было немало вроде бы искренне-заинтересованных вопросов после моего доклада. Было обсуждение на час-полтора в коридоре после выступления, на котором мы обсудили кучу интереснейших, но уже довольно узкоспециальных вещей (вроде оптимизации тяжелых баз данных на Oracle, бизнеса управления поставками, data mining-a, статистического анализа, бизнес-логики на Groovy и почему это не совсем маразм, и еще кучу всего). В итоге собрали неплохую такую кучку в кулуарах, даже из JetBrains некоторые ребята подтянулись послушать и пообщаться :) Были люди, подходившие ко мне после доклада, хлопавшие по плечу и говорившие — «чувак, ты реально зажег». Были, наконец, какие-то упоминания в паре блогов и в твиттере.

Тем подозрительнее тот факт, что особенной критики в свой я (пока) не слышал. Может, просто не натыкался еще, или критики мой доклад проигнорировали, и писать отзыв им стало лениво (а жаль…). В любой случае, конструктивной критике буду рад.

Сложновато из-за непривычки оказалось выступать в таком зале, говоря в микрофон с выходом на мощные фронтальные колонки. Первые несколько минут меня жутко сбивал с толку собственный голос, доносившийся с некоторым лагом, и я не мог себе представить, как меня слышат (или не слышат вовсе) сидящие в зале. Но потом вроде приноровился.

И тут же небольшое замечание. Я старался держаться на сцене энергичным и бодрым, а не как манакен с вмонтированным устройством для озвучки слайдов, но этому препятствовал в какой-то степени микрофон, который приходилось держать в руке близко к ротовому отверстию. Реально — радиогарнитура, прикручиваемая к голове был бы куда удобнее (с другой стороны, микрофон для многих докладчиков решает извечную проблему — куда же девать руки во время рассказа:))

А так — все было классно. Не считая некоторого волнения — получил искреннее удовольствие от выступления, от ответов на интересные, по существу, вопросы в конце и от общения с аудиторией. Надеюсь, она тоже свою порцию удовольствия получила :)

©

Михаил Антонов реально зажёг. Очень классный доклад. Даже захотелось заняться софтом для управления поставками :)).

©
Михаил Антонов про системы управления поставками, рассказывал хорошо, и область интересная, хотел бы я так рассказывать. ©
Название доклада Михаила Антонова не предвещало ничего интересного. Но неожиданно выступление оказалось очень собранным и по существу. Плюс внутренности слабо интерактивной системы, работающей с крупными массивами данных, ничуть не менее интересны, чем какой-нибудь распиаренный хайлоад. Отличная презентация. ©

  • Особенности масштабирования систем планирования и управления поставками (Михаил Антонов, ADD-2011)

То самое случайное 100 % попадание — компания делает почти то же, что и мы, только круче :) обслуживает крупные западные сети, планирует им поставки с помощью купленных библиотек с алгоритмами. Тоже используют этот дурацкий Oracle, который масштабировать настолько дорого, что проще перейти на MySQL, и кучу Java-серверов приложений, которые как раз добавить дешевле. Собственно, заказчики консервативные и это предпочитают тоже. И объёмы данных у них огромные. И библиотеки прогнозные только под винду.

По описанию доклада это был чисто наш кейс. Так и оказалось. Ребята из Самары автоматизируют процессы для крупных американских продуктовых ритейлеров. Тот же Oracle, те же сервера приложений (правда на Java). Тот же самописный ORM, те же сложные запросы, не укладывающиеся в ORM и написанные на голом SQL. Тот же ExtJS для веб-морды. В общем, мы явно идем в струе.

После оооочень долгого описания предметной области докладчик наконец-то перешел к техническим подробностям. Я сильно не вслушивался, так как в производительности Оракла не копенгаген, но нашим проектам, где Oracle хочется ускорить, может быть получится узнать что-то новое. Хотя, наверняка у нас примерно то же самое все и используется.

Из интересного — сервера приложений у них хоть и на Java, но все равно на Windows 2003 сервер, так как какие-то аналитические библиотеки доступны только как dll.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Note.svg В случае Спортмастера эта система как раз 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 * 109 = 50 миллиардов фактов продаж в финансовый год (почему-то длительность взяли в 500 дней).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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



Внимание! Данная статья выбрана для репликации во внешнюю базу знаний компании. Пожалуйста, не допускайте в этой статье публикацию конфиденциальной информации, ведения обсуждений в теле статьи, и более ответственно относитесь к качеству самой статьи — проверяйте орфографию, пишите по-русски, избегайте непроверенной вами информации.