2020MichalFiala AbsolvováníindividuálníodbornépraxeIndividualProfessionalPracticeintheCompany VŠB–TechnickáuniverzitaOstravaFakultaelektrotechnikyainformatikyKatedrainformatiky

(1)

VŠB – Technická univerzita Ostrava Fakulta elektrotechniky a informatiky

Katedra informatiky

Absolvování individuální odborné praxe

Individual Professional Practice in the Company

2020 Michal Fiala

(2)

(3)

(4)

(5)

Rád bych tímto krátkým odstavcem poděkoval Ing. Janu Kožusznikovi, Ph.D za odborné vedení při této práci. Dále bych chtěl poděkovat mým vedoucím z firmy Tieto Czech s.r.o, Ing. Petře Crhákové, Ph.D a Ing. Danu Bierzovi za odborné rady pro řešení této práce. Rovněž bych chtěl poděkovat rodině a své přítelkyni za morální podporu.

(6)

Abstrakt

Účelem této bakalářské práce je popis absolvování studentské stáže ve společnosti Tieto Czech s.r.o. Náplní stáže bylo analyzování a porovnání stejného Business Intelligence řešení na dvou platformách a následná migrace z jedné platformy na druhou. Jednalo se o vícerozměrné datové kostky, které se nachází ve ON-PREMISE platformě. Po zvážení, pro nové řešení, byla vybrána platforma Microsoft Azure. Tam se následně využily služby jako Azure Automation, Azure Data Factory a Azure Data Bricks pro načtení a očištění dat. Pomocí technologie Power BI byla data transformována do finálního produktu. Nakonec bylo provedeno srovnání výkonu, spolehlivosti a dostupnosti.

Klíčová slova: ON-PREMISE, datové kostky, Business Intelligence, Microsoft Azure, Azure Automation, Azure Data Factory, Power BI, Azure Data Bricks

Abstract

The purpose of this bachelor thesis is describtion of intership in company named Tieto Czech s.r.o. Purpose of the intership was to analys and compare two same Business Intelligence solutions on different platform and their migration from one platform to the other one. By solution is meant multidimensional data cubes. After consideration, the platform for new solution was selected Microsoft Azure. There were then used cloud services like Azure Automation, Azure Data Factory and Azure Data Bricks for load and cleaning of the data. With help of technology Power BI data were transformed into final product. Finally, there were comparison of power, reliability and availability.

Keywords: ON-PREMISE, data cubes, Azure, Powershell runbook, Azure Data Factory, Power BI, Azure Data Bricks

(7)

Obsah

Seznam použitých zkratek a symbolů 9

Seznam obrázků 10

Seznam tabulek 11

Seznam výpisů zdrojového kódu 12

1 Úvod 13

2 O společnosti 14

2.1 Základní popis firmy . . . 14

2.2 Základní popis oddělení . . . 14

2.3 Business Intelligence . . . 14

3 O Zákazníkovi 18 3.1 Základní informace . . . 18

3.2 Struktura organizace . . . 18

3.3 Migrační plán zákazníka . . . 18

4 Zadané úkoly a pracovní zařízení 24 4.1 Pracovní zařízení . . . 24

4.2 Zadané úkoly . . . 24

5 Použité technologie 26 5.1 T-SQL a SSMS . . . 26

5.2 Visual Studio . . . 26

5.3 Power BI . . . 26

5.4 Azure . . . 27

6 Technické řešení 29 6.1 Zvolený postup při řešení zadaných úkolů . . . 29

7 Použité a chybějící znalosti 38 7.1 Použité znalosti . . . 38

7.2 Chybějící znalosti . . . 38

8 Závěr 39

Literatura 40

7

(8)

Přílohy 43

(9)

Seznam použitých zkratek a symbolů

ETL – Extract, Transfrom and Load

SSIS – SQL Server Integration Services

UAT – User acceptance testing

API – Application Programming Interface OLAP – Online Analytical Processing

DSL – domain specific language

VNET – virtuální sítě

PaaS – Platform as a service

IoT – Internet of Things

AD – Active Directory

CSV – Comma-separated value

ER model – Entity-relationship model

SSMS – SQL Server Management Studio

GUI – Graphical user interface

9

(10)

Seznam obrázků

1 Přístup architektury dle Inmona [15] . . . 16

2 Přístup architektury dle Kimballa [16] . . . 16

3 Star schema a OLAP kostka [5] . . . 17

4 Struktura organizace . . . 23

5 Krátký kód v jazyce M . . . 26

6 Schéma datového skladu podle Kimballa [12] . . . 30

7 Architektura ON-PREMISE řešení . . . 30

8 Architektura v Microsoft Azure . . . 32

9 PowerShell Runbooky v Azure . . . 34

10 Architektura "Users"Kostky . . . 44

11 Architektura "Surveys"Kostky . . . 45

12 Architektura "Energycomp"Kostky . . . 46

13 Nastavený kanál pro zpracování dat . . . 46

14 Spouštěč zapínání kanálu . . . 47

15 Pracovní plocha s vytvořenou sestavou v Power BI . . . 48

16 Přidání práv do pracovního prostředí Power BI . . . 49

17 Struktura tabulek v Power BI . . . 50

18 Graf vytvořeným pomocí dvou mír. . . 50

19 Míra s pevně danými argumenty. . . 51

20 Míra proměnlivými argumenty. . . 51

21 Historie běhů pro kostku "Users"z ON-PREMISE. . . 51

22 Historie běhů pro kostku "Users"z Microsoft Azure. . . 52

23 Historie běhů pro kostku "Surveys"z ON-PREMISE. . . 52

24 Historie běhů pro kostku "Surveys"z Microsoft Azure. . . 53

(11)

Seznam tabulek

1 Časová náročnost jednotlivých úkolů . . . 25

11

(12)

Seznam výpisů zdrojového kódu

1 Kód pro zpracování xlsx souboru . . . 35 2 Pohled pro úpravu Ark data . . . 42 3 DMV kód pro zjištění definice mír . . . 43

(13)

1 Úvod

Formu odborné praxe pro absolvování bakalářské práce, jsem si vybral z důvodu načerpání důležitých životních a profesních zkušeností, které tato možnost nabízí. Z nabídky společností jsem si vybral Tieto Czech, z důvodu její pověsti mezi studenty a kvůli nabídky pozice v sektoru Business Intelligence, která mě zajímá a po dokončení vzdělání bych v ní chtěl i nadále pokračovat.

První část práce budu popisovat firmu, oddělení, úkoly, které mi byly přiděleny a zákazníka, pro kterého budu tyto úkoly vykonávat. Popíšu zde i základní myšlenku a důležité procesy, které se v Business Intelligence využívají. V druhé části uvedu jak jsem tyto úkoly řešil, který software jsem použil a uvedu znalosti, které mi při práci byly užitečné a znalosti, které mi při řešení úkolů chyběly.

13

(14)

2 O společnosti

2.1 Základní popis firmy

Tieto je největší skandinávská IT společnost, která se zabývá soukromým a veřejným sektorem.

Jeho konání začíná ve Finsku v Helsinkách koncem 60. let, v dnešní době má přes 14 000 IT expertů, kteří působí ve více jak 20 zemích. Tieto Czech je české odvětví společnosti, které za- městnává okolo 2600 zaměstnanců v oblasti IT. Jedná se taky o třetí největší pobočku Tieto.

