Обзор подключений к базам данных¶

Содержание¶

1. Как работают подключения
2. Руководства по технологиям
3. Предварительное условие: установка драйвера ODBC на хосте digna
4. Создание подключения к базе данных
5. Свойства ODBC
6. Шифрование значений свойств
7. Проверка подключения
8. Какую базу данных видит подключение
9. Режим профилирования и рабочая схема
10. Использование DSN
11. Устранение неполадок

Как работают подключения¶

digna обращается к каждой технологии-источнику через ODBC. Подключение — это список свойств ODBC, которые вы вводите в виде пар «ключ/значение». Когда digna открывает подключение, она объединяет эти пары в строку подключения — Key=Value, разделённые ;, в том порядке, в котором вы их указали, — и передаёт её диспетчеру драйверов ODBC на хосте digna.

Именно то, что вы сами вводите свойства, делает настройку без DSN (DSN-less): подключение содержит всё, что нужно драйверу, поэтому на хосте не требуется регистрировать источник данных ODBC (DSN). Это рекомендуемый способ настройки digna, поскольку определение подключения целиком хранится в digna и переносится вместе с ней.

Почему ODBC¶

В ранних релизах можно было выбрать между драйвером для конкретной технологии и ODBC с помощью переключателя Use ODBC. Начиная с Release 2026.06, digna работает только через ODBC. Единый стандартный интерфейс даёт больше, чем набор специализированных драйверов:

• Аутентификация — аутентификация является частью ODBC, поэтому подключение может использовать всё, что поддерживает его драйвер: пароли, токены и PAT, Kerberos и Active Directory, MFA и единый вход через браузер, облачные учётные записи, клиентские сертификаты и TLS. Новые методы появляются с обновлением драйвера, без ожидания нового релиза digna.
• Драйверы, которые поддерживают сами производители баз данных — собственный драйвер производителя следит за новыми версиями сервера и исправлениями безопасности, и вы можете обновлять его по своему графику, независимо от digna.
• Единый способ настройки — каждая технология описывается списком свойств «ключ/значение» с одним и тем же интерфейсом, одинаковым шифрованием конфиденциальных значений и одинаковым устранением неполадок, вместо отдельного набора полей для каждого источника.
• Тонкая настройка и охват — параметры уровня драйвера, такие как тайм-ауты, настройки TLS, прокси и размер выборки (fetch size), доступны для каждого источника, и можно подключить любую технологию с совместимым драйвером ODBC, в том числе ту, для которой у digna нет отдельного руководства.

Руководства по технологиям¶

Имена свойств различаются в зависимости от драйвера, и у каждой технологии есть одна-две особенности, которых нет у других. Руководства ниже описывают именно эту часть; эта страница описывает сторону digna, которая одинакова для всех.

Предварительное условие: установка драйвера ODBC на хосте digna¶

digna открывает подключения к источникам с сервера, на котором работает бэкенд digna, а не из браузера. Поэтому драйвер ODBC должен быть установлен на этой машине, а его имя — зарегистрировано в локальном диспетчере драйверов.

odbcinst -q -d

odbcinst -q -d

Вместо зарегистрированного имени все распространённые диспетчеры драйверов принимают также полный путь к библиотеке драйвера, например Driver=/opt/simba/spark/lib/64/libsparkodbc_sb64.so. Это удобно, когда драйвер установлен, но не зарегистрирован.

Создание подключения к базе данных¶

Откройте Admin Panel, перейдите на вкладку Database Connections и нажмите Add DB Connection. На экране нужно указать пять параметров:

Подключение администрируется централизованно, а затем назначается одному или нескольким проектам, поэтому одно и то же подключение может обслуживать несколько проектов.

Свойства ODBC¶

Для каждого свойства нажмите Add Property и заполните Key, Value, а для секретов — флажок Encrypted. В каждом руководстве по технологии приведён пример набора свойств, который вы адаптируете к своей версии драйвера и серверу, — см. примечание выше.

