Использование Git с заданиями Lakeflow

Задания могут извлечь исходный код непосредственно из удаленного репозитория Git.

Следующие типы задач поддерживают удаленные репозитории Git:

Ноутбуки
скрипты Python
SQL-файлы
Проекты инструмента построения данных (dbt)

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

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

Замечание

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

Источник репозитория Git и папки Git

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

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

Настройка поставщика Git для задания

Пользовательский интерфейс заданий содержит диалоговое окно для настройки удаленного репозитория Git. Это диалоговое окно доступно в области сведений о задании под заголовком Git или в любой задаче, настроенной для использования поставщика Git. Чтобы открыть диалоговое окно, нажмите кнопку "Добавить параметры Git " в области сведений о задании .

В диалоговом окне Git (помеченное как информация о Git, если доступ осуществляется во время конфигурации задачи) введите следующие сведения:

URL-адрес репозитория Git.
Выберите поставщика Git в раскрывающемся списке.
В поле Git reference введите идентификатор ветки, тега или коммита, соответствующий версии исходного кода, которую требуется запустить.
Выберите ветвь, тег или коммит из выпадающего списка.

Необходимо указать только одно из следующих элементов:

ветвь: имя ветви, например main.
tag: имя тега, например release-1.0.0.
commit: хэш конкретного коммита, например e0056d01.

Замечание

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

Запустить задание Git с ролью

Important

Для выполнения задания в качестве роли требуется управление доступом на основе ролей (RBAC), которое находится в общедоступной предварительной версии.

Если в рабочей области используется RBAC, можно задать для задачи идентификатор Run as как группу (роль). Затем задание клонирует свой репозиторий Git с помощью учетных данных Git для роли, поэтому администратор должен сначала настроить эти учетные данные, иначе заданию не удастся клонировать репозиторий. Чтобы задать для задания параметр Run as как группу, см. раздел Настройка параметра Run as как группы.

Чтобы исправить задачу, которая завершается сбоем из-за проблемы в коде, используйте один из способов внесения изменений в репозитории и ветке этой задачи. Примите на себя эту роль, чтобы воспроизвести и исправить проблему на данных роли, закоммитьте исправление, а затем повторно запустите задачу.

Разреженная выгрузка для больших репозиториев

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

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

Как Azure Databricks кэширует выгрузку репозитория

Azure Databricks кэширует каждую проверку Git на основе четырех значений:

Workspace
URL-адрес репозитория
Точный хэш фиксации
Отпечаток разреженного шаблона извлечения (точный набор путей к папке)

Любое выполнение задания, соответствующее всем четырём критериям, повторно использует запись кэша, которая остаётся действительной в течение недели. Например, если у вас есть 3 разных задания и все они используют одинаковые критерии, то они используют один и тот же кэш для репозитория, пока не появится новый коммит (или через 1 неделю).

Каждый уникальный способ разреженной выгрузки создаёт отдельный отпечаток и, следовательно, отдельную запись в кэше. Если 20 пользователей каждый добавляет пользовательскую папку в шаблон, система создает 20 отдельных ключей кэша и импортирует дерево общей папки 20 раз, умножая нагрузку на рабочую область. Создание единого разреженного шаблона извлечения, включающего все 20 своих папок (например, родительскую папку), позволяет одному кэшу работать чаще и повысить производительность заданий. Компромисс заключается в том, что в вашем выкачивании будет большее количество файлов.

Решите, следует ли использовать разреженный выход

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

Размер: репозиторий большой (например, он превышает 2500 файлов).
Стабильное целевое таргетирование: целевая ветвь обновляется редко (например, около одного коммита в час или меньше). Избегайте веток, которые быстро изменяются из-за использования автоматизированных рабочих процессов CI/CD.

Если вы используете разреженную выборку, ваша организация также должна принять одну или обе из следующих стратегий шаблонов:

Стандартизация: используйте три или меньше общих шаблонов оформления заказа по всей организации, чтобы максимизировать количество попаданий кэша.
Микронацеливание: структурируйте шаблоны так, чтобы каждый нацеливался на небольшое количество файлов. Чтобы обеспечить оптимальную производительность, ставьте цель — менее 200 файлов.

Это может помочь свести к минимуму скорость импорта.

Вычисление скорости импорта

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

Файлы в час = выполнения заданий в час × коэффициент промахов кэша × файлов, импортированных на промах

Фактор	Что движет этим
Выполнение задания в час	Частота триггера для всех пользователей
Частота пропуска кэша	Частота коммитов на целевой ветке и количество уникальных разреженных шаблонов
Импортированные файлы на мисс	Общий размер репозитория или размер разреженной выборки подмножества

Пример: 180 запусков/час × 10% доля промахов × 6 000 файлов/промах = 108 000 файлов/час

Сравните результат с этими порогами:

Импортированные файлы в час	Ожидаемое влияние рабочей области
Ниже 150 000	Обычная операция
150,000 – 300,000	Снижение производительности. Некоторые задания могут испытывать задержки или сбои.
Выше 300 000	Задания не выполняются надежно.

Управление частотой изменений коммитов с использованием выпускной ветви

Когда задания нацелены на быстро развивающуюся ветвь, такую как master или main, хэш фиксации часто изменяется, что приводит к промахам кэша практически во всех запусках. Использование выделенной ветки релиза, которая обновляется по фиксированному расписанию, повышает частоту попаданий в кэш.

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

Чтобы настроить ветвь выпуска, выполните приведенные выше действия.

Создайте долгоживущую ветку (например, release-candidate) в репозитории Git.
Автоматизируйте обновление этой ветви, чтобы она соответствовала master в фиксированные промежутки времени, например в начале каждого часа.
Настройте задания, поддерживаемые Git, для использования release-candidate в качестве целевой ссылки на Git.

Ознакомьтесь с этими компромиссами перед реализацией:

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

Пример: автоматизация с помощью GitHub Actions

Следующий GitHub Actions рабочий процесс автоматизирует почасовую ветвь выпуска.

Шаг 1. Фиксация .github/workflows/cut-release-branch.yml файла в репозитории:

name: Cut Hourly Release Candidate

on:
  schedule:
    - cron: '0 * * * *'
  workflow_dispatch:

jobs:
  update-branch:
    runs-on: ubuntu-latest
    permissions:
      contents: write

    steps:
      - name: Checkout main branch
        uses: actions/checkout@v4
        with:
          ref: main
          fetch-depth: 0

      - name: Update release-candidate branch
        run: |
          git push origin HEAD:release-candidate --force

Шаг 2: вручную запустите действие GitHub, чтобы убедиться, что ветвь release-candidate создана.

Шаг 3. Обновите существующие задания для использования release-candidate в качестве целевой ссылки на Git.

Активировать разреженную проверку с помощью Jobs API

Чтобы включить разреженную проверку, вставьте блок в sparse_checkout внутри git_source при создании или обновлении задачи.

{
  "git_source": {
    "git_url": "https://github.com/example/my-repo",
    "git_provider": "gitHub",
    "git_branch": "release-candidate",
    "sparse_checkout": {
      "patterns": ["src/models", "src/utils"]
    }
  }
}

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

Обратная связь

Были ли сведения на этой странице полезными?

Last updated on 2026-07-22