DataForge против dbt: Semantic-first vs SQL-first

16.12.2025

Современные архитектуры хранилищ данных становятся всё более сложными.

Компаниям нужно работать с:

• растущими объёмами информации,
• десятками источников,
• различными форматами данных,
• гибридными и облачными окружениями,
• повышенными требованиями к качеству,
• множеством BI-инструментов,
• развитием self-service,
• появлением AI-агентов и LLM-интеграций.

На фоне этого возникает естественный вопрос:

Какой инструмент лучше использовать на уровне трансформаций и формирования витрин данных?

dbt и DataForge — два инструмента, которые решают задачи преобразования данных, но делают это принципиально разными методами:

• dbt — инструмент для data engineers, который строит DWH путём написания SQL-моделей.
• DataForge — инструмент для аналитиков и BI-разработчиков, который строит DWH на уровне бизнес-моделей и семантики показателей, генерируя SQL автоматически.

Чтобы понять разницу, важно разобраться:
какие процессы происходят на уровне Data Marts (Gold/Platinum слои), какие требования предъявляются к семантической модели, и почему подходы “semantic-first” и “SQL-first” дают разные результаты.

Эта статья — глубокое методологическое объяснение.

1. Как устроен dbt: подход SQL-first

1.1. Ключевая философия dbt

dbt исходит из идеи, что:

• вся логика трансформаций должна быть записана в SQL;
• модели должны состоять из SQL-выражений;
• разработчик управляет вычислениями, джоинами, фильтрами и агрегатами вручную;
• код является основным способом документировать намерения.

Иными словами, dbt — это инструмент автоматизации SQL-инженеров.

Его сильная сторона — формализация pipeline:
пакеты, референсы, зависимости, версии моделей, линейдж, CI/CD.

dbt очень хорошо работает в командах, где:

• data engineers пишут SQL руками,
• архитектура хранилища строится инженерами,
• бизнес-семантика вынесена в документацию,
• BI-разработчики работают поверх уже готовых витрин.

1.2. Чем dbt привлекателен инженерам

• строгое управление зависимостями;
• модульность SQL;
• CI/CD для данных (тесты, проверки, автоматические сборки);
• управление материализациями (view/table);
• поддержка окружений dev/stage/prod;
• интеграция с git.

dbt вырос из инженерной культуры — там, где логика определяется кодом.

1.3. Где dbt испытывает ограничения

1. dbt не работает на уровне бизнес-смыслов.
Он не знает, что такое Gross Profit, что такое Net Sales, что такое Conversion.

2. dbt не управляет каталогом показателей и измерений.
В нём нет семантического слоя, KPI dictionary, lineage метрик или бизнес-описаний.

3. dbt не поддерживает визуальное моделирование.
Всё — код.
Даже для простых операций нужен SQL.

4. dbt плохо подходит для BI-ролей.
BI-разработчики и аналитики редко пишут SQL такого уровня.

5. dbt не формирует data marts автоматически.
Каждую витрину нужно писать вручную.

6. dbt не обеспечивает self-service.
Для любой трансформации нужен инженер.

7. dbt не может работать как back-end для AI.
У AI нет доступа к смыслам данных, только к SQL-моделям.

2. Как устроен DataForge: подход Semantic-first

DataForge исходит из другой философии:

• сначала создаётся модель сущностей, показателей и связей (семантика),
• затем эта семантика превращается в витрины и таблицы,
• SQL является результатом, а не средством.

То есть:

Центром архитектуры является смысл данных, а не код.

Семантический слой DataForge включает:

• показатели (measures),
• измерения (dimensions),
• бизнес-формулы,
• метаданные источников,
• привязки к физическим таблицам,
• бизнес-описания,
• группировки, варианты значений,
• lineage,
• ответственность за данные.

SQL при необходимости генерируется автоматически.

2.1. Что DataForge делает иначе

• логика KPI не пишется вручную;
• связи между фактами и измерениями задаются визуально;
• DDL и DML генерируются автоматически;
• любое изменение требований отражается сразу во всех слоях;
• все модели документируются автоматически;
• API позволяет использовать семантику в BI, ML и AI.

DataForge вырос не из инженерной культуры SQL, а из культуры Data Governance + BI + архитектуры DWH.

3. Основные различия: таблица “dbt vs DataForge”

Функция	dbt	DataForge
Основной фокус	SQL-трансформации	Семантика, бизнес-логика, модели
Тип пользователей	Data Engineers	Аналитики, архитекторы, BI
Notion: “Что первично?”	SQL	Бизнес-смысл
Создание витрин	Ручное, SQL	Автоматическое по модели
Семантический слой	Нет	Есть
Документация	Отдельно	Автоматическая
Self-service	Нет	Да
Интеграция с AI	Ограничена	Полная через semantic API
Role in Medallion Architecture	Silver-level ETL	Gold/Platinum semantic modeling
Влияние на развитие DWH	Через код	Через модели и семантику
Необходимость писать SQL	Да	Нет