Tieto Czech má i vlastní start-upový program, který podporuje české inovátory a zákazníky.

Také podporují české studenty, díky velké nabídce studentských stáží nebo možnosti absolvo- vání bakalářské práce pomocí odborné praxe. Podle průzkumu patří k pěti nejoblíbenějším IT společnostem mezi českými studenty. [2]

2.2 Základní popis oddělení

Oddělení Business Intelligence, do kterého jsem nastoupil po dobu vykonávání praxe, sídlí z jedné ze dvou poboček v České Republice a to v Ostravě. Oddělení se potom rozlišuje do menších týmů, které se zajímá o zpracování firemních nebo zákaznických dat. Tým, do kterého jsem byl přidělen, pracuje na řešeních pro jednoho konkrétního zákazníka z Norska. Mezi služby, které nabízí zákazníkovi, patří například budování datových skladů a datových struktur nebo integrace dat. Dále tým pracuje na vytváření sestav, které umožňují zákazníkovi analyzovat data, bez nutnosti technických znalostí. Jako poslední je zajištěna kompletní podpora nového i starého Business Intelligence řešení.

2.3 Business Intelligence

Na internetu je veliká variace jak definovat Business Intelligence. obecně se jedná o kombinaci strategie a technologie pro shromáždění, analýzu a interpretaci dat z interního a externího zdroje, kde konečný výsledek tkví v poskytování informací o minulosti, současnosti a budoucím stavu subjektu, který je zkoumán.[1]

2.3.1 Datový sklad

Business inteligence je převážně zaměřena na obchodní analýzu dat zákazníka, proto jednou z důležitých zásad je používání datového skladu. Datový sklad je typ systému správy dat, který je navržen tak, aby umožňoval a podporoval aktivity business intelligence (BI), zejména analýz.

Datové sklady jsou určeny výhradně k provádění dotazů a analýz a často obsahují velké množství historických dat. Data v datovém skladu jsou obvykle odvozena ze širokého spektra zdrojů, jako jsou soubory protokolu aplikací a transakční aplikace.[3]

Datové sklady rozlišuje zejména na dva hlavní typy metod, jak navrhnut architekturu skladu.

První metoda byla navržena Williamem H. Inmonem a druhá metoda byla navržena Ralphem

(15)

Kimballem. Je prokázáno, že oba přístupy jsou úspěšné pro dodání datových skladů. Jejich rozdíly jsou v kladech a záporech daných metod. Hlavními faktory určující, který přistup je vhodnější pro dané řešení, jsou požadavky na analýzu dat, množství potřebného času na implementaci datového skladu, četnost změn a organizační kultura. [4]

Rozdíly těchto přístupů je možné vidět v následujících obrázcích 1, 2.

2.3.2 Dimenzionální modelování

Ke správnému využití datové skladu, patří dimenzionální modelování. Jedná se o techniku, která je preferována pro prezentaci analytických dat, protože poskytuje data srozumitelná podnikovým uživatelům a zajišťuje rychlý výkon dotazů.

Podle Ralpha Kimballa můžeme k implementaci dimenzionálních modelů přistupovat dvěma způsoby. První možnost, tzn. "Star Schema"je metoda, kdy se implementuje na relační databázi.

Druhý způsob je v implementaci vícerozměrné databáze, nazývanou "Online Analytical Proces- sing(OLAP) cube", tyto metody jsou vyobrazeny na obrázku 3. Logický design obou metod je stejný, liší se pouze ve fyzické implementaci. Ralph Kimball doporučuje používání obou způsobů modelování současně, kde "Star Schema"je vhodné pro načtení podrobných atomických informací a použití OLAP kostek pro naplnění dat z "Star Schema".[5]

15

(16)

Obrázek 1: Přístup architektury dle Inmona [15]

Obrázek 2: Přístup architektury dle Kimballa [16]

(17)

Obrázek 3: Star schema a OLAP kostka [5]

17

(18)

3 O Zákazníkovi

Z důvodu zachování důležitých informací a know-how firmy, jméno zákazníka a názvy případ- ných objektů a názvů objevujících se v řešení, budou cenzurovány. Cenzura bude formou pře- jmenování na všeobecné názvy. U jednotlivých jmen datových kostek, budou názvy vymyšlené.

V prostředí softwaru firmy, budou ostatní objekty, které nebudou důležité pro úkoly odborné praxe rozmazány a to se týká i citlivých dat.

3.1 Základní informace

Zákazník je Norská industriální společnost operujících na polích energie a širokopásmovém při- pojení, založené na optických vláknech. Společnost začala svoji činnost na začátku roku 1999, ale její kořeny sahají víc jak 100 let zpátky v čase. V současné chvíli je společnost vlastněna 16 obcemi.

Momentálně je Zákazník významný národní operátor v oblasti obnovitelných zdrojů energie.

Navíc během posledních patnácti let, se Zákazník rozšířil na pole působení v budování a správě plynovodů a chytrých domů.

3.2 Struktura organizace

Zákazník je organizovaný do několika malých společností, kde hlavní odvětví Zákazník AS je mateřskou společností.

Mateřská společnost má vlastnickou roli v plně vlastněných a částečně vlastněných společ- nostech. Organizuje běžné funkce, jako je ekonomika, finance, marketing, personalistika, komunikace, právní záležitosti, veřejné zakázky, služby v oblasti nemovitostí atd. Skupina je organi- zována ve třech oblastech podnikání: energie, infrastruktura a telekomunikace. Rozdělení skupin a společností je popsán v obrázku 4.

3.3 Migrační plán zákazníka 3.3.1 Důvod migrace

Myšlenka migrace byla zahájena na přání zákazníka, kterému nevyhovuje z dlouhodobého hlediska stávající řešení a chtěl by investovat do nových technologií. Momentálně je na ON-PREMISE řešení 54 OLAP kostek, které jsou denně používány Zákazníkem, nebo zákazníky od Zákazníka.

3.3.2 Plán migrace

Tieto Czech přišlo s návrhem na migraci kostek a předneslo, jak by se mělo postupovat po čtyřech jednotlivých krocích. Jako první krok je nutné provést tzn. „0. stage“.

(19)

Jedná se o fázi, kterou je nutné splnit před migrací jakékoliv kostky. V tomto kroku, se jedná o předělání zdrojů dat, které se používají v ON-PREMISE řešení. "0. stage"je dále rozdělena na tři kroky a jednotlivé dílčí kroky.

1. Analýza

(a) Analyzovat, které tabulky se používají v jednotlivých kostkách (b) Jaký průběh ETL je nastavený pro každý objekt

(c) Jak změnit nebo uložit xlsx soubory v novém prostředí 2. Implementace

(a) Přesunutí všech závislých databází do Microsoft Azure Managed Instance

(b) Přesunutí procesů pro extrakci a proces Data Martu do Microsoft Azure Data Factory 3. Závislost

(a) Závislosti na jiné kostky (b) Závislosti na API řešení

Po dokončení "0. stage"přišly na řadu zbylé kroky. Jedná se o typy provedení migrace, řešení častých chyb, strategie UAT a dekomise starého řešení.

3.3.3 Typy provedení migrace

Se zákazníkem se odsouhlasili tři typy migrace, které budou použitelné pro všechny kostky.

1. Lift and shift

Tento scénář je nejjednodušší variantou migrace, jedna se o přenesení kostky bez nutnosti vývoje nového řešení. Tento scénář dále rozdělujeme na dva typy:

