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 Заключительные мысли и возможные пути улучшения оптимизации цепей поставок.
Резюме
Kieran Chandler интервьюирует Joannes Vermorel, основателя Lokad, о оптимизации цепей поставок и обработке огромных наборов данных. Lokad увеличил свою вычислительную мощность в 20 раз с 2017 года, используя их предметно-ориентированный язык Envision для масштабной обработки данных. Envision упрощает распределённые вычисления в контексте цепей поставок по сравнению с универсальными языками программирования. Достижения Lokad позволили сократить время обработки данных с часов до минут, что позволяет специалистам по цепям поставок работать более эффективно. Vermorel подчёркивает важность гибкости и итеративной оптимизации для успешных инициатив в области оптимизации цепей поставок. Терабайтовая масштабируемость Lokad обеспечивает более целостный подход к оптимизации и планы по повышению выразительности Envision-скриптов для более точного отражения реальных условий цепей поставок.
Расширенное резюме
В этом интервью ведущий Kieran Chandler обсуждает с Joannes Vermorel, основателем Lokad — компании, специализирующейся на оптимизации цепей поставок, проблемы, связанные с обработкой огромного объёма данных в отрасли цепей поставок, и достижения Lokad в области терабайтовой масштабируемости.
Joannes отмечает, что 2018 год стал годом масштабируемости для Lokad: компания увеличила свою вычислительную мощность в 20 раз по сравнению с прошлым годом. Это улучшение позволило Lokad с относительной лёгкостью обрабатывать наборы данных размером в несколько терабайт, учитывая современное состояние технологий.
Компания достигла этого, разработав платформу Solocat, предназначенную для количественной оптимизации цепей поставок. Платформа использует предметно-ориентированный скриптовый язык Lokad под названием Envision. Envision создан для удовлетворения специфических потребностей задач цепей поставок и для облегчения масштабной обработки данных.
До 2018 года один скрипт Envision мог выполняться только на одной машине, даже если платформа могла хранить несколько терабайт данных. Компания реализовала некий уровень масштабируемости, распределяя вычисления для машинного обучения между несколькими машинами. Однако задачи, такие как сортировка данных, всё ещё выполнялись на одной мощной машине.
В 2018 году Lokad внедрил полностью обновлённую архитектуру для серверной логики исполнения скриптов Envision. Новая архитектура обеспечивает автоматическую параллелизацию на нескольких процессорах и даже на целых кластерах машин. В результате задачи, такие как сортировка данных, теперь могут выполняться намного быстрее благодаря использованию вычислительных мощностей десятков машин.
При сравнении Envision с универсальными языками программирования, такими как Python, Java, C++ и C#, Joannes объясняет, что Envision — это предметно-ориентированный язык, созданный для решения задач цепей поставок. В то время как универсальные языки предоставляют почти безграничные возможности, они часто требуют более сложных настроек и глубокого понимания специфических библиотек и фреймворков для реализации распределённых вычислений.
Envision, с другой стороны, упрощает эти технические моменты, что облегчает работу с распределёнными вычислениями и обработку масштабных наборов данных в контексте оптимизации цепей поставок. Такой специализированный подход позволяет Lokad повышать масштабируемость и эффективнее работать с терабайтами данных по сравнению с универсальными языками программирования.
Они обсуждают программное обеспечение компании, Envision, его преимущества и то, как недавние достижения улучшили аналитику цепей поставок.
Envision — это скриптовый язык, специально разработанный для задач цепей поставок, что делает его использование проще и эффективнее, чем языки общего назначения. Он жертвует некоторой выразительностью ради простоты, но, поскольку он ориентирован на конкретный тип задач, этот компромисс оправдан. Vermorel сравнивает лёгкость использования Envision с созданием продвинутых таблиц Excel, выполняющих сложные вычисления, сортировки и поиск.
Год назад Lokad уже внедрил колонный способ хранения данных для аналитики больших данных, который больше подходит для пакетной обработки, а не для работы в реальном времени. Этот подход хранит данные по столбцам, а не по строкам, что позволяет эффективнее обрабатывать операции, затрагивающие лишь несколько столбцов. Однако недостатком является то, что добавление новых строк требует обработки каждого столбца, что делает его менее эффективным для обработки в реальном времени.
Обсуждая затраты, связанные с обработкой большого объёма данных, Vermorel подчёркивает, что самым дорогим ресурсом является специалист по цепям поставок (или data scientist), так как их мало, они требуют специфических знаний и обширной подготовки. В результате Lokad стремится оптимизировать использование их времени за счёт сокращения времени, затрачиваемого на обработку данных.
Ранее обработка терабайт данных занимала часы, но недавние достижения сократили это время до минут. Это позволяет специалистам по цепям поставок сосредоточиться на своих задачах и быстрее переходить к следующему этапу, а не ждать результатов. Однако это также означает, что у них меньше возможностей для перерывов.
Прорыв в быстрой обработке больших наборов данных имеет несколько практических преимуществ. Это позволяет компаниям более эффективно анализировать и оптимизировать свои цепи поставок, что в конечном итоге улучшает их общую работу.
Они обсуждают проблемы достижения оптимизации, важность гибкости и итеративного подхода, необходимого для решения практических непредвиденных ситуаций.
Vermorel определяет основную опасность при реализации количественной инициативы в области цепей поставок как длительность времени, необходимую для доведения системы до совершенства, поскольку крайне важно учесть все крайние случаи, чтобы избежать ручного вмешательства. Чем дольше это занимает, тем выше вероятность, что проект столкнется с сбоями, такими как обновления IT или ERP, либо с кардинальными бизнес-трансформациями, которые могут сделать предыдущую работу устаревшей.
Чтобы добиться успеха, инициативы по оптимизации цепей поставок нужно быстро вводить в эксплуатацию, что требует гибкости. Vermorel объясняет, что, хотя может показаться, что за несколько месяцев можно сделать многое, слишком долгий процесс рискует провалом проекта. Он подчёркивает итеративный подход к оптимизации, который необходим из-за непредсказуемости цепей поставок и практических непредвиденных обстоятельств, способных сорвать числовые рецепты.
Итеративная оптимизация необходима для управления бесконечным потоком неожиданных ситуаций, связанных с управлением цепями поставок. Vermorel объясняет, что цепи поставок представляют собой комплексные системы, включающие несколько рынков, стран, поставщиков и продуктовых линеек. Невозможно заранее предугадать и перечислить все потенциальные технические проблемы, поэтому гибкость имеет решающее значение при корректировке числовых рецептов.
Затем Kieran спрашивает Vermorel о влиянии терабайтовой масштабируемости на Lokad и её перспективах. Vermorel утверждает, что компания достигла невероятных улучшений в обработке масштабируемости, что открывает новые возможности для оптимизации цепей поставок. Он поясняет, что масштабируемость касается не только работы с более крупными компаниями, но и достижения оптимизации на уровне сети.
Vermorel подчёркивает, что настоящая оптимизация требует рассмотрения всей сети как единого целого, а не оптимизации каждого магазина или поставщика по отдельности. Терабайтовая масштабируемость позволяет Lokad подходить к оптимизации более целостно, что, в свою очередь, помогает предотвратить перемещение проблем вниз по цепи поставок.
В будущем Lokad планирует использовать достижения в области масштабируемости для повышения выразительности, что позволит создавать более гибкие и прямые способы отражения сложных реальных ситуаций в их скриптах Envision. Это упростит разработку числовых рецептов, эффективно решающих реальные задачи цепей поставок.
Интервью завершается тем, что Vermorel подчёркивает важность гибкости, итеративной оптимизации и целостного подхода к управлению цепями поставок.
Полная транскрипция
Kieran Chandler: Сегодня на Lokad TV мы собираемся понять огромные объёмы данных, которыми управляет цепь поставок, а также обсудить, как Lokad разработал терабайтовую масштабируемость для работы с ними. Итак, Joannes, сегодня мы поговорим немного о исследованиях и разработках, проведённых в Lokad за последний год. Над чем вы работали в 2018 году?
Joannes Vermorel: 2018 год стал для нас годом масштабируемости. Мы практически непрерывно работали в течение года над увеличением масштабируемости. По сравнению с тем же числом в прошлом январе, мы увеличили нашу вычислительную мощность примерно в 20 раз, что позволяет нам с относительной лёгкостью обрабатывать наборы данных размером в несколько терабайт. Простая обработка терабайт данных невозможна, учитывая текущее состояние технологий, но её можно сделать относительно простой.
Kieran Chandler: Фактор 20 звучит как невероятно значимое улучшение. Какие шаги вам пришлось предпринять для достижения этого улучшения?
Joannes Vermorel: Lokad — это платформа, предназначенная для оптимизации цепей поставок. Технически, она доступна через скрипты, написанные на нашем собственном самодельном скриптовом языке под названием Envision. Этот язык разработан не только для того, чтобы специально решать задачи оптимизации цепей поставок, но и для облегчения масштабной обработки данных. До прошлого года один аккаунт одного из наших клиентов мог содержать несколько терабайт данных, но один скрипт или фрагмент кода выполнялся на одной машине. Мы уже внедрили масштабирование, поэтому идея состояла в том, чтобы распределять вычисления по многим машинам для таких задач, как машинное обучение. Однако, в общих чертах, когда речь шла просто о сортировке данных, это происходило на одной мощной машине. В 2018 году мы запустили полностью обновлённую архитектуру для серверной логики исполнения скриптов Envision. Сегодня у вас есть автоматическая параллелизация не только на нескольких процессорах и CPU, но и на целом парке машин. Это означает, что один скрипт, выполняющий простую операцию, такую как сортировка данных по дате, продукту, магазину или цене, может выполняться на десятках машин, благодаря чему процесс становится намного быстрее.
Kieran Chandler: Давайте поговорим немного об Envision. Как Envision способствует этим улучшениям и повышению масштабируемости по сравнению с использованием других языков программирования, таких как Python или подобное?
Joannes Vermorel: Envision — это предметно-ориентированный язык программирования, в то время как Python, Java, C++, и C# — универсальные языки программирования. Универсальный язык предоставляет возможность делать практически всё, но за это приходится платить: в среду программирования проникают определённые технические нюансы. Например, на Python можно реализовать распределённые вычисления, но для этого нужно писать код так, чтобы использовать конкретные библиотеки и фреймворки, позволяющие выполнять вычисления на кластере машин. Кроме того, вам придётся самостоятельно настраивать кластер машин для выполнения этой распределённой логики. Если у вас одновременно работают несколько программ на одном кластере из-за различных скриптов или разных пользователей, ситуация становится сложнее. Разные требования… Ну, нужно обеспечить всю необходимую инфраструктуру для совместного использования ресурсов — пропускную способность, диски, CPU и тому подобное. Именно это Envision и делает для вас встроенным способом. Так что, что вы теряете? Вы теряете значительную часть выразительности, что устраивает, поскольку, повторюсь, Envision способен работать. Он не ломается, несмотря на потерю части выразительности, потому что мы специализируемся на конкретном типе задач, а именно на задачах цепей поставок. Мы не пытаемся решить каждую проблему. Мы не пытаемся написать движок для игры в шахматы или для 3D-моделирования. Он ориентирован на конкретные типы задач.
Kieran Chandler: То есть, вы говорите, что использовать Envision намного проще, чем другие языки программирования?
Joannes Vermorel: Именно. Написание скрипта, который обрабатывает таблицы, содержащие несколько миллиардов строк, для проведения аналитики, ожидаемой в контексте цепей поставок — например, оценки затрат и влияния дефицита товара по большой сети за последние три года — можно сделать буквально в несколько десятков строк кода. И код оказывается лёгким. Когда я говорю, что его легко написать, я имею в виду, что написать код никогда не бывает очень просто, но он не сложнее, чем, скажем, создание продвинутой Excel-таблицы, выполняющей сложные вычисления, сортировки и поиск по данным.
Kieran Chandler: Ладно, а каковы были ключевые идеи и прорывы, приведшие к этим улучшениям?
Joannes Vermorel: Чтобы понять, с чего мы начали, год назад у Lokad уже было множество компонентов для работы с большими данными. Одним из них был столбцовый подход к хранению данных. Короче говоря, традиционные SQL базы данных используют табличное хранение. Это означает, что когда у вас есть таблица, вы храните строки данных, и если у вас есть строка, она хранится как единое целое, и это и есть ваша единица. По сути, это делает табличные базы данных очень эффективными для выполнения небольших обновлений или операций чтения/записи построчно.
В противоположность этому, за последние десятилетия, когда вы хотите проводить анализ больших данных, был разработан столбцовый подход. Иначе говоря, если у вас есть таблица с, скажем, 20 столбцами, данные будут храниться по столбцам. Что это означает? Это значит, что при выполнении операции, например: «У меня есть цена за единицу и количество. Пусть у вас есть таблица, представляющая историю продаж. Теперь вы хотите узнать общий объем продаж, поэтому нужно умножить цену на количество и сложить результаты по всей таблице». Оказывается, в вашей таблице может быть 20 столбцов, но описанная мной операция затрагивает всего два столбца. Таким образом, если у вас столбцовое хранение, главное преимущество в том, что обрабатываются только те столбцы, которые участвуют в операции, а остальные можно просто игнорировать. При табличном формате другие столбцы остаются в расчете и не могут быть просто пропущены.
Но недостаток может заключаться в том, что если вы добавляете новые строки, особенно при работе в режиме реального времени со столбцовым подходом, при добавлении строки вам придется обрабатывать каждый столбец.
Kieran Chandler: То есть, при добавлении строки приходится задевать 20 столбцов, что делает операцию относительно неэффективной. Столбцовое хранение больше подходит для пакетного анализа, а не для работы в режиме реального времени, хотя именно такой анализ вам интересен для цепочки поставок. Оно может обновляться каждую минуту, но не каждую миллисекунду. Давайте поговорим немного о затратах, связанных с вычислительной мощностью и обработкой больших объемов данных. Как внедрение масштабируемости до терабайта повлияло на затраты на работу с данными?
Joannes Vermorel: На самом деле, довольно сильно. Самые дорогостоящие ресурсы при оптимизации масштабной цепочки поставок — это специалисты по логистике и цепочкам поставок. Эти люди не даны бесплатно, и найти, а затем обучить специалистов с нужными навыками — непростая задача. Дефицитный ресурс — это не процессоры, диски или пропускная способность, которые можно недорого взять у вашей любимой облачной платформы, а талантливые люди, которые будут работать над решением проблемы.
Когда вы возвращаетесь в область обработки терабайт данных, всё становится медленным. Анализировать терабайт данных может занимать довольно много времени, особенно если вы выполняете нетривиальные вычисления с участием вероятностных расчетов со случайными величинами. Раньше это могло занимать часы, а теперь — минуты. Для специалистов по цепочке поставок это означает, что они могут сосредоточиться на задаче, получить результаты и перейти к следующей работе, вместо того чтобы застревать в ожидании результатов. Таким образом, для наших специалистов по цепочке поставок это, если что, плохая новость, так как у них становится меньше перерывов на кофе.
Kieran Chandler: Что этот прорыв означает для реального мира? Очевидно, что теперь мы можем работать с гораздо большими наборами данных и обрабатывать их намного быстрее, но есть ли ещё какие-то преимущества?
Joannes Vermorel: Да, одной из ключевых опасностей, или первопричин провала количественных инициатив в цепочке поставок, является время, необходимое для доведения системы до совершенства, чтобы она работала корректно и была полностью отполирована, без оставшихся нерешённых крайних случаев. Благодаря возможности быстрого анализа больших объемов данных, мы можем теперь решать эти задачи более эффективно, что в конечном итоге приводит к принятию лучших решений в управлении цепочкой поставок.
Kieran Chandler: Ваши системы хороши, но всё же остается один человек, который работает вручную. Это требует больших людских ресурсов для того, чтобы вручную прорабатывать все крайние случаи, которые не обрабатываются должным образом. Это несколько сводит на нет смысл наличия продвинутой автоматизации оптимизации на основе машинного обучения. Опасность заключается в том, что процесс устранения всех крайних случаев, для того чтобы действительно улучшить числовой алгоритм принятия решений, может затянуться.
Joannes Vermorel: Да, и эта задержка смертельна, потому что в какой-то момент люди теряют веру в успех инициативы. Если вы медлите, есть вероятность, что в процессе произойдут сбои в IT. Например, если ваш проект занимает два года, существует вероятность 1 к 3, что посреди него произойдет обновление ERP-системы. Вы начинаете оптимизировать цепочку поставок, а затем внутри компании происходит кардинальное изменение концепции. Большая часть проделанной работы разваливается, просто потому что все системы меняются.
Чем дольше вы ждёте, тем больше факторов может нарушить ход проекта. Сам бизнес может претерпеть драматические трансформации, делающие вашу предыдущую работу устаревшей в свете новых изменений. Существует множество движущих сил, оказывающих давление на быстрое выведение продукта на рынок. Если вам не удастся добиться успеха за несколько месяцев, велика вероятность, что ваша инициатива провалится. Именно здесь абсолютная гибкость становится необходимой.
Это может показаться много — пару месяцев, но когда вы работаете с терабайтами данных, и получение результата занимает часы, вы по сути корректируете свои числовые алгоритмы максимум один-два раза в день. Всё начинает двигаться очень медленно.
Kieran Chandler: Итак, вы затрагиваете итеративный подход к оптимизации цепочки поставок. Почему именно итеративный подход? Почему нельзя просто нажать кнопку, использовать глубокое обучение для обучения и получить хороший прогноз и отличные результаты?
Joannes Vermorel: Реальность всегда встает у вас на пути. Цепочка поставок — это, прежде всего, умение справляться с реальными непредвиденными обстоятельствами. Существует так много крайних случаев, которые вытекают из самой природы реальности. Например, вы начинаете вычислять идеальное количество для заказа, скажем, 80 единиц. Это оптимальное количество для заказа, но поддоны поставляются только с 0 или 100 единицами, так как они упакованы на поддон. 80 не является вариантом, так что вы делаете?
Таких ситуаций десятки. Вы можете подумать, что ценность вашего инвентаря постепенно снижается с течением времени, но это не так. Почему? Потому что существует срок годности с конкретной датой. Когда вы достигаете предела срока годности, стоимость запасов падает от какого-то значения до нуля или даже становится отрицательной, поскольку теперь вам приходится платить за утилизацию этого бесполезного товара.
Реальность такова, что цепочки поставок сложны. Если говорить о компаниях, работающих на многих рынках, в нескольких странах, с множеством поставщиков и, возможно, с десятками продуктовых линий, существует масса сложностей. Наивно думать, что можно просто сесть в комнате и устроить мозговой штурм с командой, чтобы перечислить все технические проблемы, которые возникнут в ходе реализации инициатив. Вы не можете просто сказать: «Соберитесь с вашей командой по цепочке поставок и составьте список всех мелких деталей, которые могут сорвать числовой алгоритм, генерирующий оптимизированные решения». Реальность, как всегда, умеет удивлять, ведь вы столкнетесь с причудливыми вещами, например, с тем, что в какой-то стране существует странный налог на что-либо. Возвращаясь к вашему первоначальному вопросу об итеративном подходе, единственный способ справиться с этим бесконечным потоком сюрпризов — быть чрезвычайно гибкими при корректировке числового алгоритма, когда вы сталкиваетесь с чем-то неожиданным.
Kieran Chandler: Теперь давайте сосредоточимся на масштабируемости до терабайта и подведем итоги. Как это меняет перспективы Lokad и что это значит для будущего?
Joannes Vermorel: Мы достигли колоссальных улучшений в обработке масштабируемости. Это развитие открывает множество возможностей, которые ранее были недоступны. Дело не только в работе с крупными компаниями; существует множество способов обойти ограничения, например, рассмотрите крупную розничную сеть. Если ваш подход к оптимизации масштабной розничной сети заключается в обработке каждого рынка изолированно, и если у вас, скажем, 200 рынков, вам понадобится всего 200 машин — по одной на каждый рынок, и это масштабируется. Но такой метод не принесет того улучшения цепочки поставок, к которому вы стремитесь, поскольку вы не оптимизируете на уровне всей сети. Вы локально оптимизируете каждый магазин, работая изолированно, полностью игнорируя то, что происходит в остальной части сети.
Kieran Chandler: То есть эти 200 машин не будут общаться друг с другом?
Joannes Vermorel: Точно. Если у вас есть независимые силосы, масштабировать обработку очень просто. Но сложность возникает, когда вы начинаете рассматривать всю сеть как единое целое, где всё связано. Вы можете перемещать запасы и материалы по сети практически любым доступным способом. Хотя существует множество способов, которые не приносят прибыли и не имеют смысла, это возможно. И некоторые из этих тонких подходов могут оказаться очень хорошими и прибыльными. Вам нужна система, способная обрабатывать всё одновременно, в монолитном режиме. Что это означает для будущего? Это открывает массу возможностей для более качественной, целостной оптимизации. Проклятие оптимизации цепочки поставок состоит в том, что вы не решаете проблему, а лишь перемещаете её. Вы можете взять одну область и оптимизировать её, но по сути, просто смещаете проблему вниз по цепочке или обратно к поставщику. Другой путь заключается в том, что теперь, когда мы значительно повысили масштабируемость, мы, вероятно, попробуем вернуться к выразительности. По существу, мы стремимся более непосредственно и плавно выражать сложные ситуации, происходящие в реальном мире, в скриптах Envision. Таким образом, становится проще создавать числовые алгоритмы, которые лучше подходят для решения реальных задач.
Kieran Chandler: Звучит отлично. Нам придётся на этом остановиться, но спасибо за уделенное сегодня время. Это всё на эту неделю. Большое спасибо за просмотр, и до встречи в следующий раз. Пока!
