Azure Databricks Git klasör sınırları ve referansı

Bu sayfada Databricks Git klasörleri için boyut sınırları, desteklenen özellikler, güvenlik konuları ve CI/CD davranışı ele alınıyor. Genel Databricks kaynak sınırları için bkz. Kaynak sınırları. Git klasörlerindeki desteklenen varlık türleri hakkında bilgi edinmek için bkz. Git klasörlerinde desteklenen varlık türleri.

Dosya ve depo sınırları

Azure Databricks, depo boyutu için bir sınır zorlamaz. Ancak aşağıdaki sınırlar geçerlidir:

  • Çalışma dalları 1 GB ile sınırlıdır.
  • Azure Databricks kullanıcı arabiriminde 10 MB'tan büyük dosyaları görüntüleyemezsiniz.
  • Her Git işlemi en fazla 2 GB bellek ve 4 GB disk yazma işlemini destekler.
  • Tek tek çalışma alanı dosyalarının boyut sınırları ayrıdır. Bkz. Sınırlamalar.

Databricks, toplam çalışma alanı varlığı ve dosya sayısının 20.000'in altında tutulmasını önerir.

İşlem başına sınırlar uygulandığından, 5 GB'lık bir deponun kopyalanması başarısız olur, ancak 3 GB'lık bir depo kopyalanır ve daha sonra 2 GB eklenir. Deponuz bu sınırları aşarsa kopyalama sırasında bir hata veya zaman aşımı alabilirsiniz ancak işlem arka planda tamamlanabilir.

Daha büyük depolarla çalışmak için sparse checkout veya Git CLI komutlarını deneyin. Küme kapatıldıktan sonra kalıcı olmayan geçici dosyalar yazmak için kullanın $TEMPDIR. Bu, dal boyutu sınırlarının aşılmasını önler ve çalışma alanı dosya sistemindeki bir çalışma dizinine (CWD) yazmaktan daha iyi performans sunar. bkz. Azure Databricks? üzerinde nerede geçici dosyalar yazmam gerekir?

Yerel dallar, uzak dal silindikten sonra 30 güne kadar ilişkili Git klasöründe kalabilir. Yerel bir dalı tamamen kaldırmak için depolama alanını silin.

Depo boyutunu küçültme

Deponuz büyük dosyalar nedeniyle boyut sınırlarını aşarsa, dosyaları .gitignore'e eklemek depo boyutunu azaltmaz. Git'e önceden kaydedilmiş dosyalar, .gitignore öğesine eklendiğinde bile depo geçmişinde kalır.

Depo boyutunu küçültmek için:

  • İşleme geçmişinden büyük dosyaları kaldırmak için veya BFG Repo-Cleaner gibi git filter-repo Git araçlarını kullanın. Bu, geçmişi yeniden yazar ve uzak deponuza zorla göndermeyi gerektirir.
  • Yalnızca belirli dizinleri kopyalama. Bkz Seyrek kullanıma alma modunu yapılandırma.
  • İlişkisiz kodu ayrı depolara taşıyın.

Daha fazla bilgi için GitHub belgelerindeki depodan hassas verileri taşıma bölümüne bakın.

Monorepo desteği

Databricks, birçok projede binlerce dosya içeren büyük, tek kuruluşlu Git depoları olan monorepos tarafından desteklenen Git klasörleri oluşturulmasını önermemektedir. Monorepo kopyalama işlemi Git klasör belleği ve disk sınırlarını aşabilir ve Git işlemlerini yavaşlatabilir. Deponuz birden çok proje içeriyorsa, hangi dizinlerin kopyalanacağını sınırlamak için deponuzu bölmeyi veya seyrek denetim kullanmayı göz önünde bulundurun. Bkz Seyrek kullanıma alma modunu yapılandırma.

Yapılandırma

Tüm standart Git özellikleri Git klasörlerinde çalışmaz ve içerik yerel kopyadan farklı şekilde depolanır. Aşağıdaki konular depolamanın nasıl çalıştığını, hangi sunucuların desteklendiği ve ve alt modüller gibi .gitignore özelliklerin nasıl davrandığını açıklar.

Depo içeriği depolama

Azure Databricks, depo içeriğini geçici olarak kontrol düzlemindeki diske klonlar. Denetim düzlemi veritabanı, ana çalışma alanında olanlar gibi not defteri dosyalarını depolar. Not defteri olmayan dosyalar 30 güne kadar diskte depolanır.

Şirket içi ve şirket içinde barındırılan Git sunucuları

Databricks Git klasörleri, GitHub Enterprise, Bitbucket Server, Azure DevOps Server ve GitLab Kendi Kendine Yönetilen'in internet erişimi varsa destekler. Şirket içi tümleştirme için bkz. Git klasörleri için Git Proxy Sunucusu .

Bir Bitbucket Server, GitHub Enterprise Server veya İnternet'e erişilemeyen kendi kendine yönetilen bir GitLab örneği ile tümleştirmek için Azure Databricks hesap ekibinize başvurun.

