Databricks'te en iyi yöntemler ve önerilen CI/CD iş akışları

CI/CD (Sürekli Tümleştirme ve Sürekli Teslim), kod değişikliklerinin hızlı ve güvenilir bir şekilde tümleştirilmesini, test edilmesini ve dağıtılmasını sağladığından modern veri mühendisliği ve analizinin temel taşı haline gelmiştir. Databricks, kuruluş tercihleriniz, mevcut iş akışlarınız ve belirli teknoloji ortamınıza göre şekillendirilen çeşitli CI/CD gereksinimlerinizin olabileceğini tanır ve çeşitli CI/CD seçeneklerini destekleyen esnek bir çerçeve sağlar.

Bu sayfada, benzersiz gereksinimlerinize ve kısıtlamalarınıza uygun sağlam, özelleştirilmiş CI/CD işlem hatları tasarlamanıza ve oluşturmanıza yardımcı olacak en iyi yöntemler açıklanmaktadır. Bu içgörülerden yararlanarak veri mühendisliği ve analiz girişimlerinizi hızlandırabilir, kod kalitesini artırabilir ve dağıtım hatası riskini azaltabilirsiniz.

CI/CD'nin temel ilkeleri

Etkin CI/CD işlem hatları, uygulama özelliklerine bakılmaksızın temel ilkeleri paylaşır. Aşağıdaki evrensel en iyi yöntemler kuruluş tercihleri, geliştirici iş akışları ve bulut ortamları için geçerlidir ve ekibinizin not defteri öncelikli geliştirme veya kod olarak altyapı iş akışlarına öncelik verip vermediği fark etmeksizin farklı uygulamalar arasında tutarlılık sağlar. Bu ilkeleri, kuruluşunuzun teknoloji altyapısına ve süreçlerine özel uyarlarken kılavuz olarak benimseyin.

• Her şeyi sürüm kontrolüne tabi tut.
  • Git'te not defterlerini, betikleri, altyapı tanımlarını (IaC) ve iş yapılandırmalarını depolayın.
  • Gitflow gibi standart geliştirme, hazırlama ve üretim dağıtım ortamlarıyla uyumlu dallanma stratejilerini kullanın.
• Testi otomatikleştirme
  • Python için pytest ve Scala için ScalaTest gibi kitaplıkları kullanarak iş mantığı için birim testleri uygulayın.
  • Databricks CLI paket doğrulama gibi araçlarla not defteri ve iş akışı işlevselliğini doğrulayın.
  • Spark DataFrames için chispa gibi iş akışları ve veri işlem hatları için tümleştirme testlerini kullanın.
• Altyapıyı Kod Olarak Çalıştırma (IaC)
  • Bildirim temelli Otomasyon Paketleri YAML veya Terraform ile kümeleri, işleri ve çalışma alanı yapılandırmalarını tanımlayın.
  • Küme boyutu ve gizli diziler gibi ortama özgü ayarları sabit kodlamak yerine parametreleştirin.
• Ortamları yalıtma
  • Geliştirme, hazırlama ve üretim için ayrı çalışma alanları sağlayın.
  • Ortamlar arasında model sürümü oluşturma için MLflow Model Kayıt Defteri'ni kullanın.
• Bulut ekosisteminizle eşleşen araçları seçin:
  • Azure: Azure DevOps ve Bildirim temelli Otomasyon Paketleri veya Terraform.
  • AWS: GitHub Actions ve Bildirim temelli Otomasyon Paketleri veya Terraform.
  • GCP: Cloud Build ve Deklaratif Otomasyon Paketleri veya Terraform.
• Geri döndürme işlemlerini izleme ve otomatikleştirme
  • Dağıtım başarı oranlarını, iş performansını ve test kapsamını izleyin.
  • Başarısız dağıtımlar için otomatik geri alma mekanizmaları uygulayın.
