Veri akışları ve paylaşılan anlam modelleri: hazırlığı bir kez yap, herkes kullansın

Veri akışı Gen2 ile Gen1 arasındaki fark, çıkış hedefleri, hazırlığın nerede yapılacağı (veri akışı, modeldeki Power Query, SQL görünümü), paylaşılan ve onaylı anlam modelleri, canlı bağlantı, ince rapor deseni, yenileme sırası ve veri tazeliği ölçüsü.

Bu sayfa dersin okuma sürümüdür. Metin bir kutuyu çalıştırmanı ya da adıma geçmeni söylüyorsa dersi uygulamada aç.

Anadolu Market’te dört analist var. Her biri kendi .pbix dosyasında aynı ürün listesini temizliyor: boşlukları siliyor, kategori adlarını düzeltiyor, iptal edilen siparişleri ayıklıyor. Ay sonunda dört raporda dört farklı “net satış” çıkıyor. Sorun DAX’ta değil, hazırlığın dört kez yapılmasında. Bu derste hazırlığı tek bir yere taşımayı ve herkesin aynı anlam modelini kullanmasını öğreneceksin.

İki katman var: veri katmanı (temizlenmiş tablolar) ve anlam katmanı (ilişkiler, ölçüler, güvenlik). Veri akışı birinci katmanı, paylaşılan anlam modeli ikinci katmanı ortak hâle getirir.

Veri akışı nedir? Gen2 ile Gen1 farkı

Veri akışı (dataflow), Power Query adımlarının bir .pbix dosyasının içinde değil, Service’te (bulutta) çalışan hâlidir. Adımlar aynıdır: “Power Query ile veri temizleme” ve “Power Query: birleştirme, ekleme, özetten çıkarma” derslerinde öğrendiğin her dönüşüm burada da var. Fark, sonucun bir kez hesaplanıp birçok kişiye sunulmasıdır.

Özellik	Veri akışı Gen2 (Fabric)	Veri akışı Gen1 (Power BI)
Sonuç nereye yazılır?	Seçtiğin bir veya birden çok çıkış hedefine (lakehouse, ambar…)	Veri akışının kendi deposuna; raporlar veri akışı bağlayıcısıyla okur
İşlem hattında adım olarak çalışma	Var (Dataflow Gen2 etkinliği)	Yok
Hızlı kopyalama (fast copy), izleme merkezi, ayrıntılı yenileme geçmişi	Var	Yok
Veri akışı bağlayıcısıyla DirectQuery	Yok; bunun yerine çıkış tablosuna doğrudan bağlanılır	Var
Zamanlanmış ve artımlı yenileme, dağıtım işlem hatları	Var	Var
Durum	Önerilen yol; Nisan 2026’dan beri yeni öğeler Git ve CI/CD desteğiyle oluşturuluyor	Eski (legacy) durumda: çalışmaya devam ediyor, yeni özellik gelmiyor

Gen1 kapanıyor mu?Microsoft Learn’e göre şu an Gen1’i kaldırma planı yok. Fabric erişimi olan kapasitelerde Gen2 öneriliyor. Pro ve PPU kullanıcıları için Gen1 desteklenmeye devam ediyor. Gen1 öğelerini kimliğini, adını ve zamanlamasını koruyarak yükselten bir sihirbaz var, ama önizleme aşamasında. Geçişten önce Learn’deki geçiş sayfasını kontrol et.

Gen2 yayımlandığında çalışma alanında DataflowsStagingLakehouse ve DataflowsStagingWarehouse gibi sistem öğeleri görebilirsin. Bunlar ara (staging) depolardır, dokunman gerekmez.

Çıkış hedefleri: veriyi nereye bırakacaksın?

Gen2’de her sorgu için bir veri hedefi (data destination) seçersin. Learn’in listesinde Fabric lakehouse tabloları ve dosyaları, Fabric ambarı, Fabric KQL veritabanı, Fabric SQL veritabanı, Azure SQL, Azure Data Explorer, ADLS Gen2, SharePoint dosyaları, Snowflake ve PostgreSQL var.

