Azure SQL’de Vektörler ve Analitik: ETL Neden Geride Kalıyor?
Bir fraud senaryosu düşünün. Kart geliyor, cihaz geliyor, konum geliyor, geçmiş davranış geliyor… ve sizden tek bir şey bekleniyor: “Bu işlem geçsin mi, geçmesin mi?” İşin aslı şu ki, bu karar çoğu zaman sadece bir SELECT sorgusuyla çıkmıyor. Ben yıllardır Azure — ki bu tartışılır — tarafında, özellikle kurumsal yapılarda bunu çok gördüm; veriyi parça parça başka yerlere taşıyınca iş büyüyor, gecikme artıyor, güvenlik ekibi ayrı konuşuyor, veri ekibi ayrı konuşuyor (kendi tecrübem). sonra herkes birbirine bakıyor.
Araya gireyim: Aditya’nın yazısındaki ana fikir bana çok tanıdık geldi: vektör araması da analitik de illâ ayrı sistemlerde yaşamak zorunda değil. Hatta açık konuşayım, bazı ekipler bunu gereksiz yere fazla dağıtıyor. 2024’te bir finans müşterisinde benzer bir mimarı tartışmasında tam bunu yaşamıştık; fraud ekibi “ben similarity search istiyorum” dedi, BI tarafı “biz de anlık baseline istiyoruz” dedi. İlk refleks yine klasik öldü: bir vektör veritabanı kuralım, üstüne data warehouse’a akıtacak ETL basalım. Sonra durduk ve şunu sorduk: Bunu tek yerde daha temiz yapabiliyor muyuz?
Neden Aynı Motor Meselesi Bu Kadar Önemli?
Bilmem anlatabiliyor muyum, Polyglot yaklaşımı ilk bakışta cazip görünüyor. Her iş için en uygun aracı seçiyorsunuz gibi dürüyor; kağıt üstünde süper. Ama pratikte biraz yorucu oluyor. Kimlik doğrulama ayrı, ağ katmanı ayrı, izleme ayrı… en sonunda küçük görünen bir fraud kontrolü bile üç servisin kapısını çalıyor.
Ben bunu 2023’te İstanbul’da bir e-ticaret platformunda net gördüm. Takım önce ilişkiseli tutmuştu ama device fingerprint için JSON store açtı, ilişkiler için graph denedi, benzer işlem bulmak için de ayrı bir vector service düşündü. Üç ay sonra operasyon tarafı “bir işlem neden gecikiyor?” sorusuna cevap veremez hâle geldi. Çünkü problem kodda değilmiş gibi görünüyordu; problem dağılımın kendisindeydi.
Hmm, bunu nasıl anlatsamdı…
Aynı motor yaklaşımının güzel yanı şu: transaction akışı tek plan içinde kalıyor. Bir yandan transactional veriyle uğraşıyorsunuz, öbür yandan benzerlik arıyorsunuz ya da milyonlarca satır üzerinden baseline hesaplıyorsunuz… ama veri başka kıtaya kaçmıyor. E tabiî bunun bedeli de var; her şeyi tek yere koyunca motorun kabiliyeti gerçekten güçlü olmalı.
Vektör araması neden sıradan filtrelerden farklı?
Şunu söyleyeyim, Mesela “amount between 8000 and 10000” yazmak kolaydır ama hayat o kadar düzgün değil. Fraud işlemlerinin çoğu net kutulara sığmaz. Benzer cihaz parmak izi vardır ama miktar değişmiştir; şehir değişmiştir ama saat penceresi aynıdır; kart yeni açılmıştır ama davranış paterni eski dolandırıcılığa çok benzer (şaşırtıcı ama gerçek)
Bak şimdi, Vektör burada devreye giriyor. Veriyi sayılara döküyorsunuz ve geometrik yakınlıkla anlam yakalıyorsunuz. Yanı kaba anlatımla iki işlem birbirine ne kadar yakınsa model önü o kadar benzer görüyor. Bu bana bazen insan ilişkisi gibi geliyor; kelime kelime aynı olmayabilirler ama his olarak çok benzeyebilirler.
Açık konuşayım: vektör arama sihir değil. Kötü hazırlanmış feature set ile mucize beklemek boşuna olur.
Analitik Tarafı Neden ETL’sız Düşünmek Gerekiyor?
Neyse, bilmem anlatabiliyor muyum, Ha bu arada ikinci büyük mesele de analitik tarafı. Anti-fraud ekipleri çoğu zaman “anlık baseline” ister ama teknik tarafta ilk tepki genelde şu olur: tamam bunu data warehouse’a basalım, orada hesaplarız! Güzel fikir gibi görünür… ta ki veri tazeliği bozulana kadar.
Bende en çok iz bırakan örneklerden biri 2022’de Ankara’da çalıştığım bir telekom projesiydi. Orada müşteri davranışlarını saatlik izliyorduk. Ekip güncel trendi birkaç dakika geriden görmek istemiyordu; çünkü kampanya suistimali hızlı gelişiyordu (işte tam o can sıkıcı an). ETL hattı kurulunca raporlar güzel görünüyordu ama karar anında veri artık eskiydi. Daha fazla bilgi için
Bana Göre Asıl Kazanç Nerede?
Eh, Bence en büyük kazanç mimarı sadelikte yatıyor.
Teknoloji sayısını azaltınca ekiplerin nefesi açılıyor.
Gözlemleme kolaylaşıyor,
güvenlik politikaları sadeleşiyor,
hatta FinOps tarafında bile daha net tablo çıkıyor.
2025 başında Logosoft’ta yürüttüğümüz bir Azure danışmanlığında tam bunu konuştuk;
“her şeyin kendi servisi olsun” fikri yerine
“işe yarayan parçaları aynı zeminde tutalım” dedik ve karmaşa belirgin biçimde azaldı.
E tabiî her şey pembe değil.
Bazı özellikler hâlâ ham hissediyor;
özellikle dokümantasyon ile gerçek kullanım arasındaki mesafe bazen insanın canını sıkabiliyor.
Ama dürüst olayım,
bu alan baya hızlı olgunlaşıyor.
Bakın, en çok da Microsoft’un multimodal veriye yaklaşımı,
sanki yıllardır dağıttığımız işleri tekrar merkeze çekmeye çalışıyor gibi.
Nerede kullanırım?
- Liveness fraud kontrolü: Canlı işlemde hem benzerlik hem baseline bakarsınız. (bence en önemlisi)
- Müşteri segmentasyonu: Davranış kümeleri ile anomaliyi birlikte takip edersiniz.
- Sahtecilik sonrası inceleme: Operasyon ekibi geçmiş örneklerle eşleştirme yapar.
Sıkça Sorulan Sorular
Azure SQL içinde vektör arama ne işe yarar?
Aynı veya benzer kayıtları semantik olarak bulmanızı sağlar. Mesela fraud detection,, öneri sistemi ve doküman eşleştirme gibi işlerde işe yarar.. Klasik filtrelerin kaçırdığı desenleri yakalamak için kullanılır..
Ayrı vector database kullanmak mı daha iyi?
Bazen evet,, özellikle çok özel iyileştirme gerekiyorsa.. Ama kurumsal tarafta ekstra entegrasyon,, yetkilendirme ve gecikme maliyeti getirir… Tek motorda çözmek çoğu zaman operasyonu rahatlatır..
Anlık analitik için ETL şart mı?
Tartışmalı konu burası.. Eğer birkaç dakika geriden gelmek sorun değilse batch yeterli.. Ama karar anında güncel sayı gerekiyorsa ETL zinciri genelde fazla yavaş kalır..
Küçük ekipler bu yaklaşımı kullanmalı mı?
Evet,, özellikle platform sayısını azaltmak istiyorlarsa mantıklı olabilir.. Küçük ekiplerde bakım yükü büyük fark yaratır. Daha az servis = daha az gece alarmı demek bazen doğrudan huzur demek!
Kaynaklar ve İleri Okuma
Azure SQL Resmî Dokümantasyonu
Azure SQL Vector Search Genel Bakış — Microsoft Learn
Microsoft Azure Blog — Azure SQL Yazıları
“Veriyi gerçekten taşımam gerekiyor mu?”
Çoğu zaman cevap hayır oluyor…
ve işte tam orada mimarı sadeleşmeye başlıyor.`
Bunun küçük versiyonunu geçen ay Bursa’daki bir üretim firmasına anlattığımda,
ekip önce şüpheyle baktı ama sonra tabloyu görünce ikna öldü.;
bazen en iyi optimizasyon yeni araç eklemek değil,. eldeki araçları doğru kullanmaktır.
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.
2 comments