Yazar: @atilayberber
Bir ETL geliştiricisinin tipik haftasını düşünün: Kaynak sistemden gelen yeni bir dosya formatı, bozuk tarihler, çift kayıtlar, bir pipeline’ın gece neden düştüğünü anlamaya çalışmak, bronze’dan silver’a, silver’dan gold’a giden notebook’ları tek tek yazmak ve sonunda “rakamlar tutuyor mu?” kontrolü.
Şimdi bunun yerine şu cümleyi yazdığınızı düşünün: “Müşteri, ürün ve satış dosyalarından bronze, silver ve gold katmanlarını kur. Ham veriyi koru, kayıtları standartlaştır ve tekilleştir, günlük satış özetleri oluştur ve gelir toplamlarının tuttuğunu doğrula.” Ve bir ajanın bu işi planlayıp, notebook’ları yazıp, çalıştırıp, sonuçları kontrol ettiğini.
Microsoft’un Ocak 2026’da satın aldığı Osmos’un üzerine kurulan Fabric data engineering agent (Project Osmos), FabCon Barcelona’da genel önizlemeye açıldı. Ve topluluğun en çok tartıştığı sorulardan birini beraberinde getirdi: ETL geliştiricisinin işi bitiyor mu?
Kısaca: Bu yazıda neler var?
- Project Osmos nedir, bir kodlama asistanından farkı ne?
- Gerçekte nasıl çalışıyor: görev ayarları ve güvenlik sınırları
- Neyi henüz yapamıyor? Önizlemenin sınırları
- İki kamp: “ETL elle yazılmayacak” ve “Ajan sadece hızlı bir stajyer”
- Benim görüşüm: ETL geliştiricisi değil, “sonuç mühendisi”
- Denemek isteyen ekipler için güvenli bir plan
Project Osmos nedir?
Kodlama asistanları (GitHub Copilot gibi) size kod önerir; kodu çalıştırmak, sonucu kontrol etmek ve hatayı düzeltmek sizin işinizdir. Osmos bunun bir adım ötesine geçiyor. Microsoft Learn’deki tanıma göre:
- Kaynakları, dönüşümleri, çıktıları ve doğrulama kurallarını içeren tam bir sonucu tarif ediyorsunuz.
- Ajan bunu SparkCore üzerinde tek bir uzak görev olarak çalıştırıyor: işi planlıyor ve sıralıyor, tablolar ve notebook’lar oluşturuyor, kodu çalıştırıyor ve sonuçları kontrol ediyor.
- Görev Fabric’te kalıcı olarak çalışıyor. Dizüstü bilgisayarınızı kapatsanız da iş devam ediyor. İlerlemeyi lakehouse explorer’dan ya da yerel ajanınıza sorarak izliyorsunuz.
Microsoft’un vurguladığı fark şu: Osmos canlı lakehouse’u inceliyor, seçenekleri deniyor ve gerçek çalıştırma sonuçlarına göre yineliyor. Genel bir kodlama asistanı ise veriyi görmeden kod yazıyor.
Osmos’u Fabric portalındaki Copilot’tan kullanamıyorsunuz; bir yerel ajan üzerinden çalışıyor. Desteklenen istemciler GitHub Copilot CLI, Claude Code ve Codex.
Gerçekte nasıl çalışıyor?
Microsoft’un hızlı başlangıç örneği ilginç bir şekilde bir perakende senaryosu: Boş bir lakehouse’ta müşteri, ürün ve satış için örnek CSV’ler oluşturmak, bronze-silver-gold tablolarını ve üç notebook’u kurmak, bunları sırayla çalıştırmak ve satır sayılarını, anahtar tekilliğini, referans bütünlüğünü ve gelir toplamlarını doğrulamak.
Benim en değerli bulduğum kısım görev ayarları. Ajan, çalışmaya başlamadan önce şu ayarlar için öneri sunuyor ve hepsini değiştirebiliyorsunuz:
| Ayar | Ne belirler? |
|---|---|
| İzin sınırı (permission boundary) | Hangi kaynaklar salt okunur, hangileri yazılabilir |
| Güvenlik kalıbı | Staging, klonla ve terfi ettir (clone-and-promote) ya da doğrudan yineleme |
| Terfi adımı | Sonuçlar ne zaman ve nasıl asıl hedefe taşınır |
| Yeniden çalıştırma davranışı | Hata ver, ekle, tekilleştir ya da değiştir |
| Şema evrimi | Şema değişikliklerine izin var mı |
| Çıktı formatı ve hedefi | Üretilen dosyalar nereye, hangi formatta |
| Akıl yürütme seviyesi | Ajanın ne kadar derin düşüneceği |
Bu tablo aslında iyi bir ETL geliştiricisinin kafasındaki kontrol listesinin ta kendisi. Ve bu, tartışmanın özüne dair bir ipucu.
Neyi henüz yapamıyor?
Heyecanı biraz frenlemek gerekiyor, çünkü Microsoft’un kendisi oldukça net:
- Özellik önizlemede. Sınırlı yetenekleri var, üretim kullanımı için tasarlanmamış, SLA’sı yok ve yalnızca bazı bölgelerde kullanılabilir olabilir.
- Giden erişim koruması (outbound access protection) açık workspace’lerde kullanılamıyor.
- En önemli uyarı: Görev, sizin erişim izniniz olan her kaynağa erişebiliyor; buna hedef workspace dışındaki kaynaklar da dahil. Görev ayarlarındaki izin sınırı ajana yol gösteriyor; ama asıl sınır Fabric ve OneLake izinleri. Hassas veriyi korumak için prompt’a değil, platform izinlerine güvenmek gerekiyor.
Son madde bence önizleme döneminin en kritik dersi. “Ajana sadece staging şemasına yazmasını söyledim” bir güvenlik önlemi değil, bir rica.
İki kamp
Kamp 1: “ETL artık elle yazılmayacak”
- Medallion mimarisi, tekilleştirme, SCD Tip 2, artımlı yükleme: Bunlar iyi bilinen, tekrar eden kalıplar. Ajanların en iyi olduğu tür iş.
- Ajan kodu sadece yazmıyor, çalıştırıp doğruluyor. “Çalışan ama yanlış” kod üretme riski, düz bir kodlama asistanına göre daha düşük.
- Microsoft’un örnek senaryoları (Dynamics 365 müşteri yaşam döngüsü, SAP sipariş-tahsilat, NetSuite finansal mutabakat, Salesforce satış hunisi) tam da kurumların en çok emek harcadığı entegrasyonlar.
- Görev saatlerce kendi kendine çalışabiliyor. Bir mühendis aynı anda birkaç görevi yönetebilir.
Kamp 2: “Ajan sadece çok hızlı bir stajyer”
- Gerçek ETL’in zor kısmı kod değil, kaynak sistemin tuhaflıkları: Hiçbir yerde belgelenmemiş bir durum kodu, gece yarısı değişen bir saat dilimi, bir şubenin üç yıl önce farklı bir ürün kodlaması kullanması. Bunlar veride değil, insanların hafızasında.
- Önizleme, üretim için değil. Kurumsal ETL’in güvenilirlik, izlenebilirlik ve geri alınabilirlik beklentileri henüz karşılanmıyor.
- “Doğrulama kriterlerini sen ver” demek, işin en zor kısmını yine insana bırakmak demek. Neyin doğru olduğunu bilmeyen biri doğru kriter yazamaz.
Benim görüşüm: ETL geliştiricisi değil, “sonuç mühendisi”
İki kamp da haklı ve ben ikisini şöyle birleştiriyorum: Ajan, “nasıl”ı devralıyor; “ne” ve “doğru mu?” insanda kalıyor.
Yukarıdaki görev ayarları tablosuna tekrar bakın. Staging mi, doğrudan yazma mı? Yeniden çalıştırınca ekle mi, değiştir mi? Şema değişebilir mi? Bunların hiçbiri teknik detay değil; hepsi iş riski kararı. Bir perakende şirketinde satış tablosunu “replace” moduyla yeniden çalıştırmak ile “append” moduyla çalıştırmak arasındaki fark, ay sonu ciro raporunda iki kat görünen satışlar demek olabilir.
Yani ETL geliştiricisinin işi ortadan kalkmıyor, yer değiştiriyor:
- Eskiden: Notebook yazmak, hata ayıklamak, aynı tekilleştirme mantığını her projede tekrar kurmak.
- Şimdi: Sonucu tanımlamak, doğrulama kriterlerini yazmak (satır sayısı, null kontrolü, tekillik, mutabakat), güvenlik kalıbını seçmek, ajanın ürettiğini incelemek ve kaynak sistem bilgisini ajana aktarmak.
Bu yeni role “sonuç mühendisi” diyorum. Ve bu rolde en değerli beceri, Python ya da Spark bilgisi değil, “doğru veri neye benzer?” sorusunu cevaplayabilmek. Yıllarca kaynak sistemle boğuşmuş bir ETL geliştiricisi, tam da bu yüzden bu yeni dönemde avantajlı başlıyor.
Denemek isteyen ekipler için güvenli bir plan
- Ayrı bir workspace ve lakehouse ile başlayın. Önizleme sürecinde üretim verisine dokunmayın.
- İzinleri platformda daraltın. Görevi çalıştıran kimliğin hassas kaynaklara erişimi olmasın; prompt’taki sınıra güvenmeyin.
- Önce bildiğiniz bir işi verin. Elle yazılmış ve doğruluğu bilinen bir pipeline’ı ajana yeniden kurdurun ve sonuçları karşılaştırın.
- Doğrulama kriterlerini görevden önce yazın. Kriteri ajanın önerisine bırakmayın; kabul testlerini siz tanımlayın.
- Güvenlik kalıbı olarak staging ya da clone-and-promote seçin. Doğrudan yineleme yalnızca tamamen deneysel işler için.
- Üretilen notebook’ları kod incelemesinden geçirin. Ajanın yazdığı kod, sizin yazdığınız kod kadar sizin sorumluluğunuzda.
Sonuç
Project Osmos, “veri mühendisliğinde ajan” fikrini bir demodan çalışan bir önizlemeye taşıdı. Bugün üretim için hazır değil ve Microsoft bunu açıkça söylüyor. Ama yön çok net: Notebook’ları elle yazan ETL geliştiricisinin yerini, sonucu tanımlayan, kriterleri koyan ve ajanı denetleyen bir mühendis alacak. Kaynak sistemi en iyi bilen kişi ise bu geçişte en değerli kişi olacak.
Siz ne düşünüyorsunuz: Kendi pipeline’larınızı bir ajana emanet eder miydiniz? Hangi koşullarda? Yorumlarda ya da LinkedIn’de konuşalım.
Kaynaklar
- Get started with Fabric data engineering agent (Project Osmos) (Microsoft Learn)
- Announcements from FabCon Barcelona 2026 (James Serra)
- Microsoft Acquires Osmos To Bring Autonomous Data Engineering to Fabric (Redmond Magazine)
HABERDAR OL
Yeni rehberler, kategorilere ayrılmış tek bir e-postada.
Her pazartesi, o hafta yayımlanan yazılar konu başlıklarına göre derlenmiş olarak gelen kutunda. Yeni yazı yoksa e-posta da yok.