Глоссарий — dbt III

Центральный in-memory объект dbt-core, представляющий весь проект после parsing: nodes (модели/тесты/snapshots/seeds), sources, macros, docs, exposures, metrics, semantic_models, parent_map, child_map. Сериализуется в target/manifest.json (schema version 12 в 1.10). Используется как для compilation и run, так и для downstream tooling (state comparison, docs site, observability). Грузится через ManifestLoader, мутируется в процессе parsing, передаётся в Linker для построения DAG.

Объединённое представление dbt_project.yml + profiles.yml + CLI флагов после загрузки и валидации. Хранит project_name, profile_name, target (с подключением), модели paths, vars, dispatch order, macro_paths, query_comment, restrict_access. Используется всеми компонентами как single source of truth для конфигурации. Создаётся один раз на старте команды через `RuntimeConfig.from_args(args)`.

Компонент dbt-core, который строит ориентированный ацикличный граф (DAG) зависимостей между nodes на основе ref/source вызовов, извлечённых во время parsing. Использует networkx под капотом. Кэшируется в target/graph.gpickle и в Manifest как parent_map/child_map. Detects cycles (cyclic reference error), validates ephemeral edges (ephemeral не может зависеть от incremental после execution-order).

Базовый класс в dbt-core для всех команд, которые обходят DAG (run, build, test, compile, snapshot, seed). Содержит GraphQueue, методы для определения nodes к выполнению (selector), оркестрацию thread pool, retries, и call_runner для каждого node. Команды-наследники: RunTask, BuildTask, TestTask, CompileTask. Subclass'ы переопределяют get_runner_class() и raise_on_first_error().

Thread-safe приоритетная очередь nodes для исполнения. Извлекает next node только если все его предки уже завершены. Реализует topological execution через готовую structure DAG. После завершения каждого node — mark_done, что разблокирует children. Обеспечивает корректный параллелизм через threads parameter.

Jinja-контекст, доступный внутри model/snapshot/test/seed SQL — самый богатый из контекстов. Включает ref(), source(), config.get/set/require, var(), env_var(), this, target, model, run_started_at, invocation_id, adapter object, statement, return, get_columns_in_relation, graph (в run-time только), execute flag. Часть переменных доступна только при execute=True (run), часть — при parse.

Jinja-контекст внутри macro определения. Похож на ProviderContext, но без некоторых model-specific переменных. Содержит adapter, execute, var, env_var, target, run_started_at, invocation_id, statement, return, и доступ к context из caller (через context() function). Используется при компиляции macros в run_query, materialization helpers, custom logic.

Минимальный Jinja-контекст для evaluation выражений вне моделей и макросов — например, в profiles.yml, dbt_project.yml, generate_schema_name. Содержит env_var, var, target, run_started_at, invocation_id, modules (datetime, pytz, re). Не имеет ref/source/adapter/execute — попытка использовать их в этом контексте даёт ошибку.

Специальный контекст для macros генерации имён: generate_schema_name, generate_database_name, generate_alias_name. Включает target и custom_schema_name/custom_database_name/node параметры. Не содержит ref/source/adapter — generate_* запускаются на parse-time до того, как доступны nodes. Это причина частой ошибки 'execute is False' при попытке вызвать run_query внутри generate_schema_name.

Оркестратор всех парсеров в dbt-core: ModelParser, AnalysisParser, SnapshotParser, SeedParser, TestParser, SourceParser, MacroParser, DocumentationParser, ExposureParser, MetricParser, SemanticModelParser. Решает, какой парсер обрабатывает каждый файл по path-paths из dbt_project.yml. Возвращает заполненный Manifest. Triggered через `ManifestLoader.parse()`.

Высокоуровневая абстракция загрузки/построения Manifest. Сначала пытается загрузить partial_parse.msgpack и инвалидировать только изменившиеся файлы; если инвалидация невозможна (изменился dbt_project.yml, packages, env_vars влияющих на parse) — делает full parse. После parse зовёт Linker для построения graph. Возвращает финальный Manifest для downstream компонентов.

