Парсинг проекта

Связанная документация

• Команда dbt parse command
• Конфигурация профиля для частичного парсинга profile config и CLI флаги
• Парсинг CLI флаги

Что такое парсинг?

В начале каждого вызова dbt, dbt читает все файлы в вашем проекте, извлекает информацию и создает манифест, содержащий каждый объект (модель, источник, макрос и т.д.). Среди прочего, dbt использует вызовы макросов ref(), source() и config() внутри моделей для установки свойств, определения зависимостей и построения DAG вашего проекта.

Парсинг проектов может быть медленным, особенно по мере увеличения проектов — сотни моделей, тысячи файлов — что раздражает в процессе разработки. Существует несколько способов оптимизации производительности dbt на сегодняшний день:

• Биндинги LibYAML для PyYAML
• Частичный парсинг, который избегает повторного парсинга неизмененных файлов между вызовами
• Статический парсер, который извлекает информацию из простых моделей гораздо быстрее
• RPC сервер, который хранит манифест в памяти и повторно парсит проект при запуске/остановке сервера

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

PyYAML + LibYAML

dbt использует PyYAML для чтения и проверки YAML файлов в вашем проекте. PyYAML написан на чистом Python, но может использовать LibYAML (написан на C, гораздо быстрее), если он доступен в вашей системе. Каждый раз, когда он парсит ваш проект, dbt сначала проверяет, доступен ли LibYAML.

Вы можете проверить, установлен ли LibYAML, выполнив эту команду в среде, где установлен dbt:

python -c "from yaml import CLoader"

Частичный парсинг

После парсинга вашего проекта, dbt сохраняет внутренний манифест проекта в файле под названием partial_parse.msgpack. Когда частичный парсинг включен, dbt использует этот внутренний манифест для определения, какие файлы были изменены (если таковые имеются) с момента последнего парсинга проекта. Затем он будет парсить только измененные файлы или файлы, связанные с этими изменениями.

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

Глобальная конфигурация PARTIAL_PARSE может быть включена или отключена через profiles.yml, переменную окружения или флаг CLI.

Известные ограничения

Атрибуты времени парсинга (зависимости, конфигурации и свойства ресурсов) разрешаются с использованием контекста времени парсинга. Когда частичный парсинг включен, и некоторые переменные контекста изменяются, эти атрибуты не будут пересчитаны и, вероятно, устареют.

В частности, вы можете увидеть некорректные результаты, если эти атрибуты зависят от "нестабильных" переменных контекста, таких как run_started_at, invocation_id или флаги. Эти переменные, вероятно (или даже гарантированно!), изменяются при каждом вызове. dbt Labs настоятельно не рекомендует использовать эти переменные для установки атрибутов времени парсинга (зависимостей, конфигураций и свойств ресурсов).

Начиная с версии v1.0, dbt будет обнаруживать изменения в переменных окружения. Он будет избирательно повторно парсить только те файлы, которые зависят от значения этой переменной env_var. (Если переменная окружения используется в profiles.yml или dbt_project.yml, потребуется полный повторный парсинг.) Однако dbt не будет повторно рендерить описания, которые включают переменные окружения. Если ваши описания включают часто изменяющиеся переменные окружения (это крайне редко), мы рекомендуем полностью повторно парсить при генерации документации: dbt --no-partial-parse docs generate.

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

• --vars
• содержимое profiles.yml (или значения env_var, используемые внутри)
• содержимое dbt_project.yml (или значения env_var, используемые внутри)
• установленные пакеты
• версия dbt
• некоторые широко используемые макросы (например, встроенные, переопределения или generate_x_name для database/schema/alias)

Если вы запускаете CI задания, преимущества частичного парсинга не применимы к новым pull-запросам (PR) или новым веткам. Однако они применяются к последующим коммитам в новый PR или ветку.

Если вы когда-либо окажетесь в плохом состоянии, вы можете отключить частичный парсинг и инициировать полный повторный парсинг, установив глобальную конфигурацию PARTIAL_PARSE в значение false или удалив target/partial_parse.msgpack (например, запустив dbt clean).

Статический парсер

Во время парсинга dbt необходимо извлечь содержимое ref(), source() и config() из всех моделей в проекте. Традиционно dbt извлекал эти значения, рендеря Jinja в каждом файле модели, что может быть медленным. В версии v0.20 мы представили новый способ статического анализа файлов моделей, используя tree-sitter. Вы можете увидеть код для начальной грамматики Jinja2 здесь.

Начиная с версии v1.0, статический парсер включен по умолчанию. Мы считаем, что он может предложить некоторое ускорение для 95% проектов. Вы можете опционально отключить его, используя глобальную конфигурацию STATIC_PARSER.

На данный момент статический парсер работает только с моделями и моделями, в которых Jinja ограничена этими тремя специальными макросами (ref, source, config). Статический парсер как минимум в 3 раза быстрее, чем полный рендер Jinja. На основе тестирования с данными из dbt Cloud, мы считаем, что текущая грамматика может статически парсить 60% моделей в дикой природе. Таким образом, для среднего проекта мы надеемся увидеть ускорение парсера моделей на 40%.

Экспериментальный парсер

В настоящее время не используется.