Teknoloji · Yapay zekâ & analitik

Her sayının tek bir tanımı olduğu panolar.

Test edilmiş veri martları üzerinde semantik modeller kuran Power BI mühendisleri: satır düzeyi güvenlik, devreye alma hatları, sizinle belirlenen yenileme hedefleri ve kod gibi incelenen DAX; böylece ekipler kimin rakamının doğru olduğunu tartışmayı bırakabilir.

Power BIOnunla neler geliştiriyoruz
01Sertifikalı semantik modeller
02Yönetim ve operasyon panoları
03Gömülü analitik
04Satır ve nesne düzeyi güvenlik
05Yenileme ve performans mühendisliği
06Yönetişim ve yaşam döngüsü
Genellikle birlikte
  1. Power BI
  2. Power BI Embedded
  3. DAX
  4. Tabular Editor
  5. DAX Studio
  6. dbt
Neden kullanıyoruz

Birçok kurumun zaten kullandığı raporlama katmanı.

Power BI, birçok kurumun zaten kullandığı raporlama katmanıdır — hâlihazırda işlettikleri Microsoft ortamının içinde durur, finans ekibi onu bilir ve güvenlik ekibi çoktan onaylamıştır. Bu da onu bir veri platformunun son adımı için pragmatik seçenek yapar: yönetişimli bir modelin, bir direktörün pazartesi sabahı açtığı bir sayfaya dönüştüğü yer. Kararların okunduğu yer orası olduğu için ve Power BI’da iyi kurulmuş bir semantik model gerçekten iyi bir mühendislik işi olduğu için kullanıyoruz — gelir, marj ve müşteri kaybının tek bir tanımı, her raporda yeniden kullanılır.

Bir Power BI ortamının hayal kırıklığı yaratmasının nedeni çoğu zaman araç değildir. Her biri bir CSV içeri aktaran, her biri marjı biraz farklı tanımlayan ve her biri birileri hatırladığında yenilenen yüz tane çalışma kitabıdır. Biz tersini kuruyoruz: dönüşümler, test edilmiş ve belgelenmiş dbt modellerinde yer alır; üzerlerinde az sayıda sertifikalı semantik model durur ve raporlar hafif kalır. Analistler yine ihtiyaç duyduklarını kurar — ama rakamları finans sistemiyle uyuşan bir modelin üzerinde.

Power BI’ı bir veri entegrasyon aracı, operasyonel bir uygulama ya da veri ambarının yerine kullanmıyoruz. Power Query hafif şekillendirme içindir, iş mantığı için değil; iş mantığının yeri, test edilebildiği veri hattıdır.

Onunla neler geliştiriyoruz

Power BI ile yayına aldığımız altı şey.

01

Sertifikalı semantik modeller

Veri ambarı martlarının üzerinde yıldız şemalı modeller; uyumlaştırılmış boyutlar, belgelenmiş ölçüler ve tek bir sahiple — analistlerin ham tablolar yerine bağlandığı model.

02

Yönetim ve operasyon panoları

İnsanların gerçekten sorduğu sorular etrafında tasarlanmış finans, satış, operasyon ve sadakat programı raporlaması; işleme kadar inen detay yolları ve sayfada görünen yenileme zamanıyla.

03

Gömülü analitik

Kendi ürün ve portallarınızın içinde Power BI Embedded; app-owns-data kimlik doğrulaması, çağıran kullanıcıya göre işleyen satır düzeyi güvenlik ve gerçek kullanıma göre boyutlandırılmış kapasiteyle.

04

Satır ve nesne düzeyi güvenlik

İşin kullandığı kimlik ve hiyerarşi verisinden kurulan güvenlik rolleri — bölge, iş birimi, müşteri — proje dışından biri bir rakam görmeden önce kimliğe bürünme ile test edilir.

05

Yenileme ve performans mühendisliği

Artımlı yenileme, toplama tabloları, bileşik modeller ve yalnızca tazeliğin gerektirdiği yerde DirectQuery — yenileme hedefleri sizinle belirlenir; varsayılmaz, izlenir.

06

Yönetişim ve yaşam döngüsü

Alan bazında çalışma alanları, geliştirmeden canlıya devreye alma hatları, onaylama kuralları, kullanım metrikleri ve kimsenin açmadığı raporlar için bir emekliye ayırma süreci.

Uygunluk

