1. Зачем dbt в аналитическом стеке
dbt (data build tool) — де-факто стандарт трансформаций в modern data stack. SQL-first подход: аналитики пишут SELECT, dbt управляет DDL, зависимостями, тестами и документацией.
Проблема: dbt обычно ассоциируют с Snowflake, BigQuery, Redshift. Мало кто знает, что dbt полноценно работает с Apache Doris через официальный open-source adapter.
dbt-doris — adapter для dbt Core 1.7+, подключение через MySQL protocol (порт 9030). Что это даёт:
- Версионирование SQL-трансформаций в Git.
- CI/CD для аналитических моделей — тестирование каждого PR.
- Data lineage: автоматический граф зависимостей между моделями.
- Documentation-as-code: описания моделей и колонок рядом с SQL.
- Автоматические тесты качества данных при каждом запуске.
2. Архитектура: dbt + Doris
Типичная архитектура dbt + Apache Doris состоит из четырёх слоёв:
| SQL Compilation | dbt Core / dbt Cloud компилирует SQL-модели: резолвит ref() и source(), генерирует target SQL, управляет зависимостями через DAG. |
| Transport | MySQL protocol (порт 9030). Стандартный MySQL connector, совместимый с любым клиентом. Не требует специального SDK. |
| Materializations | table, view, incremental, ephemeral. Incremental модели используют Unique Key таблицы Doris для UPSERT-семантики. |
| Data Serving | Apache Doris выполняет SQL, управляет таблицами, поддерживает Multi-Catalog для доступа к внешним источникам. |
Ключевое преимущество: dbt + Doris не требует Spark, Hadoop или дополнительных вычислительных движков. Весь pipeline — SQL от начала до конца.
3. Quick Start: установка и конфигурация
Установка adapter через pip:
// УСТАНОВКА DBT-DORIS
pip install dbt-doris Конфигурация подключения в profiles.yml:
// PROFILES.YML — ПОДКЛЮЧЕНИЕ К DORIS my_doris_project:
target: dev
outputs:
dev:
type: doris
host: 127.0.0.1 port: 9030 username: root
password: ""
database: analytics
schema: dbt_models Подключение через MySQL protocol (порт 9030). Поддержка нескольких баз через Doris Multi-Catalog. Проверка соединения:
// ПРОВЕРКА ПОДКЛЮЧЕНИЯ
dbt debug 4. Materializations и модели данных Doris
Как materializations dbt маппятся на объекты Doris:
| dbt Materialization | Doris Implementation | Когда использовать |
|---|---|---|
| table | CREATE TABLE AS SELECT | Полная перестройка, маленькие таблицы |
| view | CREATE VIEW | Логические слои, без материализации |
| incremental | INSERT INTO (Unique Key + UPSERT) | Большие таблицы, дневные/часовые инкременты |
| ephemeral | CTE (Common Table Expression) | Промежуточные вычисления |
Incremental strategy для Doris Unique Key таблиц:
// INCREMENTAL MODEL: DORIS UNIQUE KEY
{{ config(
materialized='incremental',
unique_key='order_id',
incremental_strategy='append'
) }}
SELECT
order_id,
customer_id,
order_total,
updated_at
FROM {{ source('raw', 'orders') }}
{% if is_incremental() %}
WHERE updated_at > (SELECT MAX(updated_at) FROM {{ this }})
{% endif %} 5. Тесты и качество данных
dbt обеспечивает качество данных через декларативные тесты:
- Schema tests: unique, not_null, accepted_values, relationships — встроенные проверки.
- Custom tests: SQL-based assertions для бизнес-логики.
- dbt-expectations: пакет расширенных тестов (распределения, форматы, аномалии).
- Freshness checks: мониторинг актуальности source-данных.
// SCHEMA TESTS: YAML models:
- name: dim_customers
columns:
- name: customer_id
tests:
- unique
- not_null
- name: email
tests:
- unique dbt test запускает все тесты и сигнализирует об ошибках. Интеграция с CI/CD: тесты на каждый PR.
6. CI/CD и production workflow
Production best practices для dbt + Doris:
- Git-based workflow: каждая модель — SQL файл в репозитории. Review через PR.
- dbt build: запуск моделей + тестов в порядке зависимостей (DAG).
- Slim CI: dbt build --select state:modified+ — собрать только изменённые модели.
- Manifest comparison: сравнение с production-манифестом, билд только дельты.
- Deployment: dbt Cloud scheduled jobs или Airflow + dbt (BashOperator).
- Lineage: dbt docs generate → визуальный DAG всех моделей и зависимостей.
- Documentation: описания моделей в YAML → авто-генерация документации.
7. Пример проекта: аналитика заказов
Полный пример трёхслойной архитектуры:
- Source: raw.orders, raw.customers — загружены через Flink CDC или Stream Load.
- Staging: stg_orders, stg_customers — очистка, типизация, переименование.
- Mart: mart_customer_orders — агрегация, готово для BI.
// MART MODEL: АНАЛИТИКА ЗАКАЗОВ
-- models/marts/mart_customer_orders.sql
{{ config(materialized='table') }}
WITH orders AS (
SELECT * FROM {{ ref('stg_orders') }}
),
customers AS (
SELECT * FROM {{ ref('stg_customers') }}
)
SELECT
c.customer_id,
c.customer_name,
c.segment,
COUNT(o.order_id) AS total_orders,
SUM(o.order_total) AS lifetime_value,
MAX(o.order_date) AS last_order_date
FROM customers c
LEFT JOIN orders o ON c.customer_id = o.customer_id
GROUP BY c.customer_id, c.customer_name, c.segment Эта модель автоматически строит граф зависимостей: сначала выполнятся stg-модели, затем mart. dbt управляет порядком через ref().