• Varlık yönetimini birleştirme
  • Kodu, işleri ve altyapıyı tek bir birim olarak dağıtmak için Bildirim temelli Otomasyon Paketleri'ni kullanın. Not defterlerinin, kitaplıkların ve iş akışlarının silolu yönetiminden kaçının.

Note

Databricks, CI/CD kimlik doğrulaması için iş yükü kimlik federasyonu önerir. İş yükü kimlik federasyonu Databricks gizli dizilerine olan ihtiyacı ortadan kaldırır ve bu sayede Databricks'e otomatik akışlarınızın kimliğini doğrulamanın en güvenli yoludur. Bkz CI/CD'de iş yükü kimlik federasyonunu etkinleştirme.

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. Bu öğeleri yaml tanımlı tek bir ünitede birleştirerek, paketler dağıtımı basitleştirir ve ortamlar arasında tutarlılık sağlar. Ancak, geleneksel CI/CD iş akışlarına alışkın kullanıcılar için paket benimsemek için bir fikir değişikliği gerekebilir.

Örneğin Java geliştiricileri Maven veya Gradle ile JAR oluşturmak, JUnit ile birim testleri çalıştırmak ve bu adımları CI/CD işlem hatlarıyla tümleştirmek için kullanılır. Benzer şekilde, Python geliştiricileri genellikle kodu tekerlekler halinde paketleyip pytest ile test ederken, SQL geliştiricileri sorgu doğrulama ve not defteri yönetimine odaklanır. Paketlerle, bu iş akışları daha yapılandırılmış ve açıklayıcı bir biçime yakınsanır ve sorunsuz dağıtım için paketleme kodunu ve altyapısını vurgular.

Aşağıdaki bölümlerde geliştiricilerin paketlerden etkili bir şekilde yararlanmak için iş akışlarını nasıl uyarlayabilecekleri incelenmiştir.

Bildirim temelli Otomasyon Paketlerini hızlı bir şekilde kullanmaya başlamak için bir öğretici deneyin: Bildirim temelli Otomasyon Paketleri ile iş geliştirme veya Bildirim temelli Otomasyon Paketleri ile işlem hatları geliştirme.

CI/CD kaynak denetimi önerileri

Geliştiricilerin CI/CD'yi uygularken yapması gereken ilk seçenek, kaynak dosyaları depolama ve sürüm oluşturma işlemidir. Paketler kaynak kodu, yapıtlar ve yapılandırma dosyaları gibi her şeyi kolayca içermenizi ve bunları aynı kaynak kod deposunda bulmanızı sağlar, ancak başka bir seçenek de paket yapılandırma dosyalarını kodla ilgili dosyalardan ayırmaktır. Seçim ekibinizin iş akışına, proje karmaşıklığına ve CI/CD gereksinimlerine bağlıdır, ancak Databricks aşağıdakileri önerir:

• Kod ve yapılandırma arasında küçük projeler veya sıkı bir bağlantı için, iş akışlarını basitleştirmek için hem kod hem de paket yapılandırması için tek bir depo kullanın.
• Daha büyük ekipler veya bağımsız yayın döngüleri için kod ve paket yapılandırması için ayrı depolar kullanın, ancak sürümler arasında uyumluluk sağlayan net CI/CD işlem hatları oluşturun.

Kodla ilgili dosyalarınızı paket yapılandırma dosyalarınızda birlikte bulmayı veya ayırmayı tercih ettiğinizde, izlenebilirlik ve geri alma özelliklerini sağlamak için Databricks'e veya dış depolamaya yüklerken her zaman Git işleme karmaları gibi sürümlü yapıtları kullanın.

Kod ve yapılandırma için tek depo

Bu yaklaşımda hem kaynak kodu hem de paket yapılandırma dosyaları aynı depoda depolanır. Bu, iş akışlarını basitleştirir ve atomik değişiklikler sağlar.