Независимо от драйвера набор свойств охватывает одни и те же четыре вещи:

• Driver — зарегистрированное имя драйвера, как описано выше.
• Адрес сервера — ключ зависит от драйвера: SERVER, HOST, DBCNAME, Server или, для Oracle, дескриптор подключения DBQ.
• Учётные данные — обычно UID и PWD; Snowflake использует UID и token, а Databricks — буквальное имя пользователя token и personal access token в PWD.
• База данных или каталог для работы, если в технологии они есть, — см. Какую базу данных видит подключение.

Всё остальное, что описано в документации драйвера, добавляется так же — пул подключений, тайм-ауты сокетов, настройки Kerberos, настройки прокси. digna не интерпретирует свойства, а только передаёт их дальше.

Шифрование значений свойств¶

Отметьте Encrypted для каждого свойства, содержащего секрет, — PWD, token, client secret. Тогда значение шифруется перед сохранением в репозитории digna, маскируется на экране и расшифровывается только при сборке строки подключения.

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

Проверка подключения¶

Нажмите Test в диалоге Add DB Connection перед сохранением. Проверка использует значения, находящиеся в форме в данный момент, и выполняет реальное подключение, поэтому сообщает ровно о том, с чем столкнулась бы инспекция, — неверное имя драйвера, отклонённый пароль, недоступный хост. Ничего не сохраняется: тестовое подключение откатывается независимо от того, успешно оно или нет.

Чтобы повторно проверить уже существующее подключение, наведите курсор на его строку на вкладке Database Connections и нажмите значок вилки (plug). Это самый быстрый способ проверить, доступен ли источник после смены пароля или изменения правил брандмауэра.

Какую базу данных видит подключение¶

Когда вы добавляете источник данных, digna предлагает каталоги, схемы и таблицы, доступные через подключение. Насколько широк этот охват, зависит от технологии:

Режим профилирования и рабочая схема¶

Режим профилирования определяет, как digna обрабатывает данные и рассчитывает метрики:

• Standard: метрики рассчитываются непосредственно на исходных таблицах без копирования данных.
• Permanent: данные за инспектируемый день копируются в постоянную таблицу, и метрики рассчитываются на скопированных данных.
• Session: данные копируются в сессионную или временную таблицу, и метрики рассчитываются на этих временных данных.

От режима зависит, какие права нужны пользователю подключения:

Standard только читает данные, поэтому именно этот режим следует выбирать, когда digna предоставлен доступ только на чтение. Work Schema используется только в режиме Permanent, но её всё равно стоит заполнить, чтобы подключение продолжало работать, если режим позже изменится.

Использование DSN¶

DSN по-прежнему работает — DSN является просто ещё одним свойством:

Key: DSN        Value: my_registered_dsn
Key: UID        Value: <user>
Key: PWD        Value: <password>        [Encrypted]

DSN должен быть зарегистрирован на хосте digna для той же учётной записи, под которой работает бэкенд digna, и как System DSN, если digna работает как служба. Всё, что настроено в DSN, можно переопределить, добавив это же значение в виде свойства.

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

Устранение неполадок¶

Data source name not found / no default driver specified¶

Симптомы: - Кнопка Test сообщает об ошибке с упоминанием data source name not found, хотя настройка выполнена без DSN

Причины и решения: 1. Значение Driver не совпадает с зарегистрированным именем драйвера — сравните его с вкладкой Drivers в ODBC Data Source Administrator (64-bit) или с выводом odbcinst -q -d 2. Драйвер установлен на вашей рабочей станции, но не на хосте digna 3. Драйвер 32-битный, а digna — 64-битная: установите 64-битный драйвер 4. Свойство Driver вообще отсутствует, и DSN тоже не указан 5. В Linux и macOS драйвер установлен, но не зарегистрирован — укажите вместо имени полный путь к библиотеке драйвера или зарегистрируйте его в odbcinst.ini

Истекает время ожидания при проверке подключения¶

Симптомы: - Test зависает, а примерно через полминуты завершается ошибкой

