Симптомы деградации централизовнной архитектуры появляются постепенно — сначала команда замечает, что добавление каждого нового отчета или витрины снижает общую производительность платформы, затем нарастает диспропорция между числом задач по поддержке модели и реальными возможностями: людей не хватает, а очередь запросов только растет. Параллельно возникают сложности другого рода — все труднее определить, кто именно отвечает за конкретный набор данных, как гарантировать их полноту и точность, как быстро подключить к платформе новое бизнес-направление. К этому добавляются разнородные требования по защите информации, несовместимые SLA для разных групп данных и операции, которые невозможно свести к стандартным запросам. Единая модель перестает быть универсальным решением и превращается в тормоз.

Дело не в ресурсах

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

Значительно расширенная команда аналитиков и архитекторов данных сможет справиться с эксплуатацией существующей системы, но не с созданием принципиально новых решений. Чтобы перевести экспоненциальный рост сложности в линейный, нужна иная архитектурная логика — единая платформа хранения, например LakeHouse [1], с продуктами данных поверх нее.

Домены и продукты данных

В доменном подходе границы определяются картой возможностей предприятия (capability map). Каждый домен объединяет связанные контексты задач и решений: пространство задач — это факторы, влияющие на оценку успеха в семантических границах, а пространство решений — фактический объем реализаций по данным и инструментам.

Полноценный продукт данных отличается от обычной витрины тем, что создается для конкретного контекста и формирует измеримую ценность. В его состав входят: документация с описанием используемых наборов данных, логическая и физическая модели, правила трансформаций и загрузки, API и инструменты визуализации для доступа к метаданным.

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

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

Рис. 1. Пример дерева метрик

Дерево метрик (рис. 1) позволяет выстраивать зависимости между продуктами данных, обеспечивая связанность всей платформы. За счет него продукты можно сравнивать, а решения, формирующиеся на их основе, принимаются на всех уровнях по общим правилам. Дерево метрик гарантирует, что решение на уровне отдельного исполнителя, системы или процесса окажет предсказуемое воздействие на метрики верхнего уровня и показатели организации в целом.

Рис. 2. Пример представления семантического слоя

Семантический слой (рис. 2) — мост между сырыми данными и конечными пользователями, которым необходимо эти данные интерпретировать и применять. Именно этот компонент позволяет решить проблемы децентрализованного ландшафта данных за счет решения задач абстракции данных, их интерпретации, а также предоставления согласованного доступа и оптимизации производительности.

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

Новые «силосы»: четыре ошибки

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

Первая причина — нарушение принципов моделирования. В доменной архитектуре особенно важно четкое разделение на три уровня: концептуальную, логическую и физическую модели. Концептуальная представляет собой общий словарь терминов, отражающий то, как бизнес себя видит, — эта модель предназначена для людей и не требует машинной обработки. Логическая переводит этот словарь в формальные структуры — к концептам добавляются атрибуты, метрики и метаданные. Физическая описывает таблицы и документы для каждого контекста, а также набор интеграционных контрактов между доменами.

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

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

Четвертая ошибка кроется в создании обособленных областей без координации через интеграционные контракты и общий семантический слой. Если домены не договариваются о правилах передачи данных и не формируют общий язык для работы с аналитикой, то децентрализация превращается в хаос.

Архитектурный каркас

Рис. 3. Архитектурный каркас на базе LakeHouse

За счет своей инфраструктуры платформа типа LakeHouse (рис. 3) хорошо подходит в качестве основы для доменной архитектуры. Компоненты системы включают: объектное хранилище с сырыми данными, табличный формат (например, Iceberg) с транзакционной консистентностью и версионированием, каталог со схемами таблиц и ключами, а также вычислительные движки для трансформаций и запросов.

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

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

Баланс между автономией и контролем

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

Как определить, работает ли система? Главный индикатор успеха — динамика сложности при создании нового продукта данных. Если она остается экспоненциальной, то при внедрении архитектуры допущены ошибки. Если переходит в линейную — основная цель достигнута. Дополнительные сигналы — то, как новые продукты встраиваются в дерево метрик, какую обратную связь дают бизнес-пользователи и руководство, а также доля внедрений, в которых возникают неучтенные риски: скрытые зависимости между доменами, расхождения в трактовке метрик, проблемы с качеством данных, нарушения SLA, избыточные доработки интеграций или сбои при масштабировании. Снижение числа таких случаев — один из наиболее заметных признаков зрелости системы.

***

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

Литература

1. Владимир Озеров. Lakehouse — архитектура современной платформы данных // Открытые системы.СУБД. — 2025. — № 1. — С. 8–12. URL: https://www.osp.ru/os/2025/01/13059362 (дата обращения: 21.06.2026).

Леонид Шумский (LSHumskiy@inno.tech) — руководитель направления «Платформа данных», Т1 ИИ (ИТ-холдинг Т1) (Москва).