Tipy na úspešnú implementáciu LuckyTemplates

Budeme pokračovať v našej sérii o plánovaní a implementácii projektov LuckyTemplates. Tentokrát budeme diskutovať o návrhu množiny údajov , profilovaní a režimoch . Pozrite si prvú časť našej série plánovania projektov, ktorá sa zaoberá, a druhú časť, ktorá hovorí o .

Obsah

• Návrh súboru údajov pre implementáciu projektu LuckyTemplates
  • 4 kroky k návrhu množiny údajov
  • Vyberte obchodný proces.
    • Anti-vzor, ​​ktorému sa treba vyhnúť pri implementácii LuckyTemplates
  • Vyhláste obilie.
  • Identifikujte rozmery.
  • Definujte fakty.
• Matica dátovej zbernice pre implementáciu projektu LuckyTemplates
• Profilovanie údajov pre implementáciu LuckyTemplates
  • SQL Server Integration Services
  • Štúdio DAX
  • LuckyTemplates Desktop
• Plánovanie súboru údajov pre implementáciu LuckyTemplates
  • Výber režimu množiny údajov
  • Niekoľko otázok, ktoré si treba položiť pri výbere režimov množiny údajov
• Záver

Návrh súboru údajov pre implementáciu projektu LuckyTemplates

Poďme sa porozprávať o procese návrhu množiny údajov a diskutovať o matici zbernice dátového skladu , čo je nástroj, ktorý existuje už nejaký čas.

Navrhovanie množín údajov Power BI je podobné ako navrhovanie údajových skladov. Takže množiny údajov aj dátové sklady majú podobné koncepty, ako sú tabuľky faktov a dimenzií, hviezdicové schémy, pomaly sa meniace dimenzie, granularita tabuľky faktov a lokálne informované kľúče na vytváranie vzťahov medzi tabuľkami.

4 kroky k návrhu množiny údajov

Proces návrhu množiny údajov má štyri kroky: vyberte obchodný proces , deklarujte štruktúru tabuliek faktov, identifikujte dimenzie a potom definujte fakty .

Vyberte obchodný proces.

V prvom kroku je každý obchodný proces reprezentovaný tabuľkou faktov s hviezdicovou schémou podľa dimenzií.

Počas procesu zisťovania alebo zhromažďovania požiadaviek je ťažké zamerať sa na jeden izolovaný obchodný proces, pretože používatelia pravidelne analyzujú viacero obchodných procesov súčasne.

Anti-vzor, ​​ktorému sa treba vyhnúť pri implementácii LuckyTemplates

Bežným anti-vzorcom (ktorý je odpoveďou na opakujúci sa problém, ktorý je vo všeobecnosti neúčinný a potenciálne kontraproduktívny), ktorému sa chcete v projektoch LuckyTemplates vyhnúť, je vývoj množín údajov pre konkrétne projekty alebo tímy, a nie pre obchodné procesy .

Napríklad vývoj súboru údajov výlučne pre marketingový tím a iného súboru údajov pre organizáciu predaja. Tento prístup prirodzene vedie k plytvaniu zdrojmi, pretože rovnaké údaje o predaji sa dopytujú a obnovujú dvakrát v oboch súboroch údajov. Tie budú spotrebovávať aj úložné prostriedky v službe LuckyTemplates.

toto sú niektoré z dôvodov, prečo chcete prejsť dobrým procesom návrhu množiny údajov. Izolovaný prístup vedie k problémom so spravovateľnosťou a správou verzií, pretože množiny údajov môžu obsahovať variácie a transformácie.

Aj keď sú analytické potreby používateľov alebo tímov prioritou projektov LuckyTemplates, je tiež dôležité plánovať udržateľné riešenia, ktoré môžu byť v konečnom dôsledku zdieľané medzi tímami.

Vyhláste obilie.

Tabuľky zrnitosti v konečnom dôsledku pokrývajú úroveň podrobností dostupnú pre analytické dotazy, ako aj množstvo údajov, ku ktorým je možné pristupovať.

Takže vyššia zrnitosť znamená viac detailov, zatiaľ čo nižšia zrnitosť znamená menej detailov. Príkladom je situácia, keď chcete získať úroveň riadku zákazky odberateľa, alebo ak chcete, aby projekt obsahoval iba súhrnnú úroveň každej zákazky odberateľa a nedostal sa ku konkrétnym produktom, ktoré boli objednané v rámci tohto predaja.

Niekedy sa toto zrno môže líšiť v závislosti od vášho časového rámca. Stretol som sa s množstvom zákazníkov, ktorí chceli veľmi jemné tabuľky faktov za aktuálny štvrťrok, ale za predchádzajúce štvrťroky potrebovali len vedieť, aké boli celkové tržby za štvrťrok.

Počas tohto kroku chcete určiť, čo predstavuje každý riadok rôznych obchodných procesov . Napríklad každý riadok tabuľky predajných faktov z nášho dátového skladu predstavuje riadok predajnej objednávky od zákazníka.