(a) Bez nutnosti předělání zdrojových dat

Pro kostky, které můžou používat stejný zdroj dat jako na ON-PREMISE řešení a není zde nutnost jakékoliv úpravy ani žádného vývoje kostky. Kostka se pouze přenese do Microsoft Azure platformy.

(b) S nutností předělání zdrojových dat

Zde je nutné aby byl dokončen krok "0. Stage", kde přesunutá kostka bude používat nově implementované datové zdroje v Microsoft Azure prostředí. I přesto, ani zde nebude nutný vývoj na kostce a kostka bude stejná jako na ON-PREMISE.

2. Cubes development

Tento scénář bude probíhat nejčastěji. Jedná se o migraci, kde bude nutný vývoj na kostce.

Ať už z důvodu obměnění stávajícího řešení, změny kvůli jinému prostředí nebo požadavku změny řešení v kostce ze strany Zákazníka. Tento scénář je rozdělen na dva typy:

19

(20)

(a) Azure kostka

Jedná se o vytvoření datové kostky v Microsoft Azure platformě. Zde je nutný návrh a architektura kostky, následný samotný vývoj, implementace a UAT.

(b) PowerBI dataset

Kostka bude předělána do softwaru Power BI. Znamená to, že samotná kostka za- nikne, místo toho, se vytvoří datová sada, která v sobě bude mít všechny data a logiky kostky. I zde je nutný vývoj, návrh architektury, následná implementace a UAT.

3. Dekomise

Jedná se o kostky, které zákazník už nepoužívá nebo v budoucnu nebude používat. Není zde potřeba pro předělání do Microsoft Azure platformy. Proces dekomise je stejný pro všechny podtypy hlavního scénáře, dělí se jenom v tom, co se zálohuje.

(a) Zdrojový kód

Uložení zdrojového kódu na verzovací systém zákazníka.

(b) Zdrojový kód a data

Uložení zdrojového kódu na verzovací systém zákazníka, uložení dat z Data Mart a uložení logiky kostek.

(c) Zdrojový kód a anonymizovaných dat

Uložení zdrojového kódu na verzovací systém zákazníka, uložení dat z Data Mart, které projdou procesem anonymizace a uložení logiky kostek.

3.3.4 Řešení častých chyb

V průběhu migrace může dojít ke spoustě problémům a počítá se s možnými komplikacemi, proto se rozhodlo, jak postupovat při nejčastějších chybách, které můžou v průběhu migrace nastat, aby se ušetřilo co nejvíce času a prostředků.

1. Špatné data v Azure databázi

Problém se řeší připojením nově vyvinuté Microsoft Azure kostky k ON-PREMISE data- bázi. ON-PREMISE kostky a databáze pojedou ještě tři měsíce po úspěšné migraci řešení do Microsoft Azure. Právě kvůli možnosti špatných dat z důvodu špatné integrace zdrojů.

2. Uživatelé bez přístupu

Při tomto problému, je nutná manuální práce pro tým servisních pracovníků z firmy Tieto Czech, je nutné ruční přidělování práv pro nové kostky v Microsoft Azure. Může nastat situace, kde je zapotřebí nastavování nových přístupových rolí, které ve starém řešení nebylo. Aby se co nejvíce eliminovalo toto riziko, bude se klást důraz na UAT a dané testovací scénáře pro každou kostku.

(21)

3. Vylepšená nebo přesunutá kostka má špatnou logiku

Problém se řeší pomocí porovnání zálohovaného zdrojového kódu a porovnání starých dat z ON-PREMISE řešení. Dále se dá použít navrácení do stavu, kdy logika byla správná.

3.3.5 Strategie UAT

Zákazníkovi byly předloženy čtyři návrhy jak provést UAT, zákazník si posléze z nich vybral, který návrh použije a bude pro něho nejpřijatelnější, protože každý z návrhů má pro zákazníka i Tieto Czech různé klady a zápory.

1. UAT – pomocí společnosti 2. UAT – pomocí kostky 3. UAT – vše dohromady 4. UAT – podle serveru

3.3.6 Dekomise starého řešení

Důležitým rozhodnutím bylo ujednání kroků pro dekomisi. Jak již bylo zmíněno, staré řešení bude v provozu ještě tři měsíce, tento čas se začne počítat až po úspěšném UAT. Výjimkou jsou kostky, které budou zařazeny rovnou do scénáře dekomise. Tyto kostky, se budou dekomisovat, jakmile Zákazník určí pevné datum pro smazání.

Dále se dojednaly jednotlivé kroky, kterými se musí řídit Tieto Czech a Zákazník. Celý proces má čtyři kroky a musí se všechny dodržet a jejich schválení se musí archivovat.

1. Vytvoření objednávky pro dekomisi

V prvním kroku, je nutné, aby zákazník vytvořil tzn. "objednávku pro dekomisi", ty může vytvořit pomocí interního Tieto Czech systému. Tato objednávka v sobě musí obsahovat informace o datu, kdy se dekomise má provést, jméno kostky, která má být smazána a typ zálohy, kterou má IT pracovník provést.

2. Odstranění přístupu a zmražení kostky

Jako druhý krok bude odstranění přístupu. Tenhle krok už je prováděn přímo Tieto Czech IT pracovníkem. Je nutné, aby se otestovalo, zda opravdu kostku nikdo nepoužívá. Zmraže- ním kostky se pak myslí vypnutí jednotlivých automatických procesů, které kostku zpra- covávají. Díky tomu kostka nebude mít nové data. Pokud je tedy jiné řešení závislé na kostce co má být smazána, tímto krokem se to projeví. Toto opatření se provádí v periodě dvou týdnů.

3. Záloha

Předposlední krok dbá na zálohu. Tady se postupuje podle toho, co bylo nastaveno v objednávce. Zákazník má možnost vybrat si jednu z tří již zmíněných typů záloh.

21

(22)

4. Smazání kostky

V posledním kroku, jakmile je kostka zálohována a neprojeví se závislost na jiné řešení, dojde k samotnému smazání kostky a tím je dekomise dokončena.

(23)

Obrázek 4: Struktura organizace

23

(24)

4 Zadané úkoly a pracovní zařízení

V této kapitole je popsáno pracovní zadání a zařízení firmy, jednotlivé úkoly a jejich časová náročnost.

4.1 Pracovní zařízení

Firma Tieto Czech s.r.o je jedna z největších zaměstnavatelů v oblasti IT, je velice známá u studentů díky nabídce praxí. O volné pozici v Business Intelligence jsem se dozvěděl pomocí aktuálně vypsaných otevřených pozic pro absolvování bakalářských praxí. Po odeslání životopisu a motivačního dopisu, jsem byl pozván na pohovor s personalistkou a svým budoucí manažerem.

Na pohovoru jsem musel prokázat své znalosti angličtiny, databází, jazyku T-SQL a také byla prověřena má schopnost logicky myslet.

Po přijetí jsem se připojil do týmu, který sídlí v Tieto Towers v centru Ostravy. Po celou dobu působení v Tietu, jsem pracoval jako specialista BI(Business Intelligence). Náplní mé práce byla integrace a transformace datových kostek a jejich migrace do platformy Azure.

4.2 Zadané úkoly

4.2.1 Zpracování a integrace dat dle základních procesů ON-PREMISE