Причины и решения: 1. Хост или порт недоступен с хоста digna — проверьте брандмауэр, а для облачных источников — список разрешённых IP-адресов 2. Имя хоста правильное, но порт принадлежит другой службе 3. Источнику требуется больше стандартных 30 секунд, чтобы принять подключение, — увеличьте DIGNA_SOURCE_LOGIN_TIMEOUT_SEC в секции [base] файла config.toml (0 — ждать бесконечно) и перезапустите бэкенд 4. Бессерверная конечная точка выходит из режима простоя — повторите попытку, а если это происходит регулярно, увеличьте тайм-аут входа, как описано выше

Аутентификация не проходит, хотя учётные данные верны¶

Симптомы: - Драйвер сообщает о неверных учётных данных, хотя тот же пользователь работает в другом SQL-клиенте

Причины и решения: 1. Пароль содержит ; — заключите значение в фигурные скобки: {p@ss;word} 2. В значение скопировался пробел в конце 3. Драйвер ожидает определённый механизм аутентификации — например, AuthMech для драйверов Hive и Databricks или authenticator для Snowflake 4. Значение было сохранено в зашифрованном виде, а затем отредактировано — зашифрованные значения нельзя прочитать обратно, поэтому введите секрет заново полностью 5. Истёк срок действия токена — personal access tokens и programmatic access tokens выдаются с датой окончания действия

На экране источника данных нет ожидаемой базы данных или схемы¶

Симптомы: - При добавлении источника данных отсутствуют каталоги, схемы или таблицы

Причины и решения: 1. Подключение указывает на другую базу данных — см. Какую базу данных видит подключение 2. У пользователя подключения нет прав на чтение схемы или словаря данных 3. Technology не соответствует источнику, поэтому digna обращается не к тому словарю данных 4. В Snowflake пользователю не назначен склад (warehouse) по умолчанию и свойство Warehouse не указано, поэтому запросы метаданных не могут выполняться

Профилирование завершается ошибкой, хотя проверка подключения проходит¶

Симптомы: - Test проходит успешно, но инспекция завершается ошибкой при создании рабочих таблиц

Причины и решения: 1. Выбрано профилирование Permanent, а пользователь подключения не может создавать таблицы в Work Schema — предоставьте права или переключитесь на Session или Standard 2. Выбрано профилирование Permanent, а поле Work Schema пустое или содержит имя несуществующей схемы 3. Выбрано профилирование Session, а пользователю подключения запрещено создавать временные таблицы 4. Длительный запрос профилирования упирается в тайм-аут запроса — увеличьте DIGNA_SOURCE_QUERY_TIMEOUT_SEC в секции [base] файла config.toml (по умолчанию 3600 секунд, 0 отключает тайм-аут)

Рекомендации¶

РЕКОМЕНДУЕТСЯ:

• Устанавливать и регистрировать драйвер на хосте digna до настройки подключения
• Отмечать Encrypted для каждого пароля и токена
• Нажимать Test перед сохранением и повторять проверку после смены пароля
• Называть подключения по источнику и среде, например sales_dwh_prod
• Выделять digna отдельного пользователя базы данных, с доступом только на чтение, если достаточно профилирования Standard
• Использовать одно подключение на одну базу данных-источник и добавлять второе, а не перенастраивать первое

НЕ РЕКОМЕНДУЕТСЯ:

• Хранить секреты незашифрованными или использовать одного пользователя базы данных для digna и других инструментов
• Использовать 32-битный драйвер с 64-битной установкой digna
• Полагаться на User DSN, когда digna работает как служба, — он не будет виден
• Указывать в свойстве значение, содержащее ;, без фигурных скобок
• Направлять Work Schema на схему, содержащую исходные данные

Поддержка¶

Нужна помощь с подключением к базе данных?

• Email: support@digna.ai
• Документация: https://docs.digna.ai
• Веб-сайт: https://www.digna.ai

Релиз: 2026.06
© 2026 digna GmbH — www.digna.ai