# Подключение Redshift Совместимо с dbt v2 Платформа dbt dbt platform поддерживает подключение к Redshift. ## Права доступа к хранилищу данных для dbt v2 Пользователь базы данных Redshift, которого использует dbt v2, должен иметь возможность выполнять рабочие нагрузки dbt и читать метаданные каталога, используемые для интроспекции. ### Необходимые объекты Redshift Перед подключением следующие объекты должны существовать или быть доступны: | Объект | Назначение | | ------------------------------------------------------------- | ------------------------------------------- | | **Кластер** (provisioned) или **рабочая группа** (serverless) | Вычислительный ресурс | | **База данных** | Целевая база данных | | **Схема** | Целевая схема в базе данных | | **Пользователь** | Пользователь базы данных для аутентификации | | **Роль или профиль IAM** (необязательно) | Для аутентификации на основе IAM | ### Основные разрешения Для базовых функций dbt необходимы следующие разрешения: | Разрешение | Объект | Назначение | | ---------- | ------------------------- | --------------------------------------- | | `USAGE` | Схема | Доступ к схеме | | `CREATE` | Схема | Создание таблиц и представлений в схеме | | `SELECT` | Таблицы или представления | Чтение данных | | `INSERT` | Таблицы | Вставка данных | | `UPDATE` | Таблицы | Обновление данных | | `DELETE` | Таблицы | Удаление данных | | `DROP` | Таблицы или представления | Удаление или замена объектов | | `TRUNCATE` | Таблицы | Очистка таблиц | ### Операции с метаданными dbt v2 запрашивает следующие системные отношения Redshift: | Системное отношение | Назначение | Необходимое разрешение | | ------------------- | ------------------------------------------------------------------------- | ----------------------------------- | | `SVV_ALL_COLUMNS` | Метаданные столбцов | SELECT для системного представления | | `pg_class` | Получение списка отношений | Доступ к системному каталогу | | `pg_namespace` | Информация о схемах | Доступ к системному каталогу | | `sys_query_detail` | Проверка актуальности источников (время последней вставки) | SELECT для системного представления | | `svv_table_info` | Получение списка материализованных представлений, если они есть в проекте | SELECT для системного представления | | `svv_mv_info` | Получение списка материализованных представлений, если они есть в проекте | SELECT для системного представления | ### Управление схемами Разрешения для управления схемами, необходимые при определённых условиях | Разрешение | Объект | Когда требуется | | --------------- | ----------- | ---------------------------- | | `CREATE SCHEMA` | База данных | Автоматическое создание схем | Примеры SQL-команд для предоставления прав доступа в Redshift см. в разделе [Права доступа в Redshift](https://docs.getdbt.tech/reference/database-permissions/redshift-permissions.md). ## Поля подключения При создании подключения используйте следующие поля: | Поле | Обязательное? | Описание | Примеры | | --------------- | ------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------- | | Server Hostname | Да | Имя хоста базы данных, к которой нужно подключиться. Это может быть имя хоста или IP-адрес. Чтобы найти имя хоста, см. раздел [Поиск кластера](https://docs.aws.amazon.com/redshift/latest/mgmt/connecting-connection-string.html). | Redshift: `hostname.region.redshift.amazonaws.com` | | Port | Да | Обычно 5439 (Redshift) | `5439` | | Database | Нет | Логическая база данных, к которой нужно подключиться и в которой будут выполняться запросы. | `analytics` | | Retries | Нет | Количество повторных попыток (для каждой SQL-инструкции). Если не задано, по умолчанию используется 3. Максимальное значение — 10. | `4` | **Примечание**: При настройке подключения к Redshift в dbt параметры SSL недоступны для ввода. [![Настройка подключения к Redshift](/img/docs/dbt-cloud/cloud-configuring-dbt-cloud/postgres-redshift-connection.png?v=2 "Настройка подключения к Redshift")](#)Настройка подключения к Redshift [![Настройка подключения к Redshift](/img/docs/dbt-platform/platform-configuring-dbt-platform/postgres-redshift-connection.png?v=2 "Настройка подключения к Redshift")](#)Настройка подключения к Redshift Ниже приведены поддерживаемые способы аутентификации для Redshift: * Имя пользователя и пароль * SSH-туннелирование * Identity Center через [external Oauth](https://docs.getdbt.tech/docs/platform/manage-access/redshift-external-oauth.md) * Аутентификация IAM User через [extended attributes](https://docs.getdbt.tech/docs/dbt-platform-environments.md#extended-attributes) * Имя пользователя и пароль * SSH-туннелирование * AWS IAM Identity Center через [внешний OAuth](https://docs.getdbt.tech/docs/platform/manage-access/redshift-external-oauth.md) (Okta или Entra ID) для подключений в среде разработки * Аутентификация пользователя IAM через [расширенные атрибуты](https://docs.getdbt.tech/docs/dbt-platform-environments.md#extended-attributes) На dbt platform аутентификация пользователя IAM в настоящее время поддерживается только через [расширенные атрибуты](https://docs.getdbt.tech/docs/dbt-platform-environments.md#extended-attributes). После создания проекта среды разработки и развертывания можно настроить на использование расширенных атрибутов для передачи описанных ниже полей, поскольку некоторые из них не поддерживаются при вводе через текстовые поля. * для кластера — в поле `user` должен быть указан пользователь базы данных. IAM User используется только для аутентификации, а пользователь базы данных — для авторизации * для Serverless — выдать IAM User разрешения в Redshift. Поле `user` игнорируется (но всё равно является обязательным) * в обоих случаях поле `password` будет игнорироваться. | Profile field | Example | Description | | ------------------- | ------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------ | | `method` | IAM | Используйте IAM для аутентификации от имени пользователя IAM | | `cluster_id` | CLUSTER\_ID | Требуется для аутентификации IAM только для выделенного кластера, но не для Serverless | | `user` | username | Пользователь, выполняющий запросы к базе данных; игнорируется для Serverless (но по-прежнему обязателен) | | `region` | us-east-1 | Регион вашего экземпляра Redshift | | `access_key_id` | ACCESS\_KEY\_ID | [Идентификатор ключа доступа](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_access-keys.html#Using_CreateAccessKey) пользователя IAM | | `secret_access_key` | SECRET\_ACCESS\_KEY | Секретный ключ доступа пользователя IAM |
#### Пример Extended Attributes для IAM User в Redshift Serverless Чтобы не вставлять секреты напрямую в extended attributes, используйте [переменные окружения](https://docs.getdbt.tech/docs/build/environment-variables.md#handling-secrets): \~/.dbt/profiles.yml ```yaml host: my-production-instance.myregion.redshift-serverless.amazonaws.com method: iam region: us-east-2 access_key_id: '{{ env_var(''DBT_ENV_ACCESS_KEY_ID'') }}' secret_access_key: '{{ env_var(''DBT_ENV_SECRET_ACCESS_KEY'') }}' ``` И `DBT_ENV_ACCESS_KEY_ID`, и `DBT_ENV_SECRET_ACCESS_KEY` должны быть [заданы](https://docs.getdbt.tech/docs/build/environment-variables.md) для каждой среды, использующей extended attributes таким образом. ### Подключение через SSH-туннель Используйте SSH-туннель, если ваш экземпляр Redshift недоступен из общедоступной сети и доступ к нему должен осуществляться через [бастионный сервер](https://docs.getdbt.tech/docs/platform/connect-data-platform/connect-redshift.md#about-the-bastion-server-in-aws). Если эта функция включена, dbt platform подключается к вашей базе данных, сначала устанавливая защищённое соединение с бастионным сервером, который затем перенаправляет трафик в вашу базу данных. Чтобы настроить подключение через SSH-туннель: 1. Перейдите в **Account settings** (нажав на название своей учётной записи в левом боковом меню) и выберите **Connections**. 2. Выберите существующее подключение для редактирования или нажмите **+ New connection**. 3. В разделе **Connection settings** убедитесь, что установлен флажок **SSH Tunnel Enabled**. 4. Введите имя хоста, имя пользователя и порт бастионного сервера. [![Открытый ключ генерируется после сохранения](/img/docs/dbt-platform/platform-configuring-dbt-platform/postgres-redshift-ssh-tunnel.png?v=2 "Открытый ключ генерируется после сохранения")](#)Открытый ключ генерируется после сохранения 5. Нажмите **Save**. dbt platform сгенерирует и отобразит открытый ключ. 6. Скопируйте новый открытый ключ на бастионный сервер и добавьте его в файл `authorized_keys` сервера, чтобы разрешить dbt platform подключаться через бастионный сервер. Если новый ключ не добавлен, установить соединение через SSH-туннель не удастся. important Каждый раз, когда вы создаёте и сохраняете новое подключение через SSH-туннель, dbt platform генерирует уникальную пару SSH-ключей, даже если параметры подключения полностью совпадают с параметрами существующего подключения. #### О бастионном сервере в AWS Что такое бастионный сервер? Бастионный сервер в [Amazon Web Services (AWS)](https://aws.amazon.com/blogs/security/how-to-record-ssh-sessions-established-through-a-bastion-host/) — это хост, который позволяет dbt устанавливать SSH-соединение.
dbt только отправляет запросы и не передаёт большие объёмы данных. Это означает, что бастионный сервер может работать на инстансе AWS любого размера, например t2.small или t2.micro.

