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

Şuraya gidin:

• Dosya ve depo sınırları
• Git klasörlerinde desteklenen varlık türleri
• SSS: Git klasör yapılandırması

Dosya ve depo sınırları

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

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

Databricks bunu bir depoda önerir:

• Tüm çalışma alanı varlıklarının ve dosyalarının toplam sayısı 20.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 2.000 Git klasörünüz olabilir. Daha fazlasına ihtiyacınız varsa Databricks desteğine başvurun.

Çalışma alanınızdaki Git klasörlerinden silinen dosyaları kurtarma

Git klasörlerindeki çalışma alanı eylemleri, dosya kurtarılabilirliği açısından farklılık gösterir. Bazı eylemler Çöp Kutusu klasörü üzerinden kurtarma işlemine izin verirken, diğerleri bunu yapmaz. Daha önce işlenen ve uzak bir dala gönderilen dosyalar, uzak Git deposu için Git işleme geçmişi kullanılarak geri yüklenebilir. Bu tabloda her eylemin davranışı ve kurtarılabilirliği özetlenmiştir:

Eylem	Dosya kurtarılabilir mi?
Çalışma alanı tarayıcısıyla dosya silme	Evet, Çöp Sepeti klasöründen
Git klasörü iletişim kutusuyla yeni bir dosya at	Evet, Çöp Sepeti klasöründen
Git klasörü iletişim kutusuyla değiştirilmiş bir dosyayı atma	Hayır, dosya gitti
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ü iletişim kutusuyla dalları değiştirme	Evet, uzak Git deposundan
Git klasörü iletişim kutusundan diğer Git işlemleri (İşleme ve Gönderme vb.)	Evet, uzak Git deposundan
PATCH Repos API'sinden güncelleştirilen /repos/id işlemler	Evet, uzak Git deposundan

Çalışma alanı kullanıcı arabiriminden Git işlemleri aracılığıyla git klasöründen silinen dosyalar, daha önce işlenip uzak depoya gönderildiyse Git komut satırı (veya diğer Git araçları) kullanılarak uzak dal geçmişinden kurtarılabilir. Çalışma alanı eylemleri, dosya kurtarılabilirliği açısından farklılık gösterir. Bazı eylemler çöp kutusu aracılığıyla kurtarma sağlarken, diğerleri bunu yapmaz. Daha önce kaydedilmiş ve uzak bir dala gönderilen dosyalar Git işleme geçmişi aracılığıyla geri yüklenebilir. Aşağıdaki tabloda her eylemin davranışı ve kurtarılabilirliği özetlenmiştir:

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örlerinde desteklenen varlık türleri

Git klasörleri tarafından yalnızca belirli Azure Databricks varlık türleri desteklenir. Desteklenen varlık türü seri hale getirilebilir, sürüm denetimi yapılabilir ve destek Git deposuna gönderilebilir.

Şu anda desteklenen varlık türleri şunlardır:

Varlık Türü	Ayrıntılar
Dosya	Dosyalar serileştirilmiş verilerdir ve kitaplıklardan ikili dosyalara, koddan görüntülere kadar her şeyi içerebilir. Daha fazla bilgi için çalışma alanı dosyaları nedir?
Not defteri	Not defterleri özellikle Databricks tarafından desteklenen not defteri dosya biçimleridir. Not defterleri, serileştirilmedikleri için dosyalardan ayrı bir Azure Databricks varlık türü olarak kabul edilir. Git klasörleri, bir not defterini dosya uzantısına (örneğin .ipynb) veya dosya içeriğindeki özel bir işaretçiyle (örneğin, kaynak dosyaların başındaki bir # Databricks notebook source açıklama) birleştirilmiş dosya uzantılarına .py göre belirler.
Klasör	Klasör, Git'teki dosyaların mantıksal gruplandırması hakkında serileştirilmiş bilgileri temsil eden Azure Databricks'e özgü bir yapıdır. Beklendiği gibi, kullanıcı bir Azure Databricks Git klasörünü görüntülerken veya Azure Databricks CLI ile erişirken bunu "klasör" olarak deneyimler.

Şu anda Git klasörlerinde desteklenmeyen Azure Databricks varlık türleri şunlardır:

• DBSQL sorguları
• Uyarılar
• Panolar (eski panolar dahil)
• Denemeler
• Genie alanları

Git'teki varlıklarınızla çalışırken dosya adlandırmada aşağıdaki sınırlamalara dikkat edin:

• Bir klasör, dosya uzantısı farklı olsa bile aynı Git deposundaki başka bir not defteri, dosya veya klasörle aynı ada sahip bir not defteri içeremez. (Kaynak biçimindeki not defterleri için uzantı .py python, Scala, .scala .sql SQL ve .r R içindir. IPYNB biçimindeki not defterleri için uzantı :.ipynb) Örneğin, kaynak biçimli Python not defteri test1.py dosyası (test1.py) olarak test1 serileştirileceği ve çakışma oluşacağı için aynı Git klasöründe adlı kaynak biçimli bir not defteri ve aynı Git klasöründe adlı test1 bir IPYNB not defteri kullanamazsınız.
• Karakter / dosya adlarında desteklenmez. Örneğin, Git klasörünüzde adlı i/o.py bir dosyaya sahip olamazsınız.

Bu desenlere sahip adlara sahip dosyalarda Git işlemleri gerçekleştirmeye çalışırsanız, "Git durumu getirilirken hata oluştu" iletisi alırsınız. Bu hatayı beklenmedik bir şekilde alırsanız Git deponuzdaki varlıkların dosya adlarını gözden geçirin. Bu çakışan desenlere sahip adlara sahip dosyalar bulursanız, bunları yeniden adlandırın ve işlemi yeniden deneyin.

Not

Desteklenmeyen mevcut varlıkları bir Git klasörüne taşıyabilirsiniz, ancak bu varlıklardaki değişiklikleri depoya geri işleyemezsiniz. Git klasöründe desteklenmeyen yeni varlıklar oluşturamazsınız.

Not defteri biçimleri

Databricks iki tür üst düzey, Databricks'e özgü not defteri biçimi dikkate alır: "source" ve "ipynb". Kullanıcı "kaynak" biçiminde bir not defteri işlediğinde, Azure Databricks platformu , .sql, .scalaveya .rgibi .pybir dil soneki içeren düz bir dosya işler. "Kaynak" biçimli not defteri yalnızca kaynak kodu içerir ve tablo görüntülemeleri ve not defterini çalıştırmanın sonuçları olan görselleştirmeler gibi çıkışlar içermez.

Ancak "ipynb" biçimiyle ilişkilendirilmiş çıkışlar vardır ve bu yapıtlar, bunları oluşturan not defteri gönderilirken Git klasörünü destekleyen Git deposuna .ipynb otomatik olarak gönderilir. Çıkışları kodla birlikte işlemek istiyorsanız, "ipynb" not defteri biçimini kullanın ve kullanıcının oluşturulan çıkışları işlemesine izin vermek için yapılandırmayı ayarlayın. Sonuç olarak, "ipynb", Git klasörleri aracılığıyla uzak Git depolarına gönderilen not defterleri için Databricks'te daha iyi bir görüntüleme deneyimini de destekler.

Not defteri kaynak biçimi	Ayrıntılar
kaynak	, ve .sqlgibi .py.scala.r kod diline işaret eden standart bir dosya soneki içeren herhangi bir kod dosyası olabilir. "source" not defterleri metin dosyaları olarak kabul edilir ve Git deposuna geri işlendiğinde ilişkili çıkışlar içermez.
ipynb	"ipynb" dosyaları ile .ipynb biter ve yapılandırılırsa Databricks Git klasöründen çıkışları (görselleştirmeler gibi) yedekleme Git deposuna gönderebilir. Not .ipnynb defteri, Databricks not defterleri tarafından desteklenen herhangi bir dilde kod içerebilir (bölümüne .ipynbrağmenpy).

Bir not defteri çalıştırdıktan sonra çıkışların deponuza geri gönderilmesini istiyorsanız bir (Jupyter) not defteri kullanın .ipynb . Yalnızca not defterini çalıştırmak ve Git'te yönetmek istiyorsanız, gibi .pybir "kaynak" biçimi kullanın.

Desteklenen not defteri biçimleri hakkında daha fazla bilgi için Databricks not defterlerini dışarı ve içeri aktarma makalesini okuyun.

Not

"Çıkışlar" nedir?

Çıktılar, tablo görüntülemeleri ve görselleştirmeler de dahil olmak üzere Databricks platformunda bir not defteri çalıştırmanın sonuçlarıdır.

Bir not defterinin dosya uzantısı dışında hangi biçimi kullandığını Nasıl yaparım??

Databricks tarafından yönetilen bir not defterinin üst kısmında genellikle biçimi gösteren tek satırlı bir açıklama bulunur. Örneğin, bir .py "kaynak" not defteri için şuna benzer bir satır görürsünüz:

# Databricks notebook source

Dosyalar için .ipynb , dosya soneki bunun "ipynb" not defteri biçimi olduğunu belirtmek için kullanılır.

Databricks Git klasörlerindeki IPYNB not defterleri

Jupyter not defterleri (.ipynb dosyalar) desteği Git klasörlerinde sağlanır. Depoları not defterleriyle .ipynb kopyalayabilir, Azure Databricks'te bunlarla çalışabilir ve sonra bunları not defteri olarak .ipynb işleyip gönderebilirsiniz. Not defteri panosu gibi meta veriler korunur. Yöneticiler çıkışların işlenip işlenemeyeceğini denetleyebiliyor.

Not defteri çıkışı işlemeye .ipynb izin ver

Varsayılan olarak, Git klasörlerinin yönetici ayarı not defteri çıkışının işlenmesine izin .ipynb vermez. Çalışma alanı yöneticileri bu ayarı değiştirebilir:

1. Yönetici ayarları Çalışma alanı ayarları'na >gidin.

2. Git klasörleri Git klasörlerinin IPYNB çıkışlarını dışarı aktarmasına izin ver altında İzin Ver: IPYNB çıkışları açılabilir'i seçin.>

   

Önemli

Çıkışlar dahil edildiğinde görselleştirme ve pano yapılandırmaları .ipynb dosya biçimiyle korunur.

IPYNB not defteri çıkış yapıt işlemelerini denetleme

Bir .ipynb dosya işlediğiniz zaman Databricks, çıkışları nasıl işleyebileceğinizi denetlemenize olanak tanıyan bir yapılandırma dosyası oluşturur: .databricks/commit_outputs.

1. Bir not defteri dosyanız .ipynb varsa ancak deponuzda yapılandırma dosyası yoksa Git Durumu kalıcısını açın.

2. Bildirim iletişim kutusunda commit_outputs dosyası oluştur'a tıklayın.

   

Dosya menüsünden de yapılandırma dosyaları oluşturabilirsiniz. Dosya menüsünde, belirli bir not defterinin çıkışlarının eklenmesini veya dışlanmasını belirtmek üzere yapılandırma dosyasını otomatik olarak güncelleştirmenizi sağlayan bir denetim vardır.

1. Dosya menüsünde Not defterleri çıkışlarını işle'yi seçin.

   

2. İletişim kutusunda, not defteri çıkışlarını işleme seçiminizi onaylayın.

   

Kaynak not defterini IPYNB'ye dönüştürme

Azure Databricks kullanıcı arabirimi aracılığıyla Git klasöründeki mevcut bir kaynak not defterini IPYNB not defterine dönüştürebilirsiniz.

1. Çalışma alanınızda bir kaynak not defteri açın.

2. Çalışma alanı menüsünden Dosya'yı ve ardından Not defteri biçimini değiştir [kaynak] öğesini seçin. Not defteri zaten IPYNB biçimindeyse, menü öğesinde [kaynak] [ipynb] olur.

   

3. Kalıcı iletişim kutusunda "Jupyter not defteri biçimi (.ipynb)" öğesini seçin ve Değiştir'e tıklayın.

   

Aşağıdakileri de yapabilirsiniz:

• Yeni .ipynb not defterleri oluşturun.
• Farkları Kod farkı (hücrelerdeki kod değişiklikleri) veya Ham fark olarak görüntüleyin (kod değişiklikleri, meta veri olarak not defteri çıkışlarını içeren JSON söz dizimi olarak sunulur).

Azure Databricks'te desteklenen not defteri türleri hakkında daha fazla bilgi için Databricks not defterlerini dışarı ve içeri aktarma bölümüne bakın.

Sık Sorulan Sorular: 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 . Git klasörlerinde desteklenen varlık türleri.

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 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ğlanma.

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

Uzak bir depoda kaynak koduyla Databricks İşleri kullanılarak oluşturulan not defteri MLflow denemeleri geçici bir depolama konumunda depolanır. Bu denemeler başlangıçta iş akışı yürütmeden sonra da devam eder, ancak daha sonra geçici depolamadaki dosyaların zamanlanmış olarak kaldırılması sırasında silinme riskiyle karşılanır. Databricks, İşler ve uzak Git kaynaklarıyla çalışma alanı MLflow denemelerinin kullanılmasını önerir.

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 A notebook 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 Git'i işlerle kullanma makalesini okuyun.

Kaynaklar

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