Gunakan Git dengan Lakeflow Jobs

Tugas pekerjaan dapat memeriksa kode sumber langsung dari repositori Git jarak jauh.

Jenis tugas berikut mendukung repositori Git jarak jauh:

  • Notebooks
  • Skrip Python
  • File SQL
  • proyek dbt (data build tool)

Semua tugas dalam job harus mereferensikan commit yang sama di repositori jarak jauh. Saat eksekusi pekerjaan dimulai, Azure Databricks mengambil cuplikan dari cabang atau commit yang ditentukan, sehingga semua tugas dalam eksekusi tersebut menggunakan versi kode yang sama.

Saat Anda melihat riwayat eksekusi tugas yang menjalankan kode dari repositori Git jarak jauh, panel Detail Eksekusi Tugas mencakup detail Git, termasuk SHA commit yang terkait dengan eksekusi tersebut. Lihat Tampilkan riwayat eksekusi tugas.

Nota

Tugas yang dikonfigurasi untuk menggunakan repositori Git jarak jauh tidak dapat menulis ke file ruang kerja. Tugas-tugas ini harus menulis data sementara ke penyimpanan sementara yang dilampirkan ke simpul driver dan data persisten ke volume atau tabel.

Menggunakan sumber repositori Git vs menggunakan folder Git.

Halaman ini membahas tugas yang dapat menarik kode sumber langsung dari repositori Git jarak jauh. Ruang kerja juga mendukung fitur yang disebut folder Git, di mana folder di ruang kerja Anda disinkronkan dengan repositori Git. Tugas dapat menggunakan folder Git sebagai sumbernya. Namun, Anda harus mengelola sinkronisasi dengan repositori. Menggunakan repositori Git remote seperti yang dijelaskan di sini secara otomatis menarik sumber baru, jika tersedia, saat pekerjaan dijalankan.

Azure Databricks merekomendasikan referensi jalur ruang kerja di folder Git hanya untuk perulangan dan pengujian yang cepat selama pengembangan. Untuk pekerjaan penahapan dan produksi, konfigurasikan tugas untuk mereferensikan repositori Git jarak jauh sebagai gantinya.

Mengonfigurasi penyedia Git untuk pekerjaan

Antarmuka pengguna pekerjaan memiliki dialog untuk mengonfigurasi repositori Git jarak jauh. Dialog ini dapat diakses dari panel Detail pekerjaan di bawah judul Git , atau dalam tugas apa pun yang dikonfigurasi untuk menggunakan penyedia Git. Untuk mengakses dialog, klik Tambahkan pengaturan Git di panel Detail pekerjaan .

Dalam dialog Git (berlabel informasi Git jika diakses selama konfigurasi tugas), masukkan detail berikut:

  • URL repositori Git.
  • Pilih penyedia Git Anda dari daftar drop-down.
  • Pada kolom referensi Git, masukkan pengidentifikasi untuk cabang, tag, atau commit yang sesuai dengan versi kode sumber yang ingin Anda jalankan.
  • Pilih cabang, tag, atau komit dari menu drop-down.

Anda hanya harus menentukan salah satu hal berikut ini:

  • cabang: Nama cabang, misalnya, main.
  • tag: Nama tag, misalnya, release-1.0.0.
  • commit: Hash dari commit tertentu, misalnya, e0056d01.

Nota

Dialog mungkin meminta Anda dengan hal berikut: Kredensial Git untuk akun ini hilang. Tambahkan kredensial. Anda harus mengonfigurasi repositori Git jarak jauh sebelum menggunakannya sebagai referensi. Lihat Mengonfigurasi integrasi Git untuk folder Git.

Saat Anda melihat riwayat jalan tugas yang menjalankan kode yang disimpan di repositori Git jarak jauh, panel Detail jalannya tugas menyertakan detail Git, termasuk SHA commit yang terkait dengan jalannya tugas. Lihat Tampilkan riwayat eksekusi tugas.

Cek keluar jarang untuk repositori besar

