Контекст
По работе мне доводилось иметь дело с аналитическими стеками любых конфигураций и размеров. Мы на собственном опыте изучили, что цена стека для встроенной аналитики данных, расположенного за фронтендом, может моментально вырасти настолько, что об окупаемости инвестиций и речи не будет. Такой риск существует, если тщательно не просчитать 1) модели ценообразования для разных технологий и затраты на единицу продукции, 2) реализованную стоимость 3) производительность труда разработчика.
Сейчас появилась целая волна инструментов, созданных специально для решений из области встраиваемой аналитики, поэтому я решил набросать этот пост, в котором покажу, как некоторые из этих инструментов сочетаются друг с другом, и почему они так хороши.
В этой статье будут исследованы соотношения затрат/ценности и преимущества нескольких стеков, ориентированных на работу с данными, а именно MotherDuck / Cube / React (MDCuRe)
Модели ценообразования для разных технологий и затраты на единицу продукции
Начнём с данных…
Подойдём к делу с практической стороны. Большинство запросов, поступающих от сторонних пользователей, не так велики. Рассмотрим классическую стратегию монетизации данных: бенчмаркинг. Тот ломтик детализированных данных, к которому имеет доступ ваш пользователь, относительно невелик по сравнению со всем «пирогом». А те метрики бенчмаркинга, что вы предоставляете, предварительно агрегируются, поэтому они несравнимо мельче, чем детализированные датасеты.
В таком случае нет никакой нужды оснащать ваши встроенные аналитические решения масштабными вычислительными возможностями, если абсолютное большинство запросов, которые требуется вычислять — невелики. На самом деле, если собрать гораздо более легковесное решение, то можно разительно уменьшить затраты на единицу продукции в сценарии предоставления данных внешним пользователям. this is the case, there’s no need to build massive compute capabilities.
Если глубоко понимать модели ценообразования, которые используются в вашем встроенном аналитическом стеке, то будет легко и прогнозировать, какую окупаемость инвестиций можно ожидать от вашего продукта. В идеале используемая вами технология должна или масштабироваться по логарифмической шкале, или давать достаточно дешёвую стоимость единицы, чтобы можно было без труда вложиться в первоначальные закупки и начальную стадию разработки.
Немного углубимся…
Если подробнее рассмотреть модели ценообразования распространённых инструментов бизнес-аналитики и семантических слоёв, оказывается, что слишком часто речь идёт о предоставлении лицензии «в пересчёте на пользователей» (per-user model). Как правило, существует базовая ставка для доступа к платформе, на которую можно допустить небольшую группу пользователей, а все дополнительные пользователи будут тарифицироваться отдельно (помесячно или ежегодно). В случае со встраиваемой аналитикой это одна из наиболее невыгодных схем ценообразования, так как по мере увеличения вашей клиентской базы цена работы с ней также масштабируется линейно. Здесь практически не на чем сэкономить, кроме того, что взнос за пользование платформой, очевидно, уменьшается в пересчете на стоимость единицы продукции.
Для сравнения рассмотрим модель ценообразования, применяемую в Cube. Здесь тарифицируется именно активное использование системы, причём, в модель целенаправленно закладываются нюансы, благодаря которым продукты для встроенной аналитики не только оказываются экономически жизнеспособными, но и значительно более привлекательными в случае масштабирования.
Ценность для клиентов (и для бизнеса)
Чтобы вы могли тарифицировать доступ к вашим данным, эти данные должны быть ценными. Благодаря описываемому здесь технологическому стеку можно значительно повысить ценность имеющихся данных, не прилагая чрезмерных усилий. Вот какими способами этого можно добиться:
Скорость
Стек MotherDuck позволяет сегментировать вычислительные мощности по пользователям (да, на каждого отдельного пользователя), благодаря чему получается среда, исключительно хорошо масштабируемая под клиентов, выполняющих аналитические запросы. Это уникальная черта MotherDuck, которую в каком-то смысле можно считать прорывной находкой во встраиваемой аналитике, поскольку зачастую такие продукты с трудом справляются с высокой конкурентностью при работе под нагрузкой. Даже при использовании хранилищ данных, в которых применяются чрезвычайно параллельные вычисления (MPP), сегодня являющиеся мейнстримом возможна ситуация, когда к одному и тому же хранилищу обращаются сотни и даже тысячи пользователей, поэтому возникает конкуренция за вычислительные ресурсы.
Но самый важный аспект MotherDuck заключается в том, что она может работать в рамках веб-приложения как локальный кэш, написанный на WASM. С таким кэшем можно обходиться и без непрерывного соединения с облачным хранилищем данных, если пользователю то и дело приходится обращаться к своему сегменту данных. В такой ситуации аналитические данные можно возвращать с такой же скоростью, как и данные о транзакциях, выполняемых у вас на сайте.
Курирование и обеспечение надёжности данных
В Cube предоставляется возможность встраивать бизнес-логику в те данные, что мы предоставляем клиентам, в результате данные становятся только ценнее. Рассмотрим простую выдержку сырых данных, предоставляемую клиенту (или веб-разработчику). На машине клиента они поглощаются, преобразуются, а затем на их основе рассчитываются бизнес-метрики. Если вы сможете сделать эту работу за пользователя, то он сэкономит время и силы, следовательно, сам продукт получится ценнее.
Если задействовать семантический уровень, то и на нём можно получать дополнительную капитализацию. Учитывая, что в Cube встраиваются пользовательские профили и аутентификация, можно предоставлять клиентам различные уровни доступа к данным и возможности исследования данных, в зависимости от того, с каким тарифным планом работает пользователь. Поскольку Cube полностью управляется через API, мы также с легкостью можем организовать вставку с обновлением для данных пользовательского профиля через клиентское приложение React, а после этого, когда пользователь обновит подписку, дать ему новые права доступа.
Работая с этими двумя инструментами, вы сможете обслужить основную массу результатов вашей встроенной аналитики, выполняемой на бэкенде. Таким образом, получаются приемлемые затраты на единицу продукции, а также крайне дешёвые взносы за пользование платформой.
Клиентская экосистема и обеспечение производительности
React продолжает доминировать среди фреймворков для разработки клиентских приложений. React выделяется своей богатой экосистемой, простотой использования и высокой производительностью. Хотя, существует много других высококачественных клиентских фреймворков, именно React часто предпочитают для многих проектов на фронтенде. На базе React существуют и вторичные веб-фреймворки, работающие по принципу «щёлкнул и развернул», например, Vercel или Netlify, их сильная сторона — скорость. Кроме того, очень интересен компилятор, который планируют выпустить в версии React 19. Он лениво перестраивает компоненты не при каждом новом отображении, а только в том случае, когда меняется состояние. В таком случае удаётся значительно сократить объём шаблонного кода, обслуживающего применяемые в React компоненты визуализации, которые излишне сложны с функциональной точки зрения и ранее сильно тормозили работу приложений.
Производительность труда разработчика
В компании Amazon популяризовали концепцию “команды, которую можно накормить двумя пиццами” — речь о минимальной группе, способной целиком поддерживать продукт или реализовать сквозной функционал бизнес-фичи. Сколько человек наестся 2 пиццами? Считается, что человек 5-8, может быть, чуть больше, если пицца занимает глубокое блюдо. Тем не менее, если стараться обеспечивать результат силами самодостаточной команды именно такого размера, то сохраняется качественная коммуникация, быстро принимаются решения, поэтому дело делается. С другой стороны, в такой команде минимизируется делегирование задач и почти не возникает зависимостей, поэтому команда может уделять потребностям клиента больше внимания, чем самоорганизации внутри себя. В идеале, всего один веб-разработчик из команды должен уметь сам сдать фичу, минимально обращаясь за помощью к людям, не относящимся к команде.
От подбора инструментов в команде разработчиков продукта может зависеть успех или случиться провал. Точно, как вся структура команды заточена на эффективную коммуникацию, интеграцию команды и комфортную доставку, набор инструментов должен соответствовать тем же самым приоритетам. Мы хотим, чтобы стек сокращал, в не умножал трения в команде, задача которой — непрерывно сдавать работающий софт.
Стек MotherDuck / Cube / React или стек MDCuRe заинтересует команды, разрабатывающие продукцию для встроенной аналитики методом непрерывной доставки. При помощи каждого из перечисленных инструментов команда может управлять изменениями через контроль исходников, а также выстраивать ровный путь от разработки на локальной машине до интеграционных окружений и далее в продакшен. Фактически, при помощи этого стека специалист может создать у себя на рабочей станции совершенно чистую песочницу для разработки.
В таком случае вполне можно представить, как разработчик собирает и развёртывает фичу от начала до конца, в том числе:
- Прописывает миграцию по хранилищам данных (при помощи такого инструмента как Atlas) и применяет эти изменения в локальном инстансе DuckDB
- Создаёт и загружает в DuckDB вспомогательные элементы (при помощи таких инструментов как Mimesis или Faker)
- Определяет модель данных при помощи IDE Cube и валидирует её в песочнице
- Устанавливает в коде права доступа к данным
- Реализует клиентский код React, потребляющий из Cube данные через интерфейс REST или GraphQL
- Методом контроля исходников регистрирует миграции данных от хранилища к хранилищу, модель Cube, а также изменения, делаемые в клиентской части
- Развёртывает все изменения кода в вышестоящие окружения, например, в стейджинг или в продакшен. Для оркестрации этих изменений используется инструмент CI/CD, например, Github Actions, поддерживающий работу с инстансами Cube Cloud и Mother Duck, развёрнутыми на хосте.
В итоге
Напомню, какие преимущества приобретаются при работе со стеком MDCuRe:
База данных: MotherDuck
- Поскольку вычисления можно сегментировать с детализацией до отдельного пользователя, исчезает конкуренция между клиентами вашего решения для встраиваемой аналитики. Соответственно, повышается согласованность запросов и их скорость для каждого пользователя.
- Благодаря молниеносной обработке данных прямо в оперативной памяти duckDB, софт MotherDuck отлично подходит как для хранения данных, так и для вычислений над ними, если требуется организовать встроенную аналитику информации.
- Наряду с техническими достоинствами DuckDB, в Motherduck также действует честная и понятная система ценообразования. В большинстве практических случаев, где может понадобиться встроенная аналитика, клиенты выполняют относительно небольшие запросы, затрагивающие узкие сегменты имеющегося множества данных. Если вам удаётся хорошо справляться с данными в вашем стеке enterprise-архитектуры, то их можно оптимизировать настолько, что единичная стоимость хранения данных и вычислений над ними составит копейки.
- Поскольку в Cube используется семантический уровень, на котором поддерживается работа с javascript, yaml или python, программисты быстро освоят все аспекты семантического моделирования данных и полный цикл разработки продукта.
- Если умело пользоваться семантическим уровнем, управляемым через API, то можно почти сразу выкатить пользователям новые ценные возможности, для этого им достаточно обновить подписку.
- В Cube предусмотрен детализированный контроль безопасности, поэтому руководители бизнеса могут быть совершенно спокойны, что любые обращения к содержимому защищены
- Поддерживает пользовательские потоки аналитических задач и позволяет тонко настраивать аспекты, связанные с брендингом
- Обеспечивает максимальную гибкость в построении информационной архитектуры и паттернов взаимодействий. Поэтому можно разрабатывать пользовательские интерфейсы и сценарии, полностью соответствующие потребностям каждого клиента
- Поддерживает оптимизацию производительности, в том числе, рендеринг на стороне сервера и библиотеки визуализации на базе webGL
- Широкая поддержка в отрасли и гигантская экосистема свободных библиотек
- Легко поддерживает интеграцию с уровнем активации, благодаря чему пользователь может задать вопрос, получить подсказку и совершить действие – всё в рамках одного экранного сегмента.