Power BI'da Artımlı Yenileme: Büyük Veri Kümelerini Verimli Bir Şekilde Kullanma

Her 4 saatte bir tamamen yenilenen 50 milyon satırlık bir işlem tablosu yalnızca uzun zaman almakla kalmaz, aynı zamanda değişmeyen verileri yeniden yükleyerek kaynakları boşa harcar. Artımlı yenileme, değişmeyen geçmiş verileri korurken yalnızca yeni ve değiştirilmiş kayıtları yükleyerek bu sorunu çözer. Doğru şekilde yapıldığında, daha önce yenilenmesi 3 saat süren bir veri kümesi, 10 dakikadan kısa bir sürede güncel hale getirilebilir.

Bu kılavuz, uygulamaları bozan yaygın hatalar ve bunları üretim açısından güvenilir kılan en iyi uygulamalar da dahil olmak üzere, Power BI'da ilk ilkelerden gelişmiş yapılandırmaya kadar artımlı yenilemeyi kapsar.

Önemli Çıkarımlar

• Artımlı yenileme, veri kümelerini tarihe göre bölümlere ayırır, her yenileme döngüsünde yalnızca en son verileri yükler
• Olgu tablosunda bir tarihsaat sütunu ve iki Power Query parametresi (RangeStart, RangeEnd) gerektirir
• Geçmiş veriler, ilk yüklemeden sonra hiçbir zaman yeniden sorgulanmayan eski bölümlerde tutulur
• Standart artımlı yenileme Power BI Pro'yu destekler; gerçek zamanlı DirectQuery bölümü eklemek için desteklenen bir Premium, PPU veya Gömülü model gerekir.
• Veri değişikliklerini algıla seçeneği yalnızca verilerin değiştiği bölümleri yenileyerek işlemeyi daha da azaltır
• Hibrit tablolar (içe aktarma ve DirectQuery'yi birleştirerek), geçmiş içe aktarma bölümlerinin yanı sıra gerçek zamanlı verilere olanak tanır
• Doğru yapılandırma, Power Query katlamanın anlaşılmasını gerektirir — katlanamayan sorgular artımlı yenilemeyi bozar
• XMLA uç noktası ve üçüncü taraf araçlar aracılığıyla bölüm sağlığının izlenmesi sessiz arızaları önler

---

Artımlı Yenileme Nasıl Çalışır?

Artımlı yenilemeyi anlamak, Power BI'ın verileri nasıl bölümlediğini anlamakla başlar.

Standart içe aktarma modelinde veri kümesinin tamamı tek bir bölümde bulunur. Her yenileme bu bölümü tamamen değiştirir. Küçük veri kümeleri için bu uygundur. Büyük tablolar için yukarıda açıklanan sorunları yaratır.

Artımlı yenileme, olgu tablosunu her biri belirli bir tarih aralığını kapsayan birden çok bölüme ayırır:

• Bölüm 1: 2020-01-01 ila 2020-12-31 (tarihsel, hiçbir zaman yenilenmedi)
• Bölüm 2: 2021-01-01 ila 2021-12-31 (tarihsel, hiçbir zaman yenilenmedi)
• Bölüm 3: 2022-01-01 ila 2022-12-31 (tarihsel, hiçbir zaman yenilenmedi)
• Bölüm 4: 2023-01-01 ila 2023-12-31 (tarihsel, hiçbir zaman yenilenmedi)
• Bölüm 5: 2024-01-01 ila 2024-12-31 (aylık olarak yenilenir)
• Bölüm 6: 2025-01-01 - 2025-03-31 (günlük olarak yenilenir)
• Bölüm 7: 2025-04-01'den güncele (saatte bir veya talep üzerine yenilenir)

Her zamanlanmış yenilemede yalnızca en yeni bölümler (bu örnekte 5, 6 ve 7) işlenir. Tarihsel bölümler ilk yüklendikleri andan itibaren bozulmadan kalır. Bu, yenileme döngüsünün toplam verinin yalnızca bir kısmını işlediği anlamına gelir; bu da süreyi, belleği ve kaynak sistem yükünü önemli ölçüde azaltır.

---

Önkoşullar ve Gereksinimler

Artımlı yenilemeyi yapılandırmadan önce şu önkoşulların karşılandığını doğrulayın:

Lisanslama: Power BI Pro, her yenileme için iki saatlik süre sınırıyla artımlı yenilemeyi destekler. Kapasiteyi model boyutuna, iş yüküne ve gerekli özelliklere göre seçin. Microsoft gereksinimleri.

Tarihsaat sütunu: Olgu tablosunda, Power BI'ın verileri bölümlemek için kullanacağı bir tarihsaat sütunu bulunmalıdır (bir tarih anahtarı tamsayı değil; gerçek bir tarihsaat türü olmalıdır). Bu genellikle işlem tarihi, olay zaman damgası veya oluşturulduğu tarih sütunudur.

Sorgu katlama: Olgu tablosunu yükleyen Power Query sorgusu, sorgu katlamayı desteklemelidir; bu, Power Query dönüştürme adımlarını kaynak sistemin yürüttüğü bir kaynak sorguya (SQL vb.) çevirme yeteneğidir. Sorgu katlama bozulursa artımlı yenileme sessizce başarısız olur; her yenilemede tüm verileri yükler ve amacı boşa çıkarır.

Kaynak sistemi desteği: Kaynağın, tarih aralığı filtrelemeyi verimli bir şekilde desteklemesi gerekir. Tarihsaat sütununda dizini olmayan bir kaynak tablo, artımlı yenileme yapılandırılmış olsa bile yavaş yenilemeler üretecektir çünkü her bölüm yenilemesi, tarih aralığındaki kayıtları bulmak için tam tablo taraması yapacaktır.

---

Adım Adım Yapılandırma

1. Adım: Gerekli Power Query parametrelerini oluşturun

Power BI Desktop'ta Power Query Düzenleyicisi'ni açın. Parametreleri Yönet → Yeni Parametre seçeneğine gidin.

Tam olarak aşağıdaki gibi iki parametre oluşturun (adlar büyük/küçük harfe duyarlıdır ve tam olarak eşleşmelidir):

Bu parametreler Tarih değil Tarih/Saat türünde olmalıdır. Çalışma zamanında Power BI'ın yenileme motoru tarafından geçersiz kılınırlar ancak geliştirme ve test için geçerli varsayılan değerlere ihtiyaçları vardır.

2. Adım: Bu parametreleri kullanarak olgu tablosunu filtreleyin

Power Query Düzenleyicisi'nde olgu tablonuzu seçin. Parametreleri kullanarak tarihsaat sütununa bir filtre uygulayın:

= Table.SelectRows(Source, each [TransactionDate] >= RangeStart and [TransactionDate] < RangeEnd)

Bu filtreleme adımı kritik öneme sahiptir: veri kaynağına katlanması gerekir. Katlamayı doğrulamak için son sorgu adımına sağ tıklayın ve "Yerel Sorguyu Görüntüle" seçeneğinin mevcut olup olmadığını kontrol edin. Gri renkteyse katlama bozulmuş demektir; bunun üzerindeki hangi dönüşüm adımlarının katlama zincirini kırdığını araştırın.

3. Adım: Sorgu katlamayı doğrulayın

Sorgu katlamanın en yaygın nedenleri şunlar olabilir:

• SQL'e çevrilemeyen özel işlevler
• Birinin veya her ikisinin de katlanmadığı iki sorguyu birleştirme (birleştirme)
• Belirli metin dönüştürme işlevleri (Text.Upper, Text.PadStart)
• Liste işlemlerini kullanma (List.Contains)
• Bir dizin sütunu ekleme
• Belirli tür dönüştürme işlemleri

Katlama bozulursa sorunlu işlemleri tarih filtresinden sonraki bir adıma aktarmak için sorguyu yeniden düzenleyin veya dönüşümü Power Query yerine kaynak veritabanındaki bir görünümde gerçekleştirin.

4. Adım: Artımlı yenileme ilkesini yapılandırın

Power BI Desktop'ta Alanlar bölmesindeki olgu tablosuna sağ tıklayın → Artımlı Yenileme.

Yapılandırma seçenekleri:

• Satırları son N takvim yılı/ayı/gününde saklayın: Bu, modelde tutulan toplam geçmiş pencereyi tanımlar. Bundan daha eski veriler modelden otomatik olarak kaldırılır (bırakılan bölümler).

• Yalnızca son N takvim yılında/ayında/gününde satırları yenile: Bu, her döngüde yeniden yenilenen kayan pencereyi tanımlar. Bu pencereden daha eski olan veriler geçmişe ait (değişmez) olarak değerlendirilir ve bir daha asla yenilenmez.

• Veri değişikliklerini algıla: Yapılandırılmış artımlı yenileme aralığında değişmeyen dönemleri atlamak için ayrı bir denetim tarihsaat sütunu kullanın.

5 yıllık geçmişe sahip işlemsel veritabanı için örnek yapılandırma:

• Son 5 yıldaki satırları saklayın
• Yalnızca son 3 gündeki satırları yenileyin

Bu, 5 yıllık verileri kapsayan bölümler oluşturur, ancak her döngüde yalnızca son 3 günün bölümleri yenilenir.

5. Adım: Yayınlayın ve doğrulayın

Raporu Power BI hizmetinde yayımlayın. Yayınlamadan sonraki ilk yenileme, sonraki yenilemelerden daha uzun sürer; tüm geçmiş verileri yükler ve tüm bölümleri ilk kez oluşturur. Bu bekleniyor.

---

Gelişmiş Yapılandırma: Veri Değişikliklerini Algıla

Değişiklik tespiti eski arşivlenmiş bölümleri otomatik olarak yenilemez. Yenileme penceresinin dışındaki geç değişikliklerin ne kadar ele alınacağını tanımlayın. Microsoft yapılandırması.

Veri değişikliklerini algılamadan: Son 3 günde hiçbir veri değişmese bile 3 günlük geçiş aralığı her zaman yenilenir.

Veri değişikliklerini tespit etme özelliğiyle: yenileme motoru, her bölümün işlenip işlenmeyeceğine karar vermeden önce kayan penceredeki herhangi bir kaydın değiştirilip değiştirilmediğini kontrol eder. Pazartesi gününün verileri Pazartesi gecesi yenilendiyse ve o zamandan beri hiçbir kayıt değiştirilmediyse Salı gecesinin yenilemesi Pazartesi bölümünü atlar.

Bu özellikle aşağıdaki senaryolar için değerlidir:

• Kaynak verileri bir kez yazılır ve nadiren güncellenir (değişmez salt ekleme olayları)
• Değişen zaman aralığı büyük (ör. 30 gün) ancak çoğu günde hiçbir değişiklik yok
• Kaynak sistem sorgu kapasitesi sınırlıdır

Veri değişikliklerini algıla sütununun kaynak veritabanında dizine eklenmesi gerekir; yenileme motoru, her yenileme döngüsünde her bölüm için bu sütunu sorgular.

---

Hibrit Tablolar: Gerçek Zamanlı + Geçmiş Veriler

Power BI Fabric/Premium, içeri aktarma modunun (geçmişsel bölümler) ve DirectQuery modunun (güncel veriler) güçlü bir birleşimi olan hibrit tabloları sunar. Bu, geçmiş içe aktarma verilerinin yanı sıra güncel dakikaya güncellenen verileri gösteren kontrol panellerini etkinleştirir.

Hibrit tablo yapılandırmasında:

• Geçmiş bölümler (dün ve daha eski) içe aktarma modundadır; hızlı, önbelleğe alınmış, tamamen toplanabilir
• Geçerli günün bölümü DirectQuery modundadır; sorgular kaynak veritabanında canlı olarak çalıştırılır

Kullanıcı deneyimi kusursuzdur; sorgular her iki modu da şeffaf bir şekilde kapsar. "Bu hafta ve geçen haftaki satışlar" sorgusu, dünün verilerini içe aktarma bölümünden ve bugünün verilerini DirectQuery aracılığıyla çekerek bunları tek bir sonuçta birleştirir.

Karma tablolarla ilgili hususlar:

• DirectQuery performansı tamamen kaynak veritabanı performansına bağlıdır; yavaş bir veritabanı, güncel sorguların yavaş olması anlamına gelir
• DirectQuery bölümü, içe aktarma modu optimizasyonlarından faydalanmaz (VertiPaq sıkıştırması yok, ön toplama yok)
• Premium veya Fabric çalışma alanı gerektirir

---

Artımlı Yenileme Sağlığını İzleme

Artımlı yenileme hataları genellikle sessizdir; bazı bölümler başarısız olsa veya tam yenilemeye geri dönse bile model "başarıyla yenilendi" olarak görünür. Üretim güvenilirliği için izleme şarttır.

XMLA uç nokta denetimi: Power BI Premium, SQL Server Management Studio (SSMS), Tablo Düzenleyici veya Azure Analiz Hizmetleri gibi araçların bağlanabileceği bir XMLA uç noktasını ortaya çıkarır. Buradan, her bölüm için son yenileme süresini ve herhangi bir bölümün hata durumunda olup olmadığını görmek için bölüm meta verilerini sorgulayabilirsiniz.

Tablo Düzenleyicisi 2 (ücretsiz): XMLA aracılığıyla Premium çalışma alanına bağlanın ve modeldeki bölüm tablosunu inceleyin. Her bölüm adını, tarih aralığını, son yenileme zaman damgasını ve durumunu gösterir. Bu, artımlı yenileme sorunlarını teşhis etmek için en pratik araçtır.

Power BI Etkinlik Günlüğü: Yönetici etkinlik günlüğü, hangi bölümlerin işlendiği ve hatalar da dahil olmak üzere yenileme işlemlerini kaydeder. Power BI REST API aracılığıyla kullanılabilir.

Yaygın hata modelleri:

---

Uygulamada Sorgu Katlama Doğrulaması

Sorgu katlama, artımlı yenilemenin vaat edilen performans kazanımlarını sağlayamamasının en yaygın nedenidir. Yaygın katlama kırılmalarını nasıl teşhis edip düzelteceğiniz aşağıda açıklanmıştır.

Test 1: Yerel Sorguyu Görüntüleme. Power Query'de RangeStart/RangeEnd filtre adımını ekledikten sonra adıma sağ tıklayın. "Yerel Sorguyu Görüntüle" mevcutsa ve tarih aralığını filtreleyen bir WHERE yan tümcesi içeren bir SQL sorgusu gösteriyorsa, katlama çalışıyor demektir.

Test 2: Oluşturulan SQL'i kontrol edin. Yerel sorgu şunun gibi bir şey içermelidir:

WHERE [TransactionDate] >= @RangeStart AND [TransactionDate] < @RangeEnd

WHERE yan tümcesi eksikse katlama bozulmuş demektir ve filtre, kaynaktan tüm veriler yüklendikten sonra Power Query'nin motorunda uygulanıyor demektir.

Katlamayı geri yükleme: Özel bir dönüşüm katlamayı bozarsa bunu tarih filtresi adımından sonra taşıyın veya dönüşümü kaynak veritabanındaki bir SQL görünümünde gerçekleştirin ve Power BI'ı tablo yerine görünüme bağlayın.

---

Sıkça Sorulan Sorular

Artımlı yenileme tüm veri kaynaklarında çalışır mı?

Artımlı yenileme, SQL Server, Azure SQL, PostgreSQL, Snowflake, BigQuery, Azure Synapse ve Databricks dahil olmak üzere sorgu katlamayı ve tarih aralığı filtrelemeyi destekleyen tüm veri kaynaklarıyla çalışır. Sorgu katlamayı desteklemeyen kaynaklarla (Excel dosyaları, düz CSV, bazı REST API'leri) iyi çalışmaz; bu durumlarda yine de tam yenileme gerekir. Katlanamayan kaynaklar için, Power BI bağlanmadan önce verileri bir SQL veritabanında hazırlamak önerilen geçici çözümdür.

Artımlı yenileme için hangi Power BI lisansı gereklidir?

Power BI Pro, standart artımlı yenilemeyi destekler. Gerçek zamanlı DirectQuery bölümleri Premium, PPU veya Embedded gerektirir. Plan seçmeden önce model sınırlarını, iş yükünü ve gerekli özellikleri kontrol edin. Microsoft gereksinimleri.

Artımlı yenileme, geç gelen verileri nasıl işler?

Geç gelen veriler (işlem tarihlerinden sonra gelen kayıtlar (örneğin, Ocak ayı veri ayıklamasına gelen bir Aralık işlemi), geç gelenleri yakalayacak kadar geniş bir sürekli yenileme penceresi ayarlanarak işlenir. Veriler 7 güne kadar geç ulaşabiliyorsa kayan pencerenin 14 güne ayarlanması, ilgili bölüm yeniden yenilendiğinde geç varışların yakalanmasını sağlar. Alternatif olarak, son değiştirilen sütuna sahip veri değişikliklerini tespit etme seçeneği, kayan pencere ayarından bağımsız olarak geç gelenleri yakalar.

Artımlı yenileme yalnızca olgularda değil, boyut tablolarında da çalışabilir mi?

Artımlı yenileme, büyük olgu tabloları için tasarlanmıştır ve bir tarihsaat filtre sütunu gerektirir. Çoğu boyut tablosu (ürünler, müşteriler, konumlar) uygun bir tarihsaat bölümü sütununa sahip değildir ve tam yenilemenin uygun olacağı kadar küçüktür. Yavaş yavaş değişen ve giderek büyüyen boyut tabloları (50 milyondan fazla satıra sahip müşteri tabloları) için alternatif bir yaklaşım, yakın zamanda değiştirilen kayıtları filtrelemek ve Power BI yerine veritabanı katmanında geçmiş saklamayı yönetmek için kaynak veritabanındaki SQL görünümlerini kullanmaktır.

Artımlı yenileme modelimde hangi bölümlerin bulunduğunu nasıl görebilirim?

En kolay yol, Tablo Düzenleyiciyi (ücretsiz sürüm 2) XMLA uç noktası aracılığıyla Power BI Premium çalışma alanınıza bağlamaktır. Tablolar → [tablonuz] → Bölümler altında, oluşturulan tüm bölümleri tarih aralıkları ve son işlenen zaman damgalarıyla birlikte göreceksiniz. SQL Server Management Studio (SSMS) ayrıca XMLA aracılığıyla bağlanır ve bölüm ayrıntılarını Object Explorer'da gösterir.

Artımlı yenileme yarı yolda başarısız olursa ne olur?

Yenileme işlemi yarıda başarısız olursa Power BI, başarısız olan bölümleri yeniden dener. Arızadan önce başarıyla tamamlanan bölümler yeniden işlenmez; yalnızca başarısız olan bölümler yeniden denenir. Bu yeniden deneme davranışı, artımlı yenilemenin geçici kaynak sistem kesintilerine karşı tam yenilemeye göre daha dayanıklı olduğu anlamına gelir. Bir bölüm sürekli olarak başarısız olursa, yeni bölümler normal şekilde yenilenmeye devam ederken bölüm başarıyla yüklenen son durumunda kalır.

---

Sonraki Adımlar

Artımlı yenileme, büyük işlemsel veri kümelerini işleyen tüm Power BI uygulamalarının temelini oluşturur. Doğru sorgu katlama, uygun kayan pencereler ve izleme ile başlangıçtan itibaren doğru bir şekilde yapmak, daha sonra pahalı yeniden planlamaya neden olan performans sorunlarını önler.

ECOSIRE'ın Power BI performans optimizasyon hizmetleri, büyük ölçekli kurumsal veri kümeleri için artımlı yenileme tasarımı ve uygulamasını içerir. Mevcut yenileme mimarinizi değerlendirmek ve optimizasyon fırsatlarını belirlemek için bizimle iletişime geçin.