Pros	Cons
Tüm ilgili yapıtlar, kod ve YAML yapılandırmaları birlikte oluşturulur ve bu da koordinasyon ek yükünü azaltır. Tek bir çekme isteği, hem derlenmiş dosyayı hem de ilgili paket yapılandırmasını güncelleştirebilir. CI/CD işlem hattı tek bir depodan derleyebilir, test edebilir, doğrulayabilir ve dağıtabilir.	Zaman içinde depo hem kod hem de yapılandırma dosyalarıyla şişirilebilir. Kod ve paket değişiklikleri eşgüdümlü bir sürüm gerektirir.

Örnek: Paketteki Python kodu

Bu örnekte Python dosyaları ve paket dosyaları tek bir depoda bulunur:

databricks-dab-repo/
├── databricks.yml               # Bundle definition
├── resources/
│   ├── workflows/
│   │   ├── my_pipeline.yml      # YAML pipeline def
│   │   └── my_pipeline_job.yml  # YAML job def that runs pipeline
│   ├── clusters/
│   │   ├── dev_cluster.yml      # development cluster def
│   │   └── prod_cluster.yml     # production def
├── src/
│   ├── my_pipeline.ipynb       # pipeline notebook
│   └── mypython.py              # Additional Python
└── README.md

Kod ve yapılandırma için ayrı depolar

Bu yaklaşımda kaynak kod bir depoda, paket yapılandırma dosyaları ise başka bir depoda tutulur. Bu seçenek, ayrı grupların uygulama geliştirme ve Databricks iş akışı yönetimini işlediği büyük ekipler veya projeler için idealdir.

Pros	Cons
Kod geliştirme üzerinde çalışan ekipler kendi depolarına odaklanabilirken, veri mühendisliği ekibi paket yapılandırmalarını yönetir. Bağımsız sürüm güncellemelerine ve derlenmiş kod, örneğin JAR, üzerinde sürüm kontrolüne ve paket yapılandırmalarına, bunları birbirine bağlamadan, olanak tanır. Her depo daha küçüktür ve yönetilmesi daha kolaydır.	Dağıtım sırasında depolar arasında ek koordinasyon gerektirir. Paket deposunda jar sürümü gibi bağımlılıkların doğru sürümüne başvurulmasını sağlamanız gerekir.

Örnek: Java projesi ve paketi

Bu örnekte, bir Java projesi ve dosyaları bir depoda, paket dosyaları ise başka bir depoda yer alır.

Depo 1: Java dosyaları

İlk depo, Java ile ilgili tüm dosyaları içerir:

java-app-repo/
├── pom.xml                  # Maven build configuration
├── src/
│   ├── main/
│   │   ├── java/            # Java source code
│   │   │   └── com/
│   │   │       └── mycompany/
│   │   │           └── app/
│   │   │               └── App.java
│   │   └── resources/       # Application resources
│   └── test/
│       ├── java/            # Unit tests for Java code
│       │   └── com/
│       │       └── mycompany/
│       │           └── app/
│       │               └── AppTest.java
│       └── resources/       # Test-specific resources
├── target/                  # Compiled JARs and classes
└── README.md

• Geliştiriciler src/main/java veya src/main/scala içinde uygulama kodu yazar.
• Birim testleri src/test/java veya src/test/scala içinde depolanır.
• Çekme isteğinde veya işlemede CI/CD işlem hatları:
  • Kodu bir JAR içinde derleyin, örneğin, target/my-app-1.0.jar.
  • JAR dosyasını bir Databricks Unity Kataloğu birimine yükleyin. Bkz. JAR'ı karşıya yükleme.

Depo 2: Dosyaları paketleme

İkinci depo yalnızca paket yapılandırma dosyalarını içerir:

databricks-dab-repo/
├── databricks.yml               # Bundle definition
├── resources/
│   ├── jobs/
│   │   ├── my_java_job.yml  # YAML job dev
│   │   └── my_other_job.yml # Additional job definitions
│   ├── clusters/
│   │   ├── dev_cluster.yml  # development cluster def
│   │   └── prod_cluster.yml # production def
└── README.md

• Paket yapılandırma databricks.yml ve iş tanımları bağımsız olarak korunur.

