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

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

• Команда 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 docs generate --no-partial-parse.

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

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

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

Когда включён частичный парсинг (partial parsing), dbt может иногда давать сбои или некорректно разбирать проект, из‑за чего:

• Ноды (например, models, sources) могут не находиться.
• Конфигурации могут применяться некорректно (например, отличаться от того, что определено в файле schema.yml модели).

Если вы столкнулись с таким состоянием, вы можете принудительно запустить полный повторный парсинг одним из следующих способов:

• Запустить команду dbt с флагом --no-partial-parse.
• Удалить файл target/partial_parse.msgpack, выполнив команду dbt clean.

Вы также можете полностью отключить частичный парсинг, установив глобальную конфигурацию PARTIAL_PARSE в значение false.

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

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

Статический парсер включён по умолчанию. Мы считаем, что он способен обеспечить некоторое ускорение для 95% проектов. При необходимости его можно отключить с помощью глобальной настройки STATIC_PARSER.

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

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

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

Нашли ошибку?

Создать GitHub Issue