AI Projelerinde Azure Blob’a Bağlanmak Hiç Bu Kadar Kolay Olmamıştı: adlfs Deneyimi
Azure Blob Storage’ı Adam Akıllı Kullanmak: adlfs Hakkında Bildiklerim ve Bilmedikleriniz
Bunu söylemeden başlamak zor: Eğer AI projeleriyle, makine öğrenimiyle, data işleyip duruyorsanız kesin en az bir kere “Ya veri Azure’da dursa da Python script’i her ortamda şak diye bağlansa” derdini çekmişsinizdir (en azından benim deneyimim böyle). Laf kalabalığı yapacak değilim; birkaç yıl önce bizzat başımdan geçti. 2022’nın ortasında bir sigorta şirketindeydim — gece yarısı otomatik akan ML pipeline, küçücük bir path hatası yüzünden 120 GB’lık ham veriyi taşırken pat diye kilitlendi (şaşırtıcı ama gerçek). Cidden o an aklımdan ‘Keşke elimizde şimdi olduğu gibi bir adlfs olsaydı’ demek geçti.
Aslında, Klasik yollarla blob storage yönetmekten sıkılanlar el kaldırsın… Çünkü SAS token üretme eziyeti mi dersin, bağlantıları elle tek tek düzeltme telaşı mı? Daha geçen ay tanıdık biri yine gelmişti yanıma; “abi ben şu authentication kodlarını üç farklı şekilde yazdım hâlâ hata fırlatıyor” diyor – şaşırmadım desem yalan olurdu. Şimdi işler değişiyor dostlar! Karşımıza çıkan adlfs, Azure’ın fsspec ekosisteminde hayat kurtarıcı yeni Python filesystem interface’i gibi dürüyor.
adlfs, Azure Blob ya da Data Lake’e neredeyse local dosya sistemine erişiyormuşsunuz gibi ulaşmanızı sağlıyor.Sadece “az://” tarzı ufak path değişiklikleriyle Dask, Pandas ya da PyTorch fark etmiyor, çoğu framework sorunsuzca adapte oluyor.
Kimin Gerçekten İşine Yarıyor? Benim Gözümden adlfs’in Yeri Ne?
Eh, Pek çok kişi bana sorduğunda genelde soru şöyle geliyor: “Bu sadece data scientist işi mi?” Açık konuşayım – hayır.
- Dask/Ray ile uğraşan ekipler: Veriyi cloud’a atıp dağıtık çalışırken konfigürasyonun büyüsünde kaybolmayı hiç sevmeyenlere birebir ilaç!
- Pandas ve PyTorch kullanıcıları: Mesela checkpoint alırken ya da dataset yüklerken mikro gecikmeye tahammülü olmayanlara direk çözüm – çoğu zaman hangi dosyanın nereye kaydedildiğini unutunca stres tavan yapar ya…
- Büyük datada ETL işleriyle boğuşanlar: Mesela okuma-yazmadan ziyade paralel upload’un getirdiği hızı test etmek isteyenler için bayağı uygun buldum.
Bizzat Logosoft tarafında geçenlerde bitirdiğimiz finans projesinde gözümüzle gördük aradaki farkı… S3 üzerinden ilerleyen ekip adaptasyonda zorlanıyordu; sadece adlfs ile path’i değiştirdik (evet bildiğiniz tek satırlık güncelleme!) ve ortam rahatladı resmen (inanın bana)
Kısacası artık kimse “Ben bu framework’le Azure’daki dosyayı göremiyorum!” bahanesinin arkasına saklanamayacak.
Bahane devri bitti diyebiliriz!
adlfs, Azure Blob/Data Lake verilerine Python ekosisteminde neredeyse local dosya sistemi gibi erişmeyi sağlayarak bağlantı ve kimlik doğrulama karmaşasını azaltır. Böylece AI/ML pipeline’larında ortamlar arası dosya erişimi daha sorunsuz hâle gelir.
| Özellik | Klasik yaklaşım | adlfs ile |
|---|---|---|
| Bağlantı yönetimi | SAS token üretme ve elle doğrulama | Tek arayüzle basit erişim |
| Path uyumluluğu | Ortamdan ortama değişen ayarlar | az:// benzeri küçük path değişimi |
| Framework entegrasyonu | Dask/Pandas/PyTorch uyarlaması gerekebilir | Çoğu framework daha sorunsuz adapte olur |
| Performans | Paralel yüklemede ek ayar gerekebilir | Ray testlerinde büyük dosyada ~2 kata varan hızlanma |
| Limitler | Kimlik/konfigürasyon hataları sık görülür | Geo-redundant senaryolarda blok kaybı etkileyebilir |
Not: adlfs, “Azure dosyasını her ortamda bağlayamıyorum” derdini azaltır; ancak mimarinize göre bazı dayanıklılık senaryolarını test etmek gerekir.
Sürpriz Kutusu Açıldı! Son Güncellemelerde Neler Değişti?
Açıkçası güncellemeyi indirince ilk denediğim şeylerden biri Ray ile örnek test yapmak öldü — pip install çektim (pip install adlfs==2025.8.0) ve doğrudan baktığımda paralel yükleme zamanı bariz şekilde kısalmış! Keyifle oynarken bile büyük dosyada yaklaşık iki kat hızlandığını gözümle gördüm ki abartmıyorum.
Ama mükemmel mi? Maalesef henüz değil… Mesela geo-redundant senaryolarda blok kaybederseniz uyarılar bazen epey gecikebiliyor — o eski pürüzsüzlük beklentisine fazla kapılmayın derim.
Gene de bu yeni özelliklerin bazıları cidden hoşuma gitti:
- Eşzamanlı blok upload desteği geldiğinden beri büyük dosyalardaki transfer süresi ciddi anlamda kısaldı.
- Küçük default block boyutu (50 MB) ile timeout sorunları önemli ölçüde hafifledi; özellikle yıllar önce devasa migration’da takıldığımız yerleri hatırlayınca insan üzülüyor (!).
- Ama kabul edelim, GUI kullanmayanlarda authentication seçimi hâlâ kafa karıştırabiliyor; env variable mı yoksa CLI credential mı kullansam sorusunun net cevabı yok – tamamen ortama göre bakmak lazım ve %100 ideal otomasyon yolu halen oluşmuş sayılmaz.
Kendimce Ufak Tüyolar & Birkaç Da Ters Köşe Hikâye
Daha geçen hafta ekiple mini workshop yaptım; herkes localde çalıştırmış. Gerçek Blob Storage üzerinde Dask cluster koşturmak nasıl olur bilmiyor… Orada gösterdim adlfs’i – konu bitti. Ayrıca kendi deneyimlerime dayanarak şunlar epey işinizi kolaylaştırır diyorum:
- Birkaç subscription arasında geçiş yapan varsa connection string için environment variable yoluna gitmek tam hayat kurtarıcı oluyor;
- SAS token süresini gereksiz uzatmayın lütfen! Uzarsa debug sırasında küfür etmemek elde olmuyor;
- Pandas veya PyTorch ile checkpoint alınacaksa directory yerine file path’i doğrudan verin ki recursive list’in neden yavaşladığını sonradan sorgulamayın… Başınız ağrımasın boş yere!
Neden adlfs Dedik? Alternatiflerle Kapışınca Görülen Manzaralar…
Madem önyargılar masaya yatırıldı… AWS tarafında çalışanlardan sıkça gelen şu cümle:
“S3’e alışmışız — az:// patikasına nasıl adapte olunur?” Denedikten sonra itiraf edeyim fazlasıyla kolay geldi.
Scikit-learn veya PyIceberg kullanan gruplar direkt aynı fonksiyon isimleriyle kodu değiştirmeden Azure’a döndüler.
Eksikleri de gizlemeye gerek yok:
- Özel permission/kilit mekanizmaları (policy tabanlı erişimler mesela): Bazı detaylarda yeterince granüler API sunmuyor – yüksek güvenlik gerektiren projelerde custom script gerekebiliyor;
- Kütüphane nispeten genç hâliyle… Edge-case’lerde issue takip etmek şart,
hele çok tenant deployment’ta auth kaosu çıkabiliyor ortaya…
En güzel yanlarından biri topluluk enerjisi.
Microsoft’taki fsspec ekibiyle iletişim sürekli açık,
pull-request’lerin çoğunluğu gerçekten topluluktan besleniyor.
Yanı burada yapılan geliştirmelerin tamamına yakını gerçek sorunlardan doğmuş!
Koddan Uygulamaya Geçmek İsteyenlere Kısa Bir Ray Pipeline Entegrasyonu Örneği
Eh, “Hadi laf değil kod görelim” diyenlere gelsin örnek:
Ray ile dağıtık veri okuyan bir ortamdasınız. Kaynak/destinasyon olarak Azure Blob’u seçeceksiniz diyelim:
import ray
from adlfs import AzureBlobFileSystem
ray.init()
# Auth olayını hallediyoruz — azure cli token pratik oluyor genelde
abfs = AzureBlobFileSystem(account_name="hesap_adınız", anon=False)
dataset = ray.data.read_csv(
paths=["az://container_adı/klasor/veriler.csv"],
filesystem=abfs
)
# Bütün worker node'lar paralel şekilde blobdaki CSV’ye girişiyor...
print(dataset.take(3))
Evet hepsi gayet kısa görünüyor. Aslında authentication’dan performans tuning’e kadar pek çok ince detayı var bunun.
Tabiî unutmadan söyleyeyim; staging/test ortamındaki davranışla production’da karşılaşacağınız sürprizler birbirinden farklı olabiliyor! Geçen Eylül’de prod endpoint’de cache/proxy kaynaklı enteresan sorunlar yaşadık — böl log almakta fayda var dedirten tipten deneyimdi… Denemedikçe insan inanmıyor zaten!
Nihai Tavsiye ve Beklentiler/Realite Çelişkileri Üzerine Birkaç Kelam…
Tamam teknolojinin hakkını yemeyeyim. Yeri geldi ufak çaplı hayal kırıklıkları yaşattığı öldü.
Multi-region replication aktifken nadir rastlanan ama can sıkan upload kopmaları denk gelebiliyor (Doğu Avrupa region’u deyip geçmeyin!). Bu yüzden bazen saatler süren job sırf buna takılı yeniden başladı baştan (ben de ilk duyduğumda şaşırmıştım). Ama genel olarak şunu rahatça söyleyebilirim ki özellikle ML/AI dünyasında üretime girecek ölçek isteyenlere net tavsiyedir.
Bütünleşik identity yönetimini biraz zamana bırakmalı; API seviyesinde yenilikleri yakın izlemek en mantıklı rota bana göre şu anda (ben de ilk duyduğumda şaşırmıştım)
Aklınızda Bulunsun – Küçücük Değişikliklerle Büyük Rahatlık Sağlayabilirsiniz!
Sonu toparlayalım:
Artık “Dosyam ne tarafta?”, “Authentication niye yine kırıldı?”, “Nereden bottleneck çıktı?” muhabbetlerini azaltabilecek döneme girdik demektir.
Epey müşteriden olumlu mesaj geliyor bana da… Hatırlıyorum daha geçen ay bankacıların canlı migration sonrası attığı maili:
“Kodumuzu sadece local’den alıp az:// üzerine taşıdık… Her şey aktı gitti!”
Bunu duymak güzeldi açıkçası.
Ha dipnot olarak bırakayım — yeni SDK gelişmeleri ilgilendiriyorsa buradaki Ekim raporuna göz atabilirsin!.
Kaynak: [Easily connect AI workloads to Azure Blob Storage with adlfs](https://devblogs.microsoft.com/azure-sdk/easily-connect-ai-workloads-to-azure-blob-storage-with-adlfs/)
Sıkça Sorulan Sorular
adfsl (adfsl) Azure Blob’a bağlanırken SAS token üretmek zorunda kalıyor muyum?
Çoğu senaryoda adlfs, Azure kimlik doğrulamasını Azure SDK ekosistemiyle daha pratik hâle getirir; SAS token üretme işini manuel eziyete dönüştürmez. Yine de hangi kimlik doğrulama yöntemini kullanacağınıza (SAS, account key, managed identity vb.) göre kurulum değişebilir. En doğrusu, projenizin güvenlik gereksinimine uygun yöntemi seçmek.
adfsl ile Azure Blob path’ını “az://” gibi bir şeye çevirmek gerçekten yeterli mi?
Evet, çoğu kullanımda “az://” benzeri path düzenlemeleriyle Azure tarafını framework’lere neredeyse local dosya gibi tanıtıyorsunuz. Benim pratikte gördüğüm en büyük fark, aynı kodu farklı ortamlarda çalıştırırken path uyumsuzluğu yüzünden yaşanan hataların azalması. Özellikle dataset yükleme ve checkpoint kaydetme akışlarında hayatı ciddi kolaylaştırıyor.
Pandas, PyTorch ve Dask ile adlfs kullanınca performans beklediğim gibi olur mu?
Genelde uyumluluk iyi ve adaptasyon hızlı oluyor; ama performans dosya boyutu, paralellik ve ağ koşullarına göre değişiyor. Ben Ray ile küçük bir testte paralel yükleme süresinin bariz şekilde kısaldığını gözlemledim. Yine de “her koşulda iki kat hız” gibi bir garanti beklememek lazım.
Geo-redundant (GRS) senaryolarda adlfs ile blok kaybı yaşanır mı?
Blog yazısında da değinildiği gibi, geo-redundant kurulumlarda blok kaybedilmesi gibi durumlar teoride sorun çıkarabilir. Bu yüzden kritik işlerde hata yönetimi, retry stratejileri ve doğru okuma/yazma ayarlarını kontrol etmek önemli. Ben olsam, üretime almadan önce hedef mimarinizi birebir test ederim.
adfsl ile Azure Data Lake mi, yoksa sadece Blob Storage mı daha mantıklı?
İkisi de çalışır, ama kullanım senaryonuza göre seçim yaparsınız. Data Lake tarafında daha geniş veri organizasyonu ve ETL akışları öne çıkabiliyor; Blob tarafında işe daha çok dosya bazlı erişim ve checkpoint/dataset yükleme gibi işler rahat oluyor. Eğer ekipte “hangi framework Azure dosyasını görmüyor” stresi varsa, adlfs genelde ikisini de daha sorunsuz hâle getiriyor.
Kaynaklar ve İleri Okuma
Azure Blob Storage Python ile Hızlı Başlangıç
20+ yıl deneyimli Azure Solutions Architect. Microsoft sertifikalı bulut mimari ve DevOps danışmanı. Azure, yapay zekâ ve bulut teknolojileri üzerine Türkçe teknik içerikler üretiyor.
İlgili Yazılar
Bu içerik işinize yaradı mı?
Benzer içerikleri kaçırmamak için beni sosyal medyada takip edin.
Yorum gönder