• databricks.yml karşıya yüklenen JAR yapıtına başvurur, örneğin:

  - jar: /Volumes/artifacts/my-app-${{ GIT_SHA }}.)jar
  

Önerilen CI/CD iş akışı

Kod dosyalarınızı birlikte konumlandırdığınızdan veya paket yapılandırma dosyalarınızdan ayırdığınızdan bağımsız olarak, önerilen bir iş akışı aşağıdaki gibi olabilir:

1. Kodu derleme ve test edin
   • Bir çekme isteğinde veya ana dalda yapılan bir commit işleminde tetiklenir.
   • Kod derleyin ve birim testlerini çalıştırın.
   • Sürümlü bir dosya çıktısı al, örneğin, my-app-1.0.jar.
2. JAR gibi derlenmiş dosyayı Databricks Unity Kataloğu birimine yükleyin ve depolayın.
   • Derlenen dosyayı bir Databricks Unity Kataloğu biriminde veya AWS S3 veya Azure Blob Depolama gibi bir yapıt deposunda depolayın.
   • Git işleme karmalarına veya anlamsal sürüm oluşturma işlemine bağlı bir sürüm oluşturma şeması kullanın; örneğin, dbfs:/mnt/artifacts/my-app-${{ github.sha }}.jar.
3. Paketi doğrulama
   • databricks bundle validate komutunu çalıştırarak databricks.yml yapılandırmasının doğru olduğundan emin olun.
   • Bu adım, eksik kitaplıklar gibi yanlış yapılandırmaların erken yakalanmasını sağlar.
4. Paketi dağıtın
   • Paketi hazırlama veya üretim ortamına dağıtmak için kullanın databricks bundle deploy .
   • Karşıya yüklenen derlenmiş kitaplığa databricks.yml referans verin. Kitaplıklara başvurma hakkında bilgi için bkz. Deklaratif Otomasyon Paketleri kitaplık bağımlılıkları.

Dallanma stratejisi

CI/CD işlem hattınızı ayarlarken aralarından seçim yapabileceğiniz çeşitli dallanma stratejileri vardır. En basit en iyi yöntem:

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 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:

Makine öğrenmesi için CI/CD

Makine öğrenmesi projeleri, geleneksel yazılım geliştirmeyle karşılaştırıldığında benzersiz CI/CD zorluklarına yol gösterir. ML projeleri için CI/CD uygularken, büyük olasılıkla aşağıdakileri göz önünde bulundurmanız gerekir:

• Çok ekipli koordinasyon: Veri bilimciler, mühendisler ve MLOps ekipleri genellikle farklı araçlar ve iş akışları kullanır. Databricks, bu işlemleri deneme izleme için MLflow, veri idaresi için Delta Paylaşımı ve kod olarak altyapı için Bildirim temelli Otomasyon Paketleri ile bir araya getirmektedir.
• Veri ve model sürümü oluşturma: ML işlem hatları yalnızca kod izlemeyi değil aynı zamanda veri şemalarını, özellik dağıtımlarını ve model yapıtlarını da izlemeyi gerektirir. Databricks Delta Lake, veri sürümü oluşturma için ACID işlemleri ve zaman yolculuğu sağlarken, MLflow Model Kayıt Defteri model kökenini işler.
• Ortamlar arasında yeniden üretilebilirlik: ML modelleri belirli veri, kod ve altyapı birleşimlerine bağlıdır. Bildirim temelli Otomasyon Paketleri, BU bileşenlerin YAML tanımları ile geliştirme, hazırlama ve üretim ortamları arasında atomik dağıtımını sağlar.
• Sürekli yeniden eğitim ve izleme: Veri düzensizliği nedeniyle modeller performans kaybına uğrar. Lakeflow İşlem Tanımları, otomatik yeniden eğitme işlem hatlarını etkinleştirirken, MLflow performans takibi için Prometheus ve Databricks Veri Kalitesi İzleme ile entegre edilir.

