Начало здесь и здесь

Реструктуризация данных с переводом на новую архитектуру может выглядеть проектом сложным и дорогостоящим, но это необходимо для качественной агентной автоматизации, без которой сложно достичь плановых показателей, предусмотренных федеральным проектом «Производительность труда». Напомним, что этот федпроект, согласно которому производительность труда российских компаний должна вырасти на 20,7% по сравнению с 2023 годом, — рассматривают как один из ключевых инструментов модернизации российских организаций. Федпроект реализуют по национальному проекту «Эффективная и конкурентная экономика».

Data Infra: четыре этапа реструктуризации данных

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

1. Создание единого управляемого фундамента

Основа «под данные» — Lakehouse, которая объединяет гибкость «озер данных» (Data Lake) с управляемостью и производительностью классических хранилищ (Data Warehouse). Одна копия данных обслуживает все нагрузки, исключая дублирование и оптимизируя использование аппаратного ресурса.

Трехслойная структура — иногда ее называют «Медальон» — радикально отличается от недавно привычной классификации горячие / теплые / холодные / ледяные. В первом слое — «Бронзовом» — размещены «сырые данные». Во втором — «Серебряном» — данные, прошедшие валидацию, очистку и обогащение; это уже единый источник достоверных фактов. Наконец, в «Золотой слой» помещены агрегированные и денормализованные витрины, оптимизированные для конкретных бизнес-задач и ИИ-приложений.

Это кажется массивным решением, но без него не построить контроль «родословной данных».

«Родословная данных» имеет три уровня, которые нужно внедрять вместе. На первом (техническом) зафиксировано перемещение чисел между колонками и базами, на втором, который наложен поверх технического, — описан бизнес-смысл данных, наконец, на третьем (операционном) собраны логи, где зафиксированы действия с данными: какие процессы с ними взаимодействовали, кем и когда они были запущены, сколько длились и пр. Последнее нужно, в частности, для контроля реальной произвольности ИТ-решений.

Переход к новой архитектуре требует предварительной совместной работы как ИТ-подразделений заказчика, так и внешних интеграторов, а также, возможно, консалтеров. Задач много — от понимания требований бизнеса и проектирования слоев хранения до миграции и совмещения обновленного хранилища с тяжелыми корпоративными системами (ERP, CRM и пр.).

2. Обеспечение непрерывного потока событий

Переход к непрерывному потоку событий (Data Streaming) от ранее привычной пакетной загрузки (например, раз в сутки). Перед проектированием такой системы для компании исполнителям нужно совместно с бизнесом выбрать ситуации, в которых ценность информации быстро убывает. В качестве примеров упомянем задачи динамического ценообразования, управления запасами, антифрод, персонализацию и пр. Эта задача организации Data Streaming технически сложная, но нужные для нее инструменты доступны: брокеры сообщений, «движки» потоковой обработки и пр.

3. Построение семантического слоя

Сегодня семантический слой (Semantic Layer) — обязательный элемент для безопасного внедрения генеративного ИИ. На этапе его формирования происходит проектирование единого бизнес-языка для всех сотрудников — как людей, так и ИИ-инструментов, — иначе велика вероятность получения противоречивых ответов из-за разных трактовок одного показателя. ИИ, обнаружив пять разных трактовок, например, показателя «затраты на привлечение клиента», не будет уточнять детали, а выберет малопредсказуемым способом одну из них, что может привести к появлению ошибочного ответа.

Сегодня Semantic Layer не просто инструмент BI, а «инфраструктурный щит» для безопасного применения ИИ. Создание собственного «толкового словаря» — что такое «клиент», «заказ» или, предположим, «выручка» — некоторым кажется странной задачей, но Gartner еще в прошлом году включил семантический слой в число базовых элементов аналитической архитектуры.

4. Построение Data Fabric

Data Fabric — не конвейер обработки, а архитектурный подход к интеграции данных на уровне предприятия, который создает единый логический слой над всеми источниками: локальными СУБД, «облачными» хранилищами, данными партнеров или контрагентов и пр. При этом данные физически не перемещают, их объединение происходит через виртуализацию и интеллектуальную маршрутизацию запросов.

В результате пользователю — сотруднику-человеку или ИИ-агенту, который работает с единым информационным пространством, — совсем не обязательно знать, где физически размещены те или иные данные. Очевидно, что процесс создания такого слоя не разовый: по мере появления новых данных активные метаданные (Active Metadata) обнаруживают, аннотируют и связывают, а также управляют качеством и политиками доступа.

Новому направлению — новые специалисты

Уже появилась роль Data Infrastructure Engineer (или Data Infra Engineer), в которой специалист сфокусирован на создании и развитии инфраструктурного «фундамента» для работы с данными. В рамках его обязанностей — задачи интеграции (включая проектирование «озер данных» и продвижение концепции «инфраструктура как код») и взаимодействие с командами: тесная работа с инженерами данных, ML-инженерами, аналитиками, разработчиками и бизнесом для детального понимания их потребностей в данных.

Следует различать роли «Data Engineer» и «Data Infrastructure Engineer»: первый следит за перемещением данных по каналам, второй — создает и развивает эти каналы. Корпоративные заказчики осознали, что для построения надежной, масштабируемой и безопасной платформы данных (особенно для ИИ) нужен отдельный инженерный профиль, а не просто «Data Engineer, который еще и за серверами присматривает».

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

Вместо заключения

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

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

Окончание следует

Источник: