Motor de stocare – Rolul său în optimizarea interogărilor DAX în LuckyTemplates

În acest tutorial, vom arunca o privire asupra celui de-al doilea motor din cadrul serviciilor de analiză - motorul de stocare.

Am discutat despre motorul de nivel superior, motorul de formule , într-un tutorial trecut. Când utilizatorii înțeleg cum funcționează ambele motoare, este mai ușor să optimizați și să îmbunătățiți performanța interogărilor DAX.

Scopul principal al motorului de stocare este de a lucra direct cu baza de date.

Motorul de formule nu are acces direct la baza de date, așa că în mod normal trece prin motorul de stocare în acest scop.

Motorul de stocare vine în două tipuri - modul de import și DirectQuery . Puteți combina și potrivi ambele tipuri în același model de date pentru a crea un model compozit.

Cuprins

• Lucrul cu modul Import în motorul de stocare
• Lucrul cu DirectQuery în motorul de stocare
• Lucrul cu modele compozite
• Alte puncte critice despre motorul de stocare
• Lucrul la interogări complicate
• Concluzie

Lucrul cu modul Import în motorul de stocare

Mai întâi, să vorbim despre modul de import. Acesta este, de asemenea, cunoscut sub numele de Vertipaq, dar se mai numește și xVelocity sau In Memory Columnar Database.

Există patru lucruri esențiale de înțeles despre modul în care funcționează modul de import.

În primul rând, Vertipaq creează o copie a datelor direct din sursa de date și o stochează în RAM în format comprimat .

În al doilea rând, datele procesate în modul de import se bazează pe ultima operațiune de reîmprospătare . Aceasta înseamnă că, dacă ați actualizat ultima dată datele săptămâna trecută, atunci datele cu care aveți de-a face sunt în continuare aceleași date de săptămâna trecută. Acest lucru este deosebit de important dacă utilizați o configurație compusă în care un tabel este în modul de import și celălalt tabel este în modul DirectQuery.

Să presupunem că aveți tabelul Produse, care a fost reîmprospătat săptămâna trecută, în modul de import. În ceea ce privește tabelul de vânzări, ați decis să îl cursați prin DirectQuery din cauza dimensiunii sale. Să presupunem, de asemenea, că vă creați raportul pe baza ambelor tabele în care introduceți coloana Brand și creați o măsură a vânzărilor totale pe același tabel de vânzări. De asemenea, doriți să vizualizați valoarea vânzărilor pe baza mărcii.

Mai întâi ar trebui să reîmprospătați datele care provin din modul de import, deoarece s-ar putea să ajungeți cu date proaspete și actualizate de la DirectQuery și date învechite de la Vertipaq. Acest lucru va lăsa câteva rânduri goale pe matrice și vizualizare.

Următorul lucru pe care trebuie să-l știți despre Vertipaq este că numai operațiunile de bază precum , , , sau sunt disponibile nativ . Aceasta înseamnă că, dacă există și alte operațiuni mai complicate incluse în planul de interogare, motorul de stocare ar trebui să apeleze motorul de formule pentru a rezolva această parte a codului.

În cele din urmă, motorul de stocare este o bază de date extrem de optimizată datorită structurii coloanei Vertipaq . Aceasta înseamnă că toate datele sunt stocate coloană cu coloană și nu rând cu rând. Datorită acestei structuri, Vertipaq va fi întotdeauna mai rapid decât o conexiune DirectQuery, chiar dacă creați indecși în modelul dumneavoastră de date relaționale.

Lucrul cu DirectQuery în motorul de stocare

Următoarea opțiune pe care o avem în cadrul serviciilor de analiză LuckyTemplates este DirectQuery. Dacă utilizați conexiunea DirectQuery, serviciile de analiză acționează doar ca trecere pentru interogările care sunt trimise de motorul de formule.

Deci, să presupunem că scrieți o interogare. Motorul de formule va genera un plan de interogare. Acesta va transmite apoi interogarea către motorul de stocare, deja tradus în limba maternă a bazei de date. De cele mai multe ori, aceste interogări vin în SQL.

Dacă interogarea folosește DirectQuery, așteptați-vă să fie actualizată tot timpul. Nu trebuie să vă faceți griji când ați actualizat ultima dată datele.

Procesul de optimizare a codului DAX și a modelului de date va depinde și de modul în care a fost creată baza de date relațională. Dacă aveți indecși în coloanele dvs., atunci interogările dvs. vor fi întotdeauna optimizate. Dar dacă baza ta de date nu este optimizată în ceea ce privește crearea de rapoarte folosind servicii de analiză sau LuckyTemplates, atunci te-ar putea confrunta cu câteva provocări de performanță. Prin urmare, fiți intenționat în crearea bazelor de date pentru dezvoltarea rapoartelor.

Lucrul cu modele compozite

A treia opțiune este să creați un model compozit, astfel încât să puteți avea un tabel în modul de import și un alt tabel în DirectQuery.

