00:00:06 Проблемы обработки данных цепей поставок и масштабируемость в терабайтах Lokad.
00:00:38 Улучшения в обработке данных Lokad за последний год.
00:01:33 Объяснение платформы Lokad и их собственного языка программирования Envision.
00:03:55 Сравнение Envision с другими языками программирования, такими как Python.
00:06:27 Основные идеи и прорывы, приведшие к улучшениям Lokad.
00:08:00 Табличное и колоночное хранение данных в базах данных и их эффективность.
00:10:36 Проблемы и затраты, связанные с обработкой больших объемов данных.
00:12:04 Влияние обработки терабайт данных на ученых в области цепей поставок и эффективность работы.
00:14:10 Реальные преимущества более быстрой обработки и работы с большими наборами данных.
00:15:30 Важность устранения граничных случаев и опасность длительных процессов в количественных инициативах в области цепей поставок.
00:17:43 Важность итеративного подхода к решению реальных проблем.
00:20:47 Проблемы и последствия обработки данных в масштабе цепей поставок.
00:21:10 Влияние масштабируемости в терабайтах на перспективы Lokad и будущее оптимизации цепей поставок.
00:24:41 Заключительные мысли и потенциальные пути для улучшения оптимизации цепей поставок.
Резюме
Киран Чандлер беседует с Жоаннесом Верморелем, основателем Lokad, о оптимизации цепей поставок и обработке больших объемов данных. Lokad увеличила свою производительность в 20 раз с 2017 года, используя свой специализированный язык программирования Envision для обработки данных в масштабе. Envision упрощает распределенные вычисления в контексте цепей поставок по сравнению с общими языками программирования. Улучшения Lokad сократили время обработки данных с часов до минут, позволяя специалистам по цепям поставок работать более эффективно. Верморел подчеркивает важность гибкости и итеративной оптимизации для успешных инициатив в области цепей поставок. Масштабируемость в терабайтах Lokad позволяет более глобально подходить к оптимизации, а планы по улучшению выразительности в скриптах Envision помогут лучше решать реальные проблемы в цепях поставок.
Расширенное резюме
В этом интервью ведущий Киран Чандлер обсуждает с основателем компании Lokad Жоаннесом Верморелем вопросы оптимизации цепей поставок. Они говорят о проблемах обработки огромных объемов данных в индустрии цепей поставок и о достижениях Lokad в области масштабируемости в терабайтах.
Жоаннес упоминает, что 2018 год стал годом масштабируемости для Lokad, и компания увеличила свою производительность в 20 раз по сравнению с предыдущим годом. Это улучшение позволило Lokad легко обрабатывать многотерабайтные наборы данных, учитывая текущее состояние технологий.
Компания достигла этого, разработав платформу Solocat, которая предназначена для оптимизации количественной цепи поставок. Платформа использует специализированный язык сценариев Lokad, называемый Envision. Envision разработан для решения конкретных задач цепи поставок и облегчения обработки данных в большом масштабе.
До 2018 года один сценарий Envision мог выполняться только на одной машине, хотя платформа могла содержать несколько терабайт данных. Компания реализовала некоторую степень масштабируемости, распределяя вычисления машинного обучения по нескольким машинам. Однако задачи, такие как сортировка данных, все еще ограничивались одной большой машиной.
В 2018 году Lokad представила полностью обновленную архитектуру для логики выполнения сценариев Envision на бэкэнде. Новая архитектура позволяет автоматическую параллелизацию на нескольких процессорах и даже на целых парках машин. В результате задачи, такие как сортировка данных, теперь могут выполняться намного быстрее с использованием вычислительной мощности десятков машин.
При сравнении Envision с общими языками программирования, такими как Python, Java, C++ и C#, Жоаннес объясняет, что Envision - это специализированный язык, разработанный для решения проблем цепи поставок. В то время как общие языки программирования предлагают возможность делать практически все, они часто требуют более сложных конфигураций и глубокого понимания конкретных библиотек и фреймворков для достижения распределенных вычислений.
Envision, с другой стороны, упрощает эти технические аспекты, упрощая обработку данных в большом масштабе и обработку больших объемов данных в контексте оптимизации цепи поставок. Такой специализированный подход позволяет Lokad улучшить масштабируемость и более эффективно обрабатывать терабайты данных по сравнению с использованием общих языков программирования.
Они обсуждают программное обеспечение компании, Envision, его преимущества и то, как недавние достижения улучшили аналитику цепи поставок.
Envision - это язык сценариев, специально разработанный для проблем цепи поставок, что делает его более простым и эффективным в использовании по сравнению с другими языками общего назначения. Он жертвует некоторой выразительностью ради простоты, но так как он фокусируется на конкретном типе проблем, такой компромисс является приемлемым. Верморель сравнивает простоту использования Envision с написанием сложных таблиц Excel с использованием средних значений, сортировок и поисков.
Год назад Lokad уже реализовала колоночный подход к хранению данных для аналитики больших данных, который более подходит для пакетной аналитики, а не для обработки в реальном времени. Этот подход хранит данные по столбцам, а не по строкам, что позволяет более эффективно обрабатывать операции, которые затрагивают только несколько столбцов. Однако недостатком является то, что добавление новых строк требует работы со всеми столбцами, что делает его менее эффективным для обработки в реальном времени.
Обсуждая затраты, связанные с обработкой больших объемов данных, Верморель подчеркивает, что самым дорогостоящим ресурсом является ученый по цепи поставок (или ученый по данным), так как они являются редкими, требуют специфических знаний и нуждаются в обширном обучении. В результате Lokad стремится оптимизировать использование времени этих ученых, сокращая время, затраченное на обработку данных.
Раньше обработка терабайтов данных занимала несколько часов, но недавние достижения сократили это время до нескольких минут. Это позволяет ученым по цепи поставок сосредоточиться на своих задачах и быстрее переходить к следующему шагу, а не ждать результатов. Однако это также означает, что у них меньше возможностей для перерывов.
Прорыв в обработке больших объемов данных более быстро имеет несколько практических преимуществ. Это позволяет компаниям более эффективно и эффективно анализировать и оптимизировать свои цепи поставок, в конечном итоге улучшая их общую деятельность.
Они обсуждают проблемы достижения оптимизации, важность гибкости и итеративный подход, необходимый для работы с реальными ситуациями.
Vermorel определяет основную опасность внедрения количественной инициативы цепочки поставок во времени, необходимом для совершенствования системы, поскольку важно обработать все крайние случаи, чтобы избежать ручного вмешательства. Чем дольше это займет, тем больше вероятность того, что проект столкнется с нарушениями, такими как обновления IT или ERP или резкие бизнес-трансформации, которые могут сделать предыдущую работу устаревшей.
Чтобы добиться успеха, инициативы по оптимизации цепочки поставок необходимо быстро внедрить в производство, что требует гибкости. Vermorel объясняет, что, хотя это может показаться многим на протяжении нескольких месяцев, слишком долгое время рискует неудачей проекта. Он подчеркивает итеративный подход к оптимизации, который необходим из-за непредсказуемой природы цепочек поставок и реальных ситуаций, которые могут сорвать числовые рецепты.
Итеративная оптимизация является неотъемлемой частью работы с бесконечным потоком сюрпризов, сопровождающих управление цепочкой поставок. Vermorel объясняет, что цепочки поставок являются сложными, включающими в себя несколько рынков, стран, поставщиков и линий продукции. Невозможно заранее обдумать и перечислить все потенциальные технические проблемы, поэтому гибкость крайне важна при исправлении числовых рецептов.
Затем Кирен спрашивает Вермореля о влиянии масштабируемости терабайт на Lokad и его перспективы на будущее. Верморель говорит, что компания сделала огромные улучшения в обработке масштабируемости, что открывает новые возможности для оптимизации цепочки поставок. Он уточняет, что масштабируемость не связана только с работой с крупными компаниями, но также с достижением оптимизации на уровне сети.
Vermorel подчеркивает, что истинная оптимизация требует рассмотрения всей сети как единого целого, а не оптимизации каждого магазина или поставщика в отдельности. Масштабируемость терабайт позволяет Lokad подходить к оптимизации более голистически, что в свою очередь помогает предотвратить проблемы, переносящиеся по цепочке поставок.
В будущем Lokad планирует использовать свои достижения в области масштабируемости для улучшения выразительности, что позволит более свободно и прямо отражать сложные реальные ситуации в их скриптах Envision. Это упростит разработку числовых рецептов, которые эффективно решают реальные ситуации в цепочке поставок.
Интервью завершается с акцентом Вермореля на важности гибкости, итеративной оптимизации и голистического подхода к управлению цепочкой поставок.
Полный текст
Кирен Чандлер: Сегодня на Lokad TV мы собираемся понять масштаб данных, которые управляются в рамках цепочки поставок, а также обсудить, как Lokad разработал масштабируемость терабайт для работы с ними. Итак, Джоаннес, сегодня мы немного поговорим о исследованиях и разработках, проведенных в Lokad в прошлом году. Над чем вы работали в 2018 году?
Джоаннес Верморель: 2018 год был для нас годом масштабируемости. Мы почти непрерывно работали в течение года над увеличением масштабируемости. По сравнению с тем же днем в прошлом январе мы увеличили нашу производительность практически в 20 раз, что позволяет нам относительно легко обрабатывать многотерабайтные наборы данных. Нет ничего такого, как легкая обработка терабайтов, учитывая существующую технологию, но это все равно можно сделать относительно просто.
Кирен Чандлер: Фактор 20 звучит как невероятное улучшение. Какие шаги вам пришлось предпринять, чтобы достичь этого улучшения?
Жоанн Верморель: Lokad - это платформа, разработанная для оптимизации цепочки поставок. Технически она доступна через скрипты, написанные на нашем собственном языке программирования под названием Envision. Этот язык разработан не только для удовлетворения потребностей оптимизации цепочки поставок, но и для облегчения обработки в большом масштабе. До прошлого года одна учетная запись для одного из наших клиентов могла содержать несколько терабайт данных, но один скрипт или кусок кода выполнялся на одной машине. У нас уже была реализована масштабируемость, поэтому идея состояла в том, чтобы распределить вычисления по множеству машин для конкретных компонентов, таких как машинное обучение. Однако, в общем, когда вы просто сортировали данные, это происходило на одной большой машине. В 2018 году мы представили полностью обновленную архитектуру для логики выполнения скриптов Envision на бэкэнде. В настоящее время у вас есть автоматическая параллелизация не только по нескольким процессорам и ЦПУ, но и по флоту машин. Это означает, что один скрипт, выполняющий простую операцию, такую как сортировка данных по дате, продукту, магазину или цене, может выполняться на десятках машин, что делает его намного быстрее.
Кирен Чандлер: Давайте немного поговорим о Envision. Как Envision помогает в достижении этих улучшений и улучшении масштабируемости по сравнению с работой с другими языками программирования, такими как Python или что-то в этом роде?
Жоанн Верморель: Envision - это язык программирования, специфичный для определенной области, в то время как Python, Java, C++ и C# - это общие языки программирования. С общим языком программирования вы получаете возможность делать практически все, но ценой, которую вам приходится платить, является то, что в программной среде возникают классы технических проблем. Например, вы можете выполнять распределенные вычисления с помощью Python, но вам нужно написать свой код таким образом, чтобы воспользоваться определенными библиотеками и фреймворками, чтобы эти вычисления происходили на флоте машин. Кроме того, вам придется самостоятельно настроить кластер машин, чтобы он мог выполнять эту распределенную логику. Если у вас есть несколько одновременно выполняющихся программ, которые выполняются на одном и том же кластере из-за разных скриптов или разных пользователей, это становится более сложным. Разные потребности… Ну, нам нужно иметь все необходимое для совместного использования ресурсов, таких как пропускная способность, диски, ЦПУ и так далее. И все это именно то, что делает Envision встроенным для вас. Таким образом, то, что вы теряете, - это много выразительности, что вполне нормально, потому что Envision может справиться. Он не сломан, несмотря на потерю множества выразительности, потому что мы специализируемся на конкретном типе проблем, которые, по сути, являются проблемами цепочки поставок. Так что мы не пытаемся решить каждую проблему. Мы не пытаемся написать движок для игры в шахматы или для 3D-моделирования. Он очень ориентирован на конкретные типы проблем.
Кирен Чандлер: Хорошо, то есть вы говорите, что использование Envision намного проще, чем использование другого языка программирования?
Жоанн Верморель: Именно так. Я имею в виду, написание скрипта, обрабатывающего таблицы, содержащие несколько миллиардов строк, для выполнения аналитики, которую вы ожидаете в контексте цепочки поставок, такой как оценка стоимости и влияния дефицита товара на большую сеть за последние три года, - это то, что вы можете сделать буквально десятью строками кода. Но код, который легко написать. Когда я говорю “легко написать”, я имею в виду, что написание кода никогда не так просто, но это не более сложно, чем, скажем, написание расширенной таблицы Excel, которая выполняет сложные средние значения, сложные сортировки и сложные поиски по данным.
Кирен Чандлер: Хорошо, а какие были некоторые ключевые идеи и прорывы, приведшие к этим улучшениям?
Жоанн Верморель: Чтобы понять, с чего мы начинали, год назад у Lokad уже было много компонентов больших данных. Один из них - это использование колоночного подхода к хранению данных. Короче говоря, традиционные SQL-базы данных используют табличное хранение. Это означает, что когда у вас есть таблица, вы храните строки данных, и если у вас есть строка, она находится вместе, и это ваша единица. Таким образом, табличные базы данных очень эффективны при выполнении небольших обновлений или чтении/записи строки за строкой.
В отличие от этого, за последние десятилетия, когда вы хотите провести большой анализ данных, был разработан колоночный подход. Таким образом, когда у вас есть таблица, допустим, у вас есть таблица с 20 столбцами, вы будете хранить данные упакованными по столбцам. Что это означает? Это означает, что когда вы выполняете операцию, например, “У меня есть цена за единицу, и у меня есть количество. Предположим, у вас есть таблица, представляющая историю продаж. Теперь вы хотите узнать общую сумму продаж, что вам нужно сделать? Вам нужно умножить цену на количество и просуммировать все это по всей таблице”. Хорошо, оказывается, что ваша таблица может иметь 20 столбцов, но операция, которую я только что описал, касается только двух столбцов. Поэтому, если у вас есть колоночное хранилище, главным преимуществом является то, что каждая операция, которая касается только нескольких столбцов, будет обработана, и остальное можно просто игнорировать. Если у вас есть табличный формат, другие столбцы все равно находятся в середине, и вы не можете их пропустить.
Но недостатком может быть то, что если вы добавляете дополнительные строки, если вы работаете в режиме реального времени, если у вас есть колоночный подход, если вы добавляете строку, вам придется работать со всеми столбцами.
Киран Чандлер: Таким образом, когда вы добавляете строку, вам приходится касаться 20 столбцов, что делает это относительно неэффективным. Колоночное хранение более подходит для пакетной аналитики, не совсем в режиме реального времени, но скорее для аналитики, которая вас интересует в сфере поставок. Его можно обновлять каждую минуту, но не каждую миллисекунду. Давайте немного поговорим о затратах, связанных с вычислительной мощностью и работой с большими объемами данных. Как внедрение масштабируемости в терабайты повлияло на затраты на работу с данными?
Жоанн Верморель: На самом деле, довольно много. Самые дорогостоящие ресурсы при оптимизации масштабной поставочной цепи - это ученые по поставочной цепи. Эти люди не бесплатны, и найти и обучить людей с нужными навыками - это вызов. Дефицитным ресурсом являются не ЦП, диски или пропускная способность, которые можно дешево создать на вашей любимой платформе облачных вычислений, а именно талантливые люди, которые должны работать над проблемой.
Когда вы входите в область обработки терабайтов, все замедляется. Обработка терабайта данных может занять довольно много времени, особенно если вы выполняете нетривиальные вычисления, включающие вероятностные расчеты с случайными переменными. Это может занять часы, но теперь это занимает минуты. Для ученых по поставочной цепи это означает, что они могут сосредоточиться на задаче, получить результаты и перейти к следующему, вместо того чтобы застрять в ожидании результатов. Так что, если что-то, это плохие новости для наших ученых по поставочной цепи, потому что у них будет меньше перерывов на кофе.
Киран Чандлер: Что это прорыв означает для реального мира? Очевидно, мы можем работать с гораздо большими наборами данных и делать это намного быстрее, но есть ли еще какие-то преимущества, которые мы видим?
Жоанн Верморель: Да, одна из ключевых опасностей или корневых причин неудачи количественных инициатив в сфере поставочной цепи - это время, которое требуется, чтобы все сделать правильно, чтобы все работало и было полностью отполировано, чтобы не было оставшихся крайних случаев. Благодаря возможности обрабатывать большие наборы данных быстрее мы теперь можем более эффективно решать эти проблемы, что в конечном итоге приводит к лучшим решениям в сфере поставочной цепи.
Кирен Чандлер: Ваши системы хороши, но все еще есть один человек, который остается полностью ручным. Для того, чтобы правильно обработать все крайние случаи, которые не обрабатываются должным образом, требуется много ресурсов для ручной обработки. Это в значительной степени противоречит цели использования передовой автоматизации машинного обучения для оптимизации. Опасность заключается в том, что процесс устранения всех крайних случаев, чтобы действительно улучшить числовые рецепты принятия решений, может занять слишком много времени.
Жоанн Верморель: Да, и эту задержку можно считать смертельной, потому что в какой-то момент люди перестают верить в успех инициативы. Если вы медленны, есть вероятность, что в середине проекта произойдет нарушение работы ИТ. Например, если ваш проект занимает два года, то существует одна третья вероятность, что в середине произойдет обновление ERP-системы. Вы начинаете оптимизировать поставочную цепь, а затем происходит массовое изменение в представлении компании. Большая часть проделанной работы рушится только потому, что все системы меняются.
Чем дольше вы ждете, тем больше вещей может нарушить ваш проект. Сам бизнес может претерпеть радикальные изменения, что делает вашу предыдущую работу устаревшей в свете новых изменений в бизнесе. Существует множество сил, оказывающих давление на быстрое внедрение продукта. Если вы не сможете добиться успеха в течение нескольких месяцев, есть вероятность, что ваша инициатива потерпит неудачу. Именно здесь абсолютно необходима гибкость.
Может показаться, что несколько месяцев - это много, но когда вы работаете с терабайтами данных и получение результата занимает часы, вы в основном настраиваете свои числовые рецепты раз или два в день в худшем случае. Все начинает замедляться.
Кирен Чандлер: Итак, то, о чем вы говорите, это своего рода итеративный подход к оптимизации поставочной цепи. Почему существует такой итеративный подход? Почему нельзя просто нажать одну кнопку, использовать глубокое обучение для обучения и получить хороший прогноз и хорошие результаты?
Жоанн Верморель: Реальность имеет свой путь препятствовать вам. Поставочная цепь на самом деле связана с работой с реальными контингентами. Существует так много крайних случаев, которые возникают из самой сути реальности. Например, вы начинаете вычислять идеальное количество для заказа, скажем, 80 единиц. Это лучшее количество для заказа, но палеты поставляются только нулевыми или 100 единицами, потому что они упакованы на палету. 80 не является вариантом, что же делать?
Есть десятки ситуаций подобных этой. Вы можете подумать, что стоимость вашего запаса постепенно снижается со временем, но это не так. Почему? Потому что есть срок годности с определенной датой. Когда вы достигаете предела срока годности, стоимость вашего запаса падает с какой-то суммы до нуля или даже становится отрицательной, потому что теперь вам приходится платить за утилизацию этого бесполезного запаса.
Реальность заключается в том, что поставочные цепи являются сложными. Если мы говорим о компаниях, которые работают на многих рынках, в нескольких странах, с множеством поставщиков, потенциально с десятками линий продуктов, возникает множество сложностей. Это мечтательное мышление полагать, что вы можете просто сесть в комнату и обсудить с командой все технические проблемы, которые возникнут в ходе инициативы. Вы не можете просто сказать… Сядьте с вашей командой поставочной цепи и скажите, давайте перечислим все мелочи, которые сорвут числовой рецепт, генерирующий оптимизированные решения в сфере поставочной цепи. Реальность, как всегда, имеет свой способ удивить вас, потому что вы обнаружите странные вещи, например, определенная страна имеет странный налог на что-то. Возвращаясь к вашему первоначальному вопросу об итеративном подходе, единственный способ справиться с этим бесконечным потоком сюрпризов - быть крайне гибкими в исправлении числового рецепта, когда вы сталкиваетесь с чем-то неожиданным.
Кирен Чандлер: Теперь давайте сосредоточимся на масштабируемости в терабайтах и начнем объединять все воедино. Что это изменяет для перспективы Lokad и что это означает для будущего?
Жоанн Верморель: Мы сделали огромные улучшения в области масштабируемости обработки. Это развитие открывает множество изменений, к которым ранее у нас не было доступа. Это не только о работе с крупными компаниями, есть много способов обмануть, например. Рассмотрим большую розничную сеть. Если ваш подход к оптимизации крупной розничной сети заключается в обработке каждого рынка в изоляции, и если у вас, скажем, 200 рынков, вам понадобится всего 200 машин, по одной на каждый рынок, и это будет масштабироваться. Но этот метод не приведет к улучшению цепочки поставок, которое вы ищете, потому что вы не оптимизируете на уровне сети. Вы локально оптимизируете каждый магазин в изоляции, полностью игнорируя то, что происходит в остальной сети.
Кирен Чандлер: То есть эти 200 машин не будут общаться друг с другом?
Жоанн Верморель: Именно. Если у вас есть независимые силосы, очень легко масштабировать вашу обработку. Но вызов состоит в том, когда вы начинаете думать о своей сети как о едином целом, где все связано. Вы можете фактически отправлять запасы и материалы по сети практически любым способом, который вам нравится. Хотя есть много способов, которые не являются прибыльными и не имеют смысла, это возможно. И некоторые из этих тонких способов могут быть очень хорошими и прибыльными идеями. Вам нужна система, которая может обрабатывать все сразу, монолитным образом. Что это означает для будущего? Это означает, что открываются множество возможностей для лучшей, всесторонней оптимизации. Проклятие оптимизации цепочки поставок заключается в том, что вы не решаете проблемы; вы просто перемещаете их. Вы можете посмотреть на одну область и оптимизировать ее, но все, что вы делаете, это передвигает проблему дальше по линии или обратно поставщику. Еще одна возможность заключается в том, что теперь, когда мы значительно улучшили масштабируемость, мы, вероятно, попытаемся вернуться к выразительности. В основном, мы стремимся более прямо и свободно выражать сложные ситуации, которые происходят в реальном мире, в этих скриптах Envision. Таким образом, легче доставлять числовые рецепты, которые хорошо подходят для решения реальных ситуаций.
Кирен Чандлер: Звучит замечательно. Мы должны закончить здесь, но спасибо за ваше время сегодня. Это все на этой неделе. Большое спасибо за просмотр, и увидимся в следующий раз. Пока!
