POWER QUERY KURUMSAL YENİLEME

Power Query PQ teal logosu yanında dairesel yenileme oku sembolü ve digital saat ibresi 03:00 zamanlı otomatik yenileme metaforu

Bir Power BI raporu Power Query ile veriye bağlanır; geliştiricinin makinesinde harika çalışır. Power BI servisine yayınlandıktan sonra rapor "veri yenileme başarısız" hatası verir. Kullanıcı pencereyi açar, "neden çalışmıyor" diye sorar. Bu sahne otomasyon yolculuğunun klasik bir adımıdır; lokal çalışma ile bulut yenilemesi arasındaki farkı anlamak kurumsal Power Query disiplininin temelidir.

Lokal ile Bulut Farkı

Power BI Desktop'ta veri kaynağına geliştirici hesabıyla bağlanılır; geliştirici izinleri var. Veri çekilir, dönüştürülür, modele yüklenir, rapor görüntülenir. Servise yayınlandıktan sonra ise yenileme zamanlanmış olarak çalışır; bu durumda kaynağa bağlanan kim, hangi izinleri var, nasıl bağlanılır soruları öne çıkar.

Çoğu kurumsal veri kaynağı (SQL Server, SharePoint, on-premises dosyalar) buluttan doğrudan erişilemez. Power BI servisinin bu kaynaklara ulaşması için On-premises Data Gateway adı verilen bir köprü kurulur. Gateway şirket ağında bir makinede çalışır; servis taleplerini alır, ağ içinde veri kaynağından çeker ve servise döndürür. Bu yapı kurulmadan yenileme çalışmaz.

Gateway Kurulumu

Gateway makinası şirket ağındaki bir sunucu veya iş istasyonudur. Sürekli açık olması, ağa stabil bağlantısı olması ve veri kaynaklarına erişebilmesi gerekir. Bir kullanıcının kişisel bilgisayarı gateway için uygun değildir; o makine kapalıyken yenileme çalışmaz. Tipik kurumsal kurulum birden çok gateway'i bir küme (cluster) olarak çalıştırır; biri çökerse diğerleri yenilemeleri devralır.

Gateway kurulumu sırasında dikkat edilmesi gereken nokta hesap yönetimidir. Gateway servisi bir hizmet hesabıyla çalışır; bu hesabın veri kaynaklarına erişim yetkisi olur. Tek tek bireysel kullanıcı hesabı kullanmak ölçeklenmez; iyi pratik adanmış bir hizmet hesabı kullanmaktır.

Sol tarafta bulut sembolü Power BI servisi ortada gateway köprü kutusu sağda şirket ağı veritabanı silindiri çift yönlü oklarla bağlı mimari

Yenileme Zamanlaması

Power BI servisinde dataset settings altında yenileme zamanlaması ayarlanır. Standart Pro lisansta günlük sekiz adede kadar yenileme mümkündür; Premium lisansta sınır kalkar. Yenileme saatleri iş gereksinimine göre seçilir; çoğu raporda gece bir yenileme yeterlidir.

Zamanlamada yaygın hata tüm yenilemeleri aynı saate koymaktır; gece 02:00'a kalan yirmi sorgu gateway'i aşırı yükler ve bazıları başarısız olur. İyi pratik yenilemeleri zaman içine dağıtmaktır; saat başına birkaç yenileme tipik bir kapasite sınırıdır.

Tipik bir kurumsal gece yenileme planı şu şekilde dağıtılır:

SaatDatasetSüre (Tahmini)
00:30Satış (incremental refresh)3 dk
01:00Finans Kapanış8 dk
02:00İK Personel Özet2 dk
03:00Üretim OEE12 dk
04:30Müşteri Dimension Dataflow5 dk
05:00Yönetim Özet Paneli (dataflow'a bağlı)2 dk

Incremental Refresh

Büyük veri setleri için tam yenileme her seferinde tüm geçmişi yeniden çeker; bu hem yavaş hem maliyetlidir. Incremental refresh sadece değişen bölümü yeniler; geçen ayın verisi sabittir, sadece son birkaç günü yenilemek yeterlidir. Bu özellik milyonlarca satırlı tabloları dakikalar yerine saniyelerde yeniler.

Incremental refresh kurulumu Power BI Desktop'ta yapılır. Tarih parametreleri tanımlanır (RangeStart, RangeEnd), tablo bu parametrelere göre filtrelenir, sonra Incremental Refresh policy uygulanır. Servis tarafında ilk yenilemede tüm geçmiş yüklenir; sonraki yenilemeler sadece son bölümü günceller.

Yenileme İzleme

Kurumsal yenileme akışında izleme kritiktir. Power BI servisinde dataset refresh history her başarılı ve başarısız yenilemeyi listeler. Başarısız olanlara tıklandığında hata mesajı görünür. Bu görünüm tek başına yetmez; yöneticilerin de bilgi alması gerekir.

Servis ayarlarından yenileme başarısızlık bildirimi açılır; başarısız yenileme olduğunda belirli e-posta adreslerine uyarı gönderilir. Daha ileri ayrıntılar Power Query resmi belgelerinde ele alınır. Daha gelişmiş izleme için Power Automate ile özel akışlar kurulur; başarısızlık olduğunda Teams kanalına bildirim, log tablosuna kayıt, gerekirse hızlı yeniden deneme yapılır.

Hata Senaryoları

Yenileme hatalarının en yaygın sebepleri şunlardır:

  • Kimlik bilgilerinin süresinin dolması (kullanıcı şifresi değişti)
  • Gateway'in offline olması (makine kapandı, servis durdu)
  • Veri kaynağı sunucusunun erişilemez olması (bakım, ağ sorunu)
  • Kaynak yapısında beklenmedik değişim (yeni kolon, isim değişikliği)
  • Veri tiplerinde dönüşüm hatası (sayı kolonunda metin değer)
  • Sorgu zaman aşımı (büyük veri, optimize edilmemiş sorgu)

Bunların her biri farklı çözüm gerektirir; hata mesajı doğru kaynaklığa yönlendirir.

Kimlik bilgileri sorunu özellikle yaygındır çünkü şifreler periyodik olarak değişir. Bu hatadan kaçınmanın yolu hizmet hesabı kullanmaktır; hizmet hesabının şifresi bireysel kullanıcı politikalarından bağımsızdır ve yöneticilerce kontrollü değişir. Bu yapı yenileme stabilitesini büyük ölçüde artırır.

Dataflow'lar

Power BI Dataflow'ları (Power Platform'da daha gelişmiş hali Dataverse Dataflow) Power Query mantığını servis tarafında tutar. Bir dataflow ortak veri dönüşümlerini bir kez yapar ve birden çok rapor bu sonuca bağlanır. Bu yapı her raporun aynı dönüşümü tekrar yapmasını önler ve performansı artırır.

