Anadolu Market’in web sitesinde her tıklama bir olaydır: ziyaret, ürün görüntüleme, sepete ekleme, ödeme, satın alma. Kampanya günü pazarlama ekibi “sepete ekleyenler ödemeye geçiyor mu?” sorusunun cevabını yarın sabah değil, şimdi istiyor. Gece yenilenen bir Import model buna cevap veremez. Fabric’te bu işin adı Real-Time Intelligence (gerçek zamanlı zekâ) iş yüküdür.
Akış verisinin yolculuğu
| Parça | Ne yapar? |
|---|---|
| Real-Time hub | Kuruluştaki akış verisini bulmak, eklemek ve paylaşmak için merkezi katalog |
| Eventstream | Olayları kodsuz toplar, dönüştürür ve hedeflere yönlendirir (eventhouse, lakehouse, Activator…) |
| Eventhouse ve KQL veritabanı | Zaman damgalı akış verisi için analiz motoru; veriyi geliş zamanına göre düzenler. Tablolar eventhouse içindeki KQL veritabanlarında durur. |
| KQL sorgu kümesi (queryset) | KQL ya da T-SQL ile sorgu yazdığın ortam |
| Gerçek zamanlı pano (Real-Time Dashboard) | Her kutucuğu bir KQL sorgusu olan, canlı yenilenen pano |
| Activator (Fabric Activator) | Veride bir koşul oluşunca e-posta, Teams mesajı, Power Automate akışı ya da bir Fabric öğesi çalıştırır |
Hangi deponun ne zaman seçileceğini “Fabric’te veriyi hazırlamak” dersinde gördün: saniyelik olay ve log verisi eventhouse’a gider.
KQL’e ilk adım
KQL (Kusto Query Language), bir tabloyla başlar ve satırları | (boru) ile bir işleçten diğerine aktarır. Okuma sırası yazma sırasıdır: “tabloyu al, süz, seç, özetle, çiz”. Örneklerde eventhouse’ta duran hayalî bir tıklama tablosu kullanıyoruz: TiklamaAkisi(Zaman, ZiyaretciNo, AdimNo, Adim, Cihaz, Kaynak).
// Son 1 saatte mobilden gelen olayların ilk 10 satırı TiklamaAkisi | where Zaman > ago(1h) and Cihaz == "Mobil" | project Zaman, ZiyaretciNo, Adim, Kaynak | take 10
- where: satırları süzer (SQL’de WHERE, DAX’ta FILTER ya da CALCULATE filtresi). Eşitlik
==ile yazılır. - project: sütun seçer ya da yeniden adlandırır (SQL’de SELECT listesi, DAX’ta SELECTCOLUMNS).
- extend: hesaplanan yeni sütun ekler (DAX’ta ADDCOLUMNS).
- take: ilk N satır;
limitile aynıdır.
// Saatlik olay sayısı ve benzersiz ziyaretçi, zaman grafiği olarak TiklamaAkisi | where Zaman > ago(1d) | summarize Olay = count(), Ziyaretci = dcount(ZiyaretciNo) by bin(Zaman, 1h) | render timechart
- summarize … by: gruplar ve toplar (SQL’de GROUP BY, DAX’ta SUMMARIZECOLUMNS).
- bin(Zaman, 1h): zamanı saatlik kovalara yuvarlar. Learn’e göre tarih sütunları için otomatik saatlik kova artık yok;
binaçıkça yazılmalı. - render: sonucu grafik olarak çizer (timechart, columnchart…).
dcount() performans için yaklaşık sonuç verir; varsayılan doğrulukta küçük kümelerde tam sayar, büyük kümelerde küçük bir hata payı olabilir. DAX’taki DISTINCTCOUNT ise her zaman tam sayar. İki aracın sonucu çok büyük tablolarda birebir tutmayabilir.Aynı soru üç dilde
DP-600, veriyi görsel sorgu düzenleyiciyle, SQL ile, KQL ile ve DAX ile süzüp toplayabilmeni ister. Soru: “Altı saatlik dilimlerde kaç olay var?”
| Dil | Sorgu |
|---|---|
| KQL | TiklamaAkisi | summarize Olay = count() by Dilim = bin(Saat, 6) |
| T-SQL | SELECT (Saat / 6) * 6 AS Dilim, COUNT(*) AS Olay FROM TiklamaAkisi GROUP BY (Saat / 6) * 6 |
| DAX | Aşağıdaki sorgu |
Bu uygulamanın modelinde aynı yapıda bir tablo var: WebOlaylari (Ekim–Kasım 2024, 2.019 olay, 900 ziyaretçi). DAX’ta kovaları GENERATESERIES ile üretip her kovadaki olayları sayabilirsin:
EVALUATE
ADDCOLUMNS(
GENERATESERIES(0, 18, 6),
"Olay", COUNTROWS(FILTER(WebOlaylari, WebOlaylari[Saat] >= [Value] && WebOlaylari[Saat] < [Value] + 6))
)
Sonuç: 00–06 arası 513, 06–12 arası 513, 12–18 arası 502, 18–24 arası 491 olay. Gün içinde belirgin bir tepe yok; trafik dengeli dağılıyor.
Huniyi KQL ile okumak
Huni sorusunda her adımda kaç farklı ziyaretçi kaldığını sayarız. KQL’de koşullu toplayıcılar işi tek satırda yapar:
TiklamaAkisi
| where Zaman between (datetime(2024-10-01) .. datetime(2024-11-30))
| summarize Ziyaret = dcountif(ZiyaretciNo, AdimNo == 1),
Odeme = dcountif(ZiyaretciNo, AdimNo == 4),
SatinAlma = dcountif(ZiyaretciNo, AdimNo == 5)
by Cihaz
| extend OdemedenSatisa = round(100.0 * SatinAlma / Odeme, 1)
DAX’ta aynı mantık, hazır [Ziyaretçi] ölçüsünü adım filtresiyle CALCULATE içine almaktır. Modelde huni 900 → 640 → 254 → 137 → 88 ziyaretçi. Ödeme adımına gelen 137 kişiden 88’i satın almış: yaklaşık %64,2. Cihaza göre bakınca masaüstünde %68,6, mobilde %59,7. Mobil ödeme sayfası ilk bakılacak yer.
Ödemeden Satışa % =
DIVIDE(
CALCULATE([Ziyaretçi], WebOlaylari[AdimNo] = 5),
CALCULATE([Ziyaretçi], WebOlaylari[AdimNo] = 4)
)
Huni görselinin kurulumu ve adım oranlarının raporda gösterimi “Vaka: e-ticaret dönüşüm hunisi ve kargo” dersinde var.
Gerçek zamanlı pano mu, Power BI raporu mu?
| Gerçek zamanlı pano | Power BI + DirectQuery + otomatik sayfa yenileme | |
|---|---|---|
| Sorgu dili | Her kutucuk bir KQL sorgusu | DAX; motor kaynağa sorgu (ör. KQL ya da SQL) gönderir |
| Yenileme | Canlı yenileme: yeni veri gelince görseller güncellenir; yenileme hızı sınırı ayarlanır | Sabit aralık ya da değişiklik algılama. Paylaşılan kapasitede en az 30 dakika; ayrılmış kapasitede (Fabric F, Premium, PPU) yönetici izin verirse saniyeler; varsayılan alt sınır 5 dakika (değişiklik algılamada 5 saniye) |
| Güçlü yanı | Operasyon ekranı: son dakikalar, log, hızlı keşif | Zengin görsel, yıldız şema, RLS, diğer verilerle birleştirme |
| Zayıf yanı | Kurumsal model, ölçü kütüphanesi yok | Kaynak her yenilemede sorgulanır; kapasite tüketir |
Otomatik sayfa yenileme yalnızca DirectQuery (ve bazı canlı bağlantı) senaryolarında çalışır; Import modelde yoktur. Direct Lake’te sabit aralık desteklenir, değişiklik algılama desteklenmez. Pratik ayrım: vardiya ekranı için gerçek zamanlı pano, yönetim raporu için Power BI.
Activator ile eyleme geçmek
Ekranı izleyen kimse yoksa gerçek zamanlı veri işe yaramaz. Activator, bir eventstream’den, gerçek zamanlı panodan ya da Power BI raporundan gelen veriyi nesne başına (ör. her ürün, her mağaza) izler ve kural sağlanınca eylem başlatır. Kurallar durumsuz (“değer 50’nin altında”) ya da durumlu (“azalıyor”, “30 dakikadır veri gelmiyor”) olabilir ve yalnızca duruma ilk girişte tetiklenir; aynı uyarı her olayda tekrar gelmez.
Örnek: “Mobil ödeme adımındaki dönüşüm 15 dakikalık pencerede %50’nin altına düşerse ödeme ekibinin Teams kanalına mesaj gönder.” Power BI tarafındaki uyarılar ve Power Automate ile eylem “Power Platform ile eyleme geçmek” dersinde anlatılıyor.
OneLake ile bağlamak
Gerçek zamanlı veri yalnız kalmamalı; geçmiş satışlarla birlikte analiz edilmeli. İki köprü var:
- Eventhouse OneLake erişilebilirliği (OneLake availability): KQL veritabanındaki tablolar OneLake’e Delta Parquet biçiminde mantıksal bir kopya olarak açılır. Veritabanı ya da tablo düzeyinde açılır. Sonra lakehouse’tan kısayolla, not defterinden ya da Direct Lake modelden okunur. Learn’e göre ek depolama ücreti yoktur. Gecikme varsayılan olarak 3 saate kadar çıkabilir, 5 dakika ile 3 saat arasında ayarlanabilir. Açıkken tabloyu yeniden adlandıramaz, satır silemez, tabloya RLS uygulayamazsın.
- Anlam modelleri için OneLake entegrasyonu: Import modelin tabloları her yenilemede OneLake’e Delta tablo olarak yazılır. Böylece veri bilimci aynı “altın” veriyi Spark’la okur. Yalnızca Import tablolar yazılır; ölçüler, DirectQuery tabloları ve hesaplama grupları yazılmaz. Fabric F ya da Premium P kapasitesi gerekir.