Microsoft Fabric’te kapasite birimi (CU) nedir?

Fabric’in işlem gücü para birimi. Her SKU sabit bir CU bütçesi sağlar (F64, 64 CU verir) ve her işlem — bir rapor sorgusu, bir model yenilemesi, bir notebook çalıştırması, bir pipeline — bu ortak havuzdan CU-saniye tüketir. Faturanızı sağladığınız SKU belirlediğine göre, Fabric’te FinOps demek havuzu boşaltan şeyi yönetmek demektir.

Fabric SKU’mu ne zaman yükseltmeliyim?

Optimizasyondan sonra, onun yerine değil. Her SKU adımı maliyeti kabaca ikiye katlar; bir yenileme yığılmasını veya kontrolden çıkmış tek bir notebook’u karşılamak için alan satın almak mümkün olan en pahalı çözümdür. Zamanlamalar yayıldıktan, ağır öğeler iyileştirildikten ve ölü iş yükleri emekliye ayrıldıktan sonra bile kullanım oranı gün boyu yüksek kalıyorsa yükseltin — o gerçek büyümedir ve bir sonraki SKU doğru cevaptır.

Kapasitemi hangi ekibin tükettiğini görebilir miyim?

Microsoft araçlarıyla yalnızca dolaylı olarak: Capacity Metrics uygulaması öğe bazında tüketimi gösterir, öğeler de workspace’lere aittir. Workspace’leri ekiplere eşlemek ve geçmişi bir fatura dönemini kapsayacak kadar uzun tutmak size kalır — maliyet dağıtımının, workspace envanterine bağlanmış uzun vadeli ve öğe bazlı bir tüketim deposu gerektirmesinin sebebi budur.

Fabric FinOps: Kapasite Maliyeti Kontrolü

Fabric faturası tek satırdır: kapasite. Onu gerçekte belirleyen şey ise o kapasitedeki tüm workspace’lerde günde binlerce işlemdir — rapor sorguları, zamanlanmış yenilemeler, dataflow’lar, notebook’lar, pipeline’lar; hepsi aynı işlem havuzundan çeker. Fabric FinOps, finansın gördüğü tek sayıyı mühendisliğin kontrol ettiği binlerce işleme bağlama disiplinidir.

Beş dakikada CU ekonomisi

Fabric SKU’ları F2 → F2048 arasında gider; her biri o kadar kapasite birimi sağlar (F64 = 64 CU) ve her adım hem kapasiteyi hem maliyeti kabaca ikiye katlar.
Her işlem CU-saniye tüketir — interaktif olanlar (rapor sorguları) ve arka plandakiler (yenilemeler, dataflow’lar, notebook’lar) tek havuzu paylaşır.
Rezerve kapasite fiyatlandırması kullandıkça-öde modelinin kabaca %40 altındadır — ama yalnızca SKU gerçekten doğru boyuttaysa kazandırır.
Power BI Premium P-SKU’ları aynı F-SKU modeline yakınsadı; dolayısıyla bu hesap artık klasik Premium ortamlarını da kapsıyor.

Smoothing: fatura neden beklediğiniz anda sıçramaz?

Fabric tüketimi gerçekleştiği anda faturalandırmaz. İnteraktif işlemler kısa bir pencereye (dakikalar), arka plan işlemleri 24 saate yayılır — gece 03:00’teki iki saatlik bir yenileme, güne yayılmış ince bir tüketim katmanına dönüşür. Bu sizi anlık sıçramalardan korur, ama aynı zamanda “ne zaman ne çalıştı” üzerinden yapılan maliyet analizini, öğe bazlı tüketim verisi olmadan yanıltıcı hâle getirir: acı, sebebinden saatler sonra ortaya çıkar.

Maliyeti workspace ve ekiplere dağıtmak

Maliyet dağıtımı (hatta dürüst bir gösterim bile) Microsoft’un size bıraktığı üç birleştirmeyi gerektirir: tam bir fatura dönemi boyunca öğe bazlı CU tüketimi, öğe → workspace eşlemesi ve workspace → ekip sahipliği. Capacity Metrics uygulaması birincisini yaklaşık 14 gün verir; gerisi envanter işidir. Birleştirildiğinde asıl önemli sorular yanıtlanabilir hâle gelir: hangi workspace’ler en çok tüketiyor, ne kadarı arka plan yenilemesi ne kadarı interaktif kullanım, hangi ekibin ayak izi büyüyor.

Büyütmek mi, optimize etmek mi? Bir karar kuralı

Bir kapasite ısındığında pahalı refleks SKU’yu yükseltmektir. Tüketim yoğunlaşmışsa önce optimize edin — birkaç öğe baskınsa, yenilemeler aynı saate yığılmışsa, zombi model’ler kimse için yenileniyorsa. Tipik kazanımlar:

Zamanlanmış yenilemeleri ortak zirve saatten uzağa yayın.
Ağır model’leri tam yükleme yerine artımlı yenilemeye taşıyın.
Kullanılmayan raporları emekliye ayırın ve sahipsiz kalan model’lerinin yenilenmesini durdurun.
Geliştirme/test iş yüklerini üretim kapasitesinden ayırın veya doğru boyutlandırın.

Yoğunlaşma ortadan kalktıktan sonra kullanım oranı hâlâ yüksek kalıyorsa yükseltin — birçok sağlıklı öğeye yayılmış, süregelen yük gerçek büyümedir ve bir sonraki SKU, throttle olmuş bir kapasitenin kuruma maliyetinden ucuzdur.

Sürekli yaklaşım

PGR Sonar Fabric kapasite metriklerini uzun vadeli geçmiş olarak saklar — öğe bazında, işlem bazında, interaktif/arka plan ayrımıyla — ve workspace envanterine bağlar. Bu, FinOps’u iki haftada bir ekran görüntüsü alma alıştırmasından kalıcı yanıtlara dönüştürür: aylar boyunca sıralanmış en ağır öğeler, maliyet dağıtımı için workspace düzeyinde tüketim ve bir sonraki SKU’ya para vermeden önce iyileştirilmeye değer model’leri, dataflow’ları veya notebook’ları işaret eden Kapasite Teşhisi önerileri.

Fabric FinOps: Kapasite Maliyetlerini Anlamak ve Kontrol Etmek