Бережливая масштабируемая обработка для цепочек поставок

Joannes Vermorel

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

В Lokad мы не взимаем с клиентов оплату за гигабайт хранения или за один процессорный час. Вместо этого основным фактором формирования наших цен при выборе наших профессиональных услуг является сложность самой задачи в области цепочек поставок. Конечно, мы учитываем затраты на вычислительные ресурсы, необходимые для обслуживания наших клиентов, но в конечном итоге каждый евро, потраченный на Microsoft Azure — расход, благодаря которому мы стали «настоящим» корпоративным клиентом — это евро, которые мы не можем инвестировать в НИОКР или в Специалиста по цепям поставок, ведущего этот проект.

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

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

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

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

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

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

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