Náplní tohoto úkolu bylo popsat prostředí ON-PREMISE. Úkol byl rozdělen na architekturu celého řešení, datový tok pro jednotlivé datové kostky a popis technologií a jejich hlavní užití na daných řešeních.

4.2.2 Analýza 3. ON-PREM kostek

V tomto případě, bylo úkolem detailně nastudovat a popsat řešení datové kostky, jednalo se zde o analýzu struktury kostky a její datové logiky.

4.2.3 Zpracování a integrace dat dle základních procesů na Azure platformě Náplní tohoto úkolu bylo popsat prostředí v Azure platformě. Úkol byl rozdělen na architekturu celého řešení, datový tok pro jednotlivé datové kostky a použití technologií a jejich hlavní užití na daných řešeních.

4.2.4 Analýza 3. Azure řešení

V tomto případě, bylo úkolem detailně nastudovat a popsat, jakým typem migrace se bude kostka přenášet do nového prostředí. Jaké řešení je nejlepší pro danou kostku, jaké technologie a software se použije.

(25)

4.2.5 Migrace ON-PREMISE řešení na Azure platformu

Zde bylo mým úkolem předělat stávající ON-PREMISE řešení do nové platformy Azure, bylo důležité držet se analýzy v předchozím kroku, aby se dodržely důležité principy, které má kostka představovat.

4.2.6 Porovnání ON-PREMISE řešením s Azure platformou

V posledním úkolu jsem měl porovnat staré ON-PREMISE řešení s nově vytvořeným řešením v Microsoft Azure platformě, zde bylo nutné porovnat zejména časovou náročnost obou řešení, spolehlivost a peněžní diferenci.

4.2.7 Časová náročnost jednotlivých úkolů Následné časy jsou uvedeny v jednotkách dnů.

Tabulka 1: Časová náročnost jednotlivého úkolu

Název úlohy Čas potřebný k vykonání

Zpracování a integrace dat dle základních procesů ON-PREMISE 8

Analýza 3. ON-PREM kostek 8

Zpracování a integrace dat dle základních procesů na Azure platformě 8

Analýza 3. Azure řešení 8

Migrace ON-PREMISE řešení na Azure platformu 12

Porovnání ON-PREMISE řešením s Azure platformou 10

25

(26)

5 Použité technologie

V této kapitole budu popisovat, které technologie a software jsem používal při vypracování odborné praxe.

5.1 T-SQL a SSMS

S technologií T-SQL a programem SSMS jsem se setkal již v průběhu studiu. Novinkou pro mě bylo zajímavé využití GUI v SSMS, při kterém bylo možno zjistit spoustu věcí bez napsání řádky kódu. Zajímavé bylo také používání a prohlížení služeb, jako je analytická služba, nebo služba integrační. Velkou část praxe jsem strávil ve službě SQL Agent, kde je možné pomocí plánovače úkolů, jednoduše nastavit automatizaci celého řešení a běhu databáze.

5.2 Visual Studio

Stejně jak tomu bylo u SSMS, i s Visual Studio softwarem jsem se setkal při studiu. Ale i zde, pro mě bylo nové používání Microsoft rozšíření, které práci s programem výrazně změnilo. Jednalo se zde zejména o rozšíření používané v odvětví "Data Science". Nejvíce používané rozšíření bylo

"SQL Server Integration Services Projects"[13], které umožňuje otevřít architekturu celé OLAP kostky. Pomocí rozšíření bylo možné si kostku zobrazit na jednotlivé dimenze a míry, nebo kostku otevřít v pohledu propojení jednotlivých tabulek. Tak jako jsem byl zvyklý z ER modelu databáze. Další důležité rozšíření bylo "Microsoft Analysis Service Projects"[14], které umožnilo vytvoření a editace jednotlivých SSIS balíčků. U nich bylo možné tvořit balíček pomocí GUI prostředí, podobné "Windows Froms"známé z .NET frameworku, nebo bylo možné celý balíček vytvořit pomocí klasického C#kódu.

5.3 Power BI

Power BI je kolekce softwarových služeb, aplikací a konektorů, které společně dokážou přeměnit nesouvisející zdroje dat na ucelené, vizuálně poutavé a interaktivní přehledy poznatků.[6]

Dále se PowerBI rozděluje na "Power BI Desktop"a služba Power BI. Z hlediska vývoje je pro nás důležité zejména "Power BI Desktop"jelikož nám nabízí možnost tvoření datové sady a vytváření sestav nad daty.

Zajímavý je i DSL jazyk "Power Query M", přes který je možné editovat data a vytvářet grafy nebo jiné funkce. Je možné používat i nejpopulárnější jazyky pro "Data Science"R a Python.

Obrázek 5: Krátký kód v jazyce M

(27)

5.4 Azure

Azure je kompletní cloudová platforma. Integruje cloudové služby, které potřebujete k vývoji, testování, nasazování a správě aplikací. Díky kompletnosti Azure, je možné vybudovat celé řešení, bez nutnosti jediného hardwaru. Momentálně je tak rozšířený v počtu služeb, že je možné zde udělat řešení mířené od Business Intteligence sektoru až po normální desktopové aplikace. Proto zde popíšu pouze služby, které jsem přímo využil v zadaných úkolech. Jednou z největší výhod je veliká škálovatelnost služeb a možnost průběžných plateb bez nutnosti správy licencí. [7]

5.4.1 Azure Managed Instace

"Managed Instace"je nový způsob, jak nasadit SQL databázi. Její hlavní výhodou je vysoká kompatibilita s SQL Server na ON-PREMISE řešením. Microsoft udává, že se jedná o téměř 100

% . Mimo jiné, "Managed Instace"implementuje nativní VNET, který má v sobě zabudované bezpečnostní principy. Díky již zmíněné vysoké kompatibilitě, je přenos ON-PREMISE řešení do cloudu bez větších problémů a nemusíme se potýkat s problémy typu staré verze SQL Serveru.

Poslední výhodou je zachování možností PaaS. [8]

5.4.2 Azure Data Factory

Jedná se o cloudovou službu ETL a integraci dat, která umožňuje vytvářet pracovní postupy řízené daty pro orchestraci přesunu dat a transformaci dat ve velkém měřítku. Důležitá je možnost ingestovat data z různorodých zdrojů pomocí jiných cloudových služeb jako je Azure Data Bricks, nebo Azure SQL Database. Automatické naplánování procesů pomocí zabudovaného plánovače, na principu spínačů z databáze. Transformace dat, které můžete publikovat do úložišť jako jsou datové sklady nebo datové jezera. S Data Factory se pracuje podobně jako je to u SSIS balíčků.

Zde je navíc možnost, vyvolávat procesy z jiných odvětví Azure cloudu, např. Runbooky z Azure Automation nebo ingestace dat pomocí Data Bricks. Je možné přímé připojení na ON-PREMISE databáze, jak k SQL serveru od Microsoft, nebo databází od Oracle. [9]

5.4.3 Azure Automation

Je cloudová služba, zajišťující automatizaci a konfiguraci řešení. Zahrnuje automatizaci procesů, správu konfigurace, správu aktualizací. Automatizace poskytuje plnou kontrolu nad nasazením, provozem a vyřazením úloh a prostředků z provozu.

