Разработка (dev) и data science в enterprise — битва за ресурсы или эффективное сотрудничество?05.07.2021 13:01

В подавляющем большинстве случае, когда речь заходит о «настоящей» разработке продукта или решения enterprise уровня, сразу появляются корпоративные архитекторы и глобальные архитектуры и шаблоны, высокоуровневые модели данных и концепты, попытки охватить всё и вся. Формируется шорт лист из языков и фреймворков, в рамках которых идет вся последующая разработка. Все «только на Java» или «только на C#» или… (впишите на свое усмотрение).
Несомненно, это является отражением предыдущего проектного опыта, лучших мировых практик, готовности подхватить новые запросы бизнеса и в общем случае такой подход оправдан. Но в каждом частном случае подобный глобализм на этапе взлета продукта, в тот момент, когда многое еще находится в состоянии неопределенности, может просто погрести под собой начинание и превратить проект в очередную неудачу. Можно ли что-то изменить, упростить и улучшить не теряя при этом в качестве?
Оказывается что это вполне возможно за счет объединения классической разработки ПО с инструментами и подходами data science (далее просто DS). Как этого можно достичь — разберем по шагам.

Материал является продолжением серии предыдущих публикаций.

Не все разработчики могут себе представлять четко, что такое data science и чем занимаются специалисты. Бытующее по фильмам и рекламе мнение, что они занимаются искусственным разумом и машинным обучением далеко от реальности. Да, в data science бывает много математики. Очень много и достаточно сложной. Да, отдельные ветки DS раньше назывались более точно — computer science и занимались они численными алгоритмами. Но это всего лишь одни из направлений.
В корпоративном мире специалисты datascience больше занимаются адаптацией готовых подходов и алгоритмов для потоков бизнес-данных, чем фундаментальной математикой.
Вывод в продуктивное использование моделей и аналитических приложений по сути очень похож на разработку ПО.
Если посмотреть чуть глубже, то промышленный DS (а вывод в корпоративный прод DS решения можно относить именно к промышленному) почти ничем не отличается от промышленного DevOps. Те же базовые технологии и методологии, jira+git, гибкие методологии, автотестирование и воспроизводимые вычисления, CI/CD, roxygen/swagger, многопоточность и логирование, разнообразные БД и распределенные вычисления, nix администрирование/контейнеризация, html+css+js для разработки АРМ и отчетов и пр. И методология управления жизненным циклом моделей (MLOps) также хорошо проработана и в части регламентов и в части инструментов.
Только в DS языки чуть по другому выглядят и набор инструментов и библиотек содержит множество эффективных алгоритмов, ориентированных именно на работу с данными. В целом, хороший промышленный DS специалист должен быть таким же хорошим аналитиком, как разработчиком или инженером.

▍Сценарий 1. Аналитическое оконтуривание задач и отработка гипотез

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

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

Вариант с общими соображениями приводит к громадным ожидаемым срокам и трудозатратам и весьма удручает держателей бюджета.
Для второго варианта применение инструментов data science является идеальным — это один из классов задач для которого они разрабатывались. Какие свойства источников могут быть изучены и проверены (на всем или почти всем объеме данных)?

Рассмотрим через призму API (REST API):

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

Интеграция через REST API — это еще очень хороший вариант, иногда это может оказаться просто Excel (выгрузка из внутреннего SAP).

В результате такого предварительного изучения на этап проектирования продукта мы подходим с четким пониманием сценариев интеграции, что позволяет создавать архитектуру, заточенную именно под задачу, а не под сфероконя. Экономия времени, финансов, снижение стоимости разработки и последующего владения налицо.

Исполнение всех этих задач инструментами data science оказывается гораздо компактнее и эффективнее, чем на классических языках программирования и фреймворках. А, поскольку, правильные инструменты data science поддерживают полноценную devops методологию, то все эти наработки в большинстве случаев можно перенести «AS IS» в продуктивную архитектуру. Немного добавив автотестов и логирования.

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

Билеты продаются с вашей площадки. Время отклика для пользователя, будь то сайт или приложение, должно составлять десятки/сотни миллисекунд. Вся актуальная информация по билетам живет на сайтах партнеров (а их может быть несколько). Модели данных партнеров и технически и содержательно вообще могут никак друг с другом не биться. Элементарно — один отвечает за кино, второй — за театры, третий — за открытые концертные площадки.
Отсюда, опять же, с учетом характерных времен появления изменений, появляется примерно такая архитектура: внутренняя универсальная стабильная модель данных по всем мероприятиям (справочник), ежесуточная актуализация справочника в оффлайне, онлайн взаимодействие с партнером на основе «живой» информации на этапе покупки билетов (API, либо виджет). Не забываем, что партнеры постоянно в развитии. То новый появится, то у текущего глобальный рефакторинг случится. Все очень динамично.

Подобная интеграционная схема организуется и поддерживается в продуктиве в разы быстрее и легче средствами data science, чем Java/C++/SQL/php.

▍Сценарий 2. Элементы внутреннего аналитического блока

Сценарий достаточно компактный и очевидный. В продуктах очень часто приходится крутить данные и делать нетривиальные алгоритмы. Быстрее и проще это исполняется в рамках data science стека. Можно выделить этот функционал, обособить и реализовать его в виде черного ящика с CLI интерфейсом, как дополнительный поток рядом, как отдельный вычислительный сервис с REST API интерфейсом. Можно использовать его и в режиме request-response и как генератор side-эффектов. Способ реализации зависит от объемов данных, информационных потоков, предпочтений разработчиков, сценариев использования и т.д. Можно себе ни в чем не отказывать.
Естественно, все с поддержкой многопоточности. Если о деталях, в части реализации многопоточного REST API в R можно поглядеть весьма интересный доклад plumber + future: Async Web APIs
Быстрее, дешевле, проще.

