Содержание

Аннотация

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

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

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

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

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

Видео

Скачать
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 некоторые ребята подтянулись послушать и пообщаться :) Были люди, подходившие ко мне после доклада, хлопавшие по плечу и говорившие — «чувак, ты реально зажег». Были, наконец, какие-то упоминания в паре блогов и в твиттере.

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

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

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

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

©

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

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

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

ADD-2011: Отчёт Виталия Филиппова/Особенности масштабирования систем планирования и управления поставками

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

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

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

ADD 2011: Отчет Глеба Тарасова/Корпоративные приложения на Oracle

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

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

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

Особенности работы с заказчиком.

Система обеспечивает решение следующей задачи. Надо ежедневно получать данные о продажах, конвертировать, валидировать, загружать. Далее — обрабатывать, обеспечивая создание заказов и корректируя имеющиеся прогнозы, долгосрочный и краткосрочный. При этом время на обработку ограничено — после получения всех данных и до первой стадии бизнес-процесса обработки заказов, обычно на это 1-1.5 часа. А объемы данных большие, оценка — 2К маг * 50К товаров (продаж в день) * 500 дней = 50 млрд строк продаж. Реально 5-10 млрд.

Пользователей системы мало, десятки-сотни они эксперты в предметной области. И они наблюдают за процессом и тушат пожары. Обнаруживать и тушить надо быстро, для этого им надо быстро и наглядно представить данные.

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

Технологии.

Задачии оптимизации

Большие таблицы — Partitioning. Если пара таблиц имеет одинаковый partitioning, то join это учитывает.

Загрузка — SQL*loader, с использованием различных ускоряющих приемов.

Оптимизация запросов по планам решения. Реально оптимизатор — улучшается. Сейчас они удаляют хинты, написанные 3-4 года назад.

Oracle Grid Control. Вкладки мониторинга запросов — он показывает еще и динамический план: сколько записей в запросе и столько он уже вытащил. И известный способ — трассировка sql_trace, tkprof.

Оптимизация пользовательского интерфейса

Пакетная обработка — цепочка engines. Масштабы впечатляют — 10К одновременных тасков, 2M всего в таблице. И это — наиболее критичная задача.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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



Любые правки этой статьи будут перезаписаны при следующем сеансе репликации. Если у вас есть серьезное замечание по тексту статьи, запишите его в раздел «discussion».

Репликация: База Знаний «Заказных Информ Систем» → «Особенности масштабирования систем планирования и управления поставками (Михаил Антонов, ADD-2011)»