Убедитесь, что инстанс расположен в той же Virtual Private Cloud (VPC), что и экземпляр Redshift, и что для группы безопасности bastion‑сервера настроены правила, позволяющие подключаться к порту хранилища данных. #### Настройка bastion‑сервера в AWS Чтобы настроить SSH-туннель в dbt, вам потребуется указать имя хоста или IP-адрес вашего бастионного сервера, имя пользователя и выбранный вами порт, к которому будет подключаться dbt. Выполните следующие действия: 1. Убедитесь, что правила сетевой безопасности бастионного сервера разрешают подключения с [IP-адресов dbt](https://docs.getdbt.tech/docs/platform/about-platform/access-regions-ip-addresses.md) через настроенный вами порт. 2. Настройте учетную запись пользователя с помощью интерфейса командной строки (CLI) экземпляра бастионного сервера. В следующем примере используется имя пользователя `dbtcloud`: ```shell sudo groupadd dbtcloud sudo useradd -m -g dbtcloud dbtcloud sudo su - dbtcloud mkdir ~/.ssh chmod 700 ~/.ssh touch ~/.ssh/authorized_keys chmod 600 ~/.ssh/authorized_keys ``` 3. Скопируйте открытый ключ, сгенерированный dbt, и вставьте его в файл authorized\_keys. Теперь бастионный сервер должен быть готов к использованию dbt в качестве туннеля для подключения к среде Redshift. ## Конфигурация Чтобы оптимизировать производительность с помощью настроек, специфичных для платформы данных, в dbt, обратитесь к разделу [Конфигурация для Redshift](https://docs.getdbt.tech/reference/resource-configs/redshift-configs.md). ## FAQs  Ошибка базы данных - не удалось подключиться к серверу: время ожидания подключения истекло При настройке подключения к базе данных через SSH-туннель требуются следующие компоненты: * Балансировщик нагрузки (например, ELB или NLB) для управления трафиком. * Bastion host (или jump server), на котором работает SSH и который служит безопасной точкой входа. * Сама база данных (например, кластер Redshift). использует SSH-туннель для подключения через балансировщик нагрузки к базе данных. Это подключение устанавливается в начале выполнения каждого задания dbt. Если соединение туннеля разрывается, выполнение задания завершается с ошибкой. dbt использует SSH-туннель для подключения к базе данных через балансировщик нагрузки. Это соединение устанавливается в начале каждого запуска задания dbt. Если соединение через туннель обрывается, задание завершается с ошибкой. * SSH-демон завершает соединение, если оно слишком долго простаивает. * Балансировщик нагрузки разрывает соединение при простое. * пытается поддерживать соединение, отправляя проверки каждые 30 секунд, и система завершает соединение, если от SSH-сервиса нет ответа в течение 300 секунд. Это помогает избежать разрывов из-за простоя, если только таймаут балансировщика нагрузки не меньше 30 секунд. * Демон SSH завершает соединение по тайм-ауту при слишком долгом бездействии. * Балансировщик нагрузки разрывает соединение при бездействии. * dbt пытается поддерживать соединение, отправляя проверочные запросы каждые 30 секунд. Если служба SSH не отвечает в течение 300 секунд, система завершает соединение. Это помогает избежать разрывов из-за бездействия, если только тайм-аут балансировщика нагрузки не составляет менее 30 секунд. Чтобы предотвратить преждевременные разрывы соединения, вы можете изменить настройки на bastion host: * `ClientAliveCountMax` — настраивает количество проверок перед тем, как клиент будет считаться неактивным. Например, `ClientAliveCountMax 10` выполняет 10 проверок. * `ClientAliveInterval` — настраивает интервал проверки активности клиента. Например, `ClientAliveInterval 30` выполняет проверку каждые 30 секунд. Приведённые примеры настроек обеспечивают отключение неактивных SSH-клиентов примерно через 300 секунд, снижая вероятность сбоев туннеля.