ML CI/CD için MLOps Yığınları

Databricks, Bildirim temelli Otomasyon Paketlerini, önceden yapılandırılmış CI/CD iş akışlarını ve modüler ML proje şablonlarını birleştiren üretim sınıfı bir çerçeve olan MLOps Yığınları aracılığıyla ML CI/CD karmaşıklığını giderir. Bu yığınlar veri mühendisliği, veri bilimi ve MLOps rolleri arasında çok ekipli işbirliği esnekliği sağlarken en iyi yöntemleri de uygular.

Team	Responsibilities	Örnek paket bileşenleri	Örnek yapıtlar
Veri mühendisleri	ETL işlem hatları oluşturma, veri kalitesini zorlama	Lakeflow Spark Bildirimli İşlem Hatları YAML, küme ilkeleri	etl_pipeline.yml, feature_store_job.yml
Veri bilimciler	Model eğitim mantığı geliştirme, ölçümleri doğrulama	MLflow Projeleri, not defteri tabanlı iş akışları	train_model.yml, batch_inference_job.yml
MLOps mühendisleri	Dağıtımları düzenleme, işlem hatlarını izleme	Ortam değişkenleri, izleme panoları	databricks.yml, lakehouse_monitoring.yml

ML CI/CD işbirliği aşağıdaki gibi görünebilir:

• Veri mühendisleri ETL işlem hattı değişikliklerini bir pakete işleyerek otomatik şema doğrulama ve hazırlama dağıtımı tetikler.
• Veri bilimcileri, birim testleri çalıştıran ve daha sonra tümleştirme testi için bir hazırlık çalışma alanına dağıtılan ML kodunu gönderir.
• MLOps mühendisleri, doğrulama ölçümlerini gözden geçirir ve MLflow Kayıt Defteri'ni kullanarak incelenen modelleri üretime yükselter.

Uygulama ayrıntıları için bkz:

• MLOps Yığınları paketi: Paket başlatma ve dağıtım için adım adım yönergeler.
• MLOps Stacks GitHub deposu: Eğitim, çıkarım ve CI/CD için önceden yapılandırılmış şablonlar.

Kuruluşlar, ekipleri standart paketler ve MLOps Yığınları ile uyumlu hale getirerek, ML yaşam döngüsü boyunca denetlenebilirliği korurken işbirliğini kolaylaştırabilir.

SQL geliştiricileri için CI/CD

Akış tablolarını ve gerçekleştirilmiş görünümleri yönetmek için Databricks SQL kullanan SQL geliştiricileri, iş akışlarını kolaylaştırmak ve yüksek kaliteli işlem hatlarını korumak için Git tümleştirmesi ve CI/CD işlem hatlarından yararlanabilir. Sorgular için Git desteğinin kullanıma sunulmasıyla BIRLIKTE, SQL geliştiricileri git'i kullanarak dosyalarını sürüm denetiminden .sql yararlanarak derin altyapı uzmanlığına gerek kalmadan işbirliği ve otomasyona olanak tanır. Ayrıca, SQL düzenleyicisi gerçek zamanlı işbirliği sağlar ve Git iş akışlarıyla sorunsuz bir şekilde tümleşir.

SQL merkezli iş akışları için:

• Sürüm denetimi SQL dosyaları

  • Databricks Git klasörlerini veya GitHub, Azure DevOps gibi dış Git sağlayıcılarını kullanarak .sql dosyalarını Git depolarında depolayın.
  • Ortama özgü değişiklikleri yönetmek için dalları (geliştirme, hazırlama, üretim gibi) kullanın.

• Dağıtımı otomatikleştirmek için dosyaları CI/CD işlem hatlarıyla tümleştirin .sql :

  • Çekme istekleri sırasında söz dizimi ve şema değişikliklerini doğrulayın.
  • Databricks SQL iş akışlarına veya görevlerine dosyaları .sql dağıtın.

