Слой данных

Безлюдный бизнес-движок стоит на данных так же, как обычная компания стоит на людях, которые «держат контекст в голове». Когда бухгалтер, операционный директор и аналитик — живые люди, противоречия в данных сглаживаются их здравым смыслом: человек видит, что «ООО Ромашка» и «Ромашка ООО» — один контрагент, что выручка в отчёте продаж и выручка в отчёте финансов посчитаны по-разному, и молча это исправляет. Агент так не умеет — точнее, умеет непредсказуемо, а непредсказуемость в учёте недопустима. Поэтому слой данных в безлюдном движке — не «подвал» архитектуры, а её несущая стена: именно здесь определяется, о чём вообще могут договориться несколько юрлиц, десятки процессов и сотни агентов. Эта глава даёт теорию и практику проектирования такого слоя: как устроены мастер-данные и золотые записи, зачем событийная история первичнее состояния, какие архитектуры хранилищ пережили сорок лет эволюции и что из этого пригодно сегодня, как семантический слой и онтология предприятия становятся «языком», на котором LLM-агенты понимают бизнес, и почему «единый источник правды» — полезный миф, который надо уметь правильно готовить.

5.1. Три сорта данных и дисциплина Master Data Management

Первое различение, без которого невозможно проектировать слой данных, — это различение трёх сортов данных по их жизненному циклу и роли. Транзакционные данные (transactional data) — это записи о событиях бизнеса: выставлен счёт, проведён платёж, подписан акт, сотрудник списал восемь часов на проект. Их много, они рождаются непрерывно и после рождения не должны меняться — счёт от 12 марта останется счётом от 12 марта навсегда. Справочные данные (reference data) — это медленно меняющиеся классификаторы, чаще всего внешние по происхождению: коды валют ISO 4217, ОКВЭД, статьи затрат, страны, ставки НДС. Их мало, они стандартизованы, и главная задача — версионировать их изменения. Наконец, мастер-данные (master data) — это описания ключевых сущностей бизнеса, которые участвуют в транзакциях: клиенты, контрагенты, сотрудники, продукты, юрлица, договоры, проекты. Мастер-данные — самый проблемный сорт: они рождаются одновременно в нескольких системах (CRM, бухгалтерия, кадровая система, трекер проектов), живут годами, меняются (клиент переехал, компания переименовалась) и при этом должны означать одно и то же везде.

Дисциплина Master Data Management (MDM) отвечает на вопрос: как из нескольких конфликтующих записей об одной сущности получить одну достоверную — так называемую золотую запись (golden record). Механика состоит из трёх этапов, и каждый важно понимать в деталях.

Первый этап — матчинг и дедупликация (matching, deduplication): определить, что записи «ООО "Ромашка"», «Romashka LLC» и «Ромашка (ИНН 7701234567)» описывают одну организацию. Матчинг бывает детерминированным (совпадение по строгому ключу — ИНН, e-mail, паспорт) и вероятностным: записи сравниваются по нескольким атрибутам с весами, и пара получает суммарный скор похожести. Классическая математическая основа вероятностного матчинга — модель Феллеги–Сантера (Fellegi–Sunter, 1969), где для каждого атрибута оценивается вероятность совпадения при условии, что записи относятся к одной сущности (m-вероятность) и к разным (u-вероятность), а логарифм их отношения даёт вес атрибута. Практически это означает три зоны: скор выше верхнего порога — автоматическое слияние, ниже нижнего — точно разные сущности, между порогами — «серая зона», которую отправляют на ручной разбор. В классическом MDM серую зону разбирает человек-стюард; в безлюдном движке — LLM-агент, у которого, в отличие от старых правил, есть здравый смысл: он может понять, что «Сбербанк» и «СБЕР» — одно, а «Альфа-Банк» и «Альфа-Капитал» — разное.

Второй этап — правила выживания (survivorship rules): из совпавших записей собрать одну золотую. Типовые стратегии: приоритет источника (данные из ЕГРЮЛ надёжнее данных, введённых менеджером в CRM), свежесть (побеждает последнее обновление), полнота (побеждает непустое значение), частота (побеждает значение, встречающееся в большинстве источников). Ключевая тонкость: правила выживания задаются поатрибутно, а не позаписно — юридический адрес берём из госреестра, контактный e-mail из CRM, платёжные реквизиты из последнего подписанного договора. Золотая запись — это не «лучшая из записей», а сборка лучших атрибутов с указанием происхождения (lineage) каждого.

Третий этап — выбор архитектурного стиля MDM, то есть решения, где живёт золотая запись и кто ей управляет. В стиле registry MDM-система хранит только кросс-ссылки: «запись 123 в CRM = запись 456 в 1С», а золотая запись собирается виртуально на лету; исходные системы остаются хозяевами данных. В стиле consolidation данные физически стягиваются в хаб, там очищаются и сливаются, но результат используется только для аналитики — обратно в операционные системы он не возвращается. В стиле coexistence золотая запись синхронизируется обратно в системы-источники, а в стиле centralized (transactional) MDM-хаб становится единственным местом создания и изменения мастер-данных: CRM и бухгалтерия только читают из него. Чем правее по этой шкале, тем чище данные и тем дороже и дольше внедрение — классическая рекомендация состоит в том, чтобы начинать с registry/consolidation и двигаться к centralized только для тех доменов, где боль реально велика (обзор стилей см., например, у Stibo Systems и Semarchy; механику survivorship — у Data Ladder).

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

5.2. Data governance и DAMA-DMBOK: управление данными без бюрократии