Ne zaman tercih edilmeli.

Doğru tercih

Kurumunuz Microsoft 365 ve Azure üzerinde çalışıyorsa, hedef kitle bir rapor talebinin karşılanmasını beklemek yerine sertifikalı bir modeli kendi keşfetmek isteyen iş kullanıcılarıysa ve satır düzeyi güvenliğe, zamanlanmış yenilemeye ve kurumsal paylaşıma bunları kendiniz kurmadan ihtiyaç duyuyorsanız Power BI’ı seçin. Azure, Snowflake, BigQuery ya da iyi modellenmiş bir PostgreSQL veri ambarı üzerine kurulu bir veri platformunun raporlama katmanı için onu seçin. Analitiğin yeri sattığınız bir ürünün ya da işlettiğiniz bir portalın içiyse Embedded’ı seçin.

Başka yere bakın

İş mantığının yaşadığı yer olarak seçmeyin — iş mantığının yeri test edilmiş dbt modelleridir, kimsenin gözden geçiremeyeceği bir Power Query adımları zinciri değil. Yavaş bir kaynağın üzerinde DirectQuery seçip hızlı bir sayfa beklemeyin. Saniye düzeyinde gecikmeyle gerçek zamanlı operasyonel izleme için seçmeyin; orada Grafana ya da amaca özel bir ekran daha iyi iş görür. Ortamınız Google öncelikliyse ve ekip zaten Looker’ın içinde yaşıyorsa, sizi taşımak yerine bunu söyleriz.

Uygulamada

Tek tanımı olan, sürüm kontrolünde gözden geçirilen ölçüler.

models/finance/measures.daxdax
Net Revenue =
    CALCULATE ( SUM ( fct_sales[net_amount] ), fct_sales[status] = "invoiced" )

Net Revenue LY =
    CALCULATE ( [Net Revenue], SAMEPERIODLASTYEAR ( dim_date[date] ) )

// margin uses the same cost basis as the finance ledger — see dbt model fct_sales
Gross Margin % =
    DIVIDE ( [Net Revenue] - SUM ( fct_sales[cogs_amount] ), [Net Revenue] )

+ Active Members = DISTINCTCOUNT ( fct_loyalty_activity[member_id] )
Referans mimari

Kaynak sistemden bir direktörün güvendiği sayfaya.

Kaynaklar
ERP / SAPCRMÜrün veritabanlarıKafka olayları
Veri hattı
Airflowdbt modelleriGreat Expectations
Veri ambarı
Azure Synapse / FabricSnowflakeBigQueryPostgreSQL
Semantik katman
Sertifikalı veri kümeleriÖlçülerRLS rolleriToplamalar
Tüketiciler
Power BI ServiceÜrünlere gömülüExcelTeams
Standartlarımız

Devrettiğimiz Power BI ortamları şöyle görünür.

  • Mantık üst akışta, modeller ince. İş kuralları, test edilip belgelendikleri dbt’de yaşar; Power Query yalnızca hafif şekillendirme yapar. Bir tanımın değişmesi gerekiyorsa, bir kez değişir.
  • Varsayılan olarak yıldız şema. Uyumlaştırılmış tarih, müşteri ve ürünlerle olgu ve boyut tabloları. Geniş düz tablo yok, kestirme olarak kullanılan çift yönlü ilişki yok.
  • Ölçüler kod gibi incelenir. DAX, Tabular Editor ile sürüm kontrolünde tutulur; tutarlı biçimde adlandırılıp belgelenir, pull request’lerde gözden geçirilir ve sürüm öncesinde DAX Studio ile profillenir.
  • Güvenlik varsayılmaz, test edilir. Kimlik kaynağından türetilen satır ve nesne düzeyi roller, bir test planı içinde kimliğe bürünme ile doğrulanır ve organizasyon şeması her değiştiğinde gözden geçirilir.
  • Yenileme hedefleri sizinle belirlenir. Büyük olgu tablolarında artımlı yenileme, izlenen yenileme geçmişi, sorumlusuna uyarı olarak iletilen hatalar ve her sayfada gösterilen son yenileme zamanı.
  • Sayfalarda performans bütçesi. Makul tutulan görsel sayısı, model büyükse toplama tabloları ve onaydan önce Performance Analyzer ile kontrol edilen bir sayfa yüklenme hedefi.
  • Yaşam döngüsü hatlar üzerinden. Devreye alma hatlarıyla geliştirme, test ve canlı çalışma alanları; onaylanmış ve sertifikalı veri kümeleri; dosya kopyalanarak yükseltilen rapor yok.
  • Kişisel veri en aza indirilir. Modele yalnızca raporun ihtiyaç duyduğu nitelikler ulaşır; hassas kolonlar maskelenir veya dışarıda bırakılır, duyarlılık etiketleri uygulanır ve KVKK ile GDPR erişim kuralları güvenlik rollerine yansıtılır.
