Databricks Git klasörleriyle Git tümleştirmesi için sınırlar ve SSS

Databricks Git klasörleri ve Git tümleştirmesinin sınırları aşağıdaki bölümlerde belirtilmiştir. Genel bilgi için bkz . Databricks sınırları.

Dosya ve depo boyutu sınırları

Azure Databricks, bir deponun boyutu üzerinde bir sınır zorlamaz. Ancak:

• Çalışma dalları 200 MB ile sınırlıdır.
• Tek tek çalışma alanı dosyaları ayrı bir boyut sınırına tabidir. Daha fazla ayrıntı için Bkz . Sınırlamalar.
• 10 MB'tan büyük dosyalar Azure Databricks kullanıcı arabiriminde görüntülenemez.

Databricks bunu bir depoda önerir:

• Tüm dosyaların toplam sayısı 10.000'i aşmaz.
• Toplam not defteri sayısı 5.000'i aşmaz.

Tüm Git işlemleri için bellek kullanımı 2 GB, disk yazma işlemleri ise 4 GB ile sınırlıdır. Sınır işlem başına olduğundan, geçerli boyutta 5 GB olan bir Git deposunu kopyalamaya çalışırsanız bir hata alırsınız. Ancak, bir işlemde boyutu 3 GB olan bir Git deposunu kopyalayıp daha sonra 2 GB eklerseniz, sonraki çekme işlemi başarılı olur.

Deponuz bu sınırları aşarsa bir hata iletisi alabilirsiniz. Depoyu kopyaladığınızda da zaman aşımı hatası alabilirsiniz, ancak işlem arka planda tamamlanabilir.

Boyut sınırlarından daha büyük depoyla çalışmak için seyrek kullanıma almayı deneyin.

Küme kapatıldıktan sonra saklamak istemediğiniz geçici dosyalar yazmanız gerekiyorsa, dal boyutu sınırlarını aşmamak için $TEMPDIR geçici dosyaları yazmak ve CWD çalışma alanı dosya sistemindeyse geçerli çalışma dizinine (CWD) yazmaktan daha iyi performans sağlar. Daha fazla bilgi için bkz . Azure Databricks'te geçici dosyaları nereye yazmalıyım?.

Çalışma alanı başına en fazla Git klasörü sayısı

Çalışma alanı başına en fazla 10.000 Git klasörünüz olabilir. Daha fazlasına ihtiyacınız varsa Databricks desteğine başvurun.

Monorepo desteği

Databricks, monorepoların desteklediği Git klasörleri oluşturmamanızı önerir. Burada monorepo , birçok projede binlerce dosya içeren büyük, tek kuruluşlu bir Git deposudur.

Git klasörü yapılandırması

Azure Databricks deposu içeriği nerede depolanır?

Bir deponun içeriği geçici olarak kontrol düzlemindeki diske kopyalanmıştır. Azure Databricks not defteri dosyaları, ana çalışma alanında bulunan not defterleri gibi denetim düzlemi veritabanında depolanır. Not defteri olmayan dosyalar 30 güne kadar diskte depolanır.

Git klasörleri şirket içi veya şirket içinde barındırılan Git sunucularını destekliyor mu?

Databricks Git klasörleri, sunucunun İnternet'e erişilebilir olması durumunda GitHub Enterprise, Bitbucket Server, Azure DevOps Server ve GitLab Kendi kendine yönetilen tümleştirmeyi destekler. Git klasörlerini şirket içi Git sunucusuyla tümleştirme hakkında ayrıntılı bilgi için Git klasörleri için Git Proxy Sunucusu makalesini okuyun.

Bitbucket Server, GitHub Enterprise Server veya İnternet'e erişilmeyen gitLab kendi kendine yönetilen abonelik örneğiyle tümleştirmek için Azure Databricks hesap ekibinizle iletişime geçin.

Hangi Databricks varlık türleri Git klasörleri tarafından desteklenir?

Desteklenen varlık türleri hakkında ayrıntılı bilgi için Bkz . Databricks Git klasörlerinde dosya varlıklarını yönetme.

Git klasörleri dosyaları destekliyor .gitignore mu?

Evet. Deponuza bir dosya eklerseniz ve Bunun Git tarafından izlenmesini istemiyorsanız, bir .gitignore dosya oluşturun veya uzak deponuzdan kopyalanmış bir dosya kullanın ve uzantı da dahil olmak üzere dosya adını ekleyin.

.gitignore yalnızca Git tarafından henüz izlenmemiş dosyalar için çalışır. Zaten Git tarafından izlenen bir dosyayı bir .gitignore dosyaya eklerseniz, dosya git tarafından izlenir.

Kullanıcı klasörü olmayan üst düzey klasörler oluşturabilir miyim?