Değiştir (Replace): Her yenilemede hedefteki veri silinir, yerine yeni sonuç yazılır. Boyut tabloları için tipik seçim.
Ekle (Append): Her yenilemede sonuç mevcut tablonun sonuna eklenir. Günlük satış dosyası gibi biriken veride kullanılır. KQL veritabanı ve Azure Data Explorer yalnızca Ekle’yi destekler.
Otomatik ayarlar: Yeni tablolarda varsayılan olarak açıktır (lakehouse, Azure SQL ve Snowflake için). Sütun eklediğinde eşlemeyi kendisi günceller ve tabloyu gerekirse yeniden oluşturur. Dikkat: tablo yeniden oluşturulunca üzerine kurduğun ilişkiler gidebilir.

Ekle + yeniden çalıştırma = çift kayıtEkle yöntemiyle çalışan bir veri akışını aynı gün iki kez elle çalıştırırsan o günün satırları iki kez yazılır. Ya Değiştir kullan ya da veri akışında “yalnızca son günü al” filtresiyle ve hedefte tekrar kontrolüyle çalış.

Hazırlık nerede yapılmalı?

Aynı temizliği üç yerde yapabilirsin. Hangisinin doğru olduğu, kimin kullanacağına ve verinin nerede durduğuna bağlıdır.

Yer	Ne zaman doğru?	Zayıf yanı
Modeldeki Power Query	Tablo yalnızca bu modelde kullanılıyor; küçük ve hızlı bir proje	Başka model aynı temizliği tekrar yazar
Veri akışı (Gen2)	Aynı tabloyu birden çok model kullanıyor; ekip Power Query biliyor; kaynak şirket içinde (ağ geçidi)	Çok büyük hacimde Spark ya da SQL kadar hızlı olmayabilir
SQL görünümü (ambar ya da SQL analiz uç noktası)	Veri zaten ambarda; mantık birkaç birleştirme ve filtre; SQL bilen ekip bakım yapacak	Direct Lake modelde görünüm kullanmak DirectQuery’ye geri dönüşe yol açabilir (“Kurumsal model” dersi)

Kural olarak: dönüşümü verinin olduğu yere en yakın ve en çok kişinin yararlanacağı katmanda yap. Anadolu Market’te ürün ve müşteri temizliği veri akışına, iptalleri ayıklayan “net satış” mantığı ise ortak anlam modeline gider.

Paylaşılan anlam modeli ve canlı bağlantı

Veri katmanı ortaklaştıktan sonra ikinci adım, ölçüleri de ortaklaştırmaktır. Bir anlam modeli bir kez yayımlanır; diğer analistler Desktop’ta Veri al → Power BI anlam modelleri ile ona bağlanır. Bu bağlantıya canlı bağlantı (live connection) denir.

Bağlanmak için modelde Derleme (Build) izni gerekir. İzin çalışma alanında ya da uygulama paylaşılırken verilir.
Canlı bağlı raporda modeli değiştiremezsin: yeni tablo, sütun ya da ilişki ekleyemezsin. Ama rapor düzeyi ölçü, görsel hesaplama ekleyebilirsin.
Modelin RLS kuralları canlı bağlı raporda da çalışır.
Güvenilir modeller tanıtılmış (promoted) ya da sertifikalı (certified) olarak işaretlenir. Kimin onaylayabildiği “Yönetişim” dersinde anlatılıyor.

Rapor düzeyi ölçü, modeldeki hazır ölçüleri kullanmalıdır. Pazarlama ekibi “sipariş başına brüt kâr” istiyor. Ortak modelde [Brüt Kâr] ve [Sipariş Sayısı] zaten var; sıfırdan SUM yazmak yerine onları kullan:

Sipariş Başı Kâr =
DIVIDE([Brüt Kâr], [Sipariş Sayısı])