Tipik eşleşmeler

Genellikle onunla birlikte teslim edilenler.

  • İşin onayladığı bir ölçü sözlüğüyle sertifikalı semantik modeller
  • Modelleri besleyen, testleri ve veri kökeni olan dbt martları; böylece rapordaki rakam kaynağına kadar izlenir
  • Belgelenmiş bir test planı ve kimliğe bürünme sonuçlarıyla satır düzeyi güvenlik rolleri
  • Geliştirme, test ve canlı çalışma alanları boyunca devreye alma hatları ve bir sürüm kontrol listesi
  • Uyarılarla birlikte yenileme ve kullanım izleme; kimsenin açmadığı raporlar için sizinle belirlenen bir ritimde düzenli emekliye ayırma listesi
Şunlarla çalışır
Power BIPower BI EmbeddedDAXTabular EditorDAX StudiodbtAirflowAzureMicrosoft FabricSnowflakeBigQueryPostgreSQLGreat Expectations
SSS

Sık sorulan sorular

Varsayılan olarak Import — daha hızlı, daha ucuz ve daha sakindir; artımlı yenileme de büyük olgu tablolarını yönetilebilir tutar. DirectQuery ya da bileşik model, yalnızca bir iş kararı gerçekten yenileme aralığı içinde değişiyorsa; o zaman da bu sorguları hızlı yanıtlayacak şekilde tasarlanmış bir kaynak üzerinde. Seçimden önce yenileme hesabını size gösteririz.
Evet; ilk adım bir envanter: hangi raporlar açılıyor, hangileri aynı ölçüyü farklı tanımlıyor, hangi kaynaklara dokunuyorlar. Ardından en çok tartışılan metrikler için sertifikalı modelleri kurar, önemli raporları bunların üzerine taşır ve geri kalanları sahiplerinin mutabakatıyla emekliye ayırırız. Karmaşanın yeniden oluşması zorlaşır, çünkü mantık artık test edilmiş veri hatlarında durur.
Evet, bir müşteri onun üzerinde standartlaşıyorsa — OneLake, lakehouse tabloları ve Direct Lake modelleri aynı mimariye oturur. Raporlama katmanı Power BI olacak şekilde Snowflake, BigQuery ve PostgreSQL veri ambarları üzerine de kuruyoruz. Modelleme ve yönetişim standartları her durumda aynıdır.
Evet. Power BI Embedded; app-owns-data kimlik doğrulaması, çağıran kullanıcıya göre işleyen güvenlik rolleri, ölçülen kullanıma göre boyutlandırılmış kapasite ve servis yavaşladığında devreye giren yedeğe geçişle. Kullanıcılarınız Power BI kullanmıyorsa, raporlama ekranlarını bunun yerine yerel olarak geliştiririz — semantik model her iki durumda da yeniden kullanılabilir.
Tasarım gereği sizin ekibiniz. Analistler sertifikalı modeller üzerinde rapor kurmayı sürdürür; adı belli bir veri sahibi ölçü değişikliklerini onaylar; veri hattı ve devreye alma mekanizmaları belgelenip devredilir. Yetkinlik aktarımı oturumları sizinle, ihtiyaçlarınıza göre belirlenir; Veri Mühendisliği ekibimiz de üst akıştaki işlerde destek olabilir.
İlgili

Komşu teknolojiler ve onları kullanan hizmet.

Grafik çizmeden önce modelleyen Power BI mühendisleri mi arıyorsunuz?

Ekiplerinizin hangi rakamlar üzerinde anlaşamadığını ve veri ambarınızın nasıl göründüğünü anlatın. Adları belli bir ekip önerir ya da kendi ekibinize analitik mühendisleri yerleştiririz.

✓ Satış sunumu yok✓ AI-native bir mühendisten yanıt✓ Yazılı geri dönüş