Evet, yöneticiler en üst düzey klasörleri tek bir derinlikte oluşturabilir. Git klasörleri ek klasör düzeylerini desteklemez.

Git klasörleri Git alt modüllerini destekliyor mu?

Hayır Git alt modülleri içeren bir depoyu kopyalayabilirsiniz, ancak alt modül kopyalanmaz.

Azure Data Factory (ADF) Git klasörlerini destekliyor mu?

Evet.

Kaynak yönetimi

Farklı bir dalı çektiğim veya kullanıma yaptığımda not defteri panoları neden kayboluyor?

Azure Databricks not defteri kaynak dosyaları not defteri panosu bilgilerini depolamadığından bu şu anda bir sınırlamadır.

Git deposundaki panoları korumak istiyorsanız, not defteri biçimini .ipynb (Jupyter not defteri biçimi) olarak değiştirin. Varsayılan olarak pano .ipynb ve görselleştirme tanımlarını destekler. Grafik verilerini (veri noktaları) korumak istiyorsanız, not defterini çıkışlarla işlemeniz gerekir.

Not defteri çıkışlarını işleme .ipynb hakkında bilgi edinmek için bkz. Not defteri çıkışı işlemeye .ipynb izin verme.

Git klasörleri dal birleştirmeyi destekliyor mu?

Evet. Ayrıca bir çekme isteği oluşturabilir ve Git sağlayıcınız aracılığıyla birleştirebilirsiniz.

Azure Databricks deposundan dal silebilir miyim?

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

Bir kitaplık bir kümede yüklüyse ve depo içindeki bir klasöre aynı ada sahip bir kitaplık ekleniyorsa, hangi kitaplık içeri aktarılır?

Depodaki kitaplık içeri aktarılır. Python'da kitaplık önceliği hakkında daha fazla bilgi için bkz . Python kitaplığı önceliği.

Bir dış düzenleme aracına güvenmeden bir işi çalıştırmadan önce Git'ten deponun en son sürümünü çekebilir miyim?

Hayır Genellikle bunu Git sunucusunda ön işleme olarak tümleştirebilirsiniz, böylece bir dala yapılan her gönderim (main/prod) Üretim deposunu güncelleştirir.

Depo dışarı aktarabilir miyim?

Not defterlerini, klasörleri veya depoların tamamını dışarı aktarabilirsiniz. Not defteri olmayan dosyaları dışarı aktaramazsınız. Depoların tamamını dışarı aktarırsanız not defteri olmayan dosyalar dahil değildir. Dışarı aktarmak workspace export için Databricks CLI'daki komutunu veya Çalışma Alanı API'sini kullanın.

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

Microsoft Entra Id (eski adıyla Azure Active Directory) için koşullu erişim ilkesi (CAP) ile ilgili sorun

Bir depoyu kopyalamaya çalıştığınızda, şu durumlarda "erişim reddedildi" hata iletisi alabilirsiniz:

• Azure Databricks, Microsoft Entra Id kimlik doğrulaması ile Azure DevOps kullanacak şekilde yapılandırılmıştı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'in IP adresi 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.

Azure AD belirteçleriyle izin ver listesi

Azure DevOps ile kimlik doğrulaması için Azure Active Directory (AAD) kullanıyorsanız, varsayılan izin verme 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.

Azure Databricks Git klasörlerinin içeriği şifreleniyor mu?

Azure Databricks Git klasörlerinin içeriği Azure Databricks tarafından varsayılan anahtar kullanılarak şifrelenir. Git kimlik bilgilerinizi şifreleme dışında müşteri tarafından yönetilen anahtarlar kullanılarak şifreleme desteklenmez.

GitHub belirteçleri Azure Databricks'te nasıl ve nerede depolanır? Azure Databricks'ten kimler erişebilir?

• Kimlik doğrulama belirteçleri Azure Databricks denetim düzleminde depolanır ve Azure Databricks çalışanı yalnızca denetlenen geçici bir kimlik bilgileri aracılığıyla erişim elde edebilir.
• Azure Databricks, bu belirteçlerin oluşturulmasını ve silinmesini günlüğe kaydeder ancak kullanımlarını günlüğe kaydeder. Azure Databricks'in, Azure Databricks uygulaması tarafından belirteçlerin kullanımını denetlemek için kullanılabilecek Git işlemlerini izleyen günlüğü vardır.
• GitHub kurumsal denetim belirteci kullanımını denetler. Diğer Git hizmetlerinde de Git sunucusu denetimi olabilir.

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

Hayır

Git klasörleri SSH'yi destekliyor mu?

Hayır, yalnızca HTTPS.

Azure Databricks'i farklı bir kiracıdaki bir Azure DevOps deposuna bağlama hatası