Bu modelde sonuç yaklaşık 544 ₺ (456.108 ₺ brüt kâr, 838 sipariş). İptal kuralı değişirse bu ölçü de kendiliğinden doğru kalır, çünkü kural tek yerde, [Net Satış] içinde.

Model mi değişmeli, rapor mu?Bir rapor düzeyi ölçü üç rapora kopyalanmaya başladıysa, model sahibine onu ortak modele taşımasını öner. Rapor düzeyi ölçü tek bir raporun ihtiyacı içindir.

İnce rapor (thin report) deseni

Ekipler büyüyünce model ve raporlar ayrılır:

Model çalışma alanı: Tek bir .pbix (ya da .pbip) içinde yalnızca model: tablolar, ilişkiler, ölçüler, RLS. Raporu yok ya da yalnızca test sayfası var. Bunu veri ekibi yönetir.
Rapor çalışma alanları: Her rapor bu modele canlı bağlı, kendi modeli olmayan bir dosyadır. Buna ince rapor denir. Satış, finans ve pazarlama ayrı raporlar yazar ama sayılar aynı modelden gelir.

Kazanç: model bir kez yenilenir, kapasite bir kez harcanır, “hangi sayı doğru?” tartışması biter. Bedel: model sahibi değişiklik yaparken bağlı raporları düşünmek zorundadır. Bunun için etki analizi ve soy (lineage) görünümü kullanılır; .pbit şablonları, .pbids veri kaynağı dosyaları ve PBIP ile Git akışı “Yaşam döngüsü” dersinde ayrıntılı anlatılıyor.

Canlı bağlantıdan bileşik modeleİnce raporda kendi Excel dosyanı da eklemek istersen, canlı bağlantıyı “Power BI anlam modellerine DirectQuery” ile bileşik modele çevirmen gerekir. Bu konu “Kurumsal model” dersinde.

Yenileme bağımlılıkları ve sıra

Anadolu Market’in gece akışı şöyle: ERP’den satış dosyası gelir → ürün ve satış veri akışları çalışır → anlam modeli yenilenir → raporlar ve abonelik e-postaları güncel veriyi gösterir. Sıra bozulursa model eski veriyle yenilenir ve sabah herkes dünün rakamını görür.

Saate göre zincir (kırılgan): Veri akışı 02:00’de, model 03:00’te. Veri akışı bir gece 70 dakika sürerse model eski veriyi alır ve kimse fark etmez.
Olaya göre zincir (sağlam): Fabric işlem hattında Dataflow Gen2 etkinliği → Anlam modeli yenileme (semantic model refresh) etkinliği. Yenileme etkinliği varsayılan olarak işin bitmesini bekler; bir adım hata verirse sonraki çalışmaz ve hata bildirimi gönderilebilir. Ayrıntı “Fabric’te veriyi hazırlamak” dersinde.
Direct Lake modelde veri kopyalanmadığı için “yenileme” yalnızca çerçevelemedir (framing); yine de veri akışı bittikten sonra yapılmalıdır.

Sırayı ne kadar iyi kurarsan kur, raporda bir tazelik göstergesi olsun. En basit hâli, olgu tablosundaki en son tarihin bir referans tarihten kaç gün geride olduğunu söyler. Bu uygulamanın verisi 31.12.2024’te bittiği için referans olarak o günü kullanıyoruz; gerçek bir modelde yerine TODAY() ya da yenileme günlüğünden gelen tarih yazılır.

EVALUATE
SUMMARIZECOLUMNS(
    Kategoriler[Kategori],
    "Son Satış", MAX(Satislar[Tarih]),
    "Gecikme (gün)", DATEDIFF(MAX(Satislar[Tarih]), DATE(2024, 12, 31), DAY)
)

Sonuçta altı kategori 0 ya da 1 gün geride, Hediye ise 16 gün (son satış 15.12.2024). Bu bir veri hatası olmayabilir; belki o kategoride gerçekten satış yoktur. Ama göstergeyi gören kişi soruyu sorar, rakamı körü körüne kullanmaz.