Automatizace procesů podporuje integraci služeb Azure a dalších veřejných systémů potřebných k nasazení, konfiguraci a správě komplexních procesů. Služba umožňuje vytvářet Runbooky v grafickém prostředí, v PowerShellu nebo pomocí Pythonu.Tyto runbooky slouží k zpracování dat z mnoha oblastí v Microsoft Azure. Jejich zpracování a funkce je velice podobná jako procesy spouštěné v SQL Server pomocí SQL Agenta.

Pomocí Hybrid Runbook Worker můžete sjednotit správu pomocí orchestrace napříč místními prostředími.[10]

27

(28)

5.4.4 Data Bricks

Je analytická platforma, která je založena na technologii Apache Spark. Jedná se o open-source, který byl optimalizovaný pro použití v Microsoft Azure. Největší využití této technologie je v extrakci a vyčištění velkého objemu dat, za relativně krátký čas, nebo možnost načtení dat z téměř všech typů souboru. Výsledek je potom možné nahrát do cloudových služeb, které s daty pracují. Nejčastěji se používá při spolupráci s Azure Data Factory, který má problém s velkými objemy dat, nebo při práci s IoT čidly.[11]

(29)

6 Technické řešení

6.1 Zvolený postup při řešení zadaných úkolů

6.1.1 Zpracování a integrace dat dle základních procesů ON-PREMISE 1. Základní popis úkolu

Mým úkolem bylo popsat architekturu celého řešení. Zejména bylo nutné zmapovat celou infrastrukturu, jako jsou servery s databázemi, zdroje dat a výstupní kanály. Dále bylo nutné popsat a vyobrazit jednotlivé procesy pro mě přidělené datové kostky, pomocí softwaru SSMS.

2. Řešení úkolu

Celková architektura infrastruktury je zpracována do obrázku 7. Ten jsem vytvořil podle informací z dokumentace o řešení, která byla vytvořena z důvodu předání informací pro firmu Tieto Czech, při přebírání celého projektu. Ostatní informace, jako procesy da- tové kostky a pravidelné zapínaní procesů, jsou získány pomocí prohledání SQL Agenta v softwaru SSMS. Průměrnou délku běhu můžeme odvodit pomocí historie běhů procesů.

Všechny tyto informace můžeme nalézt v příloze ve formě obrázků.

Architektura databáze je vytvořena jako datový sklad podle návrhu od Ralpha Kimballa používající kombinaci "Star Schema"a OLAP kostky, kde databáze je rozdělena do "Sta- ging"a "Data Mart"vrstvy.

(a) Staging

"Staging"databáze slouží jako koncové úložiště ETL procesů. To znamená, že se do téhle vrstvy uloží všechny data, které ještě nejsou zpracovány pomocí byznys logiky a dalších procesů tvořící vyčištěná data.

(b) Data Mart

Slouží k procesu dat ze "Staging"vrstvy. Pomocí T-SQL příkazů, které obsahují důle- žitou byznys logiku, vytváří podmnožinu dat z které čerpá datové skladiště a OLAP kostky samotné.

29

(30)

Obrázek 6: Schéma datového skladu podle Kimballa [12]

Obrázek 7: Architektura ON-PREMISE řešení

6.1.2 Analýza 3 ON-PREM kostek 1. Základní popis úkolu

Zde bylo nutné popsat architekturu kostek, které jsem dostal přidělené. Důležité bylo analyzovat jejich funkci. Dále bylo nutné nastudovat SSIS balíčky, které kostku zpracovávají a tvoří dimenze a míry. Vedoucí týmu mi přidělil tři kostky. Jmenují se "Users", "Surveys"a

"Energycomp"

2. Řešení úkolu

Architekturu kostek, jsem zjistil pomocí archivovaných zdrojových kódů, které jsem dostal k dispozici. Samotné kostky jdou otevřít v programu Visual Studio, ale to musí mít nainstalované potřebné rozšíření, jak jsem již zmínil v kapitole 5.

Jakmile si otevřeme zdrojové kódy a přepneme se do režimu "Modular", je možné přehledně vidět složení tabulek a jejich propojení, viz. obrázky 10, 11.

(31)

Druhým krokem v úkolu byla analýza SSIS balíčků, které kostku zpracovávají. Ty jsou taky možné vidět pomocí Visual Studio. Ale i zde, je nutné mít nainstalované rozšíření, které nám umožňuje otevřít a upravovat jednotlivé balíčky.

Poslední krok bylo analyzovat jejich byznys funkci. Tenhle krok byl možný zjistit pouze nastudováním dokumentace k dané kostce. Pouze pomocí analýzy dat není možné jasně určitě tuto logiku.

Funkce kostky "Users"spočívá v udržování informace, kteří uživatelé Zákazníka mají pří- stup na jednotlivé kostky v celém ON-PREMISE řešení. Jsou zde uloženy všechny role, které kostky obsahují. Ty jsou propojené pomocí AD skupin a přidělují se na jednotlivé uživatelské účty.

Kostka "Surveys"má funkci podávání informací ohledně ohlasu Zákazníka. Zákazník posílá svým zákazníkům online průzkumy, které musí vyplnit a ty jsou potom posílaný jako xlsx soubory na analýzu. V průzkumech je několik otázek, které jsou orientované jak na byznys, PR společnosti nebo základní informace o firmě. Tyto data jsou potom analyzovány a využity.

"Energycomp"slouží jako datová kostka obsahující informace z postavených měřících pří- strojů. Konkrétně se jedná o měření spotřeby u plynovodů. Na tuto kostku je potom při- pojené API řešení, které slouží uživatelům v internetovém portálu, jako přehled spotřeby energie.

6.1.3 Zpracování a integrace dat dle základních procesů na Azure platformě 1. Základní popis úkolu

Úkolem bylo zmapování cloudových služeb, které zákazník používá. Poslední část tohoto úkolu bylo, seznámit se s již předělanými zdrojovými daty a architekturou databáze, která vznikla po dokončení "0. stage".

2. Řešení úkolu

K přehlednému zmapování služeb používané Zákazníkem jsem vytvořil obrázek 8.

Architektura databáze stejně jako u ON-PREMISE řešení, je tvořena jako datový sklad podle návrhu od Ralpha Kimballa používající "Star Schema". Zde jsou databáze rozděleny do pěti vrstev databáze.

(a) Metadata

Slouží k uchovávání důležitých informací ohledně ETL.

(b) Ark

Vrstva používána na přenos dat, obdoba "Staging"databáze. Všechny nezpracované data, které jsou získány pomocí ELT jsou uloženy zde. Od téhle vrstvy se s daty začíná

31

(32)

pracovat na databázové úrovni a jsou dále upravovány a ohýbány podle daných kritérií a byznys logiky.

(c) ANO

Vrstva sloužící k uchování dat a jejich anonymizace. V těchto databázích můžeme najít data, které jsou staré dva a více let. Je to z důvodu GDPR, kde Zákazník sdělil, že data starší dvou let proběhnou anonymizací, pokud v sobě budou mít citlivé data.

(d) Data Mart

Stejně jako u ON-PREMISE, slouží jako spojka mezi aplikační vrstvou a databází.

Všechny změny dat a počítaní jsou dělány na téhle úrovni. Dále se tato úroveň používá jako pomyslné zapouzdření, aby nebylo možné přistupovat k datům z Ark vrstvy.

Obrázek 8: Architektura v Microsoft Azure

6.1.4 Analýza 3 Azure řešení 1. Základní popis úkolu

Zde bylo nutné rozhodnout, které scénáře pro jednotlivé kostky použiji. Které služby budou potřebné pro zpracování zdrojových dat kostek a určit, v jaké podobě bude finální řešení.

