Databricks'te geliştirici en iyi yöntemleri

Bu sayfa, sürüm denetimi, ortam yönetimi, geliştirici araçları ve yönetilen dağıtımlar dahil olmak üzere veri mühendisliği ve geliştirme yaşam döngüsünüz için en iyi yöntemleri sağlar.

Kaynak denetimi

Tüm dosyaları sürüm denetimine alın

Bildirim temelli otomasyon, bir şey sürüm denetiminde değilse mevcut olmadığı fikrine dayalıdır. Bu nedenle Databricks, aşağıdakiler de dahil olmak üzere hemen hemen tüm dosyaları sürüm denetimi olarak kullanmanızı önerir:

• Tüm not defterleri ve kaynak dosyaları (.py, .sql)
• Yapılandırma dosyalarının (databricks.yml ve ortama özgü YAML geçersiz kılmaları) paketlenmesi

Ancak şunları işlemeyin:

• veya .jar dosyaları gibi .whl yapıtlar oluşturun. Bunun yerine, CI sırasında derlenmiş ikili dosyaları Unity Kataloğu birimlerine yükleyin. Bkz. JAR'ı karşıya yükleme.
• Belirteçler veya kimlik bilgileri. Bulut gizli dizi yöneticisi (AWS Gizli Dizi Yöneticisi veya Azure Key Vault gibi) tarafından yedeklenen çalışma alanı düzeyinde gizli dizi yönetimini kullanın ve değerleri Databricks gizli dizi kapsamlarına eşitleyin. Bkz. Gizli yönetim.
• PII ile yerel veri örnekleri ve dosyaları. Bunları dışlamak için kullanın .gitignore .

Tek depo

Databricks, işbirliği ve hem insanlar hem de yapay zeka için kod ve en iyi yöntemlerin paylaşımını kolaylaştıracak şekilde tüm kodunuz (kaynak kodu ve yapılandırma dosyaları) için tek bir depo kullanmanızı önerir. Ayrı dağıtım yaşam döngüleri için birden çok paketiniz varsa bunları tek bir depoda tutun.

Tek depo önerisinin tek istisnası, gizlilik amacıyla birden çok deponun gerekli olduğu düzenlenmiş sektörlerdir.

Ana dal tabanlı dallanma stratejisi

Birleştirme çakışmalarını en aza indirmek ve ana dalın her zaman dağıtılabilir durumda olduğundan emin olmak için gövde tabanlı bir dallanma stratejisi kullanın.

Basit bir iş akışı şöyle olabilir:

1. Değişiklikleri test etmek için yerel olarak veya çalışma alanında geliştirin ve databricks geliştirme çalışma alanına dağıtın.
2. Sürüm denetimi güncelleştirmeleri için kısa süreli bir özellik dalı oluşturun ve yerel veya çalışma alanı değişikliklerinizi düzenli olarak eşitleyin.
3. Test tamamlandığında özellik dalını ana dal ile birleştirin.
4. CI/CD, ana dalı bir hazırlama çalışma alanına otomatik olarak dağıtır ve otomatikleştirilmiş testler tetiklenir.
5. Hazırlama testleri ve denetimleri başarılı olduğunda, CI/CD ana dalı bir üretim çalışma alanına dağıtır.

Bu adımlar aşağıdaki diyagramda özetlenmiştir:

Çalışma alanı yapılandırması

Çalışma alanı ortamlarını yalıtma

Başarısız bir dağıtımın etkisini en aza indirmek için çalışma alanı ortamlarını yalıtın. Örneğin:

• Küçük ekipler (en fazla 5 veri mühendisi): Tek bir bulut hesabında iki çalışma alanı (geliştirme ve üretim) ile başlayın.
• Büyüyen ekipler (5'in üzerinde veri mühendisi):Üç çalışma alanına (geliştirme, hazırlama ve üretim) geçin. Hazırlama, ölçeği azaltılmış olsa bile aynı paket yapılandırması, şema ve kritik tümleştirmeler gibi üretimi işlevsel olarak temsil etmelidir.
• Düzenlenen sektörler (bankacılık, sağlık hizmetleri, savunma): Veri sızıntısını önlemek için çalışma alanlarını ve bulut hesaplarını fiziksel olarak yalıtma. Tek bir hesapta IAM ve Unity Kataloğu sınırları aracılığıyla yalıtımı yönetmek mümkündür, ancak daha az güçlü bir güvenlik duruşu sağlar.

Üretim çalışma alanları için mümkün olduğunca ağ ilkeleriyle sunucusuz işlem kullanın. Aksi takdirde, bulut hesaplarını sıkı şekilde denetlenen çıkış trafiğine ve ağ güvenliği kontrollerine sahip özel alt ağları veya VNet’leri kullanacak şekilde yapılandırın.

Daha fazla bilgi için bkz. Bağlam tabanlı ağ ilkeleri.

Veri depolamayı yalıtma

• Tek bir Unity Kataloğu meta veri deposu kullanın ve çalışma alanı düzeninizi yansıtan geliştirme, hazırlama (varsa) ve üretim için ayrı kataloglar oluşturun.
• Geliştirme ve hazırlık (üretim dışı) katalogları için bireysel geliştiricilere kişisel şemalar kullanın.
• Üretim kataloğunu ISOLATED modda yalnızca üretim çalışma alanına bağlayın. Bir kataloğun yalıtım modunu ISOLATED olarak ayarlamak, bir kimlik yanlış yapılandırılmış olsa bile üretim verilerine geliştirme veya staging ortamlarından erişilememesini sağlar.
• Ayrı meta veri depolarını, hesapları veya bölgeleri yalnızca mevzuat, veri hakimiyeti veya katalog düzeyinde yalıtımın karşılayamayacağı çok bölgeli gereksinimlere sahip kuruluşlar için ayırın.

Tablo ve sütun meta verilerini kod olarak işleme

Tablo ve sütun açıklamalarını kodunuzun bir parçası olarak değerlendirin. Bunları Bildirim temelli Otomasyon Paketleri tanımlarınızın yanı sıra dosyalarda .sql tutun ve doğru, işletmeye yönelik tanımların her zaman kullanılabilir olması için bunları bir meta veri işi aracılığıyla dağıtın. Sütun adını yinelemek yerine satırın neyi temsil ettiğini, birimleri ve geçerli değerleri düz dilde açıklayan açıklamalar yazın.

Kişisel şemaları yapılandırma

Geliştirme sırasında, paketleri kullanıcı başına kişisel şema kullanacak şekilde yapılandırın, örneğin dev_${user_name}. Bu, geliştiricilerin paylaşılan bir çalışma alanında birbirlerinin tablolarının üzerine yazmalarını engeller.

Sunucusuz işlem kullanma

Küme yönetimini basitleştirmek ve maliyeti iyileştirmek için sunucusuz işlem kullanın. Bkz. Sunucusuz bilişime bağlanma.

CI/CD önerileri

CI/CD için Bildirim temelli Otomasyon Paketleri

Bildirim temelli Otomasyon Paketleri (eski adıyla Databricks Varlık Paketleri), Databricks ekosisteminde kod, iş akışları ve altyapıyı yönetmeye yönelik güçlü ve birleşik bir yaklaşım sunar ve CI/CD işlem hatlarınız için önerilir.

CI/CD iş akışları için paket kullanma hakkında ek ayrıntılar için bkz. Databricks'te CI/CD iş akışları.

Bildirim temelli Otomasyon Paketleri hakkında daha fazla bilgi için bkz. Bildirim temelli Otomasyon Paketleri nedir?.

Terraform'un yalnızca dış kaynaklar için kullanılması

Terraform'ı kullanarak aşağıdaki kaynakları tanımlayın:

• Bulut düzeyindeki ve dış kaynaklar
• Çalışma alanı sağlama veya bulut ağı yapılandırması gibi ayrıcalıklı olmayan kullanıcıların gerçekleştirmemesi gereken yönetici eylemleri

Diğer tüm Databricks kaynakları için Bildirim temelli Otomasyon Paketlerini kullanın.

Paket yönetimi

Küçük paketler oluşturma

Databricks, tek bir büyük paket üzerinde küçük, odaklanmış paketler geliştirmenizi önerir.

• Tek bir ekibin sahip olduğu her şeyi tek bir pakete yerleştirin.
• Aynı yaşam döngüsünü ve yayın temposunu paylaşan aynı CI/CD işlem hattı aracılığıyla test edin ve dağıtın.
• Her paket, ortam başına ayrı paketler kullanmak yerine belirli bir proje için tüm ortamları (geliştirme, hazırlama, üretim) kapsamalıdır.

Için ayrı paketler oluşturun:

• "Faturalama analizi" ve "Sahtekarlık algılama" gibi farklı ürünler veya etki alanları
• Farklı sahiplik veya izin sınırları
• Açıkça farklı yaşam döngülerine sahip iş yükleri
• Bağımsız yükseltmeye veya geri alma işlemine ihtiyacınız olan durumlar

Paylaşılan klasörleri eşitlemek için sync.paths kullanma

Bir depoda birden çok paketi yönetirken, paylaşılan klasörleri paket kökü dışından eşitlemek için kullanın sync.paths . Bu, farklı projelerin ayrı dağıtım kimliklerini korurken gibi ../commonortak bir kitaplık klasörünü paylaşmasına olanak tanır.

CI/CD'de paketler arası bağımlılıkları modelleme

B Paketi, A Paketi tarafından yayımlanan varlıklara bağımlı olduğunda, bu bağımlılığı her ikisini tek bir pakette birleştirmek yerine CI/CD veya orkestrasyon katmanınızda modelleyin.

• Paket A'nın dağıtım ve yayımlama iş akışını B Paketi için açık bir önkoşul yapın. B Paketi'nin yalnızca Paket A'nın dağıtımı başarılı olduktan ve tüm gerekli doğrulama denetimleri geçtikten sonra başlaması için işlem hattınızı iletin.
• Yayımlanan varlık tanımlayıcılarını veya konumlarını işlem hattı girdileri olarak ileri iletin ve üst akıştaki varlıklar eksikse işlemi hemen başarısızlığa uğratın. Bu, B Paketinin kısmen yayımlanmış bir duruma karşı hiçbir zaman dağıtılmasını sağlamaz.

Paket paylaşımı hakkında daha fazla bilgi için bkz. Paket ve paket dosyalarını paylaşma.

Özel paket şablonları

Her projenin izinleri, etiketlemeyi, küme ilkelerini, CI/CD kablolarını ve örnek taban çizgilerini her ekip sıfırdan çözmeden aynı korumaları devralması için yeni projeler için varsayılan başlangıç noktası olarak özel Bildirim temelli Otomasyon Paketleri şablonlarını kullanın.

Şablonlar, idare, performans varsayılanları, ortam düzeni ve kota sınırları gibi paylaşılan, uzun süreli kuralları kodlamalıdır. Şablonlardaki uygulamaya özgü iş mantığı, gizli diziler veya tek seferlik yapılandırmalardan kaçının.

Yalnızca takıma, projeye veya ortama göre değişiklik göstermesi beklenen girişleri parametreleştirin:

• Project veya uygulama adı
• Hedef çalışma alanı ayarları
• Katalog veya şema adları
• Hizmet asıl adı tanımlayıcıları
• Zamanlamalar ve bildirim ayarları

Platform korumalarını ve paylaşılan varsayılanları parametreleştirmek yerine şablonda sabit tutun.

Özel paket şablonları ve bunların nasıl oluşturulacağı hakkında bilgi için bkz . Bildirim temelli Otomasyon Paketleri proje şablonları.

Geri almalar ve acil düzeltmeler için plan yapın

Paketleri, birbiriyle ilgisiz birçok iş yükü arasında geri alma sürecini koordine etmek yerine, tek bir paket için hedefli geri alma yapabileceğiniz kadar küçük tutun.

Bir olay sırasında:

1. Etkilenen paketi son bilinen iyi sürüme geri döndürün veya geri alın.
2. Düzeltmeyi yalnızca normal yükseltme akışını bekleyemeyen acil, dar kapsamlı düzeltmeler için kullanın.
3. Ana hattın tek doğruluk kaynağı olarak kalması için, herhangi bir hotfix’i doğrulamanın hemen ardından ana dala geri birleştirin.

Genel geliştirme

Hizmet sorumlularını veya OIDC'i kullanma

Otomatik iş akışlarını tek tek kullanıcı hesaplarından ayrıştırmak ve iç kullanıcılar ayrıldığında işlerin çalışmaya devam ettiğinden emin olmak için tüm geliştirme dışı otomasyon için hizmet sorumlularını kullanın. Bkz. Hizmet sorumluları.

• Dağıtım ve çalışma zamanı için ayrı hizmet sorumluları kullanın. Paket dağıtımları için ayrılmış dağıtım hizmet sorumlusu en düşük veri erişimine sahip olmalıdır. Her üretim işi veya işlem hattı, yalnızca ilgili iş yükünün gerektirdiği veri ve kaynaklarla sınırlandırılmış kendine ait bir run-as hizmet sorumlusuna sahip olmalıdır. Bu ayrım, veri erişim izinlerini döndürdüğünüzde veya sıkılaştırdığınızda dağıtımların güvende kalmasını sağlar ve altyapı değişikliklerini üretim veri erişimine bağlamayı önler.
• Düzenlenen sektörler: CI/CD için İş Yükü Kimlik Federasyonu (OIDC) kullanın. Bu sayede GitHub Actions veya Azure DevOps’taki uzun ömürlü gizli bilgiler ortadan kaldırılır. Bkz CI/CD'de iş yükü kimlik federasyonunu etkinleştirme.

Databricks geliştirici araçlarını kullanma

Git Klasörleri'ni veya yerel bir IDE'yi kullanarak Databricks çalışma alanı kullanıcı arabiriminde geliştirme. Visual Studio Code'u veya uyumlu bir türevini kullanıyorsanız, aşağıdakiler için resmi Databricks uzantısını yükleyin:

• Databricks’e özel ajan becerileri
• Unity Kataloğu ve dosya sistemi erişimi
• İş yüklerini Databricks işlem kaynaklarında çalıştırmaya yönelik uzaktan geliştirme olanakları

Daha fazla bilgi için bkz. Visual Studio Code için Databricks uzantısı.

Not defterlerinde iş mantığını en aza indirme

Notebook’leri iş mantığının birincil kapsayıcısı olarak görmeyin. Bunları yalnızca keşif ve görselleştirme için kullanın.

• Python: Çekirdek mantığı, .py veya src/ içindeki içe aktarılabilir src/py/ modüllerine yerleştirin ve not defterlerinden bu işlevleri çağırın.
• SQL: Sorguları, .sql veya src/ içindeki src/sql/ dosyalarında tutun ve SQL'i not defterlerine satır içi olarak eklemek yerine bu dosyalara işlerden ve işlem hatlarından başvurun.

Not defterlerini yalnızca temel alınan kodu çağıran ince düzenleme ve görselleştirme katmanları olarak kullanın. Bu yaklaşım test ve yeniden kullanımı kolaylaştırır.

Not defteri ağırlıklı bir projeyi taşırken bunu kademeli olarak yapın. Bir kerede bir yeniden kullanılabilir modül veya SQL dosyası ayıklayın ve geçirilen varlıkları projenin geri kalanıyla aynı dağıtım ve test iş akışı altına getirmek için Bildirimli Otomasyon Paketleri'ni kullanın.

Bağlamı dinamik olarak iletme

Görev bağımlılıkları için statik değişkenlerden kaçının. Çok aşamalı bir işte görevler arasında çalışma zamanı bağlamını aktarmak için {{tasks.<task_key>.values.<value_key>}} gibi dinamik değer başvurularını kullanın.

Test ve gözlemlenebilirlik

Test katmanlarını uygulama

Paketlerinizin üretim aşamasına nasıl taşındığını gösteren üç test katmanı kullanın:

1. Birim testleri: İş mantığını içe aktarılabilir src/ modüllerde tutun ve bunu pytest veya eşdeğer bir çerçeveyle testlerle kapsayın. Bunları her pull request'te çalıştırın; böylece başarısızlıklar birleştirmeyi engeller.
2. Paket doğrulama: Yerel olarak çalıştırın bundle validate . CI'de, üretim dağıtımı öncesinde YAML ve kaynak eşleme sorunlarını yakalamak için üretim dışı bir çalışma alanını tercih edin bundle deploy .
3. Hazırlık ortamında entegrasyon testleri: Hazırlık ortamına dağıtımdan sonra, tamamlanma kontrolleri ve satır sayısı veya şema beklentileri gibi kritik veri kalitesi doğrulamalarıyla uçtan uca görevleri çalıştırın.

“ana dalda ve hazırlık ortamında tüm testlerin geçmesi”ni, artefaktları üretime almak için ölçüt olarak kabul edin.

Lakeflow işlem hatları için geçici not defteri çalıştırmaları yerine yerleşik geliştirme ve doğrulama özelliklerini kullanın. İşlem hattı mantığını hata içeren kayıtlar içeren küçük ve temsili veri kümeleriyle test edin ve üretim tablolarını güncelleştirmeden önce değişiklikleri doğrulamak için geliştirme modunu kullanın.

Günlük kaydını dağıtımın bir parçası olarak değerlendirin

Bildirim temelli Otomasyon Paketleri tarafından dağıtılan iş yükleri için, ölçümleri ve günlüğe kaydetmeyi her projenin bağımsız olarak tanımladığı bir şey yerine dağıtım sözleşmesinin bir parçası olarak değerlendirin.

• Yapılandırılmış günlükleri işler, işlem hatları ve görevler genelinde tutarlı bir şekilde yayınlayın. Paket adını, hedef ortamı, iş yükü adını, çalıştırma tanımlayıcısını ve hataları izlemek için gereken tüm iş tanımlayıcılarını ekleyin.
• Her üretim iş yükü için standart bir işlem ölçümleri kümesini izleyin: çalışma durumu, süre, yeniden deneme sayısı ve uygun olduğunda aktarım hızı veya yenilik göstergeleri.
• Ekiplerin her proje için gözlemlenebilirlik desenlerini yeniden oluşturmak zorunda olmaması için bu kuralları paylaşılan kitaplıklarda, yeniden kullanılabilir iş yükü tanımlarında veya paket şablonlarında kodlayın.