Naopak, riadky plánu predaja a marže budú agregované v kalendárnom mesiaci, podkategórii produktu a oblasti územia predaja. takže v tomto prípade máte dve rôzne tabuľky faktov a dve rôzne zrná. ak ich chcete porovnať, bude to vyžadovať prácu na modelovaní údajov.

Identifikujte rozmery.

Rozmery sú len prirodzeným vedľajším produktom zrna zvoleného v predchádzajúcom kroku návrhu.

Takže jeden vzorový riadok z tabuľky faktov by mal jasne indikovať súvisiaci s daným procesom, ako je zákazník, ktorý si zakúpil individuálny projekt, produkt k určitému dátumu av určitom čase. Tabuľky faktov predstavujúce nižšie zrná majú menej rozmerov.

Napríklad tabuľka faktov predstavujúca úroveň hlavičky nákupnej objednávky môže identifikovať predajcu, ale nie jednotlivý nákup produktu od predajcu. takže v takom prípade by ste nepotrebovali zahrnúť dimenziu kategórie produktu alebo podkategórie produktu.

Definujte fakty.

Fakty predstavujú číselné stĺpce zahrnuté v tabuľkách faktov. Takže zatiaľ čo stĺpce dimenzie z kroku 3 sa používajú na vzťahy, stĺpce faktov sa používajú v mierach obsahujúcich logiku agregácie, ako je súčet stĺpca množstva alebo priemer stĺpca ceny.

Matica dátovej zbernice pre implementáciu projektu LuckyTemplates

Matica zbernice dátového skladu je základom architektúry dátového skladu Ralpha Kimballa, ktorá poskytuje prírastkový a integrovaný prístup k návrhu dátového skladu.

Architektúra, ktorú tu vidíte, je z The Data Warehouse Toolkit , 3. vydanie od Ralpha Kimballa. Umožňuje škálovateľné dátové modely, ktoré často vyžadujú viaceré obchodné tímy alebo funkcie na prístup k rovnakým obchodným procesom a dimenziám.

Udržiavanie zbernicovej matice dátového skladu je užitočné. keď ho vyplníte, budete vedieť, či existujú ďalšie množiny údajov, ktoré obsahujú podobné tabuľky internetových faktov a tabuľky dimenzií. to podporuje opätovnú použiteľnosť projektu a zlepšuje komunikáciu projektu.

Každý riadok teda odráža dôležitý a opakujúci sa obchodný proces, akým je napríklad mesačná uzávierka hlavnej knihy. každý stĺpec predstavuje obchodnú entitu, ktorá sa môže týkať jedného alebo viacerých obchodných procesov, zatiaľ čo tieňované riadky predstavujú obchodný proces, ktorý je súčasťou projektu.

Profilovanie údajov pre implementáciu LuckyTemplates

po identifikácii zrnitosti a dokončení štvorstupňového procesu návrhu súboru údajov by po ňom mala okamžite nasledovať technická analýza zdrojových údajov tabuliek faktov a rozmerov .

Technické metadáta, vrátane databázových diagramov a výsledkov profilovania údajov, sú nevyhnutné pre fázu plánovania projektu.

Tieto informácie sa používajú na zabezpečenie toho, aby množina údajov Power BI odrážala zamýšľané obchodné definície a bola postavená na kvalitnom a dôveryhodnom zdroji.

Ide teda o tri rôzne spôsoby zhromažďovania týchto profilovacích informácií, čo by mal byť úplne prvý krok, ktorý ľudia urobia, keď vyjdú z procesu návrhu.

SQL Server Integration Services

Existuje niekoľko spôsobov, ako to dosiahnuť. Jednou z metód je použitie úlohy profilovania údajov v rámci balíka SQL Server Integration Services (SSIS).

Úloha profilovania údajov vyžaduje pripojenie ADO.NET a môže zapísať svoj výstup do súboru XML alebo premennej SSIS.

V tomto príklade sú zdrojové údaje ADO.NET dátový sklad AdventureWorks, databáza a SQL server a cieľom je súbor XML.

Takže po vykonaní úlohy je možné čítať súbor XML pomocou prehliadača údajových profilov servera SQL. Môžete vidieť výsledky z hľadiska nulového počtu a percenta nulového počtu.

Štúdio DAX

Ďalší spôsob profilovania údajov je cez DAX Studio. musíte skutočne prijať údaje do súboru údajov LuckyTemplates tak, že prejdete do DAX Studio, prejdite na kartu rozšírené a spustite súbor .

Ukáže vám rovnaký druh informácií o mohutnosti vašich stĺpcov, takže budete vedieť, ktoré z nich zaberajú najviac miesta vo vašom dátovom modeli. zahŕňa všetky rôzne štatistiky týkajúce sa údajov.

LuckyTemplates Desktop

profilovanie údajov je k dispozícii aj v silovom dotaze v rámci pracovnej plochy LuckyTemplates. ak prejdete na kartu Zobraziť , môžete zapnúť napríklad kvalitu stĺpcov, rozdelenie stĺpcov a profil stĺpcov. Minimálne pre prvých tisíc riadkov môžete vidieť informácie, ako sú chyby, hodnoty null, priemery a štandardné odchýlky.

Plánovanie súboru údajov pre implementáciu LuckyTemplates

