Databricks ile makine öğrenmesi iş akışları nasıl kurulur?
Beceri rehberi

Databricks ile makine öğrenmesi iş akışları nasıl kurulur?

Hazırlayan: Mindset Institute EditörlüğüGüncellendi: 5 dk okuma

Databricks üzerinde MLflow ile deney takibi, Feature Store, model eğitimi, servis etme ve MLOps adımlarıyla makine öğrenmesi iş akışı kurmayı öğrenin.

Databricks ML iş akışı neyi çözer?

Makine öğrenmesi projeleri çoğu zaman modelin kendisinde değil, çevresindeki işlerde tıkanır: veriyi hazırlamak, denemeleri kaydetmek, özellikleri tekrar kullanılabilir yapmak, modeli canlıya almak, canlıdaki davranışı izlemek. Databricks bu parçaları veri platformunun yanında bir arada sunar. Veri mühendisi ile veri bilimcinin aynı veri üzerinde çalışması, ayrı sistemler arası kopyalamayı azaltır.

İş akışı kavramı bu bağlamda, ham veriden canlı tahmine uzanan adımların tekrar çalıştırılabilir bir zincir olarak tanımlanmasıdır. Zincir elle yürütülen bir not defteri dizisi olduğunda kırılgandır; zamanlanmış ve izlenen bir iş olduğunda ürün haline gelir.

Temel bileşenler

  • Not defterleri ve küme (cluster): keşif ve geliştirme ortamı. Hesaplama gücü kod dışında, küme ayarlarıyla belirlenir.
  • MLflow: deney takibi için kullanılır. Her eğitimin parametreleri, metrikleri ve ürettiği model kaydedilir, denemeler karşılaştırılır.
  • Feature Store: model için hesaplanmış özelliklerin tek bir yerde tutulması. Eğitimde kullanılan özellik, canlı tahminde de aynı tanımla üretilir; böylece eğitim ile canlı arasındaki tutarsızlık azalır.
  • Model kayıt defteri: modellerin sürümlendiği ve onaylandığı yer. Databricks'te önerilen kayıt defteri Unity Catalog'dur. Unity Catalog'daki modellerde eski Staging ve Production aşamaları desteklenmez; ortam ayrımı katalog ve şema adlarıyla, dağıtıma yükseltme ise belirli bir model sürümünü işaret eden değiştirilebilir takma adlarla (örneğin champion) yapılır.
  • Model servis etme: kayıtlı modelin bir uç noktadan gerçek zamanlı çağrılabilir hale getirilmesi.
  • İşler (jobs) ve iş akışları: bu adımların zamanlanıp birbirine bağlanması.

Adım adım kurulum akışı

Birinci adım, veri hazırlığıdır. Ham veri bir veri hattı ile temizlenir ve özellik tablolarına dönüştürülür. Bu işi not defterinde bir kez yapmak yerine zamanlanmış bir hat olarak kurmak, modelin sürekli taze veriyle beslenmesini sağlar.

İkinci adım deney yönetimidir. Her eğitim çalıştırması MLflow'a kaydedilir. Aynı veri üzerinde farklı algoritma ve parametre kombinasyonları denenir, metrikler yan yana okunur. Hiperparametre optimizasyonu bu aşamada otomatikleştirilebilir.

Üçüncü adımda seçilen model Unity Catalog'daki kayıt defterine yeni bir sürüm olarak alınır, doğrulama kontrollerinden geçer ve onaylanırsa üretimi temsil eden takma ad (örneğin champion) bu sürüme taşınır. Servis ve toplu puanlama işleri sürüm numarasına değil takma ada baktığı için yükseltme ya da geri alma, iş kodunu değiştirmeden takma adı başka sürüme çevirerek yapılır.

Dördüncü adımda model gerçek zamanlı bir uç noktaya ya da toplu puanlama işine bağlanır.

Son adım izlemedir: gelen verinin dağılımı ve model çıktısı gözlenir, sapma görüldüğünde yeniden eğitim işi tetiklenir.

Her adımın sonunda küçük bir doğrulama koymak zinciri sağlamlaştırır: veri hattında satır sayısı ve boş değer kontrolü, eğitimde asgari başarı eşiği, kayıt defterinde onay adımı, servis aşamasında örnek bir isteğin beklenen biçimde yanıtlanması. Bir kontrol başarısız olursa iş durur ve sorumluya bildirim gider; bozuk bir model sessizce üretime çıkmaz.

Gerçek bir iş örneği: talep tahmini

Örneğin bir perakende zinciri, mağaza bazında haftalık ürün talebini tahmin etmek istiyor. Satış, promosyon ve takvim verisi platformda zaten duruyor.

Veri ekibi satış verisinden gecikmeli satış, hareketli ortalama ve tatil göstergesi gibi özellikleri hesaplayıp Feature Store'a koyar. Veri bilimci bu özelliklerle birkaç farklı modeli eğitir; her deneme MLflow'da kayıtlıdır ve metrikler karşılaştırılır. Metrikleri en güçlü bulunan model kayıt defterine yeni sürüm olarak alınır ve onaydan sonra üretim takma adı ona verilir. Zamanlanmış bir iş her hafta özellikleri yeniler, modeli toplu olarak çalıştırır ve tahminleri tedarik ekibinin kullandığı tabloya yazar.

Bu kurguda kritik nokta, aynı özellik tanımının hem eğitimde hem tahminde kullanılmasıdır. Aksi halde model laboratuvarda başarılı, sahada tutarsız olur.