2. Řešení úkolu

Služby, které jsem vybral, jsou popsány v kapitole Použité technologie viz. 5. Jelikož je každá kostka jiná, rozhodl jsem se tento úkol rozdělit po jednotlivých kostkách.

(a) "Energycomp"

Při analyzování ON-PREMISE kostky v předchozím kroku, jsem zjistil, že již není zákazníkem používá. Je to z důvodu vytvoření nové API. To splňuje stejnou funkci jako staré řešení, ale navíc má v sobě zahrnuté i ostatní odvětví spotřeby energie, které zákazník nabízí. Z toho důvodu jsem rozhodl, že pro tuto kostku bude použit scénář dekomise. Není tedy nutné zabývat se tím, které služby by byly potřebné.

(33)

(b) "Users"

Kostka "Users"hraje důležitou roli pro přehled oprávnění. Je tedy nutné ji přenést do nového řešení, navíc zde bude nutná úprava, jelikož staré řešení pracuje pouze s ON- PREMISE AD skupinami a jejich kostkami. Do nového řešení se tak musí přidat nové oprávnění z nově vytvořených kostek v Microsoft Azure. Navíc zde bude muset být i propojení pomocí Azure AD grafu, kde jsou uložené nově vytvořené AD skupiny pro Azure samotný. Z těchto důvodů, použije cloudovou službu Data Automation, kde pomocí Powershell Runbooku, kterému se přidělí nutná oprávnění, je možná tyto data získat. Takto ingestované data budeme používat ve službě Data Factory, která bude ovládat celý proces ETL a následně upravené data uloží do Managed Instance, která slouží jako databáze. Jako poslední funkci musí nová kostka obsahovat i staré řešení, neboť staré kostky se budou migrovat v průběhu delším než tři měsíce. Což je doba pro zachování staré kostky na ON-PREMISE. Kostka nebude obsahovat veliké množství dat, nebude náročná na zpracování a bude mít rychle vypočítané míry, s ohledem na tyto poznatky, není potřebné kostku předělávat do OLAP Azure kostky, ale bude stačit vytvoření Power BI data setu, na který se udělají sestavy pracující s těmito daty.

(c) "Surveys"

U kostky "Surveys"nebude nutné předělávat nic co se týče zpracovávání dat, byznys logiky nebo sestavy nad daty. Protože vstupní data budou formou xlsx souboru, využiji službu Azure Data Bricks, která soubor přeloží do CSV formy. Proces ETL zde bude tvořený použitím Azure Data Factory a data budou uloženy do stejné Managed Instance, jako data kostky "Users". Jediný rozdíl bude ve finálním řešení, kde místo kostky, se použije scénář vytvoření Power BI data setu ze stejných důvodů jako u

"Users".

6.1.5 Migrace ON-PREMISE rešení na Azure platformu 1. Základní popis úkolu

Mým úkolem bylo implementovat celé nové řešení pro dané kostky. Důležité bylo používat služby a postupovat podle návrhů, ke kterým jsem se dostal v předchozích krocích.

2. Řešení úkolu

Řešení je rozděleno dle jednotlivých kostek.

(a) "Energycomp"

Scénář dekomise pro mě byl nejjednodušší na provedení. Postupoval jsem podle pře- dem stanovených kroků, které byly dány Zákazníkem, viz. 3.3.6. Po přijetí objednávky na dekomisi, jsem provedl odstranění přístupů a zmražení kostky pomocí softwaru

33

(34)

SSMS. Odstranění jsem prováděl pomocí smazání rolí v kostce a zmražení pomocí za- kázání jednotlivých procesů v SQL Agent. Jelikož se kostka používala v API řešení, bylo nutné monitorovat i ostatní API řešení, zda neobsahují odkazy na kostku.

Software SSMS má v sobě taky funkce, pro vytvoření zálohy, ta se potom přenese na danou archivní databázi a tam se záloha obnoví. Zálohu zdrojového kódu potom uložíme na předem stanovený verzovaný software.

Po uplynutí dvoutýdenního intervalu se kostka smaže z analytické služby, poté se smažou i jednotlivé tabulky a pohledy, které jsou uložené v databázi.

(b) "Users"

Jako první je nutné vytvoření procesu na vyjmutí dat z Azure AD grafu. K tomu byl vytvořen PowerShellový skript. Ten umožňuje přihlášení do grafu pomocí použití objektově instanční aplikace, která má speciální práva obcházející zabezpečení, pro normální služby a jiné aplikace. Druhým krokem bylo vytvoření stejně fungujícího skriptu, který bude vyjímat data ze starého řešení. Poté byly vytvořeny čtyři Power- Shellové runbooky v Azure Automation, které umožňují spouštění skriptů i z jiných služeb. Každý Runbook načítal jinou část informace z AD grafu. Těmto runbookům nebyl přidělený spouštěč na automatické zapínání. Automatizace je řešená pomocí Azure Data Factory, která runbooky volá a spouští je kdy potřebuje.

Obrázek 9: PowerShell Runbooky v Azure

V Azure Data Factory byl vytvořen kanál, který ovládá orchestraci a zpracování dat.

Důležité jsou nástroje "Webhook", které spouští jednotlivé Runbooky a získávají data jako soubory, které jsou kvůli archivaci uloženy do Azure Data Lake a nástroj "Copy Data", který z těchto souborů kopíruje data přímo do SQL managed Instance (viz obr. 13).

Na tento kanál byl nastavený spínač, který můžeme vidět na obrázku 14, ten spouští proces jednou denně v 01:00.

Kostka "User"používá jako v Managed Istance Ark databáze s názvem „Ark_AD“, tam se nachází tabulky, do kterých se vlívají data z Data Factory. Jako Data Mart je použita databáze "DM_Users", kvůli velikosti kostky a počtu dat, které bude obsahovat, nebylo nutné abych zakládal tabulky. Všechnu práci obstarají tři pohledy.

Jelikož kostka obsahuje pouze data zaměstnanců Zákazníka, není zde nutnost zaklá- dání anonymizované databáze.

(35)

Byznys logika celé kostky, je přehledný seznam uživatelů. Musí se proto upravit výpis dat. Data, které ukazují na ON-PREMISE AD skupiny, jsou již připravené po přenosu z Data Factory. U dat, které mají informace z Azure AD, zde bylo nuceno udělat několik změn. Zejména jde o spojování tabulek a přidávání prefixů. Na SQL kód je možné se podívat zde 2.

Poslední pohled slouží k propojení Azure AD dat a ON-PREMISE dat. Tenhle pohled je i pak použitý jako jediný datový zdroj pro datovou sadu používající v Power BI.

V Power BI desktop aplikaci, již jen stačilo si nastavit datový zdroj pomocí "Di- rectQuery"a vytvořit sestavu, která bude sloužit zákazníkovi jako přehled uživatelů.

Protože se jedná o pouhý seznam, nebylo zde nutné nijak nastavovat míry. Byla pouze udělána plocha, která se skládá z interaktivního prostředí s daty a z filtrů. Z velké části, je toto podobné staré technologii "PowerPivot"od Microsoft Excelu. Pracovní plochu můžeme zhlédnout na obrázku 15.