Desteklenen varlık türleri

Desteklenen varlık türleri hakkında ayrıntılı bilgi için bkz. Git klasörlerinde desteklenen varlık türleri.

.gitignore dosyası desteği

Git klasörleri .gitignore dosyalarını destekler. Git'in bir dosyayı izlemesini önlemek için dosya adını (uzantı dahil) bir .gitignore dosyaya ekleyin. Bir dosya oluşturun veya uzak deponuzdan kopyalanmış mevcut bir dosyayı kullanın.

.gitignore yalnızca izlenmeyen dosyalar için çalışır. 'a .gitignore zaten kaydedilmiş bir dosya eklemek, dosyayı Git geçmişinden kaldırmaz veya depo boyutunu küçültmez. Kaydedilmiş dosyaları kaldırmak için bkz. Depo boyutunu küçültme.

Git alt modülü desteği

Standart Git klasörleri Git alt modüllerini desteklemez, ancak Git CLI erişimi olan Git klasörleri bunları kullanabilir. Bkz . Git CLI komutlarını kullanma (Beta).

Azure Data Factory desteği

Azure Data Factory (ADF) Git klasörlerini destekler.

Kaynak yönetimi

Git klasörlerindeki birkaç işlem, özellikle not defterleri ve dal silme işlemleri için standart Git iş akışına göre farklı çalışır.

Notebook gösterge tabloları ve dal değişiklikleri

Azure Databricks kaynak biçimi not defterleri pano bilgilerini depolamaz.

Panoları korumak için not defteri biçimini .ipynb (Jupyter biçimi) olarak değiştirin; bu biçim varsayılan olarak pano ve görselleştirme tanımlarını destekler. Görselleştirme verilerini korumak için çıktılarla birlikte not defterini kaydedin.

Bkz. IPYNB not defteri çıkış işlemelerini yönetme.

Dal birleştirme desteği

Git klasörleri dal birleştirmeyi destekler. Ayrıca bir pull request oluşturabilir ve Git sağlayıcınız üzerinden birleştirme yapabilirsiniz.

Dalları silme

Bir dalı silmek için Git sağlayıcınızda çalışmanız gerekir.

Python bağımlılık önceliği

Git klasöründeki Python kitaplıkları, başka bir yerde depolanan kitaplıklara göre önceliklidir. Örneğin, Databricks işleminizde bir kitaplık yüklüyse ve git klasöründe aynı ada sahip bir kitaplık varsa Git klasör kitaplığı içeri aktarılır. Bkz. Python kitaplığı önceliği.

Güvenlik, kimlik doğrulaması ve belirteçler

Azure Databricks Git kimlik bilgilerini yerel ortamınızda değil denetim düzleminde depolar. Aşağıdaki konular Git klasör içeriğinin nasıl şifrelendiğini, belirteçlerin nasıl depolandığını ve denetlendiğini ve kimlik doğrulaması sorunlarıyla karşılaşırsanız ne yapmanız gerektirdiğini kapsar.

Microsoft Entra ID için koşullu erişim ilkesi (CAP) ile ilgili sorun

Aşağıdaki durumlarda bir depo kopyalanırken "erişim reddedildi" hatası alabilirsiniz:

  • Azure Databricks çalışma alanınız Microsoft Entra ID kimlik doğrulamasıyla Azure DevOps kullanır.
  • Azure DevOps bir koşullu erişim ilkesini ve Microsoft Entra ID koşullu erişim ilkesini etkinleştirdiniz.

Bu sorunu çözmek için, Azure Databricks IP adresleri veya kullanıcıları için koşullu erişim ilkesine (CAP) bir dışlama ekleyin.

Daha fazla bilgi için bkz . Koşullu erişim ilkeleri.

Microsoft Entra Kimlik belirteçleriyle izin listesi

Azure DevOps kimlik doğrulaması için Microsoft Entra ID kullanırsanız, varsayılan izin verilenler listesi Git URL'lerini şu şekilde kısıtlar:

  • dev.azure.com
  • visualstudio.com

Daha fazla bilgi için bkz. Git URL izin verilenler listeleri.

Git klasörü şifrelemesi

Azure Databricks Git klasör içeriğini varsayılan bir anahtar kullanarak şifreler. Müşteri tarafından yönetilen anahtarlar yalnızca Git kimlik bilgilerini şifrelemek için desteklenir.

GitHub belirteç depolama ve erişimi

  • Azure Databricks denetim düzlemi kimlik doğrulama belirteçlerini depolar. Çalışanlar bunlara yalnızca denetlenen geçici kimlik bilgileri aracılığıyla erişebilir.
  • Azure Databricks belirteç oluşturma ve silme işlemini günlüğe kaydeder ancak kullanımı günlüğe kaydedemez. Git işlem günlüğü, Azure Databricks uygulaması tarafından belirteç kullanımını denetlemenize olanak tanır.
  • GitHub Enterprise, belirteç kullanımını denetler. Diğer Git hizmetleri de sunucu denetimi sunabilir.

