Ограничения и ответы по интеграции Git с папками Databricks Git

Папки Databricks Git и интеграция с Git имеют ограничения, указанные в следующих разделах. Общие сведения см. в статье Ограничения Databricks.

Ограничения размера файлов и репозитория

В Azure Databricks не применяется ограничение на размер репозитория. Тем не менее

• Размер рабочих ветвей ограничен 200 МБ.
• Отдельные файлы рабочей области подвергаются отдельному ограничению размера. Дополнительные сведения см. в разделе "Ограничения".
• Файлы размером более 10 МБ невозможно просмотреть в пользовательском интерфейсе Azure Databricks.

В Databricks рекомендуется, чтобы в репозитории:

• общее количество всех файлов не превышало 10 000;
• общее количество записных книжек не превышало 5000.

Для любой операции Git использование памяти ограничено 2 ГБ, а запись дисков ограничена 4 ГБ. Так как ограничение выполняется для каждой операции, при попытке клонировать репозиторий Git с текущим размером составляет 5 ГБ. Однако если клонировать репозиторий Git размером 3 ГБ в одной операции, а затем добавить в нее 2 ГБ позже, следующая операция вытягивания будет выполнена успешно.

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

Чтобы работать с репозиторием, превышающим ограничения размера, попробуйте выполнить разреженную проверку.

Если вы должны записывать временные файлы, которые не нужно хранить после завершения работы кластера, записывает временные файлы, чтобы $TEMPDIR избежать превышения ограничений размера ветви и обеспечивает лучшую производительность, чем запись в текущий рабочий каталог (CWD), если CWD находится в файловой системе рабочей области. Дополнительные сведения см. в статье "Где следует записывать временные файлы в Azure Databricks?".

Максимальное количество папок Git на рабочую область

В рабочей области может быть не более 2 000 папок Git. Если требуется больше, обратитесь в службу поддержки Databricks.

Поддержка единого репозитория

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

Конфигурация папки Git

Где хранится содержимое репозитория Azure Databricks?

Содержимое репозитория временно клонируется на диск на уровне управления. Файлы записной книжки Azure Databricks хранятся в базе данных на уровне управления, как и записные книжки в основной рабочей области. Файлы, не относящиеся к записной книжке, хранятся на диске до 30 дней.

Поддерживают ли папки Git локальные или локальные серверы Git?

Папки Databricks Git поддерживают GitHub Enterprise, Bitbucket Server, Azure DevOps Server и локальную интеграцию GitLab, если сервер доступен в Интернете. Дополнительные сведения об интеграции папок Git с локальным сервером Git см. на сервере прокси-сервера Git для папок Git.

Чтобы интегрироваться с Bitbucket Server, GitHub Enterprise Server или экземпляром самостоятельно управляемой подписки GitLab, который недоступен в Интернете, обратитесь к команде по учетной записи Azure Databricks.

Какие типы ресурсов Databricks поддерживаются папками Git?

Дополнительные сведения о поддерживаемых типах активов см. в статье "Управление файлами" в папках Databricks Git.

Поддерживают .gitignore ли папки Git файлы?

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

.gitignore работает только для файлов, которые еще не отслеживаются в Git. Если добавить в файл .gitignore тот файл, который уже отслеживается в Git, файл все равно будет отслеживаться в Git.

Можно ли создавать папки верхнего уровня, не являющиеся пользовательскими папками?

Да, администраторы могут создавать папки верхнего уровня с одним уровнем. Папки Git не поддерживают дополнительные уровни папок.

Поддерживают ли папки Git подмодулы Git?

№ Вы можете клонировать репозиторий, содержащий подмодули Git, но подмодуль не клонируется.

Поддерживает ли Фабрика данных Azure (ADF) папки Git?

Да.

Управление источником

Почему панели мониторинга записной книжки исчезают при получении или извлечении другой ветви?

В настоящее время это ограничение, так как исходные файлы записной книжки Azure Databricks не хранят сведения о панели мониторинга записной книжки.

Если вы хотите сохранить панели мониторинга в репозитории Git, измените формат .ipynb записной книжки на (формат записной книжки Jupyter). По умолчанию .ipynb поддерживает определения панели мониторинга и визуализации. Если вы хотите сохранить данные графа (точки данных), необходимо зафиксировать записную книжку с выходными данными.

Сведения о фиксации .ipynb выходных данных записной книжки см. в статье "Разрешить фиксацию .ipynb выходных данных записной книжки".

Поддерживают ли папки Git объединение ветвей?

Да. Вы также можете создать запрос на вытягивание и объединить с помощью поставщика Git.

Можно ли удалить ветвь из репозитория Azure Databricks?

№ Чтобы удалить ветвь, необходимо работать в поставщике Git.

Если библиотека установлена в кластере, и в папку в репозитории входит библиотека с тем же именем, то какая библиотека будет импортирована?

Импортируется библиотека в репозитории. Дополнительные сведения о приоритете библиотеки в Python см. в разделе "Приоритет библиотеки Python".

Можно ли вытянуть последнюю версию репозитория из Git перед запуском задания, не используя внешнее средство оркестрации?

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

Можно ли экспортировать репозиторий?

Вы можете экспортировать записные книжки, папки или весь репозиторий. Невозможно экспортировать файлы, отличные от записных книжек. При экспорте всего репозитория файлы, не являющиеся записными книжками, не включаются. Чтобы экспортировать, используйте команду в интерфейсе командной строки Databricks или используйте workspace export API рабочей области.

Безопасность, проверка подлинности и маркеры

Проблема с политикой условного доступа (CAP) для идентификатора Microsoft Entra (ранее Azure Active Directory)

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

