Yuriy Gavrilov: posts tagged ETL

Современный семантический слой на dbt + MetricFlow + DuckDB: макросы вместо пакетов

Wed, 09 Sep 2026 22:52:12 +0300

В этой статье мы построим полностью рабочий семантический слой для аналитики на данных Superstore.csv (от Tableau Desktop, можно скачать его где-то), используя dbt, MetricFlow и DuckDB. Вместо устаревшего пакета `dbt_metrics` (который несовместим с dbt 1.12+), мы применим современный подход — вынесем логику метрик в макросы dbt. Это позволяет централизованно управлять расчётами, автоматически обновлять витрины при изменении метрик и использовать семантический слой для ad-hoc-запросов через `mf`. Все шаги проверены на последних версиях инструментов и готовы к использованию в реальных проектах.

1. Зачем нужен семантический слой и почему макросы — это современный подход?

Семантический слой решает ключевые проблемы аналитики:

Единое место определения метрик — бизнес-логика хранится в одном файле.
Автоматическая генерация SQL — не нужно писать `GROUP BY`, `JOIN` и агрегации вручную для ad-hoc-запросов.
Согласованность — аналитики и BI-инструменты используют одни и те же метрики.

Ранее для использования метрик в моделях применялся пакет `dbt_metrics`, но он несовместим с dbt 1.12 и выше (требует версию <1.6.0). Современный подход — **выносить выражения метрик в макросы dbt**. Это:

Не требует внешних пакетов.
Работает с любой версией dbt.
Даёт полный контроль над SQL.
Легко поддерживается и версионируется.

Мы будем использовать:

dbt 1.12.4 — для управления моделями и витринами.
MetricFlow (встроенный в dbt) — для семантического слоя и ad-hoc-запросов через `mf`.
DuckDB 1.5.5 — лёгкая БД для разработки.
Макросы dbt — для переиспользования логики метрик в витринах.

2. Установка инструментов и создание проекта

Используем `uv` — быстрый менеджер пакетов Python.

mkdir dbtflow_duck
cd dbtflow_duck

uv init
uv venv
source .venv/bin/activate

uv pip install dbt-duckdb dbt-metricflow pandas duckdb

Проверяем версии (на момент написания):

dbt-core: 1.12.4
duckdb: 1.5.5
metricflow: 0.212.0

3. Загрузка данных Superstore

Скачайте `Superstore.csv` (например, с Kaggle) и поместите в корень проекта.

Создайте `load_data.py`:

import pandas as pd
import duckdb

df = pd.read_csv('Superstore.csv', sep='\t', encoding='latin1')
df.columns = [col.lower().replace(' ', '_').replace('/', '_').replace('-', '_') for col in df.columns]

for col in ['sales', 'discount', 'profit']:
    if col in df.columns:
        df[col] = df[col].astype(str).str.replace(',', '.').astype(float)

df['order_date'] = pd.to_datetime(df['order_date'], dayfirst=True)
df['ship_date'] = pd.to_datetime(df['ship_date'], dayfirst=True)
df['postal_code'] = df['postal_code'].astype(str)

db_path = 'dbtflow_duck.duckdb'
con = duckdb.connect(db_path)

con.execute("DROP TABLE IF EXISTS superstore")
con.execute("""
CREATE TABLE superstore (
    row_id INTEGER, order_id VARCHAR, order_date DATE, ship_date DATE,
    ship_mode VARCHAR, customer_id VARCHAR, customer_name VARCHAR, segment VARCHAR,
    country_region VARCHAR, city VARCHAR, state VARCHAR, postal_code VARCHAR,
    region VARCHAR, product_id VARCHAR, category VARCHAR, sub_category VARCHAR,
    product_name VARCHAR, sales DOUBLE, quantity INTEGER, discount DOUBLE, profit DOUBLE
)
""")

con.execute("INSERT INTO superstore SELECT * FROM df")
print(f"✅ Загружено {len(df)} строк в {db_path}")
con.close()

