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

Aşağıdaki bölümlerde Databricks Git klasörleri ve Git tümleştirmesi için sınırlar belirtilir. Genel bilgi için bkz . Kaynak sınırları.

Şuna atla:

• Dosya ve depo sınırları
• Configuration

Git klasörlerinde desteklenen Databricks varlık türleri hakkında bilgi edinmek için bkz. Git klasörleri hangi varlık türleri tarafından desteklenir?

Dosya ve depo sınırları

Azure Databricks, depo boyutu için bir sınır zorlamaz. Ancak:

• Ç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.
• Tek tek çalışma alanı dosyalarının boyut sınırları ayrıdır. Bkz. Sınırlamalar.
• 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.

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

Her Git işlemi 2 GB bellek ve 4 GB disk yazma işlemiyle sınırlıdır. İşlem başına sınırlar uygulandığından, 5 GB'lık depo kopyalama işlemi 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'te geçici dosyaları nereye yazmalıyım?.

Silinen dosyaları kurtarma

Dosya kurtarılabilirliği eyleme göre değişir. Bazı eylemler Çöp Sepeti klasörü üzerinden kurtarma işlemine izin verirken, diğerleri bunu gerçekleştirmez. Daha önce işlenen ve uzak dala gönderilen dosyalar, uzak deponun Git işleme geçmişi kullanılarak geri yüklenebilir:

Eylem	Dosya kurtarılabilir mi?
Çalışma alanı tarayıcısıyla dosya silme	Evet, Çöp Sepeti klasöründen
Yeni bir dosyayı Git klasörü iletişim kutusunu kullanarak sil	Evet, Çöp Sepeti klasöründen
Git klasörü iletişim kutusuyla değiştirilmiş bir dosyayı atma	Hayır, dosya yok.
reset (sabit) kaydedilmemiş dosya değişiklikleri için	Hayır, dosya değişiklikleri yok
reset (sabit) kaydedilmemiş, yeni oluşturulan dosyalar için	Hayır, dosya değişiklikleri yok
Git klasörünün iletişim kutusunu kullanarak dalları değiştirin	Evet, uzak Git deposundan
Git klasörü iletişim kutusundan işleme veya gönderme gibi diğer Git işlemleri	Evet, uzak Git deposundan
PATCH Repos API'den /repos/id güncelleyen işlemler	Evet, uzak Git deposundan

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.

Yapılandırma

Bu bölüm Git klasör depolama, sunucu desteği ve genel kurulum sorularını kapsar.

Depo içeriği depolama

Azure Databricks, depo içeriğini geçici olarak denetim 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, sunucu internet erişimine açıksa GitHub Enterprise, Bitbucket Server, Azure DevOps Server ve GitLab Kendi Kendine yönetilen klasörleri destekler. Şirket içi tümleştirme için bkz. Git klasörleri için Git Proxy Sunucusu .

Bitbucket Server, GitHub Enterprise Server veya GitLab tarafından yönetilen ve İnternet'e erişilmeyen bir örnekle tümleştirmek için Azure Databricks hesap ekibinize başvurun.

Desteklenen varlık türleri

Desteklenen yapıt türleri hakkında ayrıntılı bilgi için bkz . Git klasörleri hangi varlık türleri tarafından desteklenir?.

Git klasörleri .gitignore dosyalarını destekler mi?

Evet. 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 zaten izlenen bir dosya eklemek .gitignore Git'in dosyayı izlemesini engellemez.

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 (ADF) Git klasörlerini destekliyor mu?

Evet.

Kaynak yönetimi

Bu bölüm dallanma, birleştirme ve Git klasörlerinin not defterlerini ve bağımlılıkları nasıl işlediğini kapsar.

Notebook dashboardları ve dallanma 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.

Git klasörleri dal birleştirmeyi destekliyor mu?

Evet. 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

Bu bölüm, Git sağlayıcılarıyla ilgili şifreleme, belirteç depolama ve kimlik doğrulama sorunlarını 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ı ile Azure DevOps kullanır.
• Azure DevOps'ta bir koşullu erişim ilkesini ve bir Microsoft Entra Id koşullu erişim ilkesini etkinleştirdiniz.

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

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

Microsoft Entra ID belirteçleriyle izin listesi oluşturma

Azure DevOps ile kimlik doğrulaması için Microsoft Entra Id kullanıyorsanı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 . İzin listeleri uzaktan depo kullanımını kısıtlar.

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 belirteci 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.

Git klasörleri işlemelerin GPG imzasını destekliyor mu?

Hayır

Git klasörleri SSH'yi destekliyor mu?

Hayır Git klasörleri yalnızca HTTPS'leri destekler.

Azure DevOps kiracılar arası hataları

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

CI/CD ve MLOps

Bu bölümde Git işlemlerinin not defteri durumunu, MLflow denemelerini ve iş yürütmeyi nasıl etkilediği anlatılır.

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 not defteri kaynak kodunu değiştirebilir, bu da Databricks Git klasörlerinin mevcut not defterinin üzerine yazılmasını gerektirir. , 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 daha düşük sürümlerle 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 dala 30 gün içinde erişmezseniz bu kayıp kalıcı olur.

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 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 görevleri ç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. Git'i işlerle kullanma bölümüne bakın.

Kaynaklar

Databricks çalışma alanı dosyalarıyla ilgili ayrıntılar için bkz . Çalışma alanı dosyaları nedir?.