Если MDM — это конкретная инженерная дисциплина, то DAMA-DMBOK (Data Management Body of Knowledge) — это попытка профессионального сообщества DAMA International собрать весь свод знаний об управлении данными в одну книгу. Второе издание (2017, переработанное издание — 2024) описывает одиннадцать областей знаний, расположенных вокруг центральной — data governance: архитектура данных, моделирование, хранение и операции, безопасность, интеграция и интероперабельность, документы и контент, справочные и мастер-данные, хранилища и BI, метаданные, качество данных. Эту схему называют «колесом DAMA» (DAMA Wheel; см. обзор DMBOK и материалы DAMA). Ценность DMBOK не в том, что его надо внедрять целиком — это справочник, а не методология, — а в том, что он даёт полный чек-лист: проектируя слой данных, вы можете пройтись по одиннадцати областям и осознанно решить, какие из них в вашем масштабе схлопываются в ноль, а какие критичны.

Data governance (руководство данными) в терминах DMBOK — это система принятия решений о данных: кто имеет право определять, что такое «клиент», кто утверждает изменение схемы, кто отвечает за качество конкретного домена. Ключевая роль здесь — data steward (стюард данных): не владелец и не инженер, а человек (в нашем случае — всё чаще агент), операционно отвечающий за конкретный набор данных — за его определения, качество и разрешение конфликтов.

В корпорациях governance печально знаменит тем, что вырождается в бюрократию: комитеты по данным, которые собираются раз в месяц и через которые проходит каждое изменение схемы. Для компании в 180 человек и тем более для безлюдного движка такой формат — смерть. Противоядие, выработанное индустрией к середине 2020-х, называется computational governance (вычислительное руководство): правила существуют не в регламентах, а в коде и срабатывают автоматически. Изменение схемы проверяется CI-пайплайном на обратную совместимость; доступ к персональным данным определяется политикой-как-кодом (policy-as-code); качество проверяется тестами при каждой загрузке; определения метрик живут в git с код-ревью вместо комитета. Человеческое решение остаётся только там, где нужен trade-off, не формализуемый правилом. Практический принцип: governance должен быть тонким слоем стандартов, на которых все обязаны сойтись (идентификаторы сущностей, форматы событий, определения метрик), и полной свободой во всём остальном.

5.3. Архитектуры хранилищ: Kimball, Inmon, Data Vault 2.0 и проблема времени

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

Kimball: звёзды и конформные измерения

Ральф Кимбалл (Ralph Kimball, «The Data Warehouse Toolkit», 1996; 3-е издание 2013) предложил строить хранилище как набор звёздных схем (star schema): в центре — таблица фактов (facts) с числовыми показателями транзакций (сумма счёта, часы, количество), вокруг — таблицы измерений (dimensions), описывающие контекст: дата, клиент, продукт, сотрудник, юрлицо. Запрос «выручка по клиентам за квартал» — это соединение фактов с двумя измерениями и агрегация; схема оптимизирована под чтение и понятна бизнес-пользователю. Ключевая идея Кимбалла, которую чаще всего упускают, — конформные измерения (conformed dimensions): измерение «Клиент» должно быть одним и тем же для витрины продаж, витрины финансов и витрины поддержки. Конформные измерения — это, по сути, проекция мастер-данных в аналитический мир: если MDM не сделан, конформности не будет, и «выручка по клиенту X» в двух отчётах разойдётся.

Кимбалл же систематизировал проблему изменяющихся измерений — slowly changing dimensions (SCD). Клиент сменил сегмент с SMB на Enterprise: что делать со старыми продажами? SCD Type 1 — перезаписать (история искажается: прошлогодняя выручка «переедет» в Enterprise). SCD Type 2 — завести новую версию строки с датами действия (valid_from/valid_to) и суррогатным ключом: старые факты остаются связаны со старой версией, новые — с новой. Type 2 — стандарт де-факто для всего, что влияет на отчётность. Механика проста, но дисциплина критична: каждое измерение при проектировании должно получить явную пометку, какие атрибуты историзируются.

Inmon: корпоративная фабрика информации

Билл Инмон (Bill Inmon, «Building the Data Warehouse», 1992) настаивал на обратном порядке: сначала единое нормализованное (3NF) корпоративное хранилище — интегрированная, предметно-ориентированная, неизменяемая, историческая база, — а уже из неё нарезаются витрины под задачи (архитектура Corporate Information Factory, CIF). Подход Инмона даёт целостность, но требует спроектировать модель всего предприятия заранее — в быстро меняющемся бизнесе это почти всегда проваливается по срокам. Исторический компромисс индустрии: ядро по мотивам Инмона там, где домен стабилен, витрины по Кимбаллу — везде, где потребляют данные.

Data Vault 2.0: устойчивость к изменениям