Запуск:

python load_data.py

4. Инициализация dbt-проекта вручную

Создаём папку проекта и файлы конфигурации (без `dbt init`, чтобы избежать проблем):

mkdir dbt_project
cd dbt_project

dbt_project.yml:

name: 'dbt_project'
version: '1.0.0'
profile: 'dbt_project'

model-paths: ["models"]
analysis-paths: ["analyses"]
test-paths: ["tests"]
seed-paths: ["seeds"]
macro-paths: ["macros"]
snapshot-paths: ["snapshots"]

clean-targets:
  - "target"
  - "dbt_packages"

models:
  dbt_project:
    +materialized: table

profiles.yml:

dbt_project:
  target: dev
  outputs:
    dev:
      type: duckdb
      path: ../dbtflow_duck.duckdb
      schema: main
      threads: 4

Создаём структуру папок:

mkdir -p models analyses tests seeds macros snapshots
export DBT_PROFILES_DIR=$(pwd)
dbt debug   # должно быть All checks passed!

5. Модели данных

models/sources.yml:

version: 2

sources:
  - name: default
    schema: main
    tables:
      - name: superstore

models/superstore_clean.sql:

{{ config(materialized='table') }}

SELECT
    row_id,
    order_id,
    order_date,
    ship_date,
    ship_mode,
    customer_id,
    customer_name,
    segment,
    country_region,
    city,
    state,
    postal_code,
    region,
    product_id,
    category,
    sub_category,
    product_name,
    sales,
    quantity,
    discount,
    profit
FROM {{ source('default', 'superstore') }}

models/time_spine.sql:

{{ config(materialized='table') }}

SELECT 
    CAST(generate_series AS DATE) AS date_day
FROM generate_series(DATE '2020-01-01', DATE '2026-12-31', INTERVAL '1' DAY)

models/metricflow_time_spine.yml (обязательно для MetricFlow):

models:
  - name: time_spine
    description: "A time spine with one row per day for MetricFlow."
    time_spine:
      standard_granularity_column: date_day
    columns:
      - name: date_day
        granularity: day

6. Семантическая модель и метрики

models/superstore.yml:

semantic_models:
  - name: superstore
    model: ref('superstore_clean')
    description: "Superstore sales data"
    defaults:
      agg_time_dimension: order_date
    
    entities:
      - name: order_id
        type: primary
        
    dimensions:
      - name: order_date
        type: time
        type_params:
          time_granularity: day
      - name: category
        type: categorical
      - name: region
        type: categorical
    
    measures:
      - name: total_sales
        agg: sum
        expr: sales
      - name: total_profit
        agg: sum
        expr: profit
      - name: total_discount
        agg: average          # Внимание: не "avg", а "average"!
        expr: discount

metrics:
  - name: total_sales
    label: Total Sales
    type: simple
    type_params:
      measure: total_sales
  - name: total_profit
    label: Total Profit
    type: simple
    type_params:
      measure: total_profit
  - name: avg_discount
    label: Average Discount
    type: simple
    type_params:
      measure: total_discount
  - name: profit_margin
    label: Profit Margin
    type: derived
    type_params:
      expr: total_profit / total_sales
      metrics:
        - total_profit
        - total_sales

Выполняем сборку и генерацию артефактов:

dbt run
dbt parse

7. Ad-hoc-запросы через MetricFlow CLI (`mf`)

Проверяем конфигурацию:

mf validate-configs

Список метрик:

mf list metrics

Вывод:

• avg_discount: metric_time, order_id__category, order_id__order_date, order_id__region
• profit_margin: metric_time, order_id__category, order_id__order_date, order_id__region
• total_profit: metric_time, order_id__category, order_id__order_date, order_id__region
• total_sales: metric_time, order_id__category, order_id__order_date, order_id__region

Примеры запросов:

mf query --metrics total_sales --group-by order_id__category
mf query --metrics profit_margin --group-by order_id__region
mf query --metrics avg_discount --group-by order_id__category

