Масштабируемая обработка для цепей поставок

Joannes Vermorel

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

В Lokad мы не взимаем плату у наших клиентов за гигабайты хранилища или за использование процессора в час. Вместо этого, основным фактором нашей ценообразования, когда клиенты выбирают наши профессиональные услуги, является сложность задачи по управлению цепями поставок, которую необходимо решить. Естественно, мы учитываем вычислительные ресурсы, которые нам необходимы для обслуживания наших клиентов, но в конечном итоге каждый евро, который мы тратим на Microsoft Azure - мы стали “настоящим” корпоративным клиентом - это евро, которое мы не можем потратить на исследования и разработку или на специалиста по цепям поставок, который заботится о клиенте.

Таким образом, платформа Lokad была разработана с принципом максимальной экономии вычислительных ресурсов¹. Задача не заключается в обработке 1 ТБ данных - что просто - а в обработке 1 ТБ данных как можно дешевле. Это привело нас к ряду несколько “необычных” решений при разработке Lokad.

Графы выполнения diff. Специалисты по цепям поставок, как и другие специалисты по обработке данных, обычно не пишут сотни строк кода сразу, прежде чем проверить свой код на данных. Процесс обычно является инкрементным: добавить несколько строк, обработать данные, повторить. Эти итерации необходимы, так как результаты, полученные из данных, часто указывают, что будет делать специалист по обработке данных дальше. Однако большинство инструментов для обработки данных (например, NumPy или R) будут пересчитывать все с нуля при каждом повторном выполнении скрипта. В отличие от этого, Envision выполняет diff между последовательными графами выполнения. В отличие от традиционного diff, который находит различия между файлами, наш diff находит различия между графами вычислений: diff определяет новые узлы вычислений, которые все еще нужно вычислить. Для всех остальных узлов результаты уже были вычислены и “перерабатываются”. Для специалиста по цепям поставок сравнение графов выполнения выглядит как очень быстрый запуск, где терабайты данных обрабатываются за считанные секунды (подсказка: Lokad не обрабатывает терабайты за секунды, только несколько сотен мегабайт, которые отличаются от одного скрипта к другому).

Типы данных, ориентированные на домен. Вероятностное прогнозирование - это подход, который меняет игру в области цепей поставок: давайте рассмотрим все возможные будущие события, а не выбираем одно будущее, как если бы оно было гарантировано. К сожалению, обработка вероятностных распределений требует алгебры распределений, которая включает в себя нетривиальные вычисления. Поэтому мы приложили значительные усилия для оптимизации этой алгебры с целью выполнения операций большого масштаба над случайными величинами с минимальными затратами процессора. В частности, мы активно учитываем тот факт, что в цепях поставок большинство случайных величин представляют вероятность в небольших количествах, обычно не более нескольких десятков единиц². По сравнению с общими подходами, предназначенными, скажем, для научных вычислений, доменно-ориентированный подход дает ускорение вычислений на два порядка.

Защитная масштабируемость. Большинство языков программирования, предназначенных для обработки данных большого масштаба (например, Scala или Julia), предлагают огромные возможности для распределения вычислений по множеству узлов. Однако это означает, что каждая строка кода, написанная, может потреблять произвольно большое количество вычислительных ресурсов. Для противодействия все более возрастающим потребностям приложения при внесении изменений в приложение требуется много инженерной дисциплины. В отличие от этого, Envision занимает защитную позицию: язык был создан таким образом, чтобы отпугнуть Supply Chain Scientists от написания кода, который был бы чрезвычайно дорог в масштабировании. Это объясняет, почему Envision не имеет циклов, например, так как практически невозможно предложить предсказуемую производительность во время компиляции, когда язык содержит произвольные циклы.

Только хранение ключ-значение. Хранение блобов³ - самый простой и экономичный подход к хранению данных, предлагаемый в облаке, с ценами, которые могут быть такими низкими, как $20 за ТБ в месяц или около того. Lokad работает напрямую с хранилищем блобов (плюс локальные диски для кэша), у нас нет никаких реляционных баз данных или NoSQL - за исключением тех, которые мы сами создали поверх хранилища блобов. На практике наш уровень хранения глубоко интегрирован с Envision, языком, посвященным оптимизации Количественной Цепи Поставок в Lokad. Это позволяет нам избежать слоев накладных расходов, которые традиционно существуют на пересечении между приложением и его уровнем доступа к данным. Вместо микрооптимизации трения на границах мы удалили эти границы полностью.

Хотя достижение эффективной масштабируемости обработки данных для вашей цепи поставок может показаться “технической” задачей для крупных цепей поставок, ИТ-накладные расходы на обработку терабайтов данных реальны. Слишком часто система либо слишком дорогая, либо слишком медленная, и трение в конечном итоге поглощает значительную часть предполагаемых преимуществ, создаваемых системой в первую очередь. Затраты на облачные вычисления по-прежнему снижаются, но не ожидайте больше 20% в год, поэтому позволить общему прогрессу вычислительного оборудования сделать свою магию больше не является вариантом, если вы не готовы отложить свою данных-ориентированную цепь поставок еще на десятилетие или около того.

Вы также можете посмотреть эпизод Lokad TV, который мы сняли о масштабируемости в терабайтах для цепей поставок.