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’nin 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 hala 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 duruyor.
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!
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 oldu — 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 Hikaye
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ç haliyle… 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.
Yani 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_adi/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.
Tabii 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 — bol 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ığı oldu.
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/)
İçeriği paylaş:
Yorum gönder