Untuk repositori besar, Anda dapat menggunakan fitur "sparse checkout" untuk mengimpor hanya direktori tertentu daripada keseluruhan repositori. Sparse checkout mengurangi waktu checkout dan penggunaan sumber daya setiap kali pekerjaan dijalankan.

Namun, konfigurasi yang tidak tepat dapat menyebabkan fragmentasi cache, yang menurunkan waktu eksekusi di seluruh ruang kerja Anda. Bagian ini menjelaskan kompromi dan masalah yang mungkin muncul saat menggunakan fitur sparse checkout (checkout sebagian) dalam Git.

Bagaimana Azure Databricks mencache keluaran repositori

Azure Databricks menyimpan setiap git checkout berdasarkan empat nilai:

  • Workspace
  • Repositori URL
  • Hash commit yang tepat
  • Sidik jari dari pola cek keluar jarang (kumpulan jalur folder yang tepat)

Setiap eksekusi pekerjaan yang cocok dengan keempat kriteria menggunakan kembali entri cache, yang tetap berlaku hingga satu minggu. Misalnya, jika Anda memiliki 3 pekerjaan berbeda, dan semuanya memiliki kriteria yang sama, mereka menggunakan cache yang sama ke repositori sampai ada komit baru atau setelah 1 minggu.

Setiap pola sparse checkout yang unik membuat sidik jari terpisah, sehingga entri cache terpisah. Jika 20 pengguna masing-masing menambahkan folder kustom ke pola mereka, sistem membuat 20 kunci cache unik dan mengimpor pohon folder bersama sebanyak 20 kali — meningkatkan beban pada ruang kerja Anda. Membuat pola pemeriksaan sparsi yang mencakup semua 20 folder mereka (sebagai contoh, adalah folder induk), memungkinkan satu cache untuk berfungsi lebih sering dan memberikan kinerja yang lebih baik dalam proses Anda. Komprominya adalah lebih banyak file dalam checkout Anda.

Tentukan apakah akan menggunakan sparse checkout

Hanya aktifkan checkout parsial jika kasus penggunaan Anda memenuhi kedua kriteria berikut:

  • Ukuran: Repositori Anda besar (misalnya, melebihi 2.500 file).
  • Penargetan stabil: Cabang target jarang diperbarui (misalnya, sekitar satu komit per jam atau kurang). Hindari cabang yang berubah dengan cepat karena alur kerja CI/CD otomatis.

Jika Anda menggunakan checkout jarang, organisasi Anda juga harus mengadopsi salah satu atau kedua strategi pola berikut:

  • Standardisasi: Gunakan tiga atau lebih sedikit pola pembayaran bersama di seluruh organisasi untuk memaksimalkan temuan cache.
  • Penargetan mikro: Pola struktur sehingga masing-masing menargetkan sejumlah kecil file. Untuk performa terbaik, targetkan kurang dari 200 file.

Ini dapat membantu meminimalkan tarif impor Anda.

Menghitung tarif impor Anda

Sebelum mengaktifkan checkout parsial, perkirakan laju impor File Per Jam yang diproyeksikan. Batasan berlaku di tingkat ruang kerja di semua pekerjaan dan pengguna.

Berkas Per Jam = Pekerjaan Berjalan Per Jam × Tingkat Miss Cache × Berkas Diimpor Per Miss

Faktor Apa yang mendorongnya
Tugas Berjalan Per Jam Frekuensi pemicu aktivitas pada semua pengguna
Tingkat Kesalahan Cache Menerapkan frekuensi pada cabang target dan jumlah pola jarang unik
File yang Diimpor Per Kesalahan Ukuran repositori total atau ukuran subset checkout jarang

Contoh: 180 kali/jam × 10% tingkat kesalahan × 6.000 file/kesalahan = 108.000 file/jam

Bandingkan hasil Anda dengan ambang batas ini:

File yang diimpor per jam Dampak ruang kerja yang diharapkan
Di bawah 150.000 Operasi normal
150,000 – 300,000 Performa terdegradasi. Beberapa pekerjaan mungkin mengalami penundaan atau kegagalan.
Di atas 300.000 Tugas tidak selesai dengan konsisten.

