(Версии dbt: v2.0 и новее) # Подключение Snowflake к dbt v2 Локальная разработка Настройте адаптер Snowflake командой `dbt init` или вручную создайте `profiles.yml` с полями для выбранного способа аутентификации. Список функций Snowflake, поддерживаемых в режиме `strict` в dbt v2, приведён в разделе [Поддержка функций Snowflake](https://docs.getdbt.tech/reference/resource-configs/snowflake-function-support.md). Адаптер Snowflake для dbt v2 поддерживает следующие [способы аутентификации](#supported-authentication-types): * Password * Key pair * Single sign-on (SSO) * Password with MFA * Workload Identity Federation примечание [Snowflake прекращает поддержку входа только по паролю](https://docs.snowflake.com/en/user-guide/security-mfa-rollout). Разработчикам следует использовать MFA или SSO. Вход по паролю остаётся доступным для сервисных пользователей Snowflake типа `LEGACY_SERVICE`. ## Разрешения в хранилище Пользователь или служебная учётная запись Snowflake, от имени которых подключается dbt v2, должны иметь возможность выполнять рабочие нагрузки dbt (запросы, операции с метаданными и стандартные материализации). Предоставьте привилегии через роль Snowflake, назначенную этому пользователю. ### Необходимые объекты Snowflake Перед подключением должны существовать следующие объекты: | Объект | Назначение | | --------------------- | ---------------------------------------------------------- | | **Аккаунт** | Идентификатор вашего аккаунта Snowflake | | **Пользователь** | Служебная учётная запись или пользователь для dbt v2 | | **Роль** | Роль с необходимыми привилегиями, назначенная пользователю | | **Виртуальный склад** | Виртуальный склад для выполнения вычислений | | **База данных** | Целевая база данных или базы данных для моделей dbt | | **Схема** | Целевая схема или схемы в базе данных | ### Основные операции Для основных операций dbt необходимы следующие разрешения: | Разрешение | Объект | Назначение | | -------------- | ------------------------- | -------------------------------------------------------- | | `USAGE` | Виртуальный склад | Выполнение запросов | | `USAGE` | База данных | Доступ к базе данных | | `USAGE` | Схема | Доступ к схемам | | `SELECT` | Таблицы или представления | Чтение существующих данных и источников | | `CREATE TABLE` | Схема | Создание моделей, материализованных в виде таблиц | | `CREATE VIEW` | Схема | Создание моделей, материализованных в виде представлений | | `INSERT` | Таблицы | Загрузка данных в таблицы | | `UPDATE` | Таблицы | Обновление инкрементальных моделей | | `DELETE` | Таблицы | Инкрементальные модели с удалением и вставкой данных | | `TRUNCATE` | Таблицы | Полное обновление инкрементальных моделей | | `DROP` | Таблицы или представления | Замена существующих объектов | ### Операции с метаданными Для операций dbt с метаданными необходимы следующие разрешения: | Разрешение | Объект | Назначение | | --------------------- | ------------------- | --------------------------------------- | | `USAGE` | INFORMATION\_SCHEMA | Запрос метаданных таблиц и столбцов | | `DESCRIBE TABLE` | Таблицы | Получение информации о структуре таблиц | | `SHOW OBJECTS` | Схема | Получение списка отношений в схеме | | `SHOW USER FUNCTIONS` | Схема | Обнаружение UDF (если используются) | ### Управление схемами и базами данных Следующие разрешения для управления схемами и базами данных необходимы при определённых условиях: | Разрешение | Объект | Когда требуется | | ----------------- | ----------- | --------------------------------------------------- | | `CREATE SCHEMA` | База данных | Если dbt должен автоматически создавать схемы | | `CREATE DATABASE` | Аккаунт | Если dbt должен автоматически создавать базы данных | ### Расширенные возможности Для расширенных возможностей доступны следующие необязательные разрешения: | Разрешение | Объект | Возможность | | -------------------- | ------ | ----------------------------------------------------- | | `CREATE STAGE` | Схема | Промежуточное размещение файлов для seeds или снимков | | `CREATE FILE FORMAT` | Схема | Пользовательские форматы файлов | | `CREATE SEQUENCE` | Схема | Последовательности | | `EXECUTE TASK` | Схема | Задачи Snowflake | Примеры ролей и выдачи прав через SQL приведены в разделе [Разрешения Snowflake](https://docs.getdbt.tech/reference/database-permissions/snowflake-permissions.md). ## Параметры подключения Snowflake Данные для настройки адаптера можно найти в меню аккаунта Snowflake: 1. Нажмите на своё имя в боковой панели Snowflake. 2. Наведите указатель на **Account**. 3. Рядом с именем аккаунта нажмите **View account details**. 4. Нажмите **Config file** и выберите нужные **Warehouse** и **Database**. [![Пример файла конфигурации в Snowflake](/img/v2/connect-adapters/snowflake-account-details.png?v=2 "Пример файла конфигурации в Snowflake")](#)Пример файла конфигурации в Snowflake ## Настройка dbt v2 При запуске `dbt init` в CLI укажите следующие данные: * **Account:** номер аккаунта Snowflake. * **User:** имя пользователя Snowflake. * **Database:** база данных Snowflake, которую нужно подключить к проекту. * **Warehouse:** вычислительное хранилище для выполнения задач проекта. * **Schema:** схема для разработки, промежуточной среды или развёртывания. * **Role (необязательно):** роль, которую dbt принимает при подключении к хранилищу. Файл `profiles.yml` также можно создать вручную. Формат полей показан в разделе [Способы аутентификации](#supported-authentication-types). Если файл уже существует, можно сохранить текущие поля или перезаписать их. Выберите способ аутентификации и заполните запрошенные поля. ## Поддерживаемые способы аутентификации ### Password При аутентификации по паролю Snowflake запрашивает пароль аккаунта. Организации всё реже используют этот способ, переходя на более безопасные варианты. Если выбрать **Password with MFA**, откроется страница входа в Snowflake, где нужно использовать ключ доступа или ввести код из приложения-аутентификатора. #### Пример настройки с паролем profiles.yml ```yml default: target: dev outputs: dev: type: snowflake threads: 16 account: ABC123 user: JANE.SMITH@YOURCOMPANY.COM database: JAFFLE_SHOP warehouse: TRANSFORM schema: JANE_SMITH password: THISISMYPASSWORD ``` #### Пример настройки с паролем и MFA profiles.yml ```yml default: target: dev outputs: dev: type: snowflake threads: 16 authenticator: username_password_mfa account: ABC123 user: JANE.SMITH@YOURCOMPANY.COM database: JAFFLE_SHOP warehouse: TRANSFORM schema: JANE_SMITH ``` ### Key pair При аутентификации по паре ключей можно: * Указать путь к файлу ключа. * Вставить ключ в формате PEM непосредственно в конфигурацию. Мы рекомендуем использовать формат PKCS#8 с шифрованием AES-256 для аутентификации с помощью пары ключей в dbt v2. dbt v2 не поддерживает устаревшее шифрование 3DES и форматы ключей без заголовка. Использование устаревших форматов ключей может привести к сбоям аутентификации. Если вы столкнулись с ошибкой `Key is PKCS#1 (RSA private key). Snowflake requires PKCS#8`, ваш закрытый ключ имеет неверный формат. У вас есть два варианта: * (Рекомендуемое решение) Повторно экспортируйте ключ с использованием современного шифрования: ```bash # Convert to PKCS#8 with AES-256 encryption openssl genrsa 2048 | openssl pkcs8 -topk8 -v2 aes-256-cbc -inform PEM -out rsa_key.p8 ``` * (Временное решение) Добавьте заголовок `BEGIN` и завершающую строку `END` к телу PEM: ```text -----BEGIN ENCRYPTED PRIVATE KEY----- < Your existing encrypted private key contents > -----END ENCRYPTED PRIVATE KEY----- ``` После настройки ключа можно указать парольную фразу, если она нужна. #### Пример настройки пары ключей profiles.yml ```yml default: target: dev outputs: dev: type: snowflake threads: 16 account: ABC123 user: JANE.SMITH@YOURCOMPANY.COM database: JAFFLE_SHOP warehouse: TRANSFORM schema: JANE_SMITH private_key: '' private_key_passphrase: YOURPASSPHRASEHERE ``` ### Single sign-on При едином входе сеанс Snowflake подтверждается в браузере. По умолчанию для каждого нового подключения dbt нужно заново пройти аутентификацию в браузере. Коннектор Snowflake умеет кэшировать токен сеанса, но [пока только на Windows и macOS](https://docs.snowflake.com/en/user-guide/admin-security-fed-auth-use.html#optional-using-connection-caching-to-minimize-the-number-of-prompts-for-authentication). Как включить эту функцию для своего аккаунта, описано в [документации Snowflake](https://docs.snowflake.com/en/sql-reference/parameters.html#label-allow-id-token). #### Пример настройки SSO profiles.yml ```yml default: target: dev outputs: dev: type: snowflake threads: 16 authenticator: externalbrowser account: ABC123 user: JANE.SMITH@YOURCOMPANY.COM database: JAFFLE_SHOP warehouse: TRANSFORM schema: JANE_SMITH ``` ### Workload Identity Federation Workload Identity Federation (WIF) позволяет входить в Snowflake из облачной среды с удостоверением этой среды. Snowflake сопоставляет удостоверение с сервисным пользователем, поэтому хранить пароль или ключ не нужно. Можно использовать токен OpenID Connect (OIDC), например выданный процессу GitHub Actions, или удостоверение AWS, Azure либо GCP. Перед настройкой dbt создайте сервисного пользователя Snowflake с удостоверением рабочей нагрузки. См. [документацию Snowflake](https://docs.snowflake.com/en/user-guide/workload-identity-federation). Для аутентификации через WIF укажите следующие поля в `profiles.yml`: | Параметр | Обязательный? | Описание | | ---------------------------------- | ------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | `method` | Да | Укажите `workload_identity`. | | `workload_identity_provider` | Да | Поставщик удостоверения. Допустимые значения: `OIDC`, `AWS`, `AZURE` или `GCP`. | | `token` | Нет | Обязательно для OIDC. Передайте токен через `env_var()`. Для AWS, Azure и GCP поле не задаётся. | | `workload_identity_entra_resource` | Нет | Только для Azure. Задайте поле, если Snowflake ожидает пользовательское приложение Entra в качестве аудитории токена. Значение — URI идентификатора приложения, например `api://APPLICATION_ID`. | Не задавайте `authenticator` вместе с `method`: профиль с обоими полями не будет работать. Поле `user` необязательно. Snowflake использует сервисного пользователя, сопоставленного с удостоверением облачной среды. Пример с OIDC: profiles.yml ```yml default: target: dev outputs: dev: type: snowflake threads: 16 account: ACCOUNT_ID # Snowflake account identifier role: USER_ROLE # Snowflake role to assume database: DATABASE_NAME # Snowflake database warehouse: WAREHOUSE_NAME # Snowflake warehouse schema: SCHEMA_NAME # dbt schema method: workload_identity workload_identity_provider: OIDC # Or AWS, AZURE, or GCP token: "{{ env_var('SNOWFLAKE_TOKEN') }}" # OIDC token ``` Для AWS, Azure или GCP используйте ту же конфигурацию, изменив `workload_identity_provider` и убрав `token`. Эти варианты работают только при запуске dbt в соответствующей облачной среде. ## Дополнительные сведения Настройки Snowflake описаны в [справочнике адаптера](https://docs.getdbt.tech/reference/resource-configs/snowflake-configs.md).