MetricFlow генерирует SQL автоматически — мы не пишем ни строчки кода для этих запросов.

8. Современный подход: макросы для переиспользования метрик в витринах

Вместо устаревшего пакета `dbt_metrics` мы создадим макросы, которые возвращают SQL-выражение для каждой метрики. Это позволяет:

Централизованно управлять логикой расчёта.
Использовать одну и ту же логику во всех витринах.
Легко изменять метрику в одном месте.

macros/get_metric_expr.sql:

{% macro get_total_sales_expr() %}
    SUM(sales)
{% endmacro %}

{% macro get_total_profit_expr() %}
    SUM(profit)
{% endmacro %}

{% macro get_avg_discount_expr() %}
    AVG(discount)
{% endmacro %}

{% macro get_profit_margin_expr() %}
    {{ get_total_profit_expr() }} / NULLIF({{ get_total_sales_expr() }}, 0)
{% endmacro %}

Теперь мы можем строить витрины, используя эти макросы.

models/sales_by_category.sql:

{{ config(materialized='table') }}

SELECT
    category,
    {{ get_total_sales_expr() }} AS total_sales
FROM {{ ref('superstore_clean') }}
GROUP BY category

models/profit_by_region.sql:

{{ config(materialized='table') }}

SELECT
    region,
    {{ get_total_profit_expr() }} AS total_profit,
    {{ get_profit_margin_expr() }} AS profit_margin
FROM {{ ref('superstore_clean') }}
GROUP BY region

models/avg_discount_by_category.sql:

{{ config(materialized='table') }}

SELECT
    category,
    {{ get_avg_discount_expr() }} AS avg_discount
FROM {{ ref('superstore_clean') }}
GROUP BY category

После добавления новых моделей выполняем `dbt run` — все витрины создаются с актуальной логикой метрик.

9. Преимущества подхода с макросами

Совместимость — работает с любой версией dbt, без внешних пакетов.
Гибкость — можно легко добавлять фильтры, условия, использовать оконные функции.
Прозрачность — SQL-код виден и контролируется, его легко отлаживать.
Единый источник истины — метрики определены как в YAML (для `mf`), так и в макросах (для витрин).
Автоматизация — изменения в макросах автоматически обновляют все витрины при следующем `dbt run`.

10. Расширенный пример: добавление фильтра в метрику

Предположим, нам нужна выручка только для категории “Technology”. Мы можем создать отдельный макрос:

{% macro get_tech_sales_expr() %}
    SUM(CASE WHEN category = 'Technology' THEN sales ELSE 0 END)
{% endmacro %}

И использовать его в витрине:

{{ config(materialized='table') }}

SELECT
    region,
    {{ get_tech_sales_expr() }} AS tech_sales
FROM {{ ref('superstore_clean') }}
GROUP BY region

Это демонстрирует, насколько легко расширять систему без изменения основной семантической модели.

11. Автоматизация пайплайнов

Настройте регулярный запуск `dbt run` в CI/CD или Airflow. При каждом запуске:

Обновляются сырые данные (если они загружаются заново).
Пересчитываются модели `superstore_clean` и `time_spine`.
Пересчитываются все витрины с актуальной логикой метрик из макросов.

Таким образом, ваши отчёты всегда актуальны, а бизнес-логика централизована.

12. Заключение

Мы построили современный семантический слой на стеке dbt + MetricFlow + DuckDB, используя макросы для переиспользования логики метрик в витринах. Этот подход:

Не требует устаревших пакетов.
Совместим с последними версиями dbt.
Даёт полный контроль над SQL.
Легко масштабируется и поддерживается.

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

Полезные ссылки:

dbt открывает исходный код MetricFlow: Управляемые метрики для AI и аналитики

Sat, 01 Nov 2025 01:03:55 +0300