Praktik terbaik

Menstandarkan pola

  • Do: Menerbitkan tiga atau lebih sedikit pola jarang yang disetujui per repositori. Pola bersama mengonsolidasikan beban dan memaksimalkan hit cache.
  • Jangan: Mengizinkan pola kustom per tim. Bahkan satu folder tambahan membuat entri cache baru dan memicu impor ulang penuh.

Mengelola pergantian komit

  • Do: Arahkan pekerjaan di cabang rilis yang stabil. Batch digabungkan ke jendela rilis terjadwal sehingga beberapa kali eksekusi berbagi commit cache yang sama.
  • Jangan gunakan checkout jarang dengan cabang yang sering diperbarui seperti atau master. Karena cache didasarkan pada hash penerapan yang tepat, setiap penerapan baru membatalkan cache dan menyebabkan impor ulang penuh untuk setiap pekerjaan yang dijalankan.

Mengelola beban

  • Lakukan: Hapus biner besar, artefak yang dihasilkan, dan file data dari kontrol sumber untuk mengurangi ukuran repositori tanpa syarat.
  • Jangan: Biarkan tugas yang tidak perlu berjalan pada frekuensi tinggi. Kurangi frekuensi pemicu untuk pekerjaan yang tidak memerlukan eksekusi berkelanjutan, jadwalkan secara bergantian, atau konsolidasi pekerjaan yang berbagi checkout yang sama.

Mengelola perubahan komit menggunakan cabang rilis

Ketika pekerjaan menargetkan cabang yang bergerak cepat seperti master atau main, hash commit sering berubah, menyebabkan terjadi cache miss pada hampir setiap eksekusi. Menggunakan cabang rilis khusus yang diperbarui menurut jadwal tetap dapat meningkatkan tingkat keberhasilan pemanggilan cache.

Dengan mengarahkan semua tugas ke cabang rilis per jam, semua pemrosesan dalam jam tersebut mengacu pada hash commit yang sama dan berbagi entri cache yang sama.

Untuk mengonfigurasi cabang rilis:

  1. Buat cabang berumur panjang (misalnya, release-candidate) di repositori Git Anda.
  2. Mengotomatiskan pembaruan cabang ini agar sesuai dengan master pada jadwal tetap, seperti setiap awal jam.
  3. Konfigurasikan pekerjaan yang didukung Git Anda untuk menggunakan release-candidate sebagai referensi Git target.

Tinjau pertimbangan ini sebelum menerapkan:

Pertimbangan Deskripsi
Lag penerapan Pekerjaan diproses menggunakan kode hingga satu jam sebelum master. Dapat diterima untuk sebagian besar beban kerja batch, tetapi mungkin tidak sesuai dengan pekerjaan yang memerlukan commit terbaru.
Jendela kegagalan Jika pekerjaan pemotongan rilis gagal, cabang tidak diperbarui untuk jam tersebut dan pekerjaan terus berjalan terhadap penerapan sebelumnya. Databricks merekomendasikan pemberitahuan tentang pekerjaan pemotongan.

Contoh: mengotomatiskan dengan GitHub Actions

Alur kerja GitHub Actions berikut mengotomatiskan pemotongan cabang rilis per jam.

Langkah 1: Terapkan .github/workflows/cut-release-branch.yml file ke repositori Anda:

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

Step 2: Jalankan GitHub Action secara manual untuk memverifikasi bahwa release-candidate cabang telah dibuat.

Langkah 3: Perbarui pekerjaan yang ada untuk digunakan release-candidate sebagai referensi Git target.

Mengaktifkan checkout parsial menggunakan Jobs API

Untuk mengaktifkan sparse checkout, sertakan sparse_checkout blok di dalam git_source saat membuat atau memperbarui job:

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

Setiap string di patterns adalah jalur direktori yang relatif terhadap akar repositori. Semua file dalam setiap direktori yang ditentukan disertakan dalam checkout.

  • Last updated on