Po profilovaní zdrojových údajov a ich vyhodnotení podľa požiadaviek identifikovaných v procese návrhu štvorstupňového súboru údajov môže tím BI ďalej analyzovať možnosti implementácie pre súbor údajov.

Takmer vo všetkých projektoch power BI, dokonca aj pri tých s významnými investíciami do podnikových údajov, skladu, architektúry a nástrojov a procesov ETL, je potrebná určitá úroveň dodatočnej logiky, integrácie alebo transformácie na zvýšenie kvality a hodnoty zdrojových údajov.

Fáza plánovania množiny údajov určuje, ako sa riešia identifikované problémy s transformáciou údajov na podporu množiny údajov. Okrem toho musí projektový tím určiť, či sa má vyvinúť množina údajov režimu importu , množina údajov priameho dotazu alebo zložená množina údajov .

Na objasnenie procesu plánovania množiny údajov tento diagram identifikuje rôzne vrstvy údajového skladu a množiny údajov LuckyTemplates, kde je možné implementovať transformáciu a obchodnú logiku.

v niektorých projektoch je potrebná minimálna transformácia a dá sa jednoducho zahrnúť do množiny údajov Power BI. Napríklad, ak je potrebných len niekoľko ďalších stĺpcov pre tabuľku dimenzií a existuje priamy návod na to, ako sa tieto stĺpce budú počítať, IT organizácia sa môže rozhodnúť implementovať tieto transformácie v rámci M power queries namiesto revízie dátového skladu.

Ak sa umožní, aby podstatná priepasť medzi potrebami BI a podnikovým dátovým skladom pretrvávala, zostavenie a údržba súborov údajov LuckyTemplates sa stanú zložitejšími.

Návrhári množín údajov by mali pravidelne analyzovať a oznamovať dôsledky množín údajov, ak existujú väčšie úrovne zložitosti.

Ak je však požadovaná transformačná logika zložitá alebo rozsiahla s viacerými spoločnými operáciami, filtrami riadkov a zmenami typu údajov, potom sa IT organizácia môže rozhodnúť implementovať zásadné zmeny v dátovom sklade na podporu novej množiny údajov a budúcich projektov BI.

Napríklad na podporu, revíziu a aktualizáciu procesu môže byť potrebná prípravná tabuľka a procedúra úložiska SQL, alebo môže byť potrebné vytvorenie indexu na zlepšenie výkonu dotazov pre množiny údajov DirectQuery.

Výber režimu množiny údajov

Následným, ale úzko súvisiacim krokom plánovania množiny údajov je výber medzi predvoleným režimom importu, režimom DirectQuery/živý režim alebo zloženým režimom.

V niektorých projektoch ide o jednoduché rozhodnutie, kde je pri známych požiadavkách uskutočniteľná alebo reálna len jedna možnosť, zatiaľ čo iné projekty si vyžadujú podstatnú analýzu kladov a záporov každého návrhu.

Ak sa teda zdroj údajov považuje za pomalý alebo nedostatočne vybavený na spracovanie veľkého množstva analytických dopytov, potom je veľmi pravdepodobne preferovanou možnosťou množina údajov režimu importu.

Podobne, ak je nevyhnutná viditeľnosť zdroja údajov takmer v reálnom čase, potom je DirectQuery alebo živý režim jedinou možnosťou, ako to dosiahnuť. DirectQuery a živý režim sú si navzájom veľmi podobné. Obidve metódy neukladajú údaje v rámci samotnej množiny údajov a obe vyhľadávajú priamo zdrojové systémy, aby získali údaje na základe akcie používateľa. Teraz máme DirectQuery pre množiny údajov LuckyTemplates a DirectQuery pre analytické služby.

Niekoľko otázok, ktoré si treba položiť pri výbere režimov množiny údajov

Tu je niekoľko otázok, ktoré si treba položiť pri rozhodovaní, ktorý režim použiť. existuje jeden zdroj pre náš súbor údajov? Ak neexistuje jediný zdroj, potom ste v minulosti nemohli použiť zdroj DirectQuery/Live.

Aj keď teraz máme množiny údajov zloženého režimu, je stále dobré položiť si otázku hneď na začiatku, pretože ak neexistuje jediný zdroj, bude to buď import, alebo zložený.

Ak je možný zdroj DirectQuery/Live, je zdroj schopný podporovať analytické dotazy? Ak pracujete s miliardami alebo biliónmi riadkov, možno nie je možné použiť množinu údajov režimu importu a budete musieť prejsť na režim DirectQuery alebo kompozitný režim, aby ste sa uistili, že množina údajov je použiteľná.

Ak je zdroj DirectQuery/Live schopný podporovať pracovné zaťaženie, je pripojenie DirectQuery/Live hodnotnejšie ako výkon a flexibilita, ktorú poskytuje model importu?

Záver

Tento príspevok uzatvára túto sériu o plánovaní projektov LuckyTemplates. Myslím si, že toto sú základné kroky pre každý projekt Power BI, na ktorom pracujete. Tieto kroky sú dôležité pri vykonávaní due diligence, najmä v prostredí podnikového business intelligence.

Všetko najlepšie,

Greg Deckler