• Ortam yalıtımı için parametreleştirme

  • Veri yolları veya tablo adları gibi ortama özgü kaynaklara dinamik olarak başvurmak için dosyalardaki .sql değişkenleri kullanın:

    CREATE OR REFRESH STREAMING TABLE ${env}_sales_ingest AS SELECT * FROM read_files('s3://${env}-sales-data')
    

• Yenilemeleri zamanlama ve izleme

  • Tablolarda ve gerçekleştirilmiş görünümlerde (REFRESH MATERIALIZED VIEW view_name ) güncelleştirmeleri zamanlamak için Databricks İşi'nde SQL görevlerini kullanın.
  • Sistem tablolarını kullanarak yenileme geçmişini izleyin.

İş akışı şu şekilde olabilir:

1. Geliştirme: Betikleri yerel olarak veya Databricks SQL düzenleyicisinde yazın ve test edin .sql, sonra onları bir Git dalına gönderin.
2. Doğrulayın: Pull request sırasında, söz dizimi ve şema uyumluluğunu otomatik CI denetimlerini kullanarak doğrulayın.
3. Dağıtma: Birleştirme işleminden sonra, ci/CD işlem hatlarını kullanarak hedef ortama .sql betikleri dağıtın, örneğin GitHub Actions veya Azure Pipelines.
4. İzleme: Sorgu performansını ve veri güncelliğini izlemek için Databricks panolarını ve uyarılarını kullanın.

Pano geliştiricileri için CI/CD

Databricks , Bildirim temelli Otomasyon Paketlerini kullanarak panoları CI/CD iş akışlarıyla tümleştirmeyi destekler. Bu özellik pano geliştiricilerinin şunları oluşturmasını sağlar:

• Denetlenebilirliği sağlayan ve ekipler arasındaki işbirliğini basitleştiren sürüm denetimi panoları.
• Uçtan uca hizalama için ortamlar arasında iş ve işlem hatlarının yanı sıra pano dağıtımlarını otomatikleştirin.
• El ile yapılan hataları azaltın ve güncelleştirmelerin ortamlar arasında tutarlı bir şekilde uygulandığını doğrulayın.
• CI/CD en iyi yöntemlerine bağlı kalarak yüksek kaliteli analiz iş akışlarını koruyun.

CI/CD'deki panolar için:

• databricks bundle generate Mevcut panoları JSON dosyaları olarak dışarı aktarmak ve paketin içinde yer alan YAML yapılandırmasını oluşturmak için komutunu kullanın:

  resources:
    dashboards:
      sales_dashboard:
        display_name: 'Sales Dashboard'
        file_path: ./dashboards/sales_dashboard.lvdash.json
        warehouse_id: ${var.warehouse_id}
  

• Değişiklikleri izlemek ve etkili bir şekilde işbirliği yapmak için bu .lvdash.json dosyaları Git depolarında depolayın.

• CI/CD işlem hatlarında panoları databricks bundle deploy ile otomatik olarak dağıtın. Örneğin, dağıtım için GitHub Actions adımı:

  name: Deploy Dashboard
    run: databricks bundle deploy --target=prod
  env:
    DATABRICKS_TOKEN: ${{ secrets.DATABRICKS_TOKEN }}
  

• SQL ambarları veya veri kaynakları gibi yapılandırmaları parametreleştirmek ve geliştirme, hazırlama ve üretim ortamlarında sorunsuz dağıtım sağlamak için gibi ${var.warehouse_id}değişkenleri kullanın.

• Databricks kullanıcı arabiriminde bundle generate --watch yapılan değişikliklerle yerel pano JSON dosyalarını sürekli eşitleme seçeneğini kullanın. Tutarsızlıklar oluşursa, yerel sürümlerle uzak panoların üzerine doğrudan yazdırmak için --force bayrağını dağıtım sırasında kullanın.

Paketlerdeki kontrol panelleri hakkında bilgi için bakınız görünüm kaynağı. Paket komutları hakkında ayrıntılı bilgi için bkz bundle . komut grubu.