Un raport Power BI care se încarcă în 18 secunde nu e un raport. E un slide pe care nimeni n-o să-l deschidă a doua oară. În practică, aproape întotdeauna problema nu e în vizuale, nici în DAX, nici în volumul de date. E în model. Iar modelul prost construit nu se vindecă cu măsuri mai deștepte.

Acest articol nu e o teorie a modelării. E inventarul concret al pașilor pe care îi parcurg, în ordinea aceasta, când primesc un raport „lent" și mi se cere să-l fac „rapid". Optimizare model Power BI înseamnă, în 90% din cazuri, aceiași șapte-opt pași aplicați disciplinat.

model Power BI: De ce un model bun face diferența

Power BI rulează pe VertiPaq, un motor columnar in-memory. Asta înseamnă două lucruri practice. Datele sunt stocate pe coloane (nu pe rânduri), comprimate agresiv. Iar performanța depinde brutal de două variabile: cardinalitatea coloanelor (numărul de valori unice) și structura relațiilor între tabele.

În 2026, cu Power BI Fabric tot mai integrat și cu modele care depășesc frecvent miliarde de rânduri prin Direct Lake, principiile de bază rămân valabile. Volumul s-a mutat în cloud, dar regulile de design ale modelului semantic n-au făcut decât să devină mai importante.

O echipă care a investit două săptămâni în reconstruirea modelului de la zero, după primul an de raportare ad-hoc, recuperează în general acel timp în trei luni - doar din productivitatea recâștigată de cei care nu mai așteaptă rapoarte.

Pasul 1: scheme star, nu spaghetti

Orice optimizare începe aici. Power BI e construit să funcționeze pe scheme de tip star (un tabel central de fapte conectat la mai multe tabele de dimensiune). Nu pe scheme normalizate 3NF cum sunt bazele OLTP. Nu pe „flatten table" cu 80 de coloane. Nu pe relații many-to-many între fapte.

Dacă modelul tău are mai mult de 3-4 tabele de fapte legate între ele direct, ai o problemă structurală. Soluția nu e încă o relație. Soluția e să decizi care e tabelul central și să normalizezi celelalte ca dimensiuni.

Capcana frecventă pe care o văd: organizații care încearcă să folosească un singur tabel uriaș care conține tot - vânzări, clienți, produse, geografie - pentru că „așa era în Excel". Funcționează pentru 100.000 de rânduri. Cade la 5 milioane. Rescrierea în schemă star nu e opțională. E investiția care evită problemele exponențiale de mai târziu.

Pasul 2: elimină coloanele de care nu te folosești

E cel mai simplu sfat și cel mai des ignorat. Cantitatea de RAM consumată de un model Power BI e direct proporțională cu numărul de coloane, ponderate cu cardinalitatea lor.

O coloană pe care n-o folosești în vizual, în filtru, în relație sau într-o măsură consumă memorie degeaba. În modele tipice business, 20-40% din coloanele importate sunt complet inutile. Adresa de email a clientului, ID-ul intern din ERP, comentariul descriptiv pe linia de comandă, marca de timp până la milisecundă - toate apar reflex în extract, niciuna nu apare în raport.

Soluția nu e să le ștergi în pasul de transformare. Soluția e să nu le aduci. În Power Query, alege „Choose Columns" și păstrează doar ceea ce te servește. Diferența pe un model real e între 2 GB și 700 MB - cu impact direct asupra refresh time și asupra timpului de încărcare la utilizator.

Pasul 3: redu cardinalitatea coloanelor

VertiPaq comprimă cel mai eficient coloanele cu puține valori unice. Bărbat/Femeie - excelentă compresie. Cod fiscal - aproape niciuna. ID tranzacție - cea mai proastă posibilă.

Există câteva mutări tactice care reduc cardinalitatea.

Pe datetime, separă data de oră. O coloană DateTime cu precizie de secunde are cardinalitate egală cu numărul de tranzacții. Dacă ai 10 milioane de tranzacții, ai 10 milioane de valori unice. Despărțite în Date (max 3650 valori pentru 10 ani) și Time (86400 valori posibile), totalul de spațiu scade drastic. În practică, despărțirea reduce dimensiunea coloanei cu un factor 5x-10x.

Pe valori numerice cu zecimale, evaluează precizia. Prețul cu 6 zecimale pentru valori care în business au sens cu 2 zecimale crește inutil cardinalitatea. Rotunjește înainte de import.

Pe text liber, evită să-l aduci ca atribut în model. Notițele clienților, comentariile pe comenzi, descrierile lungi - dacă nu sunt folosite efectiv pentru filtre, scoate-le din model. Dacă e nevoie să fie accesibile prin drill-through, păstrează-le pe partea de detail, nu pe partea analizată.

Pasul 4: tipurile de date contează