Компания dbt Labs объявила о важном изменении в своей стратегии: `MetricFlow`, ключевая технология, лежащая в основе `dbt Semantic Layer`, становится полностью открытой. Проект переводится под лицензию Apache 2.0, что позволяет любому использовать, изменять и встраивать его в свои продукты. Это стратегический шаг, направленный на создание единого отраслевого стандарта для определения бизнес-метрик, особенно в свете бурного развития AI-систем.

Оригинал тут: https://www.getdbt.com/blog/open-source-metricflow-governed-metrics
А гит тут: https://github.com/dbt-labs/metricflow

Еще кстати есть https://github.com/memiiso/opendbt ( Make dbt great again! :) Может они сольются с метриками, интересно.

Проблема: почему семантический слой стал критически важен

Концепция семантического слоя, который служит промежуточным слоем для определения бизнес-логики (метрик, измерений, связей), не нова. Она уже много лет используется в BI-системах для обеспечения согласованности отчетов. Однако с появлением больших языковых моделей (LLM) и инструментов в стиле “Chat with your data” проблема вышла на новый уровень.

Когда AI-агент или LLM пытается ответить на вопрос, обращаясь напрямую к базе данных, он вынужден самостоятельно генерировать SQL-запрос. При этом модель “угадывает”, какие таблицы нужно соединить (`JOIN`), как правильно отфильтровать данные, какую использовать гранулярность по времени и какие оконные функции применить.

Проблемы такого подхода:

Несогласованность: Две разные модели (или даже одна и та же, но с другим запросом) могут сгенерировать разный SQL для расчета, казалось бы, одной и той же метрики. Это приводит к разным цифрам в отчетах.
Ошибки: LLM может не знать о тонкостях бизнес-логики, например, о том, что при расчете выручки нужно учитывать возвраты или использовать специальный финансовый календарь.
Потеря доверия: Когда пользователи получают противоречивые или неверные данные, доверие ко всей системе аналитики быстро падает.

Метрики не должны быть вероятностными, зависящими от “догадок” LLM при каждом вызове. Они должны быть детерминированными.

`MetricFlow` решает именно эту задачу.

Что такое MetricFlow и как он работает

`MetricFlow` — это движок, который преобразует семантические определения бизнес-понятий в готовый к выполнению и оптимизированный SQL-код. Аналитик один раз определяет метрику “Валовая маржа” на языке `MetricFlow`, и после этого любая система (BI-инструмент, AI-агент, Python-скрипт) может запросить эту метрику по имени, будучи уверенной, что получит корректный и одинаковый результат.

Ключевые изменения и их значение

Лицензия Apache 2.0: Это одно из главных нововведений. Apache 2.0 — это разрешительная лицензия, которая позволяет другим компаниям свободно встраивать `MetricFlow` в свои коммерческие и открытые продукты. Это снимает барьеры для принятия технологии и способствует ее распространению как стандарта.
Сотрудничество с Open Semantic Interchange (OSI): dbt Labs будет развивать `MetricFlow` совместно с такими партнерами, как Snowflake и Salesforce, в рамках инициативы OSI. Цель — создать единый стандарт для семантической совместимости между разными платформами, чтобы метрики, определенные один раз, одинаково работали во всех инструментах.

Как MetricFlow обеспечивает надежность AI

`MetricFlow` предоставляет открытый стандарт для метаданных и расширяемый движок, который превращает намерение (“покажи валовую маржу”) в SQL-запрос для хранилища данных.

Пример работы:

Предположим, пользователь задает AI-агенту вопрос:

“Покажи валовую маржу (%) по месяцам за прошлый квартал для Северной Америки (за вычетом скидок и возвратов, по финансовому календарю).”

Без семантического слоя LLM пришлось бы конструировать сложный запрос с нуля. С `MetricFlow` процесс выглядит так:

Агент распознает намерение и запрашивает у `MetricFlow` метрику `gross_margin_pct` с нужными измерениями (`region`, `fiscal_month`) и фильтрами.
`MetricFlow`, на основе заранее созданных определений, строит план запроса:
- Находит нужные таблицы: `orders`, `discounts`, `returns`, `cogs` (себестоимость).
- Применяет правильные `JOIN` между ними.
- Применяет фильтр по региону (`North America`).
- Группирует данные по месяцам финансового, а не календарного, года.
- Рассчитывает числитель (выручка) и знаменатель (себестоимость) с учетом того, что популяция данных для них должна быть одинаковой.
- Вычисляет итоговое соотношение.
`MetricFlow` компилирует этот план в оптимизированный SQL-запрос, специфичный для диалекта конкретного хранилища (Snowflake, BigQuery, Databricks и т.д.).
Запрос выполняется в хранилище, и результат возвращается пользователю.

При этом весь сгенерированный SQL доступен для проверки, что обеспечивает прозрачность и объяснимость вычислений.

Основные возможности движка:

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

`MetricFlow` vs. `dbt Semantic Layer`

Важно понимать различие между двумя компонентами:

`MetricFlow` — это движок с открытым исходным кодом для определения и вычисления метрик. Это “сердце” системы, которое выполняет всю сложную работу по генерации SQL.
`dbt Semantic Layer` — это коммерческий продукт dbt Labs, построенный *поверх* `MetricFlow`. Он добавляет функциональность корпоративного уровня:
- Управление доступом (`RBAC`).
- Версионирование определений метрик.
- Аудит и отслеживание происхождения данных (`lineage`).
- Надежные API и коннекторы для интеграции с BI- и AI-инструментами.

Таким образом, `MetricFlow` становится общедоступным строительным блоком, а `dbt Semantic Layer` — готовым решением для его безопасного и управляемого внедрения в компаниях.

Итог

dbt Labs сделала `MetricFlow` (движок для расчета метрик) полностью открытым под лицензией Apache 2.0. Это позволяет всем желающим использовать его без ограничений.
Главная цель — создать открытый стандарт для определения бизнес-метрик. Это особенно актуально для AI-систем, которые часто ошибаются при самостоятельной генерации SQL.
`MetricFlow` позволяет AI и BI-инструментам запрашивать данные по имени метрики (например, `revenue`), получая детерминированный и корректный SQL-запрос. Это повышает надежность и согласованность данных.
Этот шаг способствует совместимости инструментов (`interoperability`) и снижает зависимость от конкретного вендора (`vendor lock-in`). Метрики, определенные один раз, будут работать одинаково в разных системах.
Коммерческий продукт `dbt Semantic Layer` продолжит развиваться как решение для управления жизненным циклом метрик в корпоративной среде (безопасность, контроль версий, аудит).

Новая эра трансформации данных: dbt против Bruin и aaC

Sat, 23 Aug 2025 16:04:02 +0300

В мире данных произошла тихая, но фундаментальная революция. На смену традиционному подходу ETL (Extract, Transform, Load), где данные преобразовывались до загрузки в хранилище, пришла новая парадигма — ELT (Extract, Load, Transform). Благодаря мощности современных облачных хранилищ (таких как Snowflake, BigQuery, Databricks, Starburst\Trino) стало выгоднее сначала загружать сырые данные, а уже затем трансформировать их непосредственно в хранилище.

Этот сдвиг породил потребность в инструментах, которые специализируются на последнем шаге — трансформации (T). Именно в этой нише dbt (data build tool) стал безоговорочным лидером, но на его поле появляются и новые сильные игроки, такие как Bruin. Давайте разберемся, что это за инструменты, какой подход они олицетворяют и в чем их ключевые различия.

Подход «Аналитика как код»

И dbt, и Bruin являются яркими представителями движения “Analytics as Code” (аналитика как код). Это не просто инструменты, а целая философия, которая переносит лучшие практики разработки программного обеспечения в мир аналитики данных.

Основные принципы и идеи:

Версионирование: Все трансформации данных описываются в виде кода (в основном SQL), который хранится в системе контроля версий, такой как Git. Это позволяет отслеживать изменения, совместно работать и откатываться к предыдущим версиям.
Модульность и переиспользование (DRY – Don’t Repeat Yourself): Сложные трансформации разбиваются на небольшие, логически завершенные модели, которые могут ссылаться друг на друга. Это делает код чище, понятнее и позволяет повторно использовать уже написанную логику.
Тестирование: Код трансформаций должен быть протестирован. Инструменты позволяют автоматически проверять качество данных после преобразований: на уникальность ключей, отсутствие `NULL` значений, соответствие заданным условиям и т.д.
Документация и прозрачность: Процесс трансформации становится самодокументируемым. Инструменты могут автоматически генерировать документацию и строить графы зависимостей моделей (data lineage), показывая, как данные текут и преобразуются от источника к конечному виду. element61.be
CI/CD (Continuous Integration / Continuous Deployment): Изменения в коде трансформаций могут автоматически тестироваться и разворачиваться в продуктивную среду, что значительно ускоряет циклы разработки.

Решаемые проблемы:

“Черные ящики” ETL: Заменяют сложные, трудноподдерживаемые и непрозрачные ETL-процессы на понятный и документированный код.
Рассинхронизация команд: Стирают границы между инженерами данных и аналитиками, позволяя аналитикам, владеющим SQL, самостоятельно создавать надежные модели данных.
Низкое качество данных: Встроенные механизмы тестирования помогают обеспечить надежность и согласованность данных.

---

dbt (data build tool): Золотой стандарт трансформации

dbt — это инструмент с открытым исходным кодом, который позволяет аналитикам и инженерам трансформировать данные в их хранилищах с помощью простых SQL-запросов. Важно понимать, что dbt не извлекает и не загружает данные. Он специализируется исключительно на шаге “T” в ELT vutr.substack.com. dbt git.

Он работает как компилятор и исполнитель: вы пишете модели данных в `.sql` файлах, используя шаблонизатор Jinja для добавления логики (циклы, условия, макросы). Затем dbt компилирует этот код в чистый SQL и выполняет его в вашем хранилище данных element61.be.

Плюсы dbt

Огромное сообщество и экосистема: dbt стал де-факто стандартом индустрии. Существует огромное количество статей, курсов, готовых пакетов (библиотек) и экспертов.
Фокус на SQL: Низкий порог входа для аналитиков, которые уже знают SQL. Это демократизирует процесс трансформации данных.
Мощное тестирование и документирование: Встроенные команды для тестирования данных и автоматической генерации проектной документации с графом зависимостей.
Зрелость и надежность: Инструмент проверен временем и используется тысячами компаний по всему миру.
Гибкость: Благодаря шаблонизатору Jinja можно создавать очень сложные и переиспользуемые макросы, адаптируя dbt под любые нужды.

Минусы dbt

Только трансформация: dbt не занимается извлечением (E) и загрузкой (L). Для этого вам понадобятся отдельные инструменты (например, Fivetran, Airbyte), что усложняет стек технологий.
Кривая обучения: Хотя основы просты, освоение продвинутых возможностей Jinja, макросов и структуры проекта требует времени.
Зависимость от Python-моделей: Хотя недавно появилась поддержка моделей на Python, она все еще не так нативна и проста, как основной SQL-подход, и требует дополнительных настроек.

---

Bruin Data: Универсальный боец

Bruin — это более новый игрок на рынке, который позиционирует себя как инструмент для создания “end-to-end” пайплайнов данных. В отличие от dbt, он не ограничивается только трансформацией, а стремится охватить больше этапов работы с данными, включая их загрузку (ingestion) https://github.com/bruin-data/bruin.

Bruin разделяет ту же философию “Analytics as Code”, но предлагает более интегрированный опыт, где SQL и Python являются равноправными гражданами.

Плюсы Bruin