GPG taahhüt imzalama

Git klasörleri, işlemelerin GPG imzasını desteklemez.

SSH desteği

Git klasörleri SSH'yi değil yalnızca HTTPS'yi destekler.

Azure DevOps kiracı sınırları aşan hatalar

DevOps'a ayrı bir kiracıyla bağlanırken Unable to parse credentials from Azure Active Directory account görebilirsiniz. Azure DevOps projesi Azure Databricks'ten farklı bir Microsoft Entra ID kiracıdaysa, bir Azure DevOps erişim belirteci kullanın. Bkz. Kişisel erişim belirteci.

CI/CD ve MLOps

Git klasöründeki dosyalara göre işler çalıştırırsanız, Git işlemlerinin not defteri durumunu ve MLflow denemelerini belirgin olmayan şekillerde nasıl etkileyebileceğini unutmayın.

Gelen değişiklikler not defteri durumunu temizler

Not defteri kaynak kodunu değiştiren Git işlemleri hücre çıkışları, açıklamalar, sürüm geçmişi ve pencere öğeleri de dahil olmak üzere not defteri durumunun kaybolmasına neden olur. Örneğin, git pull Git klasörlerinin var olan not defterinin üzerine yazılmasını gerektiren not defteri kaynak kodunu değiştirebilir. , git commitveya yeni dal oluşturma gibi pushişlemler kaynak kodu etkilemez ve not defteri durumunu korumaz.

Önemli

MLflow denemeleri Databricks Runtime 14.x veya önceki sürümleriyle Git klasörlerinde çalışmaz.

Git klasörlerindeki MLflow denemeleri

İki tür MLflow denemesi vardır: çalışma alanı ve not defteri. Bkz. MLflow denemeleriyle eğitim çalıştırmalarını düzenleme.

  • Çalışma alanı denemeleri: Git klasörlerinde çalışma alanı MLflow denemeleri oluşturamazsınız. MLflow çalıştırmalarını, normal bir çalışma alanı klasöründe oluşturulan bir denemeye kaydedin. Çok kullanıcılı işbirliği için paylaşılan çalışma alanı klasörünü kullanın.

  • Not defteri denemeleri: Databricks Git klasöründe not defteri denemeleri oluşturabilirsiniz. Not defterinizi dosya olarak .ipynb kaynak denetimine denetlerseniz, MLflow günlüğü otomatik olarak oluşturulan bir denemede çalıştırır. Kaynak denetimi denemeyi veya çalıştırmalarını denetlemez. Not defteri denemesi oluşturma için bkz.

MLflow denemelerinde veri kaybını önleme

Uzak bir depoda bulunan kaynak kodu ile Lakeflow İşleri kullanılarak oluşturulan defter MLflow denemeleri geçici depoda saklanır. Bu denemeler başlangıçta iş akışı yürütüldükten sonra da devam eder, ancak zamanlanmış temizleme sırasında silinme riski vardır. Databricks, çalışma alanı MLflow deneylerinin Görevler ve uzak Git kaynaklarıyla kullanılmasını önerir.

Uyarı

Not defteri içermeyen bir dala geçiş yapmak, ilişkili MLflow deneme verilerini kaybetme riski taşır. Önceki dalı 30 gün içinde ziyaret etmediğinizde bu kayıp kalıcı hale gelir.

30 günlük süre dolmadan önce eksik deneme verilerini kurtarmak için özgün not defteri adını geri yükleyin, not defterini açın ve sağ bölmedeki Deneme simgesine tıklayın. Bu, deneyi tetikler mlflow.get_experiment_by_name(), performansını geri yükler ve çalıştırır. 30 gün sonra, Azure Databricks GDPR uyumluluğu için yalnız bırakılmış MLflow denemelerini temizler.

Veri kaybını önlemek için depodaki not defterlerini yeniden adlandırmaktan kaçının. Not defterini yeniden adlandırırsanız, sağ bölmedeki deneme simgesine hemen tıklayın.

Git işlemleri sırasında işleri çalıştırma

Git işlemi sırasında bazı not defterleri güncellenirken, diğerleri henüz güncellenmeyebilir ve bu da öngörülemeyen davranışlara neden olabilir.

Örneğin, notebook A tarafından notebook Z kullanılarak çağrıldığında ve bir iş Git işlemi sırasında başlatıldığında, bu iş, en son %run sürümünü daha eski bir notebook A ile çalıştırabilir. İş başarısız olabilir veya farklı commit'lerden not defterlerini çalıştırabilir.

Bunu önlemek için iş görevlerini çalışma alanı yolu yerine Git sağlayıcınızı kaynak olarak kullanacak şekilde yapılandırın. Daha fazla bilgi için Lakeflow İşleri’nde Git Kullanımı.

Sonraki Adımlar

  • Last updated on