O coloană declarată ca text consumă semnificativ mai multă memorie decât una numerică, chiar dacă valorile sunt identice. „12345" ca text e tratat diferit față de 12345 ca integer.

Verifică toate coloanele și asigură-te că tipul e cel corect. Coduri numerice ascunse ca text (frecvent când vin din CSV). Date de tip text neconvertite la date type. Boolean stocat ca „Da"/„Nu" text în loc de True/False.

Un detaliu uitat des: integerele mari (peste 2 miliarde) consumă mai mult decât integerele mici. Dacă ai ID-uri de tip BIGINT generate de sistem dar care în model n-au nevoie de gama maximă, gândește dacă păstrarea formatului are sens.

Pasul 5: relațiile - one-to-many, single direction

Relațiile bidirecționale sunt una dintre cele mai mari surse de probleme de performanță și de bug-uri logice pe rapoarte mari. Implicit, fac filtrele să curgă în ambele direcții, ceea ce duce la ambiguități și la calcule duplicate.

Regula practică: începe cu single direction. Aproape întotdeauna funcționează. Folosește bi-directional doar în cazuri concrete - tipic, pentru many-to-many soluționat prin tabel-punte. Și documentează explicit de ce ai făcut-o.

Relațiile many-to-many directe între tabele sunt aproape întotdeauna un semn că modelul nu e finalizat. Power BI le acceptă din 2018, dar acceptarea tehnică nu înseamnă recomandare. Pe modele cu trafic real, soluția corectă e tabelul de jonctiune.

Pasul 6: coloane calculate doar când chiar e nevoie

Coloanele calculate în Power BI Desktop par ieftin de creat. Sunt scumpe de păstrat. Fiecare coloană calculată ocupă memorie ca orice coloană obișnuită, dar nu beneficiază de aceleași optimizări de compresie ca o coloană importată.

Două alternative aproape întotdeauna mai bune.

Calculează în Power Query. Operațiile făcute upstream sunt cached, comprimate corect, vizibile în diagnostic. Coloana de „categorie de produs derivat din preț" se calculează în Power Query, nu în DAX.

Folosește măsuri. Dacă rezultatul depinde de filtrele aplicate în vizual, e o măsură, nu o coloană. Greșeala clasică e să faci o coloană „flag client activ" și apoi să te miri că nu se schimbă când filtrezi pe interval de dată.

Coloanele calculate sunt potrivite pentru clasificări statice (categoria produsului în funcție de cod), pentru extragerea unui element dintr-un string (anul dintr-un text concatenat), sau pentru coloane care intră într-o relație. Pentru restul, alternative.

Pasul 7: agregări pentru volume mari

La modele care depășesc câteva zeci de milioane de rânduri, agregările (aggregations) sunt instrumentul care face diferența dintre un raport utilizabil și unul abandonat.

Conceptul: păstrezi tabelul de fapte detaliat, dar creezi un al doilea tabel mai mic, agregat la nivel mai mare (de exemplu, vânzări per zi-magazin-categorie în loc de tranzacție individuală). Power BI învață, prin configurare, să folosească automat tabelul agregat când întrebarea o permite.

Pe Direct Lake (default-ul recent în Fabric), conceptul rămâne, dar implementarea s-a schimbat. Documentația Microsoft acoperă noile pattern-uri pentru workspace-uri Fabric.

Agregările nu sunt pentru oricine. Setup-ul corect cere disciplină. Dar pentru rapoartele executive pe date masive (retail cu sute de magazine, telecom, fintech), e diferența între raport executiv „real-time" și raport care arată „last refresh: 4 hours ago".

Pasul 8: măsurile - lizibile, reutilizate, fără duplicat

Multe rapoarte care „funcționează greu" au, pe lângă modelul prost, măsuri prost organizate. Trei principii.

Construiește măsuri-rădăcină reutilizabile. Total Vânzări o singură dată. Profit derivat din Total Vânzări - Total Cost. Marjă din Profit / Total Vânzări. Așa, dacă mâine trebuie să modifici cum se calculează vânzările (de exemplu adăugând TVA), modifici un singur loc.

Folosește variabile (VAR) pentru orice măsură non-trivială. Codul devine mai lizibil și DAX-ul recalculează o singură dată ce e în variabilă, în loc să o reevalueze de fiecare dată.

Evită FILTER inutil. Un FILTER pe un tabel de fapt mare, evaluat în 15 vizuale simultan, e adesea sursa lentorii. Folosește filtrul direct în CALCULATE când e suficient.

Cum măsori dacă optimizarea a funcționat

Două instrumente concrete pentru a verifica dacă pașii de mai sus au avut efect.

În Power BI Desktop, View - Performance Analyzer înregistrează timpul de execuție al fiecărui vizual. E primul loc unde te uiți când vrei să identifici unde se scurge timpul.