Универсальность: Один инструмент для определения всего пайплайна: от загрузки из источников до финальных витрин данных. Это может упростить стек технологий.
Нативная поддержка SQL и Python: Позволяет легко комбинировать задачи на разных языках в одном пайплайне без дополнительных настроек. Это идеально для задач, где чистый SQL громоздок (например, работа с API, машинное обучение).
Простота конфигурации: Зачастую требует меньше шаблонного кода (boilerplate) для определения ассетов и пайплайнов по сравнению с dbt.
Встроенное качество данных: Как и dbt, делает акцент на проверках качества на каждом шаге.

Минусы Bruin

Пока маленькое сообщество: Как у нового инструмента, у Bruin гораздо меньше пользователей, готовых решений и обсуждений на форумах по сравнению с dbt. Найти помощь или готовый пакет для решения специфической задачи сложнее.
Незрелость: Инструмент моложе, а значит, наверное, потенциально менее стабилен и может иметь меньше интеграций по сравнению с проверенным dbt. Пока нет облачных функция за деньги. Я так думал, но все же есть https://getbruin.com.
“Мастер на все руки — эксперт ни в чем?”: Стремление охватить все этапы (E, L, T) может означать, что в каждом отдельном компоненте Bruin может уступать лучшим в своем классе специализированным инструментам (например, Fivetran в загрузке, dbt в трансформации), но это конечно субъективно.

Сводное сравнение

Характеристика	dbt (data build tool)	Bruin Data
Основная задача	Трансформация (T в ELT)	Весь пайплайн (E, L, T)
Ключевые языки	SQL с шаблонизатором Jinja	SQL и Python как равноправные
Экосистема	Огромная, стандарт индустрии	Маленькая, развивающаяся
Зрелость	Высокая, проверен временем	Низкая/Средняя
Стек инструментов	Требует отдельных E/L инструментов	Стремится быть самодостаточным

Итого

Выбор между dbt и Bruin — это выбор между двумя стратегиями построения современного стека данных.

Выбирайте dbt, если:

Вы строите гибкий стек из лучших в своем классе инструментов (“best-of-breed”): один для загрузки, другой для хранения, третий для трансформации.
Ваша команда в основном состоит из аналитиков, сильных в SQL.
Для вас критически важны поддержка сообщества, стабильность и наличие готовых решений.
Вы работаете в большой организации, где принятие отраслевых стандартов является преимуществом.
Вы готовы переехать к ним в платное облако, когда нибудь. Большая часть функционала доступна там.

Выбирайте Bruin, если:

Вы предпочитаете единый, интегрированный инструмент для управления всеми пайплайнами, чтобы упростить архитектуру
Вы любите open source и End-to-end дата framework: фор data ingestion + transformations + кволити. :)
Ваши пайплайны требуют тесной связки SQL и Python для трансформаций (например, обогащение данных через вызовы API или модели ML).
Вы начинаете новый проект или работаете в небольшой команде и цените скорость настройки и меньшее количество движущихся частей.
Вы Go’шник :) – Bruin написан на Go почти на 100%.

И dbt, и Bruin — мощные инструменты, воплощающие современные подходы к инженерии данных. dbt предлагает проверенный, сфокусированный и невероятно мощный движок для трансформаций, ставший стандартом. Bruin же предлагает более универсальный и интегрированный подход, который может быть привлекателен для команд, стремящихся к простоте и нативной поддержке Python.

А что такое “Аналитика как код” (Analytics as Code, AaC)?

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

Самая близкая и известная аналогия — это Infrastructure as Code (IaC). Как IaC (например, с помощью Terraform) позволил инженерам описывать серверы, сети и базы данных в коде вместо ручной настройки через веб-интерфейсы, так и AaC позволяет описывать в коде всё, что связано с данными medium.com.

Идея проста и убедительна: “настройте свои системы один раз, выразите это в виде кода, а затем поместите в систему контроля версий” holistics.io.

Проблема: Как было раньше?

Чтобы понять ценность AaC, нужно посмотреть на проблемы, которые он решает. В традиционном подходе аналитика часто была разрозненной и хрупкой:

Логика в “черных ящиках”: Сложные преобразования данных были скрыты внутри GUI-интерфейсов старых ETL-инструментов или непосредственно в настройках BI-платформы (например, Tableau, Power BI). Никто, кроме автора, не мог легко понять, как рассчитывается та или иная метрика.
Разрозненные SQL-скрипты: Аналитики хранили важные SQL-запросы на своих локальных машинах, в общих папках или на wiki-страницах. Не было единой версии правды, код дублировался и быстро устаревал.
Отсутствие контроля версий: Невозможно было отследить, кто, когда и почему изменил логику расчета ключевого показателя. Откат к предыдущей работающей версии был настоящей головной болью.
“Ручное” тестирование: Проверка качества данных после изменений была ручным, подверженным ошибкам процессом. Часто о проблемах узнавали уже от бизнес-пользователей, которые видели неверные цифры в отчетах.
Рассинхронизация: Инженеры данных готовили сырые таблицы, а аналитики строили свою логику поверх них. Любые изменения с одной стороны могли сломать всю цепочку, не будучи замеченными вовремя.

Этот хаос приводил к главному — недоверию к данным. Никто не мог быть уверен, что цифры в дашборде верны.

Ключевые принципы “Аналитики как код”

AaC решает эти проблемы, внедряя практики из мира разработки ПО.

Декларативное определение: Все аналитические артефакты описываются в файлах.
- Модели данных:** `SELECT * FROM ...` в `.sql` файлах.
- Тесты:** `not_null`, `unique` в `.yml` файлах.
- Документация:** Описания таблиц и полей в `.yml` файлах.
- Метрики и дашборды:** Определения в `.yml` или специализированных файлах medium.com.

Контроль версий (Git): Весь код хранится в репозитории (например, на GitHub или GitLab).
- Прозрачность:** Каждое изменение — это `commit` с понятным описанием.
- Совместная работа:** Аналитики работают в отдельных ветках, а изменения вносятся через `Pull Request` (или `Merge Request`), что позволяет проводить ревью кода (code review).
- Восстанавливаемость:** Если что-то пошло не так, можно легко откатиться к предыдущей версии.

Автоматизированное тестирование: Тесты являются неотъемлемой частью кода. Они запускаются автоматически при каждом изменении, чтобы гарантировать, что данные по-прежнему соответствуют ожиданиям (например, `user_id` всегда уникален и не равен `NULL`).

CI/CD (Непрерывная интеграция и развертывание): Процессы полностью автоматизированы.
- Когда аналитик вносит изменения в `Pull Request`, автоматически запускаются тесты.
- После одобрения и слияния ветки изменения автоматически развертываются в продуктивной среде (например, dbt Cloud или Jenkins запускает команду `dbt run`).

Модульность и переиспользование (DRY – Don’t Repeat Yourself): Сложные потоки данных разбиваются на небольшие, логичные и переиспользуемые модели. Одна модель может ссылаться на другую, создавая четкий граф зависимостей (lineage), который можно визуализировать.

Преимущества подхода AaC

Принятие этой философии дает компании ощутимые выгоды:

Надежность и доверие: Благодаря автоматическому тестированию и ревью кода значительно повышается качество данных, а вместе с ним и доверие бизнеса к аналитике.
Скорость и гибкость: Аналитики могут вносить изменения гораздо быстрее. Цикл от идеи до готового отчета сокращается с недель до дней или даже часов.
Масштабируемость: Кодовая база легко поддерживается и расширяется. Новые члены команды могут быстро разобраться в проекте благодаря документации и прозрачности.
Прозрачность и обнаруживаемость: Автоматически сгенерированная документация и графы зависимостей позволяют любому сотруднику понять, откуда берутся данные и как они рассчитываются.
Демократизация: AaC дает возможность аналитикам, владеющим SQL, самостоятельно создавать надежные и протестированные модели данных, не дожидаясь инженеров данных. Это стирает барьеры между командами.

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