Aynı örnekte yeniden eğitim kararı da net tanımlanabilir: tahmin hatası belirlenen eşiği aştığında ya da mevsim değişimi gibi bilinen bir olay yaklaştığında iş yeniden eğitimi tetikler, yeni model eskisiyle karşılaştırılır ve ancak daha başarılıysa onaya sunulur. Karşılaştırma kaydı da MLflow'da tutulduğu için karar geriye dönük açıklanabilir.

Başlangıçtan ileri düzeye yol

Başlangıç düzeyinde platformu tanımak, bir not defteriyle küme çalıştırmak ve ilk modeli eğitip MLflow'da kaydetmek yeterli bir hedeftir.

Orta düzeyde özellik mühendisliği, Feature Store kullanımı, hiperparametre optimizasyonu ve modeli bir uç noktada sunma öğrenilir. Gerçek zamanlı çıkarımla toplu puanlama arasındaki seçim bu aşamada netleşir.

İleri düzeyde MLOps pratikleri gelir: kodun sürüm kontrolüyle yönetilmesi, otomatik test ve doğrulama, onay süreçleri, izleme ve yeniden eğitim tetikleyicileri. Kurumsal düzeyde ayrıca yönetişim konuları eklenir: kimin hangi veriye ve modele eriştiği, değişikliklerin nasıl kayıt altına alındığı.

Sık yapılan hatalar

  • Denemeleri kaydetmemek: hangi parametrelerin hangi sonucu verdiğini hatırlamak imkânsızlaşır, başarılı model yeniden üretilemez.
  • Özellik hesabını eğitim ve tahmin için ayrı yazmak: iki ayrı kod, iki ayrı sonuç demektir.
  • Kümeyi açık bırakmak: boşta çalışan küme gereksiz kaynak tüketir. Otomatik kapanma ayarı kullanılmalıdır.
  • Not defteri zincirine güvenmek: elle sırayla çalıştırılan hücreler üretimde kırılır. Zamanlanmış ve izlenen işler kullanılmalıdır.
  • Veri kalitesini izlememek: model değil çoğu zaman veri bozulur. Girdi dağılımı takip edilmelidir.
  • Yönetişimi sona bırakmak: erişim ve denetim kuralları baştan düşünülmezse kurumsal ortamda proje yayına çıkamaz.

Mindset programlarında nerede çalışılır?

Mindset kataloğundaki Databricks ML Workflows programının modül başlıkları şunlardır: Databricks platformuna giriş, MLflow ile deney yönetimi, Feature Store ve veri pipeline, model eğitimi ve hiperparametre optimizasyonu, model servis etme ve gerçek zamanlı çıkarım, MLOps ve üretim süreçleri, kurumsal uygulama ve yönetişim. Bu sıra, veriden canlı tahmine uzanan iş akışının adımlarıyla paralel ilerler.

İlgili Mindset programı

Databricks ML Workflows

Sık sorulanlar

Sık sorulan sorular

MLflow nedir, Databricks'e özel midir?

MLflow, makine öğrenmesi denemelerini ve modellerini kaydetmek, karşılaştırmak ve yönetmek için kullanılan açık kaynaklı bir araçtır. Databricks içinde entegre sunulur ama yalnız orada kullanılmaz. Öğrendiğiniz deney takibi ve model sürümleme mantığı başka ortamlara da taşınır. Böylece ekip değişse bile hangi modelin nasıl üretildiğini geriye dönük izlemek mümkün olur.

Feature Store olmadan ML iş akışı kurulabilir mi?

Kurulabilir, özellikle küçük projelerde. Ancak aynı özelliği birden fazla model kullanıyorsa ya da eğitim ve canlı tahminde tutarlılık önemliyse ortak bir özellik deposu hata riskini azaltır. Projeniz büyüdükçe bu ihtiyaç belirginleşir. Küçük bir denemede bu ek yapı gereksiz görünebilir, ancak üretime geçerken en çok zaman kazandıran adımlardan biri olur.

Databricks öğrenmek için Spark bilmek gerekir mi?

Zorunlu değildir ancak yararlıdır. Platform dağıtık işlemeyi sizin yerinize yönetir; yine de büyük veri üzerinde çalıştığınız için temel kavramları bilmek performans sorunlarını anlamanıza yardımcı olur. Python ve veri analizi temeli başlangıç için yeterlidir.

Gerçek zamanlı servis ile toplu puanlama nasıl seçilir?

Tahminin kullanıcı bir işlem yaparken anında gerektiği durumlarda gerçek zamanlı servis tercih edilir. Tahminler önceden hesaplanıp bir tabloda saklanabiliyorsa, örneğin haftalık talep planı, toplu puanlama daha sade ve genelde daha az kaynak tüketen yoldur. Maliyet ve karmaşıklık da kararı etkiler; gerçek zamanlı yol her zaman daha fazla işletme sorumluluğu getirir.

Modelin canlıdaki performansı nasıl izlenir?

İki şey izlenir: girdi verisinin eğitim verisinden ne kadar saptığı ve modelin çıktılarının gerçekleşen sonuçlarla uyumu. Sapma görüldüğünde uyarı üretilir ve yeniden eğitim işi tetiklenir. İzleme, model canlıya alındıktan sonra yapılacak bir ek iş değil, tasarımın parçasıdır. Bu sayede model, sorun yaşandığında fark edilir ve düzeltilir.