4. Кому подходит dbt, а кому DataForge

4.1. Когда dbt — лучший выбор

• в компании есть сильная команда дата-инженеров;
• объём трансформаций большой, но отчёты стандартизированы;
• бизнес редко меняет требования к метрикам;
• BI работает поверх одного типа витрин;
• бизнес не работает с семантикой самостоятельно.

4.2. Когда лучше подходит DataForge

• бизнес активно меняет показатели;
• много BI-систем, нужно единое описание метрик;
• требуется self-service;
• бизнес хочет понимать логику KPI;
• Data Governance важнее, чем простое создание SQL;
• витрины должны собираться визуально;
• компания хочет использовать AI для работы с данными.

5. Глубокое объяснение разницы подходов

5.1. SQL-first: слабый контроль смысла

В SQL-first подходе смысл хранится:

• в голове аналитиков,
• в документах,
• в BI-инструментах,
• в коде dbt.

Можно сказать, что смысл “распылён”.

Это приводит к тому, что:

• одни и те же показатели рассчитываются по-разному,
• lineage строится только по таблицам, но не по метрикам,
• сложно объяснить, почему значение KPI стало именно таким.

dbt не знает, что один и тот же показатель может иметь разные формулы в зависимости от контекста.

5.2. Semantic-first: управление смыслом в центре архитектуры

В DataForge показатель — это:

• бизнес-описание,
• техническая формула,
• список зависимостей,
• привязка к источникам,
• ограничения,
• видимость,
• ответственное подразделение,
• версия изменений.

Здесь смысл данных становится объектом управления.

Витрины строятся так:

Бизнес определяет → Аналитик описывает → DataForge собирает → SQL генерируется → Таблица создаётся.

6. Кейсы

Кейс 1. Несогласованные KPI между подразделениями

Ситуация

В большой торговой компании показатель “Gross Margin” использовался в:

• финансовой отчётности,
• маркетинге,
• коммерции,
• BI-дашбордах.

Формула отличалась на уровне:

• учёта промо,
• логистических расходов,
• возвратов,
• экспортных продаж.

В dbt каждая команда писала свою модель.
Объективного эталона не существовало.

Как решается в DataForge

Показатель фиксируется один раз.
Все витрины используют одну семантическую формулу.

Кейс 2. Быстрая адаптация к изменению бизнес-логики

Компания меняет определение “active customer”.
В dbt:

• нужно найти все модели, где используется эта логика,
• переписать SQL,
• протестировать,
• пересобрать pipeline.

В DataForge:

• меняется семантический объект,
• все витрины обновляются автоматически.

Кейс 3. AI-аналитика поверх семантики

Пользователь спрашивает:

“Покажи динамику ROI по категориям с учётом возвратов в расчёте.”

AI:

• понимает, что такое ROI,
• знает, что входит в возвраты,
• строит корректный SQL,
• выдаёт график.

В dbt AI не может понять, что такое ROI — нет семантики.

7. Риски подходов и как с ними работать

7.1. Риск: размывание ответственности за модели в dbt

Данные живут в SQL-файлах.
Если инженер уходит — знание исчезает.

Что помогает

Документация.
Но она редко содержит бизнес-контекст.

7.2. Риск: ограниченная гибкость BI-команды

BI-разработчики не могут писать сложный SQL.

Что помогает

DataForge снижает порог работы: drag-n-drop модели.

7.3. Риск: рост количества витрин

При SQL-first подходе витрин становится очень много.
Это усложняет управление.

Что помогает

Семантическое объединение эмоций.

8. Бизнес-ценности от внедрения DataForge

1. Снижение количества витрин в 2–5 раз

Заменяются сотни SQL-моделей единым семантическим описанием.

2. Ускорение создания новых отчётов

Аналитик сам собирает витрину, инженеры не нужны на каждом шаге.

3. Повышение доверия бизнес-пользователей

Все KPI — согласованные, документированные, проверяемые.

4. Ускорение внедрения AI

AI может работать с метриками, а не с SQL.

5. Упрощение Data Governance

Ответственные лица закреплены за метриками.

6. Повышение устойчивости хранилища

Все изменения проходят через семантическую модель.

9. Вопрос–Ответ

Вопрос: Может ли dbt заменить DataForge?

Нет. dbt работает только с SQL.
Он не знает бизнес-смыслов.

Вопрос: Может ли DataForge заменить dbt?

В Silver-слое — нет.
DataForge работает на Gold/Platinum.

Вопрос: Какие компетенции нужны для работы с DataForge?

Знание бизнес-смыслов.
SQL писать не нужно.

Вопрос: Можно ли использовать DataForge и dbt вместе?

Да.
dbt — для технических преобразований.
DataForge — для семантических и витринных.

Вопрос: Почему semantic-first лучше для self-service?

Пользователь работает с KPI, а не с таблицами.

 

Вернуться к статьям

Вернуться на главную