В условии непрерывных социальных и экономических изменений принятие решений на основе фактов и знаний стало отправной точкой, относительно которой сегодня можно отсчитывать уровень зрелости цифрового бизнеса. Необходимый атрибут такого бизнеса — корпоративная аналитическая платформа, которая должна обладать тремя основными свойствами:
1) обеспечивать бизнесу возможность эффективно решать все задачи, как минимум получать прибыль или минимизировать потери;
2) гарантировать высокие стандарты кибербезопасности, что проявляется в автоматизации процессов эксплуатации платформы, обезличивании и легализации данных и моделей;
3) обеспечить надежность и эффективность платформы, что отражается в технологическом стеке.
Пользователи корпоративной аналитической платформы — исследователи данных ('D-people') — изучают скрытые характеристики предметной области, создают и развивают продукты на основе данных промышленного качества (дата-продукты). Платформа предоставляет исследователям виртуальные автоматизированные рабочие места (ВАРМ), обеспечивающие все необходимое для работы с дата-продуктами и искусственным интеллектом. Шкала зрелости корпоративной аналитической платформы позволяет проследить за непрерывным углублением разделения труда в компании для выполнения сравнения.
Первое поколение аналитических платформ (см. врезку «Первое поколение. Капитализация данных») появилось благодаря стремлению компаний капитализировать свои данные — извлекать из накопленных данных новые знания и монетизировать их либо напрямую через экономию, либо косвенно — посредством расширения номенклатуры и качества продуктов.
Второе поколение (см. врезку «Второе поколение. Глубокое применение искусственного интеллекта») открыло дополнительные возможности по капитализации данных — как унифицированного массового продукта для собственного потребления и для своих партнеров. Попутно у бизнеса возникла экономическая потребность в экосистемах — производная капитализация: владелец аналитической платформы получает деньги за свои дата-продукты, продавая их партнерам, а партнеры повторно монетизируют данные, извлекая из них полезные для своего бизнеса знания.
Третье поколение аналитических платформ (см. врезку «Третье поколение. Управление бизнес-метриками») открывает эпоху управляемых бизнес-метрик: TTM (time to market, иногда — T2M) — время, необходимое на дизайн, производство и выпуск нового продукта на рынок, и TTD (time to deployment, иногда — T2D) — время, требуемое для выпуска с минимальными изменениями новой версии продукта. Управление бизнес-метриками позволяет достичь уровня зрелости корпоративной аналитической платформы, соответствующего цели цифровой трансформации — «бизнес на основе искусственного интеллекта». Вероятно, третье поколение — это начало следующего большого этапа развития систем хозяйствования, когда бизнес приступит к капитализации «навыков» — стандартизованных массовых программ на основе искусственного интеллекта.
Рис. 1. Эволюция штатного расписания поколений аналитических платформ |
В зависимости от поколения корпоративной аналитической платформы меняется и штатное расписание (рис. 1).
Первое поколение. Капитализация данных
Бизнес осознал самостоятельную ценность хранящихся в его ИТ-системах данных как источник знаний для автоматизированной оперативной поддержки принятия рациональных решений. В состав руководства компании введена позиция CDO (Chief Data Officer), ответственного за капитализацию данных. Под его управлением находится специальное подразделение по работе с данными — вертикаль CDO. Разработана и принята к исполнению стратегия капитализации данных, определяющая технологические политики по сбору, продуктивизации и дистрибуции дата-продуктов. В ИТ-ландшафт внедрен магазин данных, в оперативной деятельности широко используются процессы по наполнению магазина дата-продуктами, развернута инфраструктура по их дистрибуции и работе с ними. Освоена новая специализация труда, выделены специальные роли и сформированы специальные рабочие места. Руководством компании усвоено понимание существенных изменений в бизнесе на основе нового разделения труда.
В бизнес-подразделениях добавляются роли:
- владелец дата-продукта (Data Product Owner) — ответственность за cбор и верификацию требований к составу и качеству дата-продукта. Формирование требований к SLA дата-продукта. Участие в приемо-сдаточных испытаниях DApp (витрина — приложение, промышленный код витрины) в качестве принимающей стороны (сторона заказчика);
- специалист по обезличиванию данных (Data Depersonalizer) — ответственность за устранение персональных данных и конфиденциальной информации в дата-продукте;
- специалист по легализации данных (Data Legalizer) — ответственность за профилирование данных дата-продукта на предмет наличия персональных данных и конфиденциальной информации.
Бизнес-архитектура
На рис. 2 приведена бизнес-архитектура корпоративной аналитической платформы.
Рис. 2. Бизнес-архитектура корпоративной аналитической платформы |
Исследователи данных подписываются на продукты в зоне подписок (1), получают доступ (3) к материализованным при помощи зоны дистрибуции данным продуктов (2), ведут разработку производных продуктов в лабораторной зоне, а при помощи зоны DevOps размещают вычислительные задания в расчетной зоне (4) и получают отчеты со значениями вычислений (5, 6). После завершения приемо-сдаточных испытаний продукта он размещается в магазине зоны подписок. Здесь имеется три магазина: данных, признаков и навыков. Продукты магазинов предоставляются в соответствии с SLA и обязательствами подписчиков по оплате. Расчеты между подразделениями в рамках одной организации, а также внутри экосистемы, основанной на аналитической платформе, производятся на основе договоров о присоединении в соответствии с тарифами услуг. Под услугами понимаются сервис панелей самообслуживания платформы, а также потребленные вычислительные ресурсы и дата-продукты. При этом внутри одной компании внутренние тарифы на услуги платформы могут отличаться от внешних тарифов, а взаиморасчеты между подразделениями могут быть основаны на взаимозачетах и, в зависимости от принятой политики, могут оплачиваться из выручки или из соответствующих статей централизованного бюджета.
Магазин данных — функциональная подсистема платформы, позволяющая потребителям подписаться на получение доверенных дата-продуктов с «исходными данными» — данными, полученными из прикладных информационных систем. Продукт этого магазина может быть статическим набором данных (данные без срока устаревания) или потоком данных (со сроком устаревания). Поток данных поставляется в виде потока экземпляров (примеров) данных в реальном времени с гарантированной задержкой каждого экземпляра или потока пакетов данных, содержащих группу экземпляров (примеров) данных, зарегистрированную за определенный интервал времени с гарантированной задержкой каждого пакета.
Магазин признаков — функциональная подсистема, позволяющая потребителям подписаться на доверенные дата-продукты с «обобщенными данными» — это признаки, описывающие предметную область или ее узкий сегмент, полученные в результате обобщающих расчетов. В качестве алгоритмов таких расчетов выступают алгоритмы по кластеризации, тематическому моделированию, суммированию, извлечению знаний, аугментации признаков (генерированию новых данных на основе имеющихся), поиску причинно-следственных связей (RCA-анализ — анализ первопричин) и другие алгоритмы и их комбинации. Примеры продуктов магазина признаков: шаблоны log-записей микросервисов в векторном представлении (эмбединги) с разметкой по классам риска отказа в обслуживании в заданной предметной области (функциональном домене); шаблоны сообщений пользователей в векторном представлении с разметкой по классам намерений в заданной предметной области; представление классов объектов предметной области или ее узкого сегмента в виде мультиграфа, где экземплярами классов объектов являются подграфы атрибутов объектов; а также другие варианты.
Магазин навыков — функциональная подсистема, позволяющая потребителям подписаться на микросервисы с доверенными ML-моделями произвольной архитектуры и промышленного уровня качества. Микросервисы выполняют анализ данных пользователя через стандартизированный программный интерфейс.
Лабораторная зона
Лабораторная зона позволяет пользователям провести анализ качества данных одного или более дата-продуктов, создать витрину дата-продукта, провести ее тестирование на данных продуктивной среды и опубликовать витрину в магазине. Витрина — это приложение (DApp), состоящее из одного или более docker-контейнеров с ETL-кодом, которое, при необходимости, использует промышленный код модели (MApp), также состоящий из одного или более docker-контейнеров, но уже с ML-моделью. MApp доступен для использования в DApp посредством стандартизованного программного интерфейса. И DApp, и MApp совместно обеспечивают исполнение конвейера обработки данных для получения целевого дата-продукта.
Лабораторная зона состоит из группы ВАРМ, расчетной зоны и разделяемого хранилища данных. Рабочее место позволяет исследователям данных разрабатывать и тестировать ETL-код и ML-модели витрин дата-продуктов. Решаемая витриной задача — выдача по заявке подписчика доверенного набора данных либо потока данных реального времени. Витрины планируются к исполнению в зависимости от расписания, которое определяется наличием и приоритетами подписок в магазине данных.
Каждое ВАРМ имеет свою специализацию. Лаборатория искусственного интеллекта обеспечивает все необходимое для исследования данных, постановки и тестирования гипотез, разработки и валидации математически корректной модели машинного обучения. Лаборатория данных обеспечивает все необходимое для исследования данных, постановки и тестирования гипотез, разработки и валидации корректного ETL-кода. Лаборатория разработки обеспечивает все необходимое для создания DApp и MApp. Для DApp обеспечиваются разработка промышленного кода витрины в виде одного или группы микросервисов, реализующих конвейер преобразования данных, сборка дистрибутива DApp и проведение испытаний DApp. Для MApp обеспечиваются разработка промышленного кода в виде одного или группы микросервисов, реализующих промышленную модель, сборка дистрибутива MApp, проведение испытаний. Лаборатория валидации обеспечивает все необходимое для разработки, сборки дистрибутива, валидации и проведения испытаний MApp, используемых далее для управления модельным риском. Необходимо отметить, что MApp для управления модельным риском в магазине навыков не публикуются, не используются в составе витрин и не доступны для анализа и изучения разработчиками витрин.
Разделяемое хранилище данных содержит временные копии наборов данных дата-продуктов и файлов коэффициентов моделей.
Расчетная зона
Для управления расчетом витрин и исполнения моделей машинного обучения требуются комплексные средства планирования вычислительных ресурсов, включая иерархические очереди, равномерное и неравномерное распределение ресурсов между очередями, порядок заданий (очередность обработки: FIFO/FAIR), политики сортировки подключаемых узлов, вытеснение и др. Иерархические очереди обеспечивают детальный контроль над квотой ресурсов для разных пользователей. Минимальная/максимальная вместимость очереди предлагает избыточное обязательство, но в то же время гарантирует наличие ресурсов для исполнения вычислительного задания. Витрины ставятся в очередь, при этом вычисления витрин планируются в определенном порядке: по мере появления ресурсов, по времени запроса на запуск, по приоритету витрины. Предоставляется пользовательский интерфейс для централизованного управления вычислениями и панель мониторинга для отслеживания использования ресурсов вычислительного кластера, очередей и статуса расчета витрин. Подходящим решением для управления расчетными заданиями может быть, например, Apache Yunikorn.
Концептуально витрина представляет собой спланированный вычислительный процесс, исполняемый в контейнерезированной среде управления вычислительными заданиями, например Kubernetes (k8s). Это дает возможность реализовать витрины в форме k8s-namespace (пространства имен) под управлением сценария планировщика исполнения вычислительного процесса, в котором каждый шаг конвейера преобразования данных является контейнером с исполняемым кодом. Такой сценарий планировщика (WF-сценарий) должен позволять создавать многоэтапные рабочие процессы (конвейеры) как последовательность задач, а также фиксировать зависимости между задачами с помощью ациклического направленного графа. При этом каждый шаг рабочего процесса является контейнером, упакованным в PoD (Point of Deploy — единица размещения исполняемых ресурсов в k8s-кластере; далее — k8s-под). K8s-под снабжен служебными контейнерами, выполняющими функции платформы (sidecar-контейнеры). К таким функциям относятся: журналирование, сбор метрик для мониторинга, аудит безопасности, идентификация и авторизация, управление секретами, защита данных, доступ к материализованным данным по подписке, управление доступом, доступ к ресурсам оверлейной сети. Такая организация расчетных заданий дает возможность выполнять сложные ресурсоемкие задачи, как с точки зрения машинного обучения, так и обработки большого объема данных. Подходящим планировщиком вычислительных процессов является, например, Argo Workflows, реализованный в виде Custom Resource Definition Kubernetes.
Второе поколение. Глубокое применение искусственного интеллекта
Бизнес усложняется и ускоряется, в какой-то момент безоговорочно принимается ценность оперативного принятия решений уже на основе искусственного интеллекта. В руководство компании введены позиции: CAIO (Chief AI Officer) — ответственного за внедрение искусственного интеллекта в бизнес и CMRO (Chief Model Risk Officer) — ответственного за управление модельным риском. Под руководством CAIO сформировано подразделение по работе с искусственным интеллектом — вертикаль CAIO, а под руководством CMRO — подразделение по управлению модельным риском, вертикаль CMRO. Разработана и принята к исполнению стратегия развития искусственного интеллекта для бизнеса, определяющая технологические политики по моделированию, оценке модельных рисков, продуктивизации и дистрибуции моделей машинного обучения. Ролевая модель вертикали CDO остается на уровне первого поколения.
Унифицированы и автоматизированы процессы по семантическому выравниванию данных, разработке, внедрению в продуктивную среду и повторному использованию моделей машинного обучения. Магазин данных расширен до уровня «Зоны подписки» в составе трех магазинов: промышленных данных, предварительно рассчитанных признаков и продуктивизированных моделей машинного обучения. В ИТ-ландшафт внедрена система управления машиночитаемых знаний, а также двухконтурная зона расчетов для исполнения витрин данных и моделей машинного обучения, в том числе участвующих в расчете витрин. На постоянной основе осуществляется оценка риска критически важных бизнес-процессов. Руководством компании освоено понимание существенных изменений в бизнесе на основе нового разделения труда.
В бизнес-подразделениях добавляются роли:
- разметчик данных (Data Assessor) — разметка данных или валидация разметки в рамках своей зоны ответственности (одного или более сценариев по разметке данных или валидации разметки данных). Отвечает за качество разметки данных;
- сценарист разметки данных (Data Annotator) — разработка сценариев по разметке данных или валидации разметки данных в рамках своей зоны ответственности (функциональный домен, субдомен, группа субдоменов). Отвечает за качество сценариев разметки или валидации разметки данных; консолидированная ответственность за качество дата-продуктов.
Зона дистрибуции
Задача зоны дистрибуции — материализовать для потребителя данных подписку на дата-продукт, обеспечить процесс получения данных инициатором подписки на дата-продукт с момента подписки до момента завершения оплаченного тарифа. В качестве инициатора подписки может выступать техническая учетная запись, под которой работает приложение DApp в расчетной зоне, либо пользовательская учетная запись D-people в его ВАРМ лабораторной зоны. Технические и пользовательские учетные записи ассоциированы с учетной записью арендатора (теннанта) — организации, присоединенной к аналитической платформе на основании договора о присоединении.
В зависимости от типа дата-продукта задача материализации данных выполняется по-разному (см. таблицу 1).
Зона DevOps
Задача зоны — обеспечить высокий уровень автоматизации процессов корпоративной аналитической платформы в условиях непрерывных изменений. В таблице 2 приведены варианты инструментов для реализации различных DevOps-задач.
Третье поколение. Управление бизнес-метриками
Бизнес начал глубокую оптимизацию и строит планы по освоению новых ниш, при этом архитекторы работают над оптимизацией процессов ИТ-ландшафта на основе цифрового следа. Эти задачи предполагают системную автоматизацию регулярных бизнес- и технологических процессов на основе искусственного интеллекта. Цель изменений — управление бизнес-метриками TTM и TTD. Унифицированы и автоматизированы процессы повторного использования компонентов приложений (программный код, микросервисы, дата-продукты, модели). В процессах разработки, тестирования, развертывания и эксплуатации активно используется искусственный интеллект. Зона подписки позволяет подписывать приложения на входящие потоки данных и публиковать на ней исходящие потоки данных. Это открывает для бизнеса новые возможности, позволяя объединить преимущества магазина данных с архитектурным шаблоном единой шины данных. В ИТ-ландшафте унифицирован бессерверный (serverless) [1] технологический стек. Освоена новая ступень углубления специализации разделения труда с выделением архитекторов в отдельный департамент — вертикаль CAO (Chief Architect Officer), отвечающую за управление бизнес-метриками TTM и TTD. Руководством компании принято понимание существенных изменений в бизнесе на основе нового разделения труда.
Ролевая модель вертикалей CDO, CAIO, управления модельным риском, а также бизнес-подразделений остается на уровне второго поколения.
Технологический стек
На рис. 3 приведен пример технологического стека аналитической платформы, а в таблице 3 — состав технологического стека [2, 3].
Рис. 3. Пример технологического стека аналитической платформы |
Поколение 3+
Формирование корпоративной аналитической платформы сопряжено с многочисленными сложностями: концептуальными, организационными, технологическими, техническими и пр., преодоление которых открывает перед компаниями точки потенциального роста.
Концептуальные точки роста — построение согласованной понятийной модели (онтологии), лежащей в основе нормативных, архитектурных и других типов документов, нормирующих и отражающих понятия и основные смысловые конструкции, лежащие в основе платформы и ее экосистемы. Понятийная модель может принимать различные представления: тезаурус, онтологическая диаграмма функционального домена или корпоративный граф знаний. Важно понять, что на основе понятийной модели будет и должна строиться как технологическая, так и организационная исполнительная документация, которая будет согласована, что уменьшит потери, связанные с проблемами неопределенности, противоречий и смысловых коллизий, а это повысит эффективность разработки новых продуктов.
Организационные точки роста — построение рекомендованной системы разделения труда с четким разделением ответственности между новыми вертикалями.
Технологические точки роста — выстраивание единой инструментальной среды, обеспечивающей эффективное решение задач кибербезопасности, разработки, эксплуатации, сопровождения и управления.
Технические точки роста — решение задач изоляции по наборам данных, сегментации ролевой модели для доступа к наборам данных и/или функциям лабораторий, управление жизненным циклом экземпляров лабораторий; решение задач системной архитектуры, таких как унификация технологических стеков, а также развитие функциональности лабораторий для покрытия всех вариантов разработки дата-продуктов.
Прочие точки роста — задачи эксплуатации, такие как рост количества и сложности инцидентов при росте количества экземпляров лабораторий, рост трудоемкости обновлений экземпляров лабораторий и недостаточный уровень утилизации вычислительных ресурсов растущим множеством экземпляров лабораторий.
***
Независимо от своих масштабов, многолетней истории и «послужного списка» компании могут находиться на разных уровнях зрелости процессов принятия решений, определяемых поколением аналитических платформ. Предложенная шкала зрелости позволяет оценить текущее положение конкретной компании либо сравнить различные компании с точки зрения готовности их системы управления к изменениям. Шкала зрелости определяет три поколения корпоративных аналитических платформ, обозначая «карту местности» и «основные ориентиры», что может облегчить работу менеджеров на пути непрерывной трансформации цифрового бизнеса. Чем выше поколение аналитической платформы, тем выше готовность системы управления компании к изменениям.
Литература
1. Андрей Фомичев, Олег Бондарь. Бессерверная альтернатива традиционным базам данных // Открытые системы.СУБД. — 2021. — № 1. — С. 20–23. URL: https://www.osp.ru/os/2021/01/13055826 (дата обращения: 21.03.2023).
2. Александр Прозоров, Роман Шнырев, Дмитрий Волков. На пути к умной инфраструктуре // Открытые системы.СУБД. — 2022. — № 1. — С. 29–31. URL: https://www.osp.ru/os/2022/01/13056120 (дата обращения: 21.03.2023).
3. Александр Прозоров, Роман Шнырев, Дмитрий Волков. Архитектура цифровых платформ будущего // Открытые системы.СУБД. — 2021. — № 2. — С. 24–28. URL: https://www.osp.ru/os/2021/02/13055934 (дата обращения: 21.03.2023).
Александр Прозоров (aalprozorov@sberbank.ru) – архитектор инфраструктуры сервисов, «СберТех»; Дмитрий Волков (vlk@keldysh.ru) — старший научный сотрудник ИПМ им. М. В. Келдыша РАН (Москва).
DOI: 10.51793/OS.2023.87.39.002