• Azure Databricks настроен для использования Azure DevOps с проверкой подлинности идентификатора Microsoft Entra.
• Вы включили политику условного доступа в Azure DevOps и политику условного доступа Идентификатора Microsoft Entra.

Чтобы устранить эту проблему, добавьте исключение в политику условного доступа (CAP) для IP-адреса или пользователей Azure Databricks.

Дополнительные сведения см. в разделе "Политики условного доступа".

Список разрешений с маркерами Azure AD

Если вы используете Azure Active Directory (AAD) для аутентификации с помощью Azure DevOps, список разрешений по умолчанию ограничивает URL-адреса Git следующими:

• dev.azure.com
• visualstudio.com

Дополнительные сведения см. в разделе Списки разрешений для ограничения использования удаленного репозитория.

Зашифрованы ли содержимое папок Azure Databricks Git?

Содержимое папок Azure Databricks Git шифруется Azure Databricks с помощью ключа по умолчанию. Шифрование с помощью ключей, управляемых клиентом, не поддерживается, за исключением шифрования учетных данных Git.

Как и где токены GitHub хранятся в Azure Databricks? Кто может получить доступ из Azure Databricks?

• Маркеры проверки подлинности хранятся в плоскости управления Azure Databricks, а сотрудник Azure Databricks может получить доступ только через временные учетные данные, которые подлежат аудиту.
• Azure Databricks регистрирует создание и удаление этих маркеров, но не их использование. В Azure Databricks выполняется ведение журнала, отслеживающее операции Git, которые можно использовать для аудита использования маркеров приложением Azure Databricks.
• Использование маркеров аудита в GitHub Enterprise. В других службах Git также может выполняться аудит сервера Git.

Поддерживают ли папки Git подписывание фиксаций GPG?

№

Поддерживают ли папки Git SSH?

Нет, только HTTPS.

Ошибка при подключении Azure Databricks к репозиторию Azure DevOps в другом клиенте

При попытке подключиться к DevOps в отдельном клиенте может появиться сообщение Unable to parse credentials from Azure Active Directory account. Если проект Azure DevOps находится в другом клиенте Идентификатора Microsoft Entra из Azure Databricks, необходимо использовать маркер доступа из Azure DevOps. См. статью "Подключение к Azure DevOps" с помощью токена DevOps.

CI/CD и MLOps

Входящие изменения очищают состояние записной книжки

Операции Git, изменяющие исходный код записной книжки, приводят к потере состояния записной книжки, включая выходные данные ячеек, комментарии, журнал версий и мини-приложения. Например, git pull можно изменить исходный код записной книжки. В этом случае папки Databricks Git должны перезаписать существующую записную книжку для импорта изменений. git commit и push или создание новой ветви не влияют на исходный код записной книжки, поэтому состояние записной книжки сохраняется в этих операциях.

Внимание

Эксперименты MLflow не работают в папках Git с DBR 14.x или более низкими версиями.

Можно ли создать эксперимент MLflow в репозитории?

Существует два типа экспериментов MLflow: рабочая область и записная книжка. Дополнительные сведения о двух типах экспериментов MLflow см. в разделе "Упорядочивание учебных запусков с помощью экспериментов MLflow".

В папках Git можно вызвать mlflow.set_experiment("/path/to/experiment") эксперимент MLflow любого типа и журналов, но этот эксперимент и связанные запуски не будут проверены в системе управления версиями.

Эксперименты MLflow рабочей области

Невозможно создать эксперименты MLflow рабочей области в папке Databricks Git (папка Git). Если несколько пользователей используют отдельные папки Git для совместной работы в одном коде машинного обучения, журнал MLflow запускается в эксперимент MLflow, созданный в обычной папке рабочей области.

Эксперименты с записными книжками MLflow

Эксперименты записной книжки можно создать в папке Databricks Git. При проверке записной книжки в системе .ipynb управления версиями в качестве файла можно записать запуск MLflow в автоматически созданный и связанный эксперимент MLflow. Дополнительные сведения см. в статье о создании экспериментов записной книжки.

Предотвращение потери данных в экспериментах MLflow

Предупреждение

При переходе на ветвь, которая не содержит записную книжку, вы рискуете потерять связанные данные эксперимента MLflow. Эта потеря становится пермнанентной, если предыдущий филиал недоступен в течение 30 дней.

Чтобы восстановить отсутствующие данные эксперимента до истечения срока действия 30 дней, переименуйте записную книжку обратно в исходное имя, откройте записную книжку, щелкните значок "Эксперимент" на правой боковой панели (это также эффективно вызывает mlflow.get_experiment_by_name() API), и вы сможете увидеть восстановленный эксперимент и запуск. Через 30 дней все потерянные эксперименты MLflow будут удалены для удовлетворения политик соответствия GDPR.

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

Предупреждение

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

Что произойдет, если задание записной книжки выполняется в рабочей области во время выполнения операции Git?

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

Например, предположим, что notebook A вызовы notebook Z с помощью %run команды. Если задание, выполняемое во время операции Git, запускает самую последнюю версию notebook A, но notebook Z еще не обновлена, %run команда в записной книжке A может запустить более раннюю версию notebook Z. Во время операции Git состояния записной книжки не прогнозируются, а задание может завершиться ошибкой или выполнением notebook A и notebook Z от различных фиксаций.

Чтобы избежать этой ситуации, используйте задания на основе Git (где источник является поставщиком Git, а не путем к рабочей области). Дополнительные сведения см. в статье "Использование управляемого версиями исходного кода в задании Azure Databricks".

Ресурсы

Дополнительные сведения о файлах рабочей области Databricks см. в разделе "Что такое файлы рабочей области?".