Jako poslední krok migrace je pak nasazení vytvořené datové sady a sestavy do online služby Power BI. To provedeme pomocí tlačítka "Publish", které můžeme vidět na obrázku 15. Jakmile je řešení ve službě, je nutné přidělit práva pro přístup do daného pracovního prostoru (viz. obrázek 16.). Po dokončení je migrace hotova.

(c) Omdomne

Prvním krokem, bylo připravení procesu pro zpracování xlsx souborů. Proces je tvo- řený v Azure Data Bricks, jedná se o jednoduchý skript v jazyce Scala, který je velice podobný jazyku Java. Tento skript načte xlsx soubor a přepíše ho do csv formátu, s kterým již dokáže pracovat Data Factory.

val df = spark.read

.format("com.crealytics.spark.excel") .option("useHeader", "true")

.option("inferSchema", "true")

.load("/mnt/adls/clusters/maindatalake/staging/surveys/xlsx_files /15101153_surveys.xlsx")

df.coalesce(1).write .mode("overwrite")

.format("com.databricks.spark.csv") .option("header", "true")

.save("/mnt/adls/clusters/maindatalake/staging/surveys/csv_files /15101153_surveys")

Výpis 1: Kód pro zpracování xlsx souboru

35

(36)

Teď nastává stejný postup jako bylo u kostky "Users". Je nutné vytvořit kanál v Azure Data Factory, který bude řídit celý proces. Důležitými prvky v tomto kanálu bude zavolání aktivity, která nám načte z Azure datového jezera nové xlsx soubory.

Ty potom pomocí skriptu v Data Bricks následující aktivita konvertuje a aktivita

"ForEach"nakopíruje informace ze souborů do Managed Instance. Ostatní aktivity slouží k zachytávání chyb a k správě monitorování jednotlivých aktivit v kanálu.

V databázi jsou data stejně rozdělená jako v předchozím zadání. V Ark_Surveys najdeme všechny nově zkopírované data z Data Factory, které se sloučili s daty z minulých běhů. Data jsou uložené v tabulkách.

V databázi "DM_Surveys"najdeme čtyři pohledy, které pomocí T-SQL aplikují byznys logiku. Tyto pohledy nebylo nutné vytvářet, jelikož se neměnilo řešení. Pohledy se tedy pouze zkopírovali ze starého řešení a jenom se muselo přepsat názvy tabulek a databází. Pohledy zde využívají logiky klasického Data Martu a jsou tvořeny v "star schéma".

Tímto je databázová úroveň hotová. Nyní je nutné vytvořit datovou sadu v Power BI desktop aplikaci. Jelikož zde pomocí metody "DirectQuery"nekopírujeme pouze jeden objekt, je nutné udělat i propojení tabulek, které se v datové sadě vytvoří. Propojení můžeme vidět na obrázku 17. Můžeme si všimnou že propojení vypadá stejně jako u architektury klasické OLAP kostky ze starého řešení (viz. obrázek 11).

Jakmile jsou tabulky propojené, musí se nastavit míry. Ty budou stejné jako na ON- PREMISE řešení, je možné je tedy zkopírovat. Definici mír na ON-PREMISE řešení jsem zjistil pomocí SQL příkazu 3. Tyto definice jsou psány v jazyce DAX, jazyk

"Power Query M"(viz. 5.3) z toho jazyku vychází a má velice podobnou strukturu.

Bylo tedy nutné přepsat jenom menší nesrovnalosti v syntaxi.

Předposledním krokem bylo vymyšlení míry, která bude zastávat funkci 100% sklá- daného sloupcového grafu, který se v Power BI nenachází. Tento krok jsem vyřešil vytvořením tří mír. První dvě míry měly pevně nakódované parametry a sloužily pro vytvoření sloupcového grafu, kde míry byly využity místo ostatních parametrů. Třetí míra měla parametry proměnlivé. Je tedy možné udělat 100% skládaný sloupcový graf s různými sloupci, ale už není možné srovnávat více os x. Míry a grafy jsou znázorněny v příloze, konkrétně 18, 19, 20.

Poslední krok, publikování a přidání oprávnění je naprosto stejný jako u řešení kostky

"Users", není zde potřeba znovu krok rozepisovat.

6.1.6 Porovnání ON-PREMISE řešení s řešením v Azure platformě 1. Základní popis úkolu

Úkol porovnání řešení, spočívalo ve srovnání rychlosti, spolehlivosti a dostupnosti nově vytvořeného a starého řešení.

(37)

2. Řešení úkolu (a) "Energycomp"

Kostka "Energycomp"je speciální případ, který se nedá srovnat. Jelikož kostka byla smazána, protože byla nepotřebná, automaticky je nové řešení ve všech ohledech lepší.

(b) "Users"

Objem dat se v kostce "Users"ztrojnásobil po přidání nového zdroje. Průměrná doba běhu nového řešení je zhruba o patnáct minut pomalejší, ale kdyby jsme srovnávali stejné množství dat, je rychlost běhu rychlejší přibližně o pět minut. Obě řešení vy- užívají vnitřní systémy jako zdroj dat. Ve srovnání spolehlivosti jsou na tom stejně.

Využitím sestav v Power BI je možné používat online služby, jako je webový prohlí- žeč nebo mobilní aplikace. Díky těmto novým vlastnostem je nové řešení o poznání dostupnější pro Zákazníka.

(c) "Surveys"

Zpracování dat a připravení datové sady je v porovnání se starým řešením, rychlejší v průměru o patnáct minut. Největší podíl na tomto rozdílu má Power BI datová sada, z důvodu toho, že se nemusí přepočítávat za běhu Data Factory. Aktuální data z databáze si sestava načte v momentu, kdy ji Zákazník otevře nebo provede nějakou aktivitu v sestavě. Spolehlivostí, jsou na tom řešení stejně, ani u jednoho se nepodařilo přijít na nedostatky, které by mohli způsobovat nepřipravenost dat. Jediný problém, který může nastat v novém řešení je, když nebude možný přístup k souborům, které se nachází v datovém jezeře. Jak je tomu u minulého případu i zde je využita online služba Power BI, značně rozšiřující možnosti dostupnosti.

37

(38)

7 Použité a chybějící znalosti

7.1 Použité znalosti

Ve firmě Tieto mou hlavní náplní práce byla analýza a zpracování dat. Při zpracovávání mi byly užitečné znalosti, získané v průběhu studia. Zejména se jednalo o Úvod do databázových systému, Technologie databázových systémů 1. a ve velké míře databázové a informační systémy díky naučení se jazyka T-SQL, který byl v průběhu praxe hojně používán. Využil jsem i všeobecné znalosti Windows serverů vyučované v předmětu Správa Windows systémů, u kterých se mi hodili znalosti skupin Active Directory. Protože část řešení se zpracovávala pomocí Visual Studia, kde kódy byly napsány v jazyce C# pomohl mi předmět Programovací jazyky 2. a Architektura technologie .NET a jako poslední jsem využil i základní znalosti Javy z předmětu Programovací jazyky 1.

7.2 Chybějící znalosti

Mé chybějící znalosti se projevili v nových technologiích jako je Microsoft Azure, s kterým jsem se potkal poprvé. Také nástroj Power BI byl pro mne novinkou. Navíc i softwary, které jsem myslel že ovládám, přinesli novinky, které jsem nikdy nepoužil, bylo tedy nutné se všechny tyto znalosti naučit při běhu praxe.

Naštěstí, byly pro mne velikou podporou solidní základy. Zejména databázových předmětů, které mi umožnili rychle pochopit logiku těchto nástrojů.