Dataflow özellikle birden çok rapor aynı kaynağa bağlanıyorsa değerlidir. Müşteri tablosu, ürün tablosu, satış olayları gibi yaygın kullanılan dimension ve fact tabloları dataflow olarak tutulur; raporlar bu hazır veriyi tüketir.

Merkezde Dataflow kutusu Musteri Urun Satis tabloları aşağıya doğru üç ayrı Power BI rapor sayfasına dağıtılan dağıtım diyagramı

Sürüm Yönetimi

Power Query sorguları zamanla değişir; yeni dönüşümler eklenir, eski adımlar değişir. Bu değişikliklerin sürüm yönetimi yapılır; PBIX dosyaları kontrolsüz birikmemelidir. Tabular Editor veya XMLA endpoint kullanılarak veri seti yapısı dışa aktarılır ve sürüm kontrolüne alınır.

Daha basit yaklaşım her büyük değişiklik öncesi PBIX dosyasının arşivlenmesidir; tarih damgalı kopyalar saklanır. Bu yapı hata sonrası önceki sürüme dönüşü mümkün kılar.

Üretim Yayın Süreci

Üretim ortamına yeni bir veri seti veya değişiklik alınmadan önce test yapılır. Test geliştirme ortamında veya ayrı bir workspace'te yapılır; yeni veri seti gerçek kullanıcılarla pilot test edilir. Sorun çıkarsa düzeltilir; çıkmazsa üretime alınır.

Üretim yayını sırasında değişiklik notları hazırlanır; ne değişti, kim onayladı, ne zaman geri alınabilir bilgileri kayıt altına alınır. Bu disiplin denetim ve hatalı yayın durumunda kurtarma için kritiktir.

Kurumsal Power Query yenileme yapısı doğru kurulduğunda raporlama platformunun sessizce yaşaması mümkün olur. Power Query ve Power Pivot eğitimi bu yapıyı pratik örneklerle ele alır.

Sıkça Sorulan Sorular

On-premises Data Gateway şart mı?

Şirket ağındaki kaynaklara (SQL, SharePoint on-prem, dosya sunucusu) erişim için şart. Tamamen bulutta kaynak kullanılıyorsa (Azure SQL, SharePoint Online) gateway gerekmez.

Gateway'i kişisel mod (personal) kullanmak doğru mu?

Hayır, kişisel mod sadece kişisel raporlar için. Kurumsal ortamda mutlaka standart (enterprise) mod kullanılır; bu mod birden çok kullanıcı ve raporla çalışır.

Yenileme kaç defa başarısız olabilir?

Power BI servisi dört defa başarısız yenileme sonrası bildirim gönderir ve zamanlamayı duraklatır. Sahibin müdahale etmesi gerekir; aksi halde rapor güncellenmeden kalır.

Incremental refresh Pro lisansta var mı?

Evet, ama Premium kapasitenin tüm özelliklerine sahip değildir. Refresh yapılır ama bazı gelişmiş özellikler (XMLA endpoint, partition yönetimi) Premium gerektirir.

Dataflow Power Apps tarafında da kullanılabilir mi?

Power Apps tarafında Dataverse dataflow'lar var. Power BI dataflow'ları Power BI ile sınırlıdır. İki yapı entegre çalışabilir ama farklı amaçlara hizmet eder.

Yenileme zamanlaması yetmeyince ne yapmalı?

Pro lisansta günde 8 yenileme sınırı vardır. Daha sık gerekiyorsa Premium kapasite veya Premium Per User lisansa geçmek gerekir; saatlik veya gerçek zamanlı yenileme bu seviyelerde mümkündür.