Canlı View’lar ile Analitik Rapor Olmaz: Operasyonel ve Analitik Veri Ayrımı

Geçtiğimiz günlerde bir paydaşımızdan, yavaşlayan bir dashboard için tanıdık bir talep geldi: “Rapor çok yavaş açılıyor, veri tarihçesini 6 aydan 4 aya düşürsek hızlanır mı?”

Bu soru, veri dünyasının en klasik “bypass” yöntemlerinden biridir. Cevabım ise netti: “Veriyi azaltarak bu günü kurtarırız, ama mimariyi değiştirmezsek yarını kaybederiz.”

Bir raporun yavaşlaması genellikle veri hacmiyle (Volume) ilişkilendirilir, ancak asıl suçlu çoğu zaman veri erişim modelidir (Velocity & Variety). Özellikle karmaşık forecast ve histogram analizleri içeren raporları, doğrudan operasyonel sistemin canlı View’ları (Görünümleri) üzerine inşa etmek, otoyolda bisikletle gitmeye benzer.

Gelin, neden “Canlı View” ile “Analitik Rapor” yapılamayacağını ve çözümün neden bir DBA ayarı değil, bir mimari karar olduğunu teknik olarak inceleyelim.

Sorun: View Bir Tablo Değildir
Yazılım ve veri ekiplerinin sıkça düştüğü bir yanılgı var: View’ları tablo gibi davranan yapılar sanmak. Oysa bir View, veriyi saklamaz; sadece sorguyu saklar.

Power BI veya benzeri bir araç, “Histogramic Dashboard” gibi karmaşık bir raporu yenilemek istediğinde, arkada bağlı olduğu 8 farklı SAP BW veya SQL View’ını aynı anda tetikler.

Bu şu anlama gelir:

Rapor her açıldığında veritabanı o sorguları sıfırdan hesaplar.
Joinler, Group By işlemleri, hesaplamalar anlık (on-the-fly) yapılır.
Eğer rapor analitik bir amaç taşıyorsa (Forecast vb.), veritabanı operasyonel işini bırakıp sizin analitik yükünüzü hesaplamaya çalışır.
Sonuç? Timeout. Burada tarih aralığını 6 aydan 4 aya düşürmek, sadece sorgunun süresini 10 saniye kısaltır ama mimari tıkanıklığı (bottleneck) çözmez. Veri 2 ay sonra tekrar büyüdüğünde, aynı sorunla tekrar masaya oturursunuz.
Mimari Ayrım: OLTP vs. OLAP

Melike Hanım ile olan yazışmamızda vurguladığım kritik bir ayrım vardı: “Bu rapor operasyonel bir rapor değil, analitik bir rapordur.”

Operasyonel Rapor (OLTP): “Şu an stokta kaç ürün var?” sorusuna cevap verir. Canlı olması gerekir. Basittir. View üzerinden okunabilir.
Analitik Rapor (OLAP): “Geçen 6 ayın stok hareketlerine göre gelecek ay tahmini ne?” sorusuna cevap verir. Tarihçe gerektirir. Karmaşıktır. Asla canlı View üzerinden okunmamalıdır.
Siz analitik bir yükü (Forecast), operasyonel bir zeminde (Canlı View) koşmaya çalışırsanız, sistemin sürdürülebilirliği kalmaz.

Çözüm: ETL ve Katmanlı Mimari
Veri mühendisliğinde altın kural şudur: “Write Once, Read Many” (Bir kere yaz, bin kere oku).

Canlı View’larda ise biz her raporda “Read and Calculate Every Time” (Her seferinde oku ve hesapla) yapıyoruz. Kaynak israfı tam olarak budur.

Bu sorunun çözümü DBA’in veritabanına indeks atması veya RAM artırması değildir. Çözüm, verinin akış yolunu değiştirmektir:

Stage Katmanı: Veri, canlı sistemden belirli aralıklarla (ETL) ham haliyle alınır. Operasyonel sistemin yükü hafifler.
DWH / Data Mart Katmanı: Veriler burada modellenir (Star Schema). Hesaplamalar, joinler burada fiziksel tablolara yazılır.
Reporting Katmanı: Power BI, artık karmaşık hesaplamalarla uğraşan View’lara değil, sonucu hazır olan tablolara gider.
Bu mimaride raporun 6 aylık veya 2 yıllık veriye bakması performansı dramatik şekilde etkilemez. Çünkü hesaplama zaten yapılmıştır, raporlama aracı sadece sonucu gösterir.

Sonuç: Teknik Borcu Yönetmek
“Tarihi kısaltalım hızlansın” yaklaşımı, teknik borcun faizini ödemektir. Borcu kapatmak ise mimariyi düzeltmekten geçer.

Eğer organizasyonunuzda raporlar sürekli “timeout”a düşüyorsa, veriyi azaltmayı değil, veriye nasıl eriştiğinizi sorgulayın.

Unutmayın; bir veri projesinde performans sorunu varsa, %20 ihtimalle donanım, %80 ihtimalle mimari suçludur.