Дэн Линстедт (Dan Linstedt; книга «Building a Scalable Data Warehouse with Data Vault 2.0», 2015 — O'Reilly) предложил третью школу, спроектированную специально под два свойства: источники постоянно меняются, а аудит должен быть полным. Модель раскладывает данные на три типа таблиц. Хабы (hubs) хранят только бизнес-ключи сущностей (ИНН контрагента, номер договора) и ничего больше. Линки (links) — только связи между хабами (договор ↔ контрагент ↔ юрлицо группы). Сателлиты (satellites) — все описательные атрибуты, привязанные к хабу или линку, с меткой времени загрузки и указанием источника. Всё хранилище — insert-only: ничего не обновляется и не удаляется, новая версия атрибутов — новая строка сателлита.

Почему это устойчиво к изменениям: когда у источника появляется новый атрибут или подключается новая система, вы не перестраиваете существующие таблицы — вы добавляете новый сателлит к существующему хабу. Когда меняется бизнес-правило слияния данных, сырая история в сателлитах не тронута — пересчитывается только слой представления. Data Vault явно разделяет «сырую правду» (raw vault — что именно сказал источник и когда) и «бизнес-правду» (business vault — что мы из этого вычислили), и это разделение — та же идея, что в event sourcing, но в мире хранилищ. Плата — большое число таблиц и соединений; поэтому Data Vault почти всегда прячут за слоем витрин по Кимбаллу, а рутинную генерацию таблиц автоматизируют (в экосистеме dbt — пакеты вроде AutomateDV; обзор модели — в Wikipedia: Data Vault modeling).

Битемпоральность: два времени каждого факта

Последний механизм этого раздела — самый недооценённый. У любого факта в учёте есть два независимых времени: valid time — когда факт был истинен в реальности (сотрудник повышен с 1 марта), и transaction time — когда система об этом узнала (кадровик внёс приказ 15 марта). Битемпоральная модель хранит оба, и только она позволяет честно ответить на вопрос аудитора: «что система знала на 10 марта?» — и корректно обработать задним числом исправленную ошибку, не переписывая историю. Для финансовой консолидации холдинга это не роскошь: перепроведение документов задним числом — ежедневная реальность российского учёта, и если хранилище фиксирует только одно время, каждый пересчёт прошлых периодов делает старые отчёты невоспроизводимыми. Формальную основу заложил Ричард Снодграсс (Richard Snodgrass, «Developing Time-Oriented Database Applications in SQL», 1999); стандарт SQL:2011 ввёл поддержку temporal-таблиц, а Мартин Фаулер популяризовал паттерн в заметке Bitemporal History. Заметьте: SCD Type 2 — это однотемпоральная историзация, Data Vault с load_date — тоже; полная битемпоральность требует явного проектирования обеих осей.

5.4. Event sourcing и CQRS: событие как первичный факт

Битемпоральность и insert-only-хранилища — частные проявления более общего принципа, который в мире прикладных систем оформился как event sourcing (событийное происхождение состояния). Классическая система хранит текущее состояние: в таблице invoices лежит строка счёта со статусом «оплачен». Event sourcing переворачивает это: первичным хранимым фактом является событие — «счёт выставлен», «счёт отправлен», «поступила оплата», — а текущее состояние есть производная, результат последовательного применения всех событий. Грег Янг (Greg Young), оформивший паттерн вместе с CQRS в конце 2000-х, формулировал это так: текущее состояние — это левая свёртка (left fold) предыдущих поведений системы (его канонический доклад — «CQRS and Event Sourcing», Code on the Beach 2014; текстовая расшифровка — на kurrent.io).

Механика такова. События пишутся в журнал событий (event store) строго последовательно и никогда не изменяются — только добавляются. Чтобы получить состояние агрегата (счёта, договора, заказа), система проигрывает его события; чтобы не проигрывать тысячи событий каждый раз, периодически сохраняются снимки (snapshots). Из того же журнала строятся проекции (projections) — материализованные представления под конкретные запросы: список неоплаченных счетов, дебиторка по контрагенту, лента активности клиента. Проекция — это одноразовая, пересоздаваемая вещь: изменилось требование к отчёту — вы пишете новую проекцию и проигрываете через неё весь журнал с начала времён. Это свойство, невозможное в state-based системах, называют retroactive query: вопрос, заданный сегодня, получает ответ по всей истории, как будто его задали в первый день.

CQRS (Command Query Responsibility Segregation — разделение ответственности команд и запросов) — парный паттерн: модель для записи (команды, проходящие через бизнес-правила и порождающие события) отделяется от моделей для чтения (проекций). Мартин Фаулер, описавший оба паттерна в своём каталоге (Event Sourcing, CQRS), настойчиво предупреждает: CQRS — не архитектура всей системы, а локальный паттерн для отдельного ограниченного контекста (bounded context), и применённый повсеместно он добавляет сложности больше, чем пользы.

Чем event sourcing ценен именно для безлюдного движка — три свойства. Первое: аудит-трейл бесплатно. Журнал событий и есть полный, неизменяемый, юридически осмысленный след того, что произошло, — в компании, где действия совершают агенты, это не приятный бонус, а условие выживания: любое действие агента должно быть восстановимо («кто, что, когда, на каком основании»). Второе: события — естественный интерфейс для агентов и автоматизации. Подписка «когда появляется событие "акт подписан" — запусти процесс выставления счёта» выражается тривиально; в state-based системе для этого пришлось бы опрашивать таблицы или навешивать триггеры. Третье: событие фиксирует намерение (intent): «клиент сменил адрес доставки» и «оператор исправил опечатку в адресе» дают одинаковое конечное состояние, но совершенно разную информацию — и для аналитики, и для LLM-агента, читающего историю клиента, разница огромна.

Теперь о том, когда event sourcing — оверкилл. Опыт индустрии 2015–2025 годов дал ясный список ловушек. Схемы событий эволюционируют, и через три года вы держите в журнале пять версий события «счёт выставлен» — нужна стратегия версионирования (этому Янг посвятил отдельную книгу «Versioning in an Event Sourced System»). Проекции асинхронны — читатели видят состояние с задержкой (eventual consistency), и UX/процессы должны это учитывать. Команде, привыкшей к CRUD, паттерн даётся тяжело. Поэтому зрелая рекомендация: event sourcing — для ядровых доменов с богатой историей и требованиями аудита (финансовые операции, договорной цикл, действия агентов), обычный CRUD с журналом изменений (change data capture, CDC) — для всего остального. Важный практический нюанс: брокер сообщений Kafka сам по себе — не event store (нет чтения потока событий одного агрегата и оптимистичных блокировок); специализированные хранилища — EventStoreDB/Kurrent, Axon, либо журнал событий поверх обычной PostgreSQL, чего в масштабе холдинга на 180 человек более чем достаточно.

Отметим симметрию, которая делает эту главу цельной: event sourcing в приложениях, insert-only-сателлиты в Data Vault, immutable-журнал в бухгалтерском учёте (проводки не стирают — делают сторно) и лог транзакций в СУБД — это одна и та же идея: истина — это журнал, состояние — это кэш. Бухгалтерия практикует event sourcing пятьсот лет; цифровой движок просто возвращает учёту его исходную форму.

5.5. Data mesh: данные как продукт, доменное владение — и откат хайпа

В 2019 году Жамак Дегани (Zhamak Dehghani), тогда — консультант ThoughtWorks, опубликовала на сайте Мартина Фаулера статью о data mesh — распределённой альтернативе централизованному озеру данных, а в 2022-м выпустила книгу «Data Mesh: Delivering Data-Driven Value at Scale» (O'Reilly). Диагноз был точен: центральная команда данных становится бутылочным горлышком — она не знает предметных областей, тонет в заявках, а доменные команды, которые данные порождают, не отвечают за их качество («перебросили через забор — дальше не наша проблема»). Data mesh предложил четыре принципа: доменное владение (данные принадлежат команде домена, а не центральной платформе), данные как продукт (data as a product: у датасета есть владелец, SLA, документация, потребители — «клиенты»), самообслуживаемая платформа данных (домены публикуют данные сами, без тикетов в центральную команду) и федеративное вычислительное руководство (общие стандарты применяются автоматически, кодом — тот самый computational governance из раздела 5.2).

К 2024–2025 годам по хайпу прокатился откат: посты «data mesh мёртв» стали жанром (характерный пример — разбор на Medium; взвешенную позицию «проблема была не в идее, а в реализации» см. у Billy Newport). Причины отката поучительны. Во-первых, data mesh — организационная трансформация, а её продавали как архитектуру: компании покупали «инструменты для data mesh», не меняя ответственности команд, и получали тот же хаос, но распределённый. Во-вторых, полный mesh требует, чтобы в каждом домене жила своя дата-инженерная компетенция, — это посильно компаниям масштаба Zalando или Intuit и разорительно для всех остальных. В-третьих, LLM-волна 2023–2025 сместила бюджеты и внимание: рынку стало не до реорганизаций аналитики.

Что из data mesh выжило и стало мейнстримом — это важнее некролога. Выжила идея «данные как продукт»: у каждого значимого датасета должен быть владелец, документация, гарантии качества и понятные потребители. Выжил computational governance. И выжили data contracts (контракты на данные) — формализованное соглашение между производителем и потребителем данных: схема, семантика полей, SLA по свежести и полноте, правила эволюции (какие изменения обратно совместимы), канал уведомления о breaking changes. Контракт живёт в git, проверяется в CI производителя: изменил тип поля — сборка падает до того, как сломались дашборды потребителей. Главный евангелист подхода — Чед Сандерсон (Chad Sanderson, бывший руководитель платформы данных Convoy, соавтор книги «Data Contracts» у O'Reilly); появился и открытый стандарт описания контрактов — Open Data Contract Standard (ODCS) проекта Bitol под эгидой Linux Foundation AI & Data (непроверено в деталях версий).

Для холдинга Алексея мораль двойная. Полный data mesh — очевидный оверкилл: при 180 сотрудниках нет ни десятка доменных команд, ни ресурсов на федерацию. Но принципы стоит применить к другому разрезу: домены = юрлица и функции холдинга, а «команды-владельцы» — это связки «системный владелец + агент-стюард». Каждый бизнес-актив публикует свои данные в общий слой как продукт с контрактом; управляющая компания потребляет их для консолидации. Контракты при этом важнее вдвойне: потребителем данных выступает не человек, способный заметить странность, а агент, который честно построит отчёт на сломанных данных.

5.6. Semantic layer и metrics layer: «одна выручка» для людей и агентов

Каждая компания рано или поздно обнаруживает у себя «проблему трёх выручек»: финансы считают выручку по актам, продажи — по оплатам, продуктовая команда — по MRR, и на планёрке три числа не сходятся. Причина не в данных, а в определениях: метрика «выручка» нигде не определена формально, и каждый инструмент BI, каждый SQL-аналитик и каждый Excel переопределяют её заново. Semantic layer (семантический слой) — это архитектурный ответ: отдельный слой, в котором бизнес-понятия (сущности, измерения, метрики и связи между ними) определены один раз, декларативно, и из которого любой потребитель — дашборд, SQL-запрос, LLM-агент — получает одно и то же вычисление.

Механика на примере современного стека. В LookML (язык Looker, придуман около 2012 года и купленный Google вместе с Looker в 2019-м за $2.6 млрд) аналитик описывает views с измерениями (dimensions) и мерами (measures) и explores со связями-джойнами; когда пользователь щёлкает «выручка по месяцам», Looker генерирует SQL из этих определений — руками SQL никто не пишет. dbt Semantic Layer на движке MetricFlow (dbt Labs купила компанию Transform в 2023-м) делает то же поверх dbt-моделей: метрика описывается в YAML — тип агрегации, мера, фильтры, допустимые измерения, — а MetricFlow компилирует запрос «metric: revenue, group by: month, region» в корректный SQL с правильными джойнами и гранулярностью. Cube — независимый semantic layer с кэшированием и API (REST, GraphQL, SQL), который в 2024–2026 годах прямо позиционирует себя как «семантический слой для AI-агентов». Общий принцип один: определение метрики — это код, живущий в git, с ревью и версионированием, а не формула, зашитая в дашборд.

До 2023 года semantic layer был «гигиеной для BI» — полезной, но необязательной. LLM-волна сделала его критической инфраструктурой, и тут есть жёсткие цифры. Бенчмарки dbt Labs показывают: в 2023 году GPT-4, генерируя SQL напрямую по схеме базы, отвечал верно лишь на 32.7% аналитических вопросов, тогда как через семантический слой — на 60.5%; к 2026 году модели уровня Claude Sonnet 4.6 и GPT-5.3 на хорошо смоделированных данных дают 84–90% в режиме text-to-SQL и 98–100% через semantic layer (dbt Semantic Layer vs. Text-to-SQL: 2026 Benchmark). Но проценты — не главное. Главное — режим отказа: text-to-SQL ошибается правдоподобно (запрос выполнился, число выглядит разумно, но джойн раздул строки вдвое), а semantic layer ошибается прозрачно — либо метрика определена и посчитана детерминированно правильно, либо запрос явно невозможен. Для автономного агента, чьи отчёты никто не перепроверяет, разница между «тихо неверно» и «громко невозможно» — это разница между катастрофой и штатной эскалацией.

Отсюда практический паттерн 2025–2026 годов: агент получает не доступ к базе, а доступ к семантическому слою (через API или MCP-сервер), где «выручка», «маржа», «загрузка производства» уже определены финансовым директором и закреплены ревью. Свободный text-to-SQL остаётся для исследовательских ad-hoc-вопросов с обязательной пометкой «неверифицированный расчёт». В 2026 году dbt Labs, по её анонсу, открыла MetricFlow под лицензией Apache 2.0 (непроверено; исторически движок жил под BSL), мотивируя это тем, что управляемые метрики — основа доверия к AI-агентам (анонс dbt Labs).

5.7. Онтологии предприятия и knowledge graphs

Семантический слой отвечает на вопрос «как посчитать метрику», но не отвечает на вопрос «как устроен мир компании»: что такое договор, чем заказчик отличается от плательщика, может ли один сотрудник работать в двух юрлицах, что происходит с проектом при расторжении договора. Формальное описание понятий предметной области, их свойств и связей называется онтологией (ontology), а её наполненная данными реализация — графом знаний (knowledge graph).

Классический технологический фундамент пришёл из Semantic Web начала 2000-х: RDF (Resource Description Framework) представляет знания как триплеты «субъект — предикат — объект» («Договор_42 — заключён_с — Контрагент_7»), OWL (Web Ontology Language) задаёт классы, свойства и аксиомы (например, «у договора ровно один плательщик», «дочерняя компания — транзитивно часть группы»), а язык SPARQL позволяет запрашивать граф. Сила подхода — в выводе (reasoning): из аксиом и фактов машина выводит неявные факты. Слабость — в пороге входа: полноценные OWL-онтологии требуют редкой квалификации, и за пределами фармы, финансов и оборонки они приживались плохо. Показательный отраслевой пример — FIBO (Financial Industry Business Ontology) от EDM Council: открытая онтология финансовой индустрии, формализующая тысячи понятий — от юридических лиц и долей владения до деривативов, — используемая банками для регуляторной отчётности и интеграции данных; это доказательство, что онтология масштаба целой отрасли возможна, и одновременно иллюстрация её цены (FIBO развивается консорциумом с 2010-х).

Коммерческий образец другого рода — Palantir Foundry Ontology, самый успешный пример «операционной онтологии» на рынке. В Foundry онтология — это не документация, а исполняемый слой из трёх элементов: объекты (object types — «Завод», «Заказ», «Партия», «Сотрудник» с их свойствами, привязанными к источникам данных), связи (link types — «Заказ размещён на Заводе»), и — ключевое отличие от академических онтологий — действия (action types — «перенести заказ», «остановить линию»), то есть операции с правилами валидации и правами, через которые единственно и можно менять мир. Онтология Palantir двунаправленна: она не только читает данные (semantic layer), но и записывает решения обратно в операционные системы (kinetic layer, слой записи обратно, writeback). Поверх этого работает AIP (Artificial Intelligence Platform): LLM-агент видит мир через объекты и связи, а действовать может только через типизированные действия с валидацией — онтология одновременно служит агенту картой мира и клеткой безопасности (сопоставление парадигм Semantic Web и Palantir — см. разбор Pebblous; первоисточник — документация Palantir Ontology). Именно эта конструкция — самый прямой из существующих на рынке прообразов безлюдного бизнес-движка.

Интерес к графам знаний резко вырос с приходом GenAI, и это не совпадение. Gartner в исследованиях 2024–2025 годов устойчиво называет knowledge graphs ключевой технологией заземления (grounding) генеративных моделей: граф даёт LLM проверяемую структуру фактов вместо статистической догадки, снижая галлюцинации и позволяя объяснить ответ цепочкой связей (см. обзоры Gartner о семантических технологиях 2025 и CIO: Knowledge graphs — the missing link in enterprise AI). Практическое воплощение — паттерн GraphRAG (Microsoft Research, 2024): вместо поиска по кускам текста агент обходит граф сущностей и связей, извлечённый из корпоративных документов, что радикально улучшает ответы на вопросы, требующие соединения фактов из разных мест.

Важная прививка от перфекционизма: онтология предприятия для холдинга из 180 человек — это не OWL-монумент на три года работы. Это прагматичный словарь из 20–40 типов объектов (юрлицо, контрагент, договор, заказ, счёт, акт, сотрудник, роль, проект, продукт, метрика…), их связей и допустимых действий, записанный в машиночитаемой форме (хоть YAML, хоть property graph в Neo4j) и связанный с мастер-данными: узел графа «Контрагент_7» — это та же золотая запись из раздела 5.1. Онтология — то место, где MDM, семантический слой и агентный доступ сходятся в одну конструкцию.

5.8. Modern data stack и его судьба: от кембрийского взрыва к консолидации

Чтобы принимать инструментальные решения, нужно понимать двадцатилетнюю траекторию рынка. До 2010-х аналитические данные жили в дорогих on-premise хранилищах (Teradata, Oracle), и данные перед загрузкой преобразовывали снаружи — ETL (extract, transform, load). Облачные хранилища — Snowflake (отделение хранения от вычислений, эластичность), BigQuery (serverless), ClickHouse (открытая колоночная СУБД с экстремальной скоростью, российского происхождения — вырос из Яндекс.Метрики) — сделали вычисления дешёвыми, и порядок сменился на ELT: грузим сырьё как есть, преобразуем внутри хранилища. Вокруг этой идеи в 2016–2021 годах вырос modern data stack (MDS): Fivetran/Airbyte таскают данные из SaaS-систем в хранилище, dbt превратил преобразования в инженерную дисциплину (SQL-модели в git, тесты, документация, lineage), BI-инструменты читают витрины, а reverse ETL (Census, Hightouch) возвращает вычисленные данные обратно в операционные системы — сегменты клиентов в CRM, скоринг в маркетинг. Параллельно Databricks развивал альтернативную линию lakehouse («озёрный дом»): данные лежат в открытых табличных форматах (Delta Lake, Apache Iceberg, Hudi) в дешёвом объектном хранилище, а движки — SQL, Spark, ML — подключаются сверху; покупка Databricks компании Tabular (создатели Iceberg) в июне 2024 года за сумму, оцениваемую свыше $1 млрд, зафиксировала победу открытых форматов: теперь и Snowflake, и BigQuery, и Databricks читают Iceberg-таблицы, и данные перестали быть заложниками вендора.

Дальше случилось то, что случается со всяким кембрийским взрывом: вымирание и консолидация. Стек из «лучших в своём классе» инструментов означал для покупателя десяток контрактов, интеграционный клей и размазанную ответственность — а с 2023 года бюджеты и внимание ушли в AI. Рынок 2024–2026 годов сжался в несколько платформ: Salesforce купила Informatica (сделка ~$8 млрд, анонсирована в мае 2025-го) ради данных для агентной платформы; Fivetran за 2025 год поглотила Census (reverse ETL) и Tobiko Data (SQLMesh — главный open-source-конкурент dbt; пресс-релиз), а в октябре 2025-го Fivetran и dbt Labs объявили о слиянии в единую компанию (сделка all-stock, оценка объединённой компании порядка $6 млрд (непроверено); анонс dbt Labs, разбор Everest Group). Инвестор Томаш Тунгуз назвал это фазой бандлинга: маятник «разъединение → объединение» качнулся обратно. Показательно, как объединённая компания себя называет: не «modern data stack», а «data layer for AI» — слой данных для ИИ. Хайповое имя умерло, инженерное содержание (ELT, версионируемые преобразования, открытые форматы) стало скучным стандартом.

Для проектировщика движка из этой истории следуют три урока. Первый: выбирать надо не инструменты, а открытые интерфейсы — SQL, Iceberg/Parquet, git-версионируемые преобразования, стандартные протоколы; инструменты будут куплены и переименованы, интерфейсы останутся. Второй: в масштабе 180 человек не нужен «стек из десяти вендоров» — достаточно одного хранилища (для российского контура естественный кандидат — ClickHouse или Postgres-семейство, для международного — Snowflake/BigQuery), dbt-подобного слоя преобразований и семантического слоя. Третий: reverse ETL — концептуально важная деталь: слой данных в безлюдном движке не только «смотрит назад» (отчётность), но и «действует вперёд» — вычисленные сигналы (скоринг контрагента, прогноз кассового разрыва) должны возвращаться в операционный контур, где по ним сработают агенты.

5.9. Data quality и data observability: данные как контракт

Классическая теория качества данных (data quality) измеряет его по измерениям: точность (accuracy), полнота (completeness), согласованность (consistency), своевременность (timeliness), валидность (validity), уникальность (uniqueness). Инженерная практика 2010-х дала инструменты проверок: тесты dbt (уникальность ключа, отсутствие NULL, ссылочная целостность), декларативные ожидания Great Expectations. Но тесты ловят только то, о чём вы догадались спросить. Категорию data observability (наблюдаемость данных) — мониторинг здоровья данных по аналогии с мониторингом приложений (Datadog для данных) — создала компания Monte Carlo; её основательница Барр Мозес (Barr Moses) ввела термин data downtime: периоды, когда данные неполны, ошибочны или устарели, а бизнес об этом не знает и принимает решения. Monte Carlo сформулировала пять столпов наблюдаемости: свежесть (freshness — обновилась ли таблица вовремя), объём (volume — не пришло ли вдвое меньше строк, чем обычно), распределение (distribution — не дрейфуют ли значения: доля NULL, средние, диапазоны), схема (schema — кто и когда изменил структуру: переименованное поле в источнике — самая частая причина тихих поломок), происхождение (lineage — из каких таблиц собрана эта витрина, чтобы при инциденте мгновенно увидеть радиус поражения). Ключевой приём — не ручные правила, а машинное обучение на истории: система сама выучивает, что таблица платежей обновляется к 6 утра и содержит 10–15 тысяч строк в день, и поднимает тревогу при аномалии.

В безлюдном движке смысл этой дисциплины меняется качественно. Человек-аналитик — это встроенный детектор аномалий: он заметит, что выручка за вчера подозрительно нулевая, и не понесёт отчёт директору. Агент не заметит — точнее, заметит только то, что ему велели проверять. Поэтому правило безлюдного движка формулируется жёстко: агенту можно давать только данные, находящиеся под контрактом и мониторингом. Свежесть и полнота из «метрик качества» превращаются в предусловие исполнения: процесс «подготовить платёжный календарь» должен начинаться с машинной проверки «данные банка свежее 24 часов, контракт не нарушен», и при нарушении — останавливаться и эскалировать, а не считать по тухлым данным. Это соединяет наблюдаемость с data contracts из раздела 5.5: контракт декларирует гарантии, observability их непрерывно проверяет, а нарушение автоматически блокирует зависимые процессы (паттерн circuit breaker — «предохранитель» на пайплайне). Показательно, что сама Monte Carlo к 2025–2026 годам переименовала категорию в «Data + AI Observability»: следить теперь надо не только за таблицами, но и за выходами моделей и агентов.

5.10. Single source of truth: почему это миф и как устроено на самом деле

«Единый источник правды» (single source of truth, SSOT) — самое частое требование заказчика к слою данных и самое опасное, если понимать его буквально: «одна база, где лежит всё, и все читают только оттуда». В буквальном смысле SSOT — миф, и вот почему. Во-первых, разные потребители физически требуют разных представлений: операционная запись счёта (нормализованная, транзакционная), аналитическая витрина (денормализованная звезда), поисковый индекс и событийный журнал — это четыре копии одних данных, и ни одну нельзя устранить. Во-вторых, «правда» зависит от момента и точки зрения: правда бухгалтерии — по проведённым документам, правда продаж — по подписанным договорам, и обе легитимны (вспомните битемпоральность: даже время у правды двоится). В-третьих, любая попытка загнать все системы в одну базу воспроизводит монолит, который слой за слоем обрастает выгрузками в Excel — теневыми копиями, худшими из всех.

Реалистичная формула, к которой пришла индустрия, звучит иначе: не единый источник правды, а единственный авторитетный источник для каждого элемента данных — «одно место правды на домен». Инженерно это раскладывается на четыре правила. Правило первое: для каждой сущности и каждого атрибута явно назначена система записи (system of record, SOR) — место, где данные рождаются и правятся: кадровые данные — в HR-системе, юридические реквизиты — в MDM-хабе (с подпиткой из госреестров), сделки — в CRM, проводки — в учётной системе; всё остальное — производные копии, которым запрещено становиться источником правок. Правило второе: производные копии создаются только управляемыми потоками (CDC, событийный журнал, ELT) с известным происхождением (lineage) и задержкой — тогда копий может быть сколько угодно, они дешёвые и одноразовые. Правило третье: правда о смыслах централизуется даже тогда, когда правда о данных распределена: реестр определений (онтология, семантический слой, справочники) — один на группу. Правило четвёртое: расхождения не «исключаются», а непрерывно сверяются машиной — реконсиляция между системой записи и копиями с автоматическим инцидентом при расхождении (в бухгалтерии это называется сверкой и практикуется веками; движок лишь делает её непрерывной).

Заметьте, как собирается конструкция главы: MDM даёт одно место правды о сущностях, событийный журнал — о происходившем, семантический слой — о метриках, онтология — о понятиях, data contracts — о гарантиях на границах. «Единый источник правды» существует, но это не база данных, а дисциплина адресации: на любой вопрос «где правда об X?» у движка есть однозначный, машиночитаемый ответ.

5.11. Слой данных под LLM-агентов: RAG, text-to-SQL, MCP, семантика

Всё, что описано выше, к 2024–2026 годам получило нового главного потребителя: не аналитика-человека, а LLM-агента. Разберём четыре механизма, через которые агент получает доступ к корпоративным данным, и что каждый из них требует от слоя данных.

RAG (retrieval-augmented generation — генерация с дополнением поиском) — базовый паттерн для неструктурированных данных: документы компании режутся на фрагменты, превращаются в векторные представления (embeddings), складываются в векторный индекс; на вопрос агента система достаёт релевантные фрагменты и подаёт их модели в контекст вместе с вопросом. RAG хорошо отвечает на вопросы «что написано в договоре с X о неустойке», но плохо — на вопросы, требующие соединения фактов из многих документов; здесь его усиливает GraphRAG из раздела 5.7 (обход графа сущностей вместо поиска по кускам) и гибридный поиск (векторный + ключевой + фильтры по метаданным из MDM: агенту, работающему на юрлицо А, не должны выпадать документы юрлица Б — это вопрос не качества, а безопасности периметра).

Text-to-SQL — для структурированных данных. Здесь важно откалибровать ожидания эмпирикой. На академическом бенчмарке Spider модели давно показывают за 90% точности, но бенчмарк Spider 2.0 (ICLR 2025), собранный из реальных корпоративных задач — тысячи таблиц, диалекты BigQuery/Snowflake, многошаговые запросы, — отрезвил индустрию: лучшие модели конца 2024 года решали лишь около 17–21% задач. К 2026 году модели стали заметно сильнее (см. цифры dbt-бенчмарка в разделе 5.6: 84–90% на хорошо смоделированной схеме), но выводы устойчивы: точность text-to-SQL — это функция качества слоя данных, а не только модели. Понятные имена таблиц и колонок, описания в каталоге, малое число хорошо документированных витрин вместо тысяч сырых таблиц, примеры запросов — всё это «дизайн данных под читателя-LLM», и он поднимает точность сильнее, чем смена модели.

Semantic layer как язык агента — самый надёжный режим для бизнес-метрик, разобранный в 5.6: агент не пишет SQL, а формулирует запрос в терминах метрик и измерений, определённых людьми. По сути, семантический слой и онтология образуют язык, на котором агент думает о бизнесе: словарь сущностей (онтология), словарь показателей (метрики), грамматика допустимых действий (actions). Чем полнее этот язык, тем меньше агент фантазирует.

MCP (Model Context Protocol — протокол контекста моделей) — транспортный стандарт, замкнувший конструкцию. Представленный Anthropic в ноябре 2024 года и в течение 2025-го принятый остальными вендорами (OpenAI объявил о поддержке в марте 2025-го), в декабре 2025 года протокол был передан в фонд Agentic AI Foundation под эгидой Linux Foundation и стал вендор-нейтральным стандартом (состояние на 2026 год). MCP-сервер описывает набор инструментов (tools) и ресурсов, которые агент может вызывать; для слоя данных это означает, что хранилище, семантический слой и каталог публикуют агенту типизированные операции: «список метрик», «запросить метрику», «описание таблицы», «выполнить читающий запрос». Такие серверы к 2026 году штатно поставляют и Snowflake (managed MCP servers), и dbt (dbt MCP server), и большинство каталогов данных. Критически важно, что MCP-сервер — это точка применения политик: именно здесь проверяются права агента (какие юрлица, какие домены, только чтение), режется контекст, пишется журнал обращений. Прямой доступ агента к базе по JDBC — антипаттерн по всем осям: без семантики, без прав, без журнала.

Собирая четыре механизма вместе, получаем эталонную архитектуру агентного доступа к данным безлюдного движка: неструктурированное — через RAG/GraphRAG с фильтрами периметра; метрики — через semantic layer; исследовательские запросы — через text-to-SQL по документированным витринам с пометкой неверифицированности; всё — через MCP-серверы с политиками, и никогда — мимо них.

5.12. Сквозной кейс: слой данных для холдинга из пяти юрлиц

Соберём теперь материал главы в проектное упражнение, максимально близкое к задаче Алексея. Дано: управляющая компания (УК) и четыре бизнес-актива — сервисная разработка, два продуктовых юрлица, новое AI-направление. Учёт в нескольких базах 1С (по юрлицу), продажи в CRM, проекты в трекере, кадры в HR-системе, банковские выписки из четырёх банков. Требуется слой данных, позволяющий УК видеть консолидированную картину и дающий агентам почву для операционной работы, — командой в одного дата-инженера с агентами.

Шаг 1. Онтология и карта правды (недели 1–2). Прежде любого кода — словарь группы: типы объектов (юрлицо, контрагент, договор, заказ, счёт, акт, платёж, сотрудник, назначение, проект, продукт, метрика), их связи и действия над ними; параллельно — карта «сущность/атрибут → система записи» из раздела 5.10. Уже на этом шаге вскрываются главные развилки: сотрудник в двух юрлицах — одна сущность «человек» с двумя «назначениями»; внутригрупповые договоры — отдельный тип связи, который при консолидации элиминируется.

Шаг 2. MDM-хаб в стиле registry/consolidation (недели 2–6). Лёгкий хаб (достаточно PostgreSQL): таблицы сущностей с глобальными идентификаторами, кросс-ссылки на записи в 1С/CRM/HR, матчинг по ИНН+нечёткое имя, поатрибутные правила выживания (реквизиты — из госреестра-провайдера, контакты — из CRM). Серая зона матчинга — очередь агента-стюарда с журналом решений; человек выборочно проверяет первые месяцы. Выход шага — золотые записи контрагентов и людей, на которые дальше ссылается всё.

Шаг 3. Событийный журнал группы (недели 4–8). Insert-only журнал бизнес-событий в общем хранилище: из 1С и CRM события снимаются CDC/выгрузками («проведён документ», «сделка передвинута»), из новых агентных процессов пишутся нативно («агент сформировал платёжный календарь», основание, версия данных). Каждое событие несёт transaction time и valid time. Полный event sourcing не внедряется — существующие системы остаются системами записи; журнал — это общая событийная история группы и аудит-трейл агентов.

Шаг 4. Хранилище и витрины (недели 6–10). Одно аналитическое хранилище; сырьё — insert-only с фиксацией источника (по мотивам Data Vault, без фанатизма: хабы/сателлиты — только для контрагентов, договоров, людей); поверх — dbt-преобразования с тестами и звёздные витрины: консолидированная выручка (с элиминацией внутригрупповых оборотов), денежный поток по группе, утилизация людей, юнит-экономика продуктов. Измерения витрин строятся из MDM-хаба — конформность бесплатно.

Шаг 5. Семантический слой и контракты (недели 8–12). Реестр из первых 15–20 метрик группы в YAML с владельцами (выручка — финдиректор, утилизация — операционный директор), скомпилированный в semantic layer. На границах «актив → УК» — data contracts: схема, свежесть (например, «управленческие данные актива — T+1 до 9:00»), правила эволюции; проверка в CI. Наблюдаемость — тесты dbt + мониторинг свежести/объёма с алертами.

Шаг 6. Агентный доступ (недели 10–14). MCP-серверы: семантический слой (метрики — для еженедельного отчёта УК, который собирает агент), каталог витрин (text-to-SQL для ad-hoc вопросов партнёров с пометкой неверифицированности), RAG по договорам с фильтром юрлица. Права агентов — в разрезе юрлиц и доменов; каждый вызов — в событийный журнал.

Итог — не «платформа данных» в корпоративном смысле, а компактный контур: один хаб, один журнал, одно хранилище, один реестр метрик, три MCP-сервера. Существенно, что порядок шагов неслучаен: онтология и карта правды до инструментов, мастер-данные до витрин, семантика до агентов. Обратный порядок — «сначала подключим агентов к данным, потом наведём порядок» — гарантированно производит систему, которая быстро и уверенно отвечает неправильно.

Источники и куда копать глубже