Skip to content

Что такое семантический слой и что на самом деле значит «определить один раз»

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

Обновлено · 6 мин чтения

Одно имя, два числа

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

Обычно это не проблема самих данных. С хранилищем всё в порядке. Беда сидит в другом месте. Определение чистой выручки живёт больше чем в одном месте, поэтому их больше одного.

Семантический слой исправляет ровно этот один сбой. Он даёт метрике единственный дом. Другие люди потом читают метрику, а не выписывают её заново.

Что такое семантический слой

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

  • Сущности. Бизнес-объекты, о которых вы говорите: клиент, заказ, полис, страховой случай.
  • Измерения. Способы их разрезать: регион, продуктовая линейка, месяц, канал.
  • Меры. Числа, каждое с точным выражением, которое его порождает.

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

Семантический слой это контракт, а не копия ваших данных. Он не хранит строк. Он хранит их согласованный смысл и указывает на таблицы, которые их несут.

Что значит «определить один раз»

Один раз означает, что выражение находится ровно в одном месте. Каждый инструмент, которому нужна метрика, читает её оттуда.

  1. Человек определяет меру в хранилище, с её выражением, гранулярностью и фильтрами.
  2. Определение публикуется как управляемый объект. Платформа сама его понимает. Это не документ о платформе.
  3. На каждый вопрос, называющий эту меру, отвечает выполнение сохранённого определения.
  4. Изменение определения меняет каждый ответ, одной правкой, под одной проверкой.

Тест прямолинеен. Измените определение чистой выручки в одном месте. Если каждый дашборд, ноутбук и ассистент следует за ним, метрика определена один раз. Если другие копии приходится искать и править, она никогда не была определена один раз.

Одна идея, четыре названия

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

Salesforce Data 360
Семантическая модель, зарегистрированная в Data 360. Поверхность вопросов, которую она питает, это Tableau Semantics.
Snowflake
Semantic view, внесённая в Horizon Catalog. Поверхность вопросов, которую она питает, это Cortex Analyst.
Databricks
Metric view, внесённая в Unity Catalog. Поверхность вопросов, которую она питает, это Genie.
Palantir AIP
Онтология, опубликованная в Foundry. Типы объектов несут сущности и их измерения, а Function это место, где объявляется мера.

Четыре названия, одна форма. Каждое это именованный объект, содержащий сущности, измерения и меры. Каждое живёт в собственном каталоге платформы, поэтому собственные инструменты платформы его соблюдают. Foundry единственная, кто не назовёт меру за вас. Когда кто-то говорит, что у его компании есть семантический слой, он имеет в виду именно этот объект. Спросить, какой из четырёх они построили, приведёт вас к цели быстрее, чем спросить, что он содержит.

Одно замечание из реальной практики, полученное при исследовании живой учётной записи Snowflake. Измерения там должны уточняться своей сущностью. Одно и то же имя измерения часто заведено на двух сущностях с разной гранулярностью, и голое имя могло бы означать любое из них. Snowflake отклоняет его как неоднозначное. Это правильное поведение, и оно делает начало запутанным.

Когда хранилищ больше одного

Внутри одной платформы «определить один раз» это короткая фраза. Большинство компаний хоть какого-то размера используют как минимум две платформы. Это не изменится.

Одна и та же логическая таблица тогда определяется дважды, по разу на платформу, двумя командами под двумя процессами проверки. Оба определения управляемые. Оба всё равно могут разойтись. Ничто ни в одной из платформ не следит за другой.

ТабТотал от Бореон читает каталоги в одну объектную модель. Одна и та же схема и таблица могут встречаться в нескольких местах. Они попадают в модель как один объект, помнящий каждый источник, из которого пришёл, а не как отдельные объекты без связи. Затем каждая пара подключённых хранилищ сравнивается, и там, где две структуры расходятся, разрыв записывается как находка управления, называющая эту пару. Вы читаете это в отчёте, а не на совещании.

Это сравнение читает то, что объявляют каталоги. Один вопрос никогда не задаётся нескольким хранилищам, чтобы проверить, совпадают ли их ответы: запрос, называющий поля более чем из одного, отклоняется, а не маршрутизируется, потому что под ними обоими нет общего движка.

Что он наследует

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

Имя слоя берётся из собственной квалифицированной метки объекта. Комментарий к объекту этого не решает. Таблица в meta находится в слое meta. Таблица в gold находится в gold. Список имён слоёв открыт. Имя, которому никто не научил инструмент, всё равно попадает на своё место. Закрытый список схлопнул бы его в «неизвестно», вместе со всеми другими соглашениями, которых он ещё не встречал.

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

Почему контракт соблюдается принудительно

Опубликованное определение, которое ничто не проверяет, это документ. Ценность проявляется в один момент. Запрос называет меру. Сохранённое определение проверяется до того, как этот запрос выполнится.

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

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

Куда смотреть

  • Семантическая консоль показывает, что синхронизировалось, по каждому хранилищу, со счётчиками и индикаторами паритета.
  • Консоль интеграций показывает, какие учётные данные использовало каждое подключение, с хостом, ролью и хранилищем. Сам секрет никогда не показывается.
  • Запись поля несёт девять атрибутов на поле, включая владельца, стюарда и классификацию. Вы видите, что задокументировано, а что нет.

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