Performance & Scalability serimizin bir parçası
Tam kılavuzu okuyunPower BI'da Artımlı Yenileme: Büyük Veri Kümelerini Verimli Bir Şekilde Kullanma
Her Power BI uygulaması sonunda aynı duvara çarpıyor: Veri kümesi, tam yenilemelerin çok uzun sürmesine, çok fazla kaynak tüketmesine ve kullanıcıların verilere ihtiyaç duymasından önce mevcut olan zaman pencerelerinin aşılmasına neden olacak kadar büyüyor.
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
- 10'dan fazla bölümle artımlı yenileme için Power BI Premium (veya Fabric) gereklidir
- 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: Artımlı yenileme, Power BI Pro (sınırlamalarla birlikte) ve Power BI Premium/Fabric'te (tam özellik) mevcuttur. Pro ile en fazla 10 yenileme periyodu yapılandırabilirsiniz. Premium bu sınırı kaldırır ve "veri değişikliklerini algıla" özelliğini ekler.
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):
| Parametre | İsim | Tür | Değer |
|---|---|---|---|
| Aralık Başlangıcı | AralıkBaşlangıcı | Tarih/Saat | Herhangi bir tarihi tarih |
| Aralık Sonu | Aralık Sonu | Tarih/Saat | Güncel tarih |
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: (Yalnızca Premium) Hangi geçmiş bölümlerin verileri değiştirdiğini tespit etmek için ayrı bir tarihsaat sütunu (genellikle "son değiştirilme" sütunu) kullanır ve yalnızca bu bölümleri yeniden işler.
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
Premium'daki "Veri değişikliklerini algıla" seçeneği başka bir verimlilik katmanı ekler. Geçmiş bölümdeki herhangi bir kaydın güncellenip güncellenmediğini belirlemek için belirlenmiş bir sütunu (genellikle bir last_modified_date sütunu) sorgulayarak çalışır. Yalnızca verilerin gerçekten değiştiği bölümler yenilenir.
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:
| Sorun | Belirti | Çözünürlük |
|---|---|---|
| Sorgu katlama bozuk | Her döngüde tam yenileme, yavaş yenileme süreleri | Katlamayı geri yüklemek için Power Query'yi yeniden düzenleyin |
| Tarihsaat sütununda eksik dizin | Yavaş bölüm yenileniyor | Kaynak veritabanına dizin ekle |
| Kaynak veri değişiklikleri yakalanamadı | Geçmiş bölümlerde eski veriler var | Veri değişikliklerini algılamayı etkinleştirin veya geçiş penceresini genişletin |
| Bölüm sayısı sınırı aşıyor | 10 bölümden sonra yenileme başarısız oluyor (Pro) | Premium veya Fabric'e Yükseltme |
| Saat dilimi uyuşmazlığı | Her bölümde yanlış kayıtlar | RangeStart/RangeEnd'in UTC kullandığından emin olun |
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?
Artımlı yenileme, Power BI Pro (10 yenileme dönemiyle sınırlıdır), Kapasite Başına Power BI Premium, Kullanıcı Başına Power BI Premium (PPU) ve Microsoft Fabric kapasitelerinde kullanılabilir. "Veri değişikliklerini algılama" özelliği ve hibrit tablolar Premium veya Fabric gerektirir. 10'dan fazla geçmiş bölüme sahip çoğu kurumsal uygulama için Premium veya Fabric gereklidir.
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.
Yazan
ECOSIRE Research and Development Team
ECOSIRE'da kurumsal düzeyde dijital ürünler geliştiriyor. Odoo entegrasyonları, e-ticaret otomasyonu ve yapay zeka destekli iş çözümleri hakkında içgörüler paylaşıyor.
İlgili Makaleler
Building Financial Dashboards with Power BI
Step-by-step guide to building financial dashboards in Power BI covering data connections to accounting systems, DAX measures for KPIs, P&L visualisations, and best practices.
Case Study: Power BI Analytics for Multi-Location Retail
How a 14-location retail chain unified their reporting in Power BI connected to Odoo, replacing 40 spreadsheets with one dashboard and cutting reporting time by 78%.
GoHighLevel + Power BI: Advanced Reporting and Analytics
Connect GoHighLevel to Power BI for advanced marketing analytics. Build executive dashboards, track multi-channel ROI, and create automated reports that go beyond GHL's native reporting.
Performance & Scalability serisinden daha fazlası
k6 Load Testing: Stress-Test Your APIs Before Launch
Master k6 load testing for Node.js APIs. Covers virtual user ramp-ups, thresholds, scenarios, HTTP/2, WebSocket testing, Grafana dashboards, and CI integration patterns.
Nginx Production Configuration: SSL, Caching, and Security
Nginx production configuration guide: SSL termination, HTTP/2, caching headers, security headers, rate limiting, reverse proxy setup, and Cloudflare integration patterns.
Odoo Performance Tuning: PostgreSQL and Server Optimization
Expert guide to Odoo 19 performance tuning. Covers PostgreSQL configuration, indexing, query optimization, Nginx caching, and server sizing for enterprise deployments.
Odoo vs Acumatica: Cloud ERP for Growing Businesses
Odoo vs Acumatica compared for 2026: unique pricing models, scalability, manufacturing depth, and which cloud ERP fits your growth trajectory.
Testing and Monitoring AI Agents in Production
A complete guide to testing and monitoring AI agents in production environments. Covers evaluation frameworks, observability, drift detection, and incident response for OpenClaw deployments.
Compliance Monitoring Agents with OpenClaw
Deploy OpenClaw AI agents for continuous compliance monitoring. Automate regulatory checks, policy enforcement, audit trail generation, and compliance reporting.