Исследование данных в реальном времени с помощью срезов
Два месяца назад мы представили значительную новую функцию для Lokad: наш первый шаг в направлении исследования данных в реальном времени. Эта функция имеет кодовое имя dashboard slicing, и для её реализации нам пришлось полностью переработать низкоуровневую систему обработки данных, обеспечивающую работу Envision. С dashboard slices каждый дашборд превращается в полноценный справочник видов дашбордов, которые можно исследовать в режиме реального времени с помощью строки поиска.
Например, путем разрезания дашборда, предназначенного для инспекции продукта, который собирает в одном месте всю информацию о продукте — включая, например, вероятностный прогноз спроса и срок поставки — теперь можно переключаться в реальном времени с одного продукта на другой.

В настоящее время Lokad поддерживает до 200,000 slices (то есть видов дашборда), которые можно создать для одного дашборда; и эти срезы могут отображаться в реальном времени через селектор, оснащённый функцией быстрого поиска для облегчения исследования данных. В отличие от инструментов business intelligence (BI), эти срезы могут содержать весьма сложные вычисления, а не просто slice-and-dice операций над кубом OLAP.

Когда речь идёт об анализе данных и составлении отчётов, обычно выделяют два направления: онлайн-обработку и пакетную обработку. Онлайн-обработка принимает поток данных, и обычно ожидается, что всё, что отображается системой, всегда актуально: система отстаёт не более чем на несколько минут, а иногда и на несколько секунд от реального времени. Кубы OLAP и большинство инструментов, именуемых business intelligence, относятся к этой категории. Хотя аналитика в режиме реального времени 1 крайне желательна не только с точки зрения бизнеса (актуальные данные лучше устаревших), но и с точки зрения конечного пользователя (производительность – это функция), она также имеет строгие ограничения. Проще говоря, предоставить умную аналитику в реальном времени2 чрезвычайно сложно. В результате все онлайн-системы аналитики имеют серьезные ограничения в том типе аналитики, которую они могут выполнять.
С другой стороны, пакетная обработка обычно выполняется по расписанию (например, ежедневными запусками), при этом загружается вся историческая информация (или её значительная часть). Актуальность результатов ограничена частотой обновлений: ежедневная партия всегда предоставляет данные, отражающие ситуацию прошлого дня, а не текущую ситуацию. Поскольку все данные доступны с самого начала, пакетная обработка идеально подходит для проведения различных вычислительных оптимизаций, которые могут значительно повысить общую производительность процесса. В результате, благодаря пакетной обработке можно выполнять целые классы сложных вычислений, которые недоступны при онлайн-обработке. Кроме того, с точки зрения IT, пакетная обработка обычно гораздо проще в реализации и эксплуатации 3. Основной недостаток пакетной обработки заключается в задержке, присущей пакетному характеру процесса.
Как программная платформа, Lokad однозначно относится к направлению пакетной обработки. Действительно, хотя оптимизация Quantitative Supply Chain требует высокой оперативности, существует множество решений, которые не требуют мгновенной реакции, например, решение о производстве дополнительного поддона продукции или о снижении цены для быстрой распродажи запасов. Для этих решений важнее всего принять наилучшее возможное решение, и если его можно существенно улучшить, затратив ещё один час вычислений, то почти гарантировано, что этот дополнительный час работы компьютера окажется выгодной инвестицией 4.
Таким образом, Envision разработан с учётом пакетной обработки. У нас в запасе немало приемов для того, чтобы Envision оставался очень быстрым даже при обработке терабайтов данных; но в таких масштабах речь идёт о получении результатов в течение нескольких минут, а не менее чем за секунду. Фактически, из-за высокораспределённой природы вычислительной модели Envision, для Lokad является сложной задача завершить выполнение любого сценария Envision менее чем за 5 секунд — даже когда задействовано всего несколько мегабайт данных. Чем более распределённая система, тем больше внутренней инерции для синхронизации всех её частей. Больше масштабируемости — враг меньшей задержки.
Несколько лет назад мы ввели понятие entry forms в Envision: функция, которая позволяет добавить на дашборд настраиваемую форму, доступную в виде входного параметра для скрипта Envision. Например, благодаря этой возможности можно было легко разработать дашборд, предназначенный для инспекции продукта, отображающий всю соответствующую информацию, относящуюся к выбранным продуктам. Однако, чтобы дашборд синхронизировался с вновь введёнными значениями формы, скрипт Envision приходилось перезапускать, что приводило к задержке в несколько секунд для получения обновлённых результатов — время, неприемлемое для исследования данных.
Срезы дашборда (подробности см. в нашей технической документации) представляют собой нашу попытку совместить лучшее из двух миров: онлайн- и пакетной обработки. Фишка в том, что теперь Lokad может пакетно вычислять огромное количество срезов (каждый срез может отражать продукт, локацию, сценарий, или их комбинацию) и позволять вам переключаться между ними в реальном времени, что становится возможным благодаря предварительным вычислениям. Естественно, предварительный расчёт большого числа срезов требует значительных вычислительных затрат, но не настолько, как можно подумать. Как правило, для Lokad дешевле вычислить 10,000 срезов за раз, чем выполнить 100 независимых запусков, каждый из которых предназначен для одного среза.
С помощью срезов Lokad приобретает возможности бизнес-аналитики на стероидах: теперь можно исследовать многие различные виды (например, продукты, локации, временные периоды) в режиме реального времени, без обычных ограничений архитектур онлайн-обработки.
-
В распределённой системе понятие «реального времени» не существует. Даже скорость света накладывает жёсткие ограничения на степень синхронизации системы, распределённой по нескольким континентам. Таким образом, эта терминология несколько преувеличена. Однако, если общая задержка составляет около одной секунды или меньше, обычно допустимо называть приложение для обработки данных «работающим в реальном времени». ↩︎
-
Даже передовые системы обработки данных в реальном времени, такие как те, что используются в автономном вождении, тщательно избегают любой операции обучения при работе в реальном времени. Все модели машинного обучения предварительно вычислены и являются статичными. ↩︎
-
Типичная реализация пакетного процесса заключается в перемещении плоских файлов, что является базовой функцией, поддерживаемой почти всеми современными системами. Далее, с точки зрения эксплуатации, если один из компонентов пакетного процесса испытывает временные сбои, обычно проблема решается с помощью простой политики повторных попыток. В отличие от этого, онлайн-системы, как правило, начинают работать некорректно при отказе одного из компонентов. ↩︎
-
На сегодняшний день один час вычислений на современном процессоре обычно стоит меньше $0.02 при использовании модели оплаты по факту на ведущих облачных платформах. Таким образом, пока выгоды от принятия одного более качественного решения в цепочке поставок оцениваются значительно выше $0.02, имеет смысл инвестировать этот дополнительный час вычислений. ↩︎