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

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

Перейти к разделу:

• Ограничения файлов и репозитория
• Типы ресурсов, поддерживаемые в папках Git
• Вопросы и ответы: конфигурация папки Git

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

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

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

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

• Общее количество всех ресурсов и файлов рабочей области не превышает 20 000.

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

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

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

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

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

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

Восстановление файлов, удаленных из папок Git в рабочей области

Действия рабочей области в папках Git зависят от возможности восстановления файлов. Некоторые действия позволяют восстановить папку корзины , а другие — нет. Файлы, ранее зафиксированные и отправленные в удаленную ветвь, можно восстановить с помощью журнала фиксаций Git для удаленного репозитория Git. В этой таблице описывается поведение каждого действия и возможность восстановления:

Действие	Можно ли восстановить файл?
Удаление файла с помощью браузера рабочей области	Да, из папки корзины
Отмена нового файла с помощью диалогового окна папки Git	Да, из папки корзины
Отмена измененного файла с помощью диалогового окна папки Git	Нет, файл исчезнет
reset (жестко) для незафиксированных изменений файлов	Нет, изменения файлов исчезли
reset (жестко) для незафиксированных только что созданных файлов	Нет, изменения файлов исчезли
Переключение ветвей с помощью диалогового окна папки Git	Да, из удаленного репозитория Git
Другие операции Git (фиксация и отправка и т. д.) из диалогового окна папки Git	Да, из удаленного репозитория Git
PATCH операции обновления /repos/id из API Repos	Да, из удаленного репозитория Git

Файлы, удаленные из папки Git с помощью операций Git из пользовательского интерфейса рабочей области, можно восстановить из журнала удаленных ветвей с помощью командной строки Git (или других средств Git), если эти файлы были ранее зафиксированы и отправлены в удаленный репозиторий. Действия рабочей области зависят от возможности восстановления файлов. Некоторые действия позволяют восстановиться через корзину, а другие — нет. Файлы, ранее зафиксированные и отправленные в удаленную ветвь, можно восстановить с помощью журнала фиксации Git. В следующей таблице описано поведение каждого действия и возможность восстановления:

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

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

Типы ресурсов, поддерживаемые в папках Git

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

В настоящее время поддерживаемые типы активов:

Тип ресурса	Сведения
Файл	Файлы сериализуются и могут включать все, от библиотек до двоичных файлов и код изображений. Дополнительные сведения см. в статье "Что такое файлы рабочей области"?
Записная книжка	Записные книжки — это форматы файлов записной книжки, поддерживаемые Databricks. Записные книжки считаются отдельным типом ресурса Azure Databricks из файлов, так как они не сериализуются. Папки Git определяют записную книжку по расширению файла (например .ipynb) или расширениям файлов в сочетании с специальным маркером в содержимом файла (например, # Databricks notebook source комментарий в начале исходных .py файлов).
Папка	Папка — это структура Azure Databricks, представляющая сериализованные сведения о логической группировке файлов в Git. Как ожидается, пользователь использует это как папку при просмотре папки Azure Databricks Git или доступе к ней с помощью Интерфейса командной строки Azure Databricks.
запрос DBSQL	Запросы Databricks SQL (DBSQL) можно сохранить как блокноты IPYNB (расширение: .dbquery.ipynb). Поддержка Git для запросов DBSQL требует активации нового SQL-редактора. Запросы, созданные с отключенной новой функцией редактора SQL, могут быть помещены в папку Git, но не могут коммититься в удаленный репозиторий.

Типы ресурсов Azure Databricks, которые в настоящее время не поддерживаются в папках Git, включают следующее:

• видны узлы
• Панели мониторинга (включая устаревшие панели мониторинга)
• эксперименты;
• Джин пробелы

При работе с ресурсами в Git обратите внимание на следующие ограничения в именовании файлов:

• Папка не может содержать записную книжку с тем же именем, что и другая записная книжка, файл или папка в одном репозитории Git, даже если расширение файла отличается. (Для записных книжек исходного формата расширение предназначено .py для Python, .scala для Scala, .sql для SQL и .r R. Для записных книжек в формате IPYNB расширение равно .ipynb.) Например, нельзя использовать записную книжку исходного формата с именем и записную книжку IPYNB с именем test1.pytest1 в той же папке Git, так как файлtest1.py записной книжки Python исходного формата () сериализуется как test1 и конфликт возникнет.
• Символ / не поддерживается в именах файлов. Например, в папке Git не может быть файл с именем i/o.py .

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

Примечание.

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

Форматы записных книжек

Формат источника записной книжки	Сведения
source	Может быть любым файлом кода со стандартным суффиксом файла, который сигнализирует языку кода, например .py, .scala.r и .sql. Записные книжки источника обрабатываются как текстовые файлы и не включают связанные выходные данные при фиксации в удаленном репозитории.
IPYNB (Jupyter)	Файлы IPYNB заканчиваются .ipynb и могут при настройке отправлять выходные данные (например, визуализации) из папки Databricks Git в удаленный репозиторий. Ноутбук IPYNB может содержать код на любом языке, поддерживаемом ноутбуками Databricks (несмотря на часть py в .ipynb).

Databricks работает с двумя типами высокоуровневых форматов записных книжек Databricks: source и IPYNB (Jupyter). Когда пользователь фиксирует записную книжку в формате source, платформа Azure Databricks фиксирует неструктурированный файл с суффиксом языка, например .py, .sql, .scalaили .r. Записная книжка формата source содержит только исходный код и не содержит выходных данных, таких как отображение таблиц и визуализации, которые являются результатами выполнения записной книжки.

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

Записные книжки IPYNB — это формат по умолчанию при создании новой записной книжки в Databricks. Чтобы изменить формат источника Databricks по умолчанию, войдите в рабочую область Azure Databricks, щелкните профиль в правом верхнем углу страницы, а затем щелкните Параметры и перейдите к Developer. Измените формат записной книжки по умолчанию в параметрах редактора под заголовком .

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

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

Примечание.

Что такое "выходные данные"?

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

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

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

1. Перейдите к настройкам администрирования>настройкам рабочей области в консоли администрирования Azure Databricks.

2. В разделе папок Gitвыберите Разрешить папки Git экспортировать выходные данные IPYNB, а затем выберите Разрешить: выходные данные IPYNB можно включить в.

   

Внимание

Если выходные данные включены, конфигурации визуализации и панели мониторинга включаются в создаваемые.ipynb записные книжки.

Управление фиксациями выходных артефактов записной книжки IPYNB

При фиксации файла .ipynb Databricks создает файл конфигурации, который позволяет управлять фиксацией выходных данных: .databricks/commit_outputs.

1. Если у вас есть файл в формате записной книжки .ipynb, но файл конфигурации в удаленном репозитории отсутствует, откройте диалог состояния Git .

2. В диалоговом окне уведомлений выберите Создать commit_outputs файл.

   

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

1. В меню "Файл" выберите "Фиксация записных книжек".

   

2. В диалоговом окне подтвердите возможность фиксации выходных данных записной книжки.

   

Преобразование исходной записной книжки в IPYNB

Вы можете преобразовать существующую исходную записную книжку в папку Git в записную книжку IPYNB с помощью пользовательского интерфейса Azure Databricks.

1. Откройте исходную записную книжку в рабочей области.

2. Выберите "Файл " в меню рабочей области и выберите "Изменить формат записной книжки" [источник]. Если записная книжка уже находится в формате IPYNB, [источник] будет [ipynb] в элементе меню.

   

3. В модальном диалоговом окне выберите "Формат записной книжки Jupyter (IPynb)" и нажмите кнопку "Изменить".

   

Кроме того, вы можете сделать следующее:

• Создание записных .ipynb книжек.
• Просмотр диффов в виде диффов кода (изменения кода в ячейках) или необработанных дифф (изменения кода представлены в формате JSON, который включает выходные данные записной книжки в виде метаданных).

Дополнительные сведения о типах записных книжек, поддерживаемых в Azure Databricks, см. в статье "Экспорт и импорт записных книжек Databricks".

Часто задаваемые вопросы: конфигурация папки 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?

Дополнительные сведения о поддерживаемых типах активов см . в папках 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.

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

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

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

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

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

• 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, созданные с помощью заданий Databricks с исходным кодом в удаленный репозиторий хранятся во временном расположении хранилища. Эти эксперименты сохраняются изначально после выполнения рабочего процесса, но могут быть подвержены риску удаления позже во время запланированного удаления файлов во временном хранилище. Databricks рекомендует использовать эксперименты MLflow рабочей области с заданиями и удаленными источниками Git.

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

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

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

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

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

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

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

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

Ресурсы

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