Lineage, her BI ortamında karşınıza çıkan iki soruyu yanıtlar. İleri yönde: “bu veritabanını değiştirirsek ne bozulur?” — her taşıma veya kapatma öncesi gelen etki analizi sorusu. Geri yönde: “bu rakam gerçekte nereden geliyor?” — denetçilerin ve yöneticilerin sorduğu güven sorusu. Power BI ikisini de yanıtlayacak metadata’ya sahiptir; sadece size derli toplu vermez.
Power BI lineage’ının şekli
Zincir şudur: veri kaynağı → semantic model → rapor → uygulama kitlesi. Kritik incelik şu: standart raporların hiçbir bağlantısı yoktur — her şeyi model’lerinden devralırlar, dolayısıyla gerçek lineage model katmanında yaşar. Sayfalandırılmış raporlar istisnadır: doğrudan kaynaklara bağlanırlar ve ayrıca haritalanmaları gerekir. İki kuraldan birini kaçırırsanız lineage tablosu sessizce yanlış olur.
Yöntem 1 — Workspace lineage görünümü
Her workspace’in yerleşik bir lineage görünümü vardır: kaynaklardan model’lere, oradan rapor ve panolara uzanan görsel bir grafik. Tek bir workspace’i anlamak için gerçekten kullanışlıdır. Sınırları: her seferinde tek workspace, workspace’ler arası bağımlılıkların yalnızca uç olarak görünmesi, dışa aktarılamaması ve tenant genelinde “X sunucusuna dokunan her şey” diye arama yapılamaması.
Yöntem 2 — Datasource ve scanner API’leri
REST API’leri altta yatan gerçekleri açar — model ve sayfalandırılmış rapor başına, tür ve bağlantı ayrıntısıyla veri kaynağı kayıtları; admin scanner API’si de aynısını tenant ölçeğinde döndürür:
# Bir semantic model'in veri kaynakları
GET /v1.0/myorg/datasets/{datasetId}/datasources
# Sayfalandırılmış bir raporun doğrudan bağlantıları
GET /v1.0/myorg/reports/{reportId}/datasourcesPratikte etki analizi
İşe yarayan hamle haritayı tersine çevirmektir: her rapora verisinin nereden geldiğini sormak yerine, tüm bağlantıları sunucu/veritabanına göre gruplayıp etkilenen model listesini okuyun — sonra o model’lerin üzerindeki raporları, sonra da o raporları gerçekte kimin kullandığını. Bu son birleştirme (lineage × kullanım), bir taşıma planını “herkese haber verelim”den “şu 12 rapor önemli, 30 tanesi zombi; taşımak yerine emekliye ayırıyoruz”a dönüştüren şeydir.
Sürekli lineage haritalama
PGR Sonar, tenant’taki her semantic model ve sayfalandırılmış raporun veri kaynağı bağlantılarını olağan katalog senkronizasyonunun parçası olarak toplar ve workspace’ler, raporlar ve kullanım geçmişiyle birleştirir. “Bu veritabanını taşırsak ne bozulur” bir script projesi olmaktan çıkar ve zaten güncel olan bir harita üzerinde filtreye dönüşür — kullanım tarafı da bağlı olduğu için etkilenen raporlardan hangisinin gerçekten aranacağını da bilirsiniz.