Pentru analiza modelului în adâncime, DAX Studio (open-source, gratuit) e standardul industriei. Permite să vezi exact dimensiunea fiecărei coloane, gradul de compresie, query-urile generate de fiecare vizual, planurile de execuție.

O echipă care a învățat DAX Studio devine capabilă să optimizeze independent. Fără el, lucrezi pe ghicit.

Un scenariu concret - de la 22 de secunde la 3

Pentru a face concretă teoria, un exemplu din 2026.

O companie de retail medie (200 de magazine, 24 milioane tranzacții/an, 18 luni de istoric în model) avea un raport executiv care se încărca în 22 de secunde. KPI-urile nu se schimbaseră de un an, dar timpul de încărcare crescuse de la 8 secunde la 22 pe măsură ce volumul a crescut.

Investigația a arătat trei probleme principale.

Modelul era „flatten" - un singur tabel cu 47 de coloane, conținând și datele clienților, și produsele, și magazinele. Rescris ca schemă star (1 tabel fapt + 5 tabele dimensiune), dimensiunea a scăzut de la 1.4 GB la 320 MB.

O coloană DateTime cu precizie până la secunde a fost despărțită în Date și Time. Reducere suplimentară de 200 MB.

Trei coloane calculate folosite ca filtre în vizuale au fost mutate în Power Query ca transformări upstream. Performanța la deschiderea raportului a scăzut sub 3 secunde.

Costul total: 5 zile-om de munca unui consultant. Beneficiul: un raport pe care managementul îl deschide acum efectiv. În proiecte reale, raportul de cost-beneficiu e copleșitor.

Ce să nu faci în 2026

Trei capcane care apar regulat în echipele care vin spre Power BI dintr-un background de Excel sau de SQL.

Nu importa „cât poți de mult" - importă cât îți trebuie. Pentru un raport executiv, ultimii 3 ani de date sunt aproape întotdeauna suficienți. Datele de 7-8 ani vechime trăiesc bine într-un data lake, nu în model.

Nu confunda Power BI cu un data warehouse. Power BI poate raporta peste un warehouse bun. Nu îl înlocuiește. Companiile care încearcă să facă din Power BI singura sursă a transformărilor de date sfârșesc cu modele imposibil de întreținut.

Nu ignora Direct Lake doar pentru că „n-ai mai lucrat cu el". E direcția implicită pe Fabric din 2026, e matur, și pentru organizațiile care au datele deja în OneLake elimină o parte considerabilă din complexitatea ETL.

Tema se leagă natural de discuția despre Power BI vs Tableau, unde am intrat în detaliu pe pattern-urile pe care le observăm în piață. În fond, model Power BI nu e doar un concept tehnic — este o decizie de business cu impact direct pe productivitatea echipei.

Ce înseamnă „model bun" la sfârșit

Un model bun se recunoaște după trei lucruri. Se înțelege de cineva nou în echipă în mai puțin de o oră. Se modifică pentru o cerință nouă în mai puțin de o zi. Și se încarcă suficient de rapid încât utilizatorii să folosească rapoartele zilnic, nu doar la prezentări lunare.

Cele opt principii din acest articol nu sunt o listă de checking exhaustivă. Sunt fundamentul minim. Optimizarea avansată (incremental refresh, perspectives, calculation groups, Fabric integration profundă) construiește deasupra. Dar fără bază, niciun feature avansat nu salvează modelul.

În practică, model Power BI a trecut de la subiect de roadmap la prioritate operațională pentru echipele care livrează rezultate de business — exact tipul de tracțiune pe care o vedem reflectată în deciziile reale de buget. Pentru cititorii care lucrează zilnic cu model Power BI, articolul rămâne deschis pentru update-uri pe măsură ce piața evoluează.

Întrebări frecvente

De ce se încarcă lent un raport Power BI?

Power BI rulează pe VertiPaq, un motor columnar in-memory, iar performanța depinde de model. Cauzele frecvente sunt un model „flatten” (un singur tabel uriaș), coloane încărcate dar nefolosite, cardinalitate mare (de exemplu DateTime cu precizie la secundă), tipuri de date greșite, relații bidirecționale și coloane calculate care ar trebui mutate în Power Query.

Ce structură de model se recomandă?

Schemă în stea, nu spaghetti. Dacă modelul are mai mult de 3-4 tabele de fapte legate direct între ele, există o problemă structurală. Relațiile pornesc one-to-many, single direction; relațiile many-to-many directe sunt aproape întotdeauna semnul unui model nefinalizat.

Cum verific dacă optimizarea a avut efect?

Cu două instrumente concrete: Performance Analyzer din Power BI Desktop (View → Performance Analyzer), care înregistrează timpul de execuție al fiecărui vizual, și DAX Studio, gratuit și open-source, pentru analiza modelului în adâncime.