Файл в target/, содержащий сериализованный (через msgpack) предыдущий Manifest и hash'и всех parsed файлов. На следующем dbt run сравниваются hash'и: только изменённые файлы re-parsed, остальные — re-used из msgpack. Даёт 10-100x ускорение parsing на больших проектах. Инвалидируется при изменении dbt_project.yml, vars, target, dbt version.

Library для incremental parsing, используемая dbt-core с 1.6+ для быстрого извлечения ref/source/config вызовов из SQL без полного Jinja render'а. Парсит SQL+Jinja как AST, что в десятки раз быстрее полного eval. Делает 'static parser' возможным — phase, где dbt узнаёт DAG без выполнения каких-либо Jinja-выражений. Если static parser не может — fall back to Jinja experimental parser, затем full parser.

Класс в dbt-core, регистрирующий новый adapter в системе. Импортируется в __init__.py adapter-пакета, содержит ссылку на dependencies (например, dbt-postgres зависит от dbt-core), Credentials class, реализацию Adapter (subclass BaseAdapter или SQLAdapter), и project plugin Manifest для определения adapter-specific macros, доступных через dispatch.

Базовый класс для всех dbt adapter'ов в dbt-adapters пакете. Определяет abstract interface: connections (ConnectionManager), Relation/Column types, execute(), get_columns_in_relation(), list_schemas(), drop_relation(), expand_target_column_types(), get_response. Конкретные adapter'ы наследуются и переопределяют warehouse-specific детали. Реальные SQL adapter'ы используют SQLAdapter — promiscuous subclass.

Subclass BaseAdapter для SQL warehouses (Postgres, Snowflake, BigQuery, DuckDB, etc.). Добавляет реализации generic SQL-операций: list_schemas через query, drop_schema через DROP SCHEMA, информацию о columns через INFORMATION_SCHEMA. Большинство production adapter'ов наследуют SQLAdapter, переопределяя warehouse-specific edge cases (Snowflake quoting, BigQuery dataset semantics, Iceberg).

Pydantic-подобный dataclass (наследует BaseConnectionContextManager), описывающий поля profiles.yml для конкретного adapter. Содержит host, port, database, schema, user, password, threads, и adapter-specific поля (warehouse в Snowflake, project в BigQuery). Имеет ALIASES dict для обратной совместимости старых имён полей, и _connection_keys() — что не светить в логах.

Class-level dict в Credentials dataclass, mapping старых названий полей (которые могут быть в legacy profiles.yml) к актуальным. Например, в dbt-snowflake: `ALIASES = {'username': 'user', 'role_name': 'role'}`. Позволяет менять API без breaking changes в существующих профилях пользователей.

Класс в adapter, который держит pool активных подключений к warehouse, по одному на каждый thread. Implements abstract methods: open() (создать connection из Credentials), get_response() (parse warehouse response в AdapterResponse), cancel() (cancel running query на abort), exception_handler() (translate exceptions в dbt-friendly errors). Inherits SQLConnectionManager для SQL warehouses.

Стандартизированный объект-результат выполнения SQL-запроса в adapter. Содержит code (SUCCESS, FAIL, и warehouse-specific code), rows_affected, query_id (для трекинга в warehouse), execution_time. Возвращается из get_response() и попадает в run_results.json. Adapter'ы могут расширять для warehouse-specific полей (Snowflake adds bytes_scanned, BigQuery — slot_ms).

Enum в dbt-adapters, описывающий what features supports adapter. Например, SchemaMetadataByRelations, TableLastModifiedMetadata, MaterializedView, MicrobatchConcurrency. Adapter regs свои capabilities через class attribute, и dbt-core проверяет capability перед использованием feature, gracefully fallback'ясь иначе. Появилось в dbt-adapters 1.0 (2024).

Механизм dbt-adapters для gradual rollout breaking changes. Adapter declares experimental behavior через behavior_flags dict; users opt-in/opt-out через flags в dbt_project.yml. Когда behavior становится default, flag deprecate, потом removed. Используется например для smarter quoting логики, новых materialization defaults.

Object в dbt-adapters, представляющий database object (table/view/cte). Содержит database, schema, identifier, type (table/view/cte/external/materialized_view), include_policy (что включать в render), quote_policy (что quotить). Создаётся через Relation.create(). Перегружает __str__ для render'а в SQL identifier. Adapter'ы могут subclass'ить (SnowflakeRelation, BigQueryRelation) для warehouse-specific логики.

Class method для конструирования Relation объекта со всеми quoting/include правилами. Используется внутри macros как `{% set rel = api.Relation.create(database=db, schema=sch, identifier=id, type='table') %}`. Применяет default policies из adapter, можно override через args. Корректный путь конструирования — никогда не делать Relation() через __init__ напрямую.

Tri-state config (database/schema/identifier по отдельности) в adapter Relation, определяющий нужно ли заворачивать identifier в quotes. Override'ится в dbt_project.yml через quoting: {database: true, schema: true, identifier: true}. Snowflake quoting=true делает identifier case-sensitive — частая trap. BigQuery quoting irrelevant — backticks для не-стандартных имён.

Jinja function dbt для polymorphic macro resolution по adapter type. `{{ adapter.dispatch('drop_relation', 'dbt')(rel) }}` ищет в порядке: `<adapter>__drop_relation`, `default__drop_relation`. Через `search_order` в dispatch_macros можно override приоритет namespace. Корневой mechanism, как adapter'ы override default behavior.

Второй аргумент adapter.dispatch — package, в котором искать macros. По умолчанию первое найденное определение wins; через config dispatch в dbt_project.yml можно forced override. Используется например когда dbt_utils.star override'ится своим star в проекте — `{% set s = dbt_utils.star() %}` но с `dispatch: [{macro_namespace: dbt_utils, search_order: [my_project, dbt_utils]}]`.

List package names в dispatch config, определяющий приоритет поиска macros внутри namespace. Первое совпадение в search_order побеждает. Используется чтобы override macros из package: проект объявляет `search_order: [my_project, dbt_utils]` — сначала ищется в my_project, потом fallback в dbt_utils.

6-фазный цикл выполнения каждой материализации в dbt: (1) prepare — определить target relation, (2) pre-hooks — run pre-hook SQL, (3) build — main DDL/DML (CREATE TABLE/MERGE/etc.), (4) post-hooks — post-hook SQL, (5) cleanup — drop temp relations, (6) return — return {'relations': [list]} для cache. Каждый custom materialization обязан следовать этой структуре.

Macro в dbt, который выполняет on-run-start/on-run-end из dbt_project.yml. Запускается до/после всего run-набора, не per-model. Не путать с pre-hook/post-hook (per-model). on-run-start полезен для CREATE SCHEMA IF NOT EXISTS, on-run-end — для GRANTS или audit logging.

Главный Jinja statement-block внутри materialization, который dbt трекает как 'основной' SQL — именно он попадает в run_results.json как timing. `{%- call statement('main', fetch_result=true) -%} SQL {%- endcall -%}`. fetch_result=true возвращает результат query в memory (для read_query patterns). main statement is required by all materializations.

Метод adapter.cache_dropped(relation), который инвалидирует in-memory relation cache после DROP. Обязателен в custom materializations, иначе adapter думает что relation существует и пытается DESCRIBE её — runtime error. Pair-ed с cache_added (после CREATE), cache_renamed (после RENAME). Часто забывают, когда пишут DROP TABLE напрямую через execute() вместо drop_relation().

Метод adapter.cache_renamed(from_rel, to_rel) для обновления in-memory relation cache после ALTER TABLE RENAME. Используется в materialization swap pattern (temp table -> atomic rename). Без него adapter думает старая relation существует. Inside dispatch macros, нужно вызывать после каждого rename через RENAME-statement.

Boolean Jinja-variable, который True во время run/compile/test/build, и False во время parse. Macros, которые делают run_query или зависят от runtime info (e.g. get_columns_in_relation), должны guard'ить эту часть: `{% if execute %} ... {% endif %}`. Без guard, parse падает с RuntimeError при попытке вызвать что-то requiring connection. Один из top-3 gotchas написания custom macros.

Python class в dbt-core (`from dbt.cli.main import dbtRunner`) для programmatic invocation. `runner = dbtRunner(); result = runner.invoke(['run', '--select', 'model_x'])`. Может pre-load Manifest для скорости (`dbtRunner(manifest=manifest)`). NOT thread-safe — нельзя shared between threads. Replaces deprecated dbt.main.handle_and_check.

Object возвращаемый dbtRunner.invoke(). Содержит .success (bool), .result (зависит от команды — Manifest для parse, RunResult для run/build/test), .exception (Exception если есть). Для run возвращает список node results с status, execution_time, adapter_response. Парсится для custom отчётности — например, slack alerts на failures.

Селектор в dbt для запуска только изменившихся моделей по сравнению с baseline manifest. Comparison делается между текущим Manifest и --state ./prod-artifacts/manifest.json. Modified — изменился raw_code, refs, configs, tests. Использует hash сравнение. Core building block для Slim CI. Расширения: state:modified+ (with children), state:modified.body, state:modified.configs.

Pattern для CI builds, где запускаются только модели изменённые в PR (state:modified+) и с defer to production. Daje 10-100x speedup vs full rebuild. Implementation: после каждого prod deploy сохраняется manifest.json в storage (S3, GCS, GH artifacts), CI fetches его и использует как --state. Без обновления prod manifest — false positives на 'modified everything'.

Флаг dbt --defer-to-state, заставляющий ref() для unbuilt моделей резолвить в production tables (из state manifest), а не в dev. Позволяет в CI билдить только changed models, ссылаясь на prod upstream. Pair-ed с --state для location. Без defer Slim CI неэффективен. Trap: модель refs prod-таблицу из defer, прод весит 100GB, CI cost растёт quadratically.

Структура в dbt-core, parsed из --select/--exclude CLI args. Combines: methods (fqn, tag, source, exposure, state, result, group, version, access, semantic_model, path, file, package), graph operators (+, +N, @), set operators (intersection, union via comma/space). Возвращает set of UniqueId после resolution на Manifest's graph.

Python library, используемая dbt-core для представления и обхода DAG моделей. Создаётся в Linker из ref/source edges. Operations: topological_sort (порядок выполнения), descendants/ancestors (для + операторов), simple_cycles (cyclic detection). Не optimized для миллионов nodes — у dbt Fusion свой Rust-based graph engine.

Файл в target/, содержащий serialized networkx graph (pickle format). Создаётся после Linker, используется при partial parse и для downstream tools. Один из artifacts'ов после parse. NOT considered API — schema может меняться. Для external consumers рекомендуется использовать parent_map/child_map в manifest.json.

Incremental strategy (dbt-core 1.9+) для timeseries моделей. Декларирует event_time column + begin date + batch_size (hour/day/month/year). Dbt сам сегментирует backfill на серию batches и выполняет их (опционально parallel — concurrent_batches). После failure rerun только failed batches через --select model_x+ --batch-size hour. Не поддерживает upserts — это by design.

Config поле на модели/source, указывающее column с timestamp событий — основа microbatch strategy. `{{ config(materialized='incremental', incremental_strategy='microbatch', event_time='order_date', begin='2024-01-01', batch_size='day') }}`. Используется dbt для определения границ batches и для filter в downstream моделях (auto-filter через ref('upstream_with_event_time')).

Config поле в microbatch, определяющее сколько prior batches пересчитывать на каждом run для коррекции late-arriving data. `lookback: 3` + `batch_size: day` = пересчёт последних 3 дней + 1 текущего. Trade-off: больше lookback = больше работа но больше correctness. Tuning важен для real-time scenarios.

Способность одного dbt project ссылаться на модели другого через `{{ ref('upstream_project', 'model_name') }}`. Требует declarations в dependencies.yml (`projects: [{name: upstream_project}]`) или в Fusion-стиле dbt_project.yml. Backed by Mesh architecture — upstream project публикует manifest, downstream consumes via metadata. NOT работает в dbt-core без dbt Cloud или Fusion.

Объявление в dependencies.yml (новый формат, заменивший packages.yml в Mesh context) проектов, на которые ссылается наш проект. `projects: [{name: jaffle_shop}, {name: marketing}]`. Resolution: dbt Cloud fetches manifest каждого project, мерджит nodes (с префиксом project_name), enforces public/private/protected access. Без Cloud — Fusion CLI или manual approach с symlinks.

Декларация модели об API: precise types, nullability, constraints. `contract: {enforced: true}` + columns с data_type/constraints. dbt валидирует на compile-time (точные types) и run-time (CONSTRAINT в DDL). Breaking changes требуют version bump. Critical для downstream consumers в Mesh-проектах. Поддерживается в Postgres/Snowflake/BigQuery с разной полнотой.

Mechanism dbt Mesh для bridge breaking changes в shared моделях. Модель `orders` может иметь v1 и v2 — каждая отдельная физическая table (orders_v1, orders_v2). Downstream проекты выбирают какую version refs'ить. После migration window старая version deprecated и удаляется. Declaration в YAML: `versions: [{v: 1, deprecation_date: ...}, {v: 2}]`.

Field в versioned model YAML, указывающий какая version — current default. `ref('orders')` без version-arg резолвится в latest_version. Allows downstream evolve consumption gradually: первая стадия — старая ref работает (latest_version=1), вторая стадия — latest_version=2 но v1 ещё доступна, третья — v1 deprecated и удалена.

Access modifier на модели в Mesh-проектах. public — модель может быть ref'нута из любого проекта; protected — только из текущего и dependent groups; private — только в текущей group. Enforced на parse-time через Linker. Group declaration в groups: section, model assigned через `group: marketing`. Critical для governance в monorepo с десятками teams.

Logical grouping моделей в dbt-проекте. Объявляется в groups: section dbt_project.yml/.yml файлах: `groups: [{name: finance, owner: {email: data@}, models: [...]}]`. Используется для access control (private моделей видны только внутри group) и для ownership/governance metadata. Может ссылаться в --select group:finance.

CLI tool (open source, в dbt-labs/dbt-meshify) для автоматизации migration монолитного dbt project в multi-project Mesh setup. Команды: split-project (разбить по groups), add-contract (генерация contracts из live data), version-model. Не часть dbt-core, но recommended companion для Mesh adoption.

Semantic Layer engine, integrated в dbt-core с 1.6 (после acquisition Transform Labs). Объявляет semantic_models (entities, dimensions, measures) и metrics поверх dbt models. Generates SQL on-demand для metric queries — каждая query — DataflowPlan, скомпилированный для конкретного warehouse. Замена dbt Metrics package (deprecated).

Internal MetricFlow representation того, как compute metric: source semantic_models -> joins -> aggregations -> grouping. Optimized для query reduction (push-down predicates, join elimination). Compiled в SQL только в финале — позволяет dialect-specific optimization. Size grows quadratically с количеством metrics + dimensions — bottleneck на 100+ metrics.

Operation в DataflowPlan: ReadSqlSourceNode, JoinToTimeSpineNode, AggregateMeasuresNode, FilterElementsNode, OrderByLimitNode, и tracking. Каждый node имеет inputs (other nodes) и outputs. Optimizer walks DAG, merging compatible nodes. Eventual SQL generation — recursive emit по nodes.

YAML declaration в MetricFlow, описывающая entities (primary/foreign keys), measures (aggregatable columns), dimensions (groupable columns), и time dimension. `semantic_models: [{name: orders, model: ref('fct_orders'), entities: [...], measures: [...], dimensions: [...]}]`. v1 spec — dbt 1.6-1.11, v2 spec — 1.12+. Replaces dbt-метрики из 2022.

Pattern в современных warehouses (Snowflake Iceberg tables, Databricks Unity Catalog, BigLake), где database в warehouse — это thin layer над Iceberg metadata. dbt-core 1.10 supports через external materialization + catalogs.yml. Позволяет один и тот же физический parquet/iceberg доступен из нескольких warehouses (Snowflake reads, Trino reads). Cross-engine query без data movement.

Конфиг файл (1.10+) для multi-catalog support, особенно Iceberg. Declares catalogs со своими auth/credentials, mapping имён в profiles.yml. `catalogs: [{name: glue_catalog, type: iceberg, ...}]`. Используется в external materialization для определения куда писать Iceberg metadata. Поддержка adapter-specific.

Rust-based replacement движка dbt-core, public beta May 2025, GA Coalesce 2025. Acquired SDF Labs technology — Semantic Compiler, SQL static analysis. 30x faster parsing, 2x faster compilation для больших проектов. Drop-in replacement для большинства commands, но: extreme Jinja patterns могут не работать, NOT все adapters supported, ADBC drivers preferred. Migration через dbt-autofix CLI.

Static analysis engine, акuired dbt Labs в апреле 2025 от SDF Labs. Понимает SQL semantics на уровне типов, column lineage, FK validation, без выполнения query. Integrated в dbt Fusion как core component. Daje compile-time errors на SQL bugs которые runtime бы поймал. Foundation для будущих features как automated test generation.

Arrow Database Connectivity — standard для accessing databases через Apache Arrow format. Adapter'ы dbt Fusion preferred используют ADBC для streaming results напрямую в Arrow без row-by-row conversion. 5-10x faster для bulk reads. Currently supported in dbt-snowflake, dbt-bigquery, dbt-duckdb. Future: replace ODBC/JDBC в data tools.

Model Context Protocol сервер от dbt Labs (2025), позволяющий LLM-агентам (Claude, GPT) взаимодействовать с dbt проектом: query manifest, get model metadata, run dbt commands programmatically. Open source. Connects через standard MCP transport (stdio/HTTP). Building block для AI-driven analytics workflows.

Pattern в dbt Fusion (и проектах вроде Dagster + dbt) где orchestrator понимает state of каждой модели в warehouse — какие freshly built, какие stale — и smart-schedule runs только needed моделей. Альтернатива cron-based 'run everything daily'. Backed by manifest state + warehouse query introspection.

CLI tool от dbt Labs для автоматической migration codebase под breaking changes. Например, при upgrade на 1.10 — переименовывает deprecated functions, fixes deprecated configs, добавляет required fields. Используется для Fusion migration. Не часть dbt-core — install отдельно (`pip install dbt-autofix`).

Тип node в dbt Mesh, представляющий упоминание модели из другого проекта без полного manifest impport. Создаётся automatically при cross-project ref когда remote project'а manifest unavailable. Содержит минимум metadata (database, schema, name) но без full lineage. Используется в Cloud Slim CI как placeholder.

Python package (dbt-labs/dbt-tests-adapter), содержащий стандартный test suite, который должен пройти каждый new adapter для базовой conformance. Tests cover: basic materializations, incremental strategies, snapshots, seeds, ephemeral, tests, sources, hooks. Запускается как pytest, configured через subclass'ы. Mandatory для официальной поддержки adapter.

Программа dbt Labs (2024+) для community-developed adapters, прошедших аудит и поддерживающих SLA. Trusted adapters получают listing на dbt docs, badge, и priority в release announcements. Requirements: pass dbt-tests-adapter, public maintained repo, documented support, semver releases. Не обязательно для использования adapter, но signal of quality.

Config field на incremental моделях, добавляющий extra WHERE-clauses в DELETE/UPDATE части merge/delete+insert strategy. `incremental_predicates: ['target.dt > current_date - 7']`. Critical для partition-pruning на больших таблицах (Snowflake, BigQuery — миллионы dollars saved). Trap: для insert_overwrite если не указать предикат — full table replace вместо partition replace.

Config incremental моделей, как handle schema drift между предыдущим run'ом и текущим. Values: ignore (default, schema стуковая), fail (error), append_new_columns (добавить новые в target), sync_all_columns (полная синхронизация — add new, drop missing). sync_all_columns is destructive — drops columns без warning.

Snapshot strategy 'check' tracks changes когда нет timestamp column — compare hash всех check_cols. Trap: floats — small precision differences вызывают false positives. Workaround: cast в decimal перед compare, или используйте timestamp strategy если есть updated_at column. Alternative — hash specific subset of columns instead of all.

Artifact в target/, схема version 6 (в 1.10), содержащий результаты run/build/test/seed. Per-node: status, execution_time, message, adapter_response, timing breakdown (compile/execute), thread_id. Используется для observability dashboards (Elementary, Recce, custom), для retry workflows (--select result:error+), для cost analysis.

Artifact из dbt docs generate, содержащий schema каждой материализованной модели + sources: columns, types, stats (если adapter supports). Generated после run, через introspection warehouse (DESCRIBE / INFORMATION_SCHEMA). Используется для docs site, для contract enforcement, для downstream tools. Generate dorogo — каждая модель = N database queries.

Artifact из dbt source freshness, содержащий per-source freshness check results: max(loaded_at), warning/error threshold check status, execution timing. Версия schema 3. Используется для observability ('какие sources stale') и для CI gates ('block deploy if upstream sources broken').

Artifact MetricFlow в target/, содержащий compiled semantic models + metrics. Используется MetricFlow CLI и Semantic Layer server для query execution. Регенерируется при каждом dbt parse если есть semantic models. v2 schema в 1.12. Точка интеграции с external tools (Mode, Hex, custom BI).

Set практик для максимизации partial parse hit-rate: минимизация global vars (vars в dbt_project.yml вместо ENV для часто меняющихся), стабильные имена файлов (rename = full reparse того файла), нейтральные generate_schema_name (без env_var зависимостей). На больших проектах разница 10s vs 100s parse time.

Параметр threads в profiles.yml, определяющий parallelism в run. Optimal зависит от warehouse: Snowflake X-Small — 4-8 threads (CPU bound, contention выше), Snowflake Large — 16-32. BigQuery — почти unlimited (slot model), но cost растёт. DuckDB — single writer per file, threads>1 ускоряет только parsing/compile, не write. Каждый thread = одно открытое connection.

Селектор state для retry workflow: запустить только failed моделей из предыдущего run + их descendants. Требует --state pointing на predыдущий run_results.json. Critical для long-running runs где flaky failures common. Pair с --defer для skipping working models.

Поле в каждом dbt artifact (manifest.json, run_results.json, catalog.json) указывающее версию JSON schema. Дискретно incremented breaking changes. Например, manifest schema v8 -> v9 в 1.5 (semantic models добавлены). Downstream consumers должны pin к специфик version или handle multiple. dbt-artifacts package abstract'ит это.

Канонический идентификатор node в dbt — `<type>.<package>.<name>` (e.g., `model.jaffle_shop.stg_orders`, `test.jaffle_shop.unique_stg_orders_order_id.<hash>`). Используется в selection, в parent_map/child_map, в manifest keys. Уникален в рамках проекта. Generated через ParseResult.compute_unique_id().

Macro в dbt для нормализации grants config. Принимает grants dict (e.g., {select: ['reporter', 'analyst']}) и возвращает normalized form. Implemented per-adapter — Snowflake требует ROLE prefix, Postgres работает с роли напрямую. Bug в кастомных implementation -> revoke/grant циклы при каждом run.

Config (`persist_docs: {relation: true, columns: true}`) указывающий dbt copy descriptions из YAML в warehouse COMMENT'ы на tables/views/columns. Critical для governance — descriptions видны в warehouse UI (Snowsight, BigQuery Console). Поддержка adapter-specific: Snowflake/BigQuery полная, Postgres только tables, DuckDB партиальная.

Когда materialization defined в нескольких местах — project, packages, dbt-core builtins — какая wins. Order: текущий проект > packages > dbt-core. Если package и project оба определяют 'incremental' — project wins. Trap: пакет имеет custom 'incremental' с side effects, проект не override -> unexpected behavior.

Helper macro в dbt-duckdb для обработки sources с external_location при :memory: DuckDB. Без неё на следующем run модели ссылающиеся на parquet перестают видеть таблицы (re-attach нужен). Pattern: add as on-run-start hook. Specific issue dbt-duckdb.