▍Сценарий 3. Бизнес-мониторинг и аналитика эксплуатации решения в продуктиве

Идея единого сквозного мониторинга и полного всестороннего охвата ИТ ландшафта муссируется на рынке уже лет 15. И если для инфраструктурных задач, особенно, у операторов связи, это было успешно решено, то в части мониторинга продуктов и приложений все выглядит очень натянутым. Даже решения класса APM (application performance monitoring), такие как AppDynamics, DynaTrace, NewRelic, … и те все равно идут от технологического мониторинга — мониторинг временных показателей технических транзакций, трассировка исполнения bytecode сборок, агентная нагрузка и пр.
Чтобы понять с точки зрения бизнеса что и как происходит в продукте — мало измерять времена и ошибки и немного подглядывать в SQL запросы. Менеджеру продукта и бизнес-заказчику важно видеть бизнес-картину, необходимо делать фокус на контроль пути исполнения каждой бизнес-транзакции и соотносить ее с бизнес-показателями. А задачи мониторинга CPU и RAM оставить службе технической поддержки.

Не надо надеяться на чудо, на единую систему мониторинга, на вендоров и службу ИТ мониторинга/технической поддержки. Все в руках менеджера продукта. Есть апробированный пошаговый подход по решению этой задачи «здесь и сейчас», основанный на стеке data science:

добавили в продукт компактное логирование бизнес-операций;
задействовали data science стек + технологию process mining;
получили представление о работе продукта во всех срезах, начиная от технического и кончая бизнес-показателями в режиме вплоть до близком к реальному.

Никто кроме разработчиков и владельца продукта досконально не знает, как на самом деле работает продукт, как он должен работать, какие операции являются бизнес-значимыми, а какие технологическими. А значит им и карты в руки, службе мониторинга уж точно не до того. Добавление в бизнес-лог различной бизнес информации по транзакциям, включая:

информацию по пользователю;
информацию по корзине/личному кабинету;
содержание ответов от сторонних систем;
содержание ответов от БД;
и прочее позволяет получить полную детализацию всех происходящих в ПО процессах непосредственно в продуктивном окружении, а это дорогого стоит. Фактически, мы получаем мониторинг ПО и полноценную бизнес-аналитику в одном флаконе.

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

По этой теме пару скобок раскрывал чуть ранее:

По выгоде — получаете то, что нельзя получить иными способами.

▍Сценарий 4. Стабилизация каркаса приложения

Речь про классическую дилемму. Владельцу продукта надо что-то добавить или поменять — новое требование в утрамбованном графике. Как это делать, какими алгоритмами, на каких кубиках, насколько сложную балалайку надо будет сочинять? Можно ли обойтись малой кровью, на что целиться, когда ведущие разработчики будут свободны?

Типичный пример: в уже почти готовом приложении надо добавить еще функционала, опирающегося на данные сверх того, что думали в начале. Например, теперь надо показывать в личном кабинете динамику средней цены на товар не за месяц, а за три месяца и это критичное требование. БД спроектирована, партиционирована и оптимизирована под другие запросы. Простым SQL запросом имеем время отклика не 50 мс, как надо для АРМ, а 5 секунд (алгоритм может быть и очень сложным). Или данные начали приходить от внешней ИС в существенно более сложном JSON и все сильно начало проседать. Или вдруг партнеры не успевают со своим релизам и вам нужно срочно поддерживать тот формат, который есть у них сейчас, а переходить на новый только как они смогут его доработать.
У вас есть релиз план, создавать еще один слой кэша, менять структуры таблиц, менять технологии парсинга и т.д. — все это весьма негативно сказывается на стабильности каркаса приложения. «Нашлепки» и «изолента», приделанные в режиме бешеной спешки делаются, как правило, первым попавшимся способом и потом покрываются новыми культурными слоями и становятся неотъемлемой частью архитектуры продукта.

Использование стека data science в качестве плотины для потоков данных позволяет достаточно легко:

локализовать и изолировать точку изменения (см. сценарий 2) и минимизировать воздействие изменившихся требований на архитектуру базового продукта;
провести локальные оперативные исследования по способам решения — их ресурсоемкость и производительность и выбрать минимально достаточный;
получить значительную отсрочку по времени для системного решения этого вопроса (если таковая необходимость останется актуальной) в рамках следующего релиза ПО.

Выгоды очевидны — гибкость в реакции на изменения во внешней среде, сроки и стоимость решения, бережливое отношение к базовой архитектуре ПО.

▍Сценарий 5. Переформатирование взаимодействия пользователя с приложением

Очень популярный сценарий — замена в enterprise решениях «дашбордийского» функционала storytelling отчетами. Чуть детальнее можно прочитать в «Storytelling R отчет против BI, прагматичный подход»

Тут вообще одни сплошные плюсы.

Это резко снижает сложность основного приложения, трудозатраты и сроки. Storytelling более информативен для конечного пользователя — повышается эффективность их работы.

Варианты взаимодействия Dev + DS может быть куда больше, но 5 сценариев вполне достаточно, чтобы подкрепить утверждение, что грамотное сочетание Dev + DS дает очень значительные выгоды бизнесу и позволяет выдавать качественный и стройный продукт в обещанные сроки.

Предыдущая публикация — «Запросить 100 серверов нельзя оптимизировать код. Ставим запятую».