DevOps'a ayrı bir kiracıda bağlanmaya çalışırken iletisini Unable to parse credentials from Azure Active Directory accountalabilirsiniz. Azure DevOps projesi Azure Databricks'ten farklı bir Microsoft Entra ID kiracısındaysa Azure DevOps'tan bir erişim belirteci kullanmanız gerekir. Bkz. DevOps belirtecini kullanarak Azure DevOps'a Bağlan.

CI/CD ve MLOps

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 defterinin kaynak kodunu değiştirebilir. Bu durumda Databricks Git klasörleri, değişiklikleri içeri aktarmak için mevcut not defterinin üzerine yazmalıdır. git commit ve push veya yeni dal oluşturmak not defteri kaynak kodunu etkilemez, bu nedenle not defteri durumu bu işlemlerde korunur.

Önemli

MLflow denemeleri DBR 14.x veya daha düşük sürümlere sahip Git klasörlerinde çalışmaz.

Depoda MLflow denemesi oluşturabilir miyim?

İki tür MLflow denemesi vardır: çalışma alanı ve not defteri. İki tür MLflow denemesi hakkında ayrıntılı bilgi için bkz . MLflow denemeleriyle eğitim çalıştırmalarını düzenleme.

Git klasörlerinde, her iki türde bir MLflow denemesi çağırabilir mlflow.set_experiment("/path/to/experiment") ve bu denemede günlük çalıştırmaları yapabilirsiniz, ancak bu deneme ve ilişkili çalıştırmalar kaynak denetiminde denetlenmeyecektir.

Çalışma Alanı MLflow denemeleri

Databricks Git klasöründe (Git klasörü) çalışma alanı MLflow denemeleri oluşturamazsınız. Birden çok kullanıcı aynı ML kodu üzerinde işbirliği yapmak için ayrı Git klasörleri kullanıyorsa, günlük MLflow normal çalışma alanı klasöründe oluşturulan bir MLflow denemesine çalıştırılır.

Not Defteri MLflow denemeleri

Databricks Git klasöründe not defteri denemeleri oluşturabilirsiniz. Not defterinizi kaynak denetimine dosya .ipynb olarak denetlerseniz, MLflow çalıştırmalarını otomatik olarak oluşturulan ve ilişkili bir MLflow denemesine kaydedebilirsiniz. Diğer ayrıntılar için not defteri denemeleri oluşturma makalesini okuyun.

MLflow denemelerinde veri kaybını önleme

Uyarı

Not defterini içermeyen bir dala her geçiş yaptığınızda, ilişkili MLflow deneme verilerini kaybetme riskiyle karşılaşırsınız. Önceki dala 30 gün içinde erişilmemesi durumunda bu kayıp önemli hale gelir.

30 günlük süre dolmadan önce eksik deneme verilerini kurtarmak için, not defterini özgün adıyla yeniden adlandırın, not defterini açın, sağ taraftaki bölmedeki "deneme" simgesine tıklayın (bu işlem API'yi etkili bir şekilde çağırır mlflow.get_experiment_by_name() ) ve kurtarılan denemeyi ve çalıştırmaları görebilirsiniz. 30 gün sonra, gdpr uyumluluk ilkelerini karşılamak için yalnız bırakılmış tüm MLflow denemeleri temizlenir.

Bu durumu önlemek için Databricks, depolardaki not defterlerini yeniden adlandırmaktan kaçınmanızı veya bir not defterini yeniden adlandırdığınızda, not defterini yeniden adlandırdıktan hemen sonra sağ taraftaki bölmedeki "deneme" simgesine tıklamanızı önerir.

Git işlemi devam ederken bir not defteri işi çalışma alanında çalışıyorsa ne olur?

Git işlemi devam ederken herhangi bir noktada, depodaki bazı not defterleri güncelleştirilmiş, diğerleri güncelleştirilmemiş olabilir. Bu durum, öngörülemeyen davranışlara neden olabilir.

Örneğin, komut %run kullanarak çağrılar notebook Z olduğunu varsayalımnotebook A. Git işlemi sırasında çalışan bir iş en son sürümünü notebook Abaşlatır ancak notebook Z henüz güncelleştirilmediyse, %run A not defterindeki komut eski sürümünü notebook Zbaşlatabilir. Git işlemi sırasında not defteri durumları tahmin edilebilir değildir ve iş başarısız olabilir veya farklı işlemelerden çalıştırılabilir notebook Anotebook Z .

Bu durumu önlemek için bunun yerine Git tabanlı işleri (kaynağın çalışma alanı yolu değil Git sağlayıcısı olduğu) kullanın. Daha fazla ayrıntı için Bkz . Azure Databricks işinde sürüm denetimli kaynak kodu kullanma.

Kaynaklar

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