Când utilizați două tabele din surse diferite, motorul de formule va trimite o solicitare către Vertipaq și o altă solicitare către sursa de date DirectQuery. În ambele cazuri, serviciile de analiză vor prelua și memoria cache de date atât din Vertipaq, cât și din DirectQuery. Motorul de formule va folosi apoi JOIN, sau orice iterație pe ambele cache de date înainte de a furniza rezultatele utilizatorului final.

Deci, să presupunem că încercați să vizualizați valoarea vânzărilor după marca produsului în raportul dvs. Motorul de formule va trimite o solicitare către Vertipaq, de unde va prelua produsul, marca și cheia produsului. Apoi, din DirectQuery, va încerca să recupereze vânzările, prețul net, cantitatea vânzărilor și cheia produsului de vânzări.

Odată ce are cele două cache de date bazate pe cheia de produs, va uni cele două cache de date și va calcula valoarea totală a vânzărilor. Apoi va prezenta rezultatele utilizatorului final.

Alte puncte critice despre motorul de stocare

Acum că am acoperit diferitele sale tipuri, există alți câțiva factori critici pe care trebuie să-i cunoașteți despre motorul de stocare pentru a vă ajuta să vă optimizați interogările DAX.

După cum am menționat mai devreme, motorul de stocare furnizează memoria cache de date înapoi motorului de formule sub forma unui cache de date necomprimat. Când sunteți în modul de import, cererea care este trimisă înapoi către Vertipaq în proces este executată într-un limbaj xmSQL.

Limbajul xmSQL este oarecum similar cu SQL, dar nu este complet același. Vom vorbi despre xmSWL în detaliu când vom vorbi despre planurile de interogare într-un tutorial diferit.

De asemenea, este important să rețineți că motorul de stocare folosește toate nucleele disponibile în procesorul dumneavoastră. Abilitatea de a utiliza mai multe nuclee este benefică în cazul în care aveți mai multe segmente în modelul dvs. de date.

Să presupunem că aveți un tabel în LuckyTemplates cu 12 milioane de rânduri. Acest tabel va fi apoi împărțit în 12 segmente, deoarece atât în ​​Power Pivot, cât și în LuckyTemplates, fiecare segment se potrivește pentru 1 milion de rânduri. Acest lucru este spre deosebire de serviciile de analiză în general, unde un segment găzduiește 8 milioane de rânduri.

Deci, dacă am șase nuclee în procesorul meu, toate cele șase nuclee vor scana primele șase dintre cele 12 segmente în același timp. Odată ce au terminat, vor trece la următoarele șase segmente.

Dar dacă lucrez cu servicii de analiză în care segmentul implicit conține 8 milioane de rânduri, vor fi folosite doar două dintre cele șase nuclee ale mele - un segment va procesa 8 milioane de rânduri, în timp ce celălalt procesează 4 milioane.

Lucrul la interogări complicate

Mai devreme, am menționat că modul de import acceptă doar operațiuni de bază precum MIN, MAX, SUM, COUNT și GROUPBY. Deci, ce se întâmplă dacă lucrați la interogări mai complicate?

Să presupunem că decideți să utilizați o instrucțiune IF în contextul rândului sau o iterație imbricată, cum ar fi SUMX, peste tabelele Produse și Vânzări.

În acest caz, motorul de stocare nu va putea rezolva singur interogarea. Apoi va apela motorul de formule, care va începe să rezolve calculul complex rând cu rând în interiorul motorului de stocare. Unii ar putea crede că acesta este un scenariu favorabil, ambele motoare lucrând împreună - dar acest lucru este departe de adevăr.

Vedeți, când se întâmplă acest lucru, memoria cache de date produsă de motorul de stocare nu poate fi stocată în cache în cazul în care există un callbackdataID în acea interogare anume. Deci, dacă reîmprospătați imaginea, același calcul va trebui făcut atât de motorul de formule, cât și de motorul de stocare, chiar dacă tocmai ați executat aceeași interogare cu câteva secunde în urmă. Acest lucru va duce la întârzieri de performanță și la o experiență proastă a utilizatorului.

De asemenea, rețineți că motorul de stocare nu știe dacă interogările au fost executate folosind DAX sau MDX. După cum am menționat mai devreme, sarcina motorului de formule este să convertească interogările în limba potrivită înainte de a transmite planul de interogare.

În cele din urmă, motorul de formule trimite interogări în motorul de stocare una câte una. Aceasta înseamnă că a avea mai multe segmente este într-adevăr mai bine, astfel încât timpul general de scanare în Vertipaq să poată fi redus, mai multe segmente fiind scanate în același timp.

DAX pentru LuckyTemplates: optimizarea utilizând motoarele de formule în DAX Studio
Tehnici și lecții de optimizare a interogărilor DAX
Performanța interogărilor și configurarea DAX Studio

Concluzie

Înțelegerea dezavantajelor motorului de stocare vă ajută cu adevărat la optimizarea interogărilor DAX, mai ales dacă utilizați DAX Studio. Dacă ați parcurs și tutorialul care explică motorul de formule, puteți lua decizii mai bune cu privire la modul de a crea interogări mai performante.

Deși motorul de formulă servește ca motor de nivel superior, nu există nicio îndoială că nu poate funcționa la fel de bine dacă nu maximizăm ambele motoare.

Toate cele bune,