(39)

8 Závěr

Při vykonání odborné praxe ve společnosti Tieto Czech, jsem pracoval jako Business Intelligence specialita. Mými úkoly bylo navrhnout a posléze vyvinout nová řešení v platformě Microsoft Azure. Během mého působení ve firmě, jsem měl možnost osvojit si technologie pracující s OLAP kostkami a datovými sklady. Získat nové znalosti v nových technologiích jako je Power BI a jeho speciální DSL jazyk.

Vykonání praxe mi přineslo i spoustu poznatků a zkušeností do života a mé budoucí kariéry, kde by chtěl pokračovat v odvětví Business Intelligence. Velkým přínosem bylo také pohybovat se v mezinárodní společnosti, plné IT specialistů. Působil jsem v této společnosti necelých šest měsíců a mohl jsem se tak seznámit z know-how velké korporátní firmy. Důležitá byla také komunikace se zákazníkem a reagování na jeho podněty.

Praxi bych ohodnotil velice kladně. Získal jsem mnoho zkušeností z firemního prostředí, naučil jsem se novým věcem v softwaru, který jsem již používal a hlavně jsem se naučil novým technologiím, které v budoucnu budou velice žádané.

39

(40)

Literatura

Dostupné z https://www.oracle.com/what-is-business-intelligence.html(překlad vlastní)

[2] Our company | Tieto. A leading Nordic IT services and software company | Tieto [online].

Dostupné zhttps://www.tieto.com/cz/about-us/our-company/

[3] Datový sklad [online]. [cit. 2020-05-02]. Dostupné z https://www.oracle.com/cz/

database/what-is-a-data-warehouse/#link1

data-warehouse-design-inmon-versus-kimball/20300(překlad vlastní)

[5] KIMBALL, Ralph. The Data Warehouse Toolkit: The Definitive Guide to Dimensional Mo- deling. 3rd edition. New Jersey: John Wiley, 2013. ISBN 9781118530801.

02.05.2020]. Dostupné z: https://docs.microsoft.com/cs-cz/power-bi/fundamentals/

power-bi-overview

developer/azure-developer-guide

sql-database-managed-instance

introduction

automation-intro

azure-databricks/what-is-azure-databricks

[12] Kimball Schema [online]. Dostupné z: https://bennyaustin.files.wordpress.com/

(upraveno autorem)

(41)

Dostupné z: https://docs.microsoft.com/en-us/sql/integration-services/

integration-services-ssis-projects-and-solutions?view=sql-server-ver15

[14] Analysis Services tabular model designer in Visual Studio | Microsoft Docs. [online].

14.05.2020]. Dostupné z: http://web.stanford.edu/dept/itss/docs/oracle/10gR2/

server.102/b14223/concept.htm

[16] Ralph Kimball data warehouse architecture. zentut - Programming Made Easy [online]. Dostupné z: https://www.zentut.com/data-warehouse/

ralph-kimball-data-warehouse-architecture/

41

(42)

Přílohy

USE [DM_brukere]

GO

SET ANSI_NULLS ON GO

SET QUOTED_IDENTIFIER ON GO

CREATE VIEW [dbo].[V_AD_CubeRole_Azure] as

WITH CUB as ( SELECT DISTINCT

rols.[server]+’/Azure’ AD_Server, rols.[Name] AD_Role,

rols.cube AD_Database,

REPLACE(REPLACE(REPLACE(rolmemb.[MemberName],’@conString’,’’),’@zakaznik .onmicrosoft.com’,’’),’obj:’,’’) AD_MeberName,

perm.[FilterExpression] AD_Filters,

CASE WHEN RIGHT(rolmemb.[MemberName],37)=’@conString’ THEN 1

WHEN RIGHT(rolmemb.[MemberName],21)=’@zakaznik.onmicrosoft.com’ THEN

2

ELSE 0 END IsGroupflag

FROM [ark_ad].[dbo].[CubeRoles] rols

LEFT JOIN [ark_ad].[dbo].[CubeRoleMemberships] rolmemb ON rols.ID=rolmemb.

RoleID and rols.[Cube]=rolmemb.[Database]

LEFT JOIN [ark_ad].[dbo].[CubePermissions] perm ON rolmemb.RoleID=perm.RoleID and rolmemb.[Database]=perm.[Database]

)

SELECT

CUB.AD_Server, CUB.AD_Database, CUB.AD_Role,

adroles.GroupName AD_Group,

(43)

ad.SAMAccountName AD_NTUser, adroles.UserName AD_Name, CUB.AD_Filters--,

-- CHARINDEX(CUB.AD_Database, adroles.GroupName) named FROM [ark_ad].[dbo].[AD_CubeRole_Azure] adroles

INNER JOIN CUB ON CASE WHEN CUB.IsGroupflag=1 THEN adroles.GroupGUID WHEN CUB.IsGroupflag=2 THEN adroles.GroupName

ELSE REPLACE(adroles.UserEmail,’#EXT#@zakaznik.onmicrosoft.com’,’

’)

END=CUB.AD_MeberName AND CASE WHEN CUB.IsGroupflag=2 THEN adroles .GroupName

ELSE adroles.GroupGUID END=CUB.

AD_MeberName

LEFT JOIN [ark_ad].[dbo].[AD_UserDescription] ad ON ad.Email=REPLACE(adroles.

UserEmail,’#EXT#@zakaznik.onmicrosoft.com’,’’) GO

Výpis 2: Pohled pro úpravu Ark data

SELECT

[CATALOG_NAME] AS SSAS_Database_Name, [CUBE_NAME] AS Cube_or_Perspective_Name, [MEASUREGROUP_NAME] AS MeasureGroup_Name, [MEASURE_NAME] AS Measure_Name,

[MEASURE_Caption] AS Measure_Caption, [MEASURE_IS_VISIBLE] AS Dimension_Visible, [MEASURE_AGGREGATOR] AS Measure_Aggregator, [DEFAULT_FORMAT_STRING] AS [Format_String], [EXPRESSION] AS Calculated_Measure_Expression FROM

$SYSTEM.MDSCHEMA_MEASURES ORDER BY

[MEASURE_NAME]

Výpis 3: DMV kód pro zjištění definice mír

43

(44)

Obrázek 10: Architektura "Users"Kostky

(45)

Obrázek 11: Architektura "Surveys"Kostky

45

(46)

Obrázek 12: Architektura "Energycomp"Kostky

Obrázek 13: Nastavený kanál pro zpracování dat

(47)

Obrázek 14: Spouštěč zapínání kanálu

47

(48)

Obrázek 15: Pracovní plocha s vytvořenou sestavou v Power BI

(49)

Obrázek 16: Přidání práv do pracovního prostředí Power BI 49

(50)

Obrázek 17: Struktura tabulek v Power BI

Obrázek 18: Graf vytvořeným pomocí dvou mír.

(51)

Obrázek 19: Míra s pevně danými argumenty.

Obrázek 20: Míra proměnlivými argumenty.

Obrázek 21: Historie běhů pro kostku "Users"z ON-PREMISE.

51

(52)

Obrázek 22: Historie běhů pro kostku "Users"z Microsoft Azure.

Obrázek 23: Historie běhů pro kostku "Surveys"z ON-PREMISE.

(53)

Obrázek 24: Historie běhů pro kostku "Surveys"z Microsoft Azure.

53