Odborná pracovní snídaně „DWH jako perpetuum mobile aneb Continuous delivery u robustních, datově orientovaných řešení“

1. Odborná snídaně:
Datový sklad jako
Perpetuum Mobile
Petr Hájek, Jan Švehla 21. října 2020

2. 2
Co nás dnes čeká
› BI Governance aneb Specifika softwarového procesu
u datově orientovaných řešení
Petr Hájek
› Automatizace vývojového cyklu DWH, nástroj TAT,
praktické zkušenosti z realizovaných datových skladů
Jan Švehla

3. 3
Kdo jsme
22 let
na trhu
(od roku 1998)
746 mil.
(Kč) obrat
v roce 2019
Finance
& Telco
významní
zákazníci
500+
zkušených
profesionálů
#3
CAD v ČR
(IDC 2017)
ČR
+ Evropa

4. 4
Naše kompetence

5. BI Governance aneb
Specifika softwarového
procesu u datově
orientovaných řešení

6. 6
Robustní datová řešení jsou software jako každý jiný a platí pro ně obecná
pravidla SW inženýrství. Přesto však mají svá specifika jako například
komplexní dopadové analýzy u nových business požadavků, velký nárůst
objemu metadat nebo řízení změn nad objekty s enormním množstvím
historicky akumulovaných dat. Povíme si o některých přístupech, jak se
s tím vším vypořádat :)
BI Governance aneb Specifika softwarového
procesu u datového skladu

7. 7
Datově orientovaná řešení
Datové sklady (DWH), Data Lakes (DL), Operational Data Stores (ODS)
L0 L1 L2
Číselníky
manuální vstupy
1:1
1:1
1:1
Datové
zdroje
Data
Model
Výstupy
Metadata

8. 8
Datově orientovaná řešení
DATA
Transformace
Přes svá mnohá specifika jsou Datově orientovaná řešení
pořád jen software, jako každý jiný.
Reductio ad
absurdum:
Data Transformace Data Transformace Data Transformace Data

9. 9
Stavební bloky datově orientovaných řešení
› Datové objekty (tabulky, datové soubory, mají struktury)
– Na „atomické úrovni“ se skládají z datových elementů (typicky sloupce
v tabulkách, prvky v XML, .json apod.)
– Datové objekty jsou „organizované shluky“ datových elementů
› Datové transformace (algoritmy, které transformují data ze
zdrojových objektů do cílových objektů)
– Za datové transformace považujeme také
například kontroly datové kvality apod.
› Orchestrační pravidla

10. 10
Vývojový cyklus
› Vytvářené datové řešení se skládá typicky z tisíců/milionů instancí
stavebních bloků (říkejme jim „artefakty“)
› Všechny artefakty musí někdo:
tzv. sestavit (build)  otestovat  nasadit  znovu otestovat …
bug = true;
Vývojáři /
Analytici
Zákazník
Build Test Release
MonitoringPlanning
bug = false;

11. 11
Konfigurační a změnové řízení
Systém
v3
Konfigurační jednotka
a její verze
v2 v1 v0
Změnové
požadavky
Popisná
a provozní metadata

12. 12
Groupe Level
Semantic Layer
Rep01 Rep02 Rep03
Staging
Kernel
Semantic Layer
Groupe Level
Semantic Layer
Rep01 Rep02 Rep03
Staging
Kernel
Semantic Layer
Groupe Level
Semantic Layer
Rep01 Rep02 Rep03
Staging
Kernel
Semantic Layer
Groupe Level
Semantic Layer
Rep01 Rep02 Rep03
Staging
Kernel
Semantic Layer
DEV TEST UAT PROD
Groupe Level
Semantic Layer
Rep01 Rep02 Rep03
Staging
Kernel
Semantic Layer
Groupe Level
Semantic Layer
Rep01 Rep02 Rep03
Staging
Kernel
Semantic Layer
Groupe Level
Semantic Layer
Rep01 Rep02 Rep03
Staging
Kernel
Semantic Layer
Groupe Level
Semantic Layer
Rep01 Rep02 Rep03
Staging
Kernel
Semantic Layer
Groupe Level
Semantic Layer
Rep01 Rep02 Rep03
Staging
Kernel
Semantic Layer
Groupe Level
Semantic Layer
Rep01 Rep02 Rep03
Staging
Kernel
Semantic Layer
Groupe Level
Semantic Layer
Rep01 Rep02 Rep03
Staging
Kernel
Semantic Layer
Groupe Level
Semantic Layer
Rep01 Rep02 Rep03
Staging
Kernel
Semantic Layer
Group Level
Semantic Layer
Rep01
Staging
Kernel
Semantic Layer
Groupe Level
Semantic Layer
Rep01
Staging
Kernel
Semantic Layer
Groupe Level
Semantic Layer
Rep01 Rep02 Rep03
Staging
Kernel
Semantic Layer
Groupe Level
Semantic Layer
Rep01 Rep02 Rep03
Staging
Kernel
Semantic Layer
Group Level
Semantic Layer
Group Level
COREP Data Mart
Rep01 Rep02 Rep03
Staging
Kernel
Semantic Layer
Group Level
Semantic Layer
Rep01 Rep02 Rep03
Staging
Kernel
Semantic Layer
Groupe Level
Semantic Layer
Rep01 Rep02 Rep03
Staging
Kernel
Semantic Layer
Groupe Level
Semantic Layer
Rep01 Rep02 Rep03
Staging
Kernel
Semantic Layer
Group Level
Semantic Layer
Group Level
COREP Data Mart
Rep01 Rep02 Rep03
Staging
Kernel
Semantic Layer
Group Level
Semantic Layer
Group Level
COREP Data Mart
Rep01 Rep02 Rep03
Staging
Kernel
Semantic Layer
Group Level
Semantic Layer
Rep01 Rep02 Rep03
Staging
Kernel
Semantic Layer
Group Level
Semantic Layer
Rep01 Rep02 Rep03
Staging
Kernel
Semantic Layer
Group Level
Semantic Layer
Group Level
COREP Data Mart
Rep01 Rep02 Rep03
Staging
Kernel
Semantic Layer
Group Level
Semantic Layer
Group Level
COREP Data Mart
Rep01 Rep02 Rep03
Staging
Kernel
Semantic Layer
Group Level
Semantic Layer
Group Level
COREP Data Mart
Rep01 Rep02 Rep03
Staging
Kernel
Semantic Layer
Group Level
Semantic Layer
Group Level
COREP Data Mart
Rep01 Rep02 Rep03
Staging
Kernel
Semantic Layer
Komplexita dále roste s počtem prostředí
› Zejména ve velkých organizacích, které mají složitou
nadnárodní organizační strukturu se počet běžných prostředí
ještě násobí lokálními instancemi / „tenanty“:
LocallevelGrouplevel

13. 13
Budování datového řešení
na zelené louce ve
4 krocích
Definice Architektury
cílového datového
řešení
Nastavení
„frameworku“
Úvodní
inkrement
Cílového
datového řešení
Provoz a rozvoj
1
2
3
4
2-3 měsíce1 měsíc 1-2 měsíce

14. 14
Nastavení „frameworku“
„Baseline“ designu řešení (= příklady „artefaktů“)
Data Transformace Data Transformace Data Transformace Data
Design
a analýza
Metadada
„Profil“
= strukturovaný zápis
architektonických
pravidel a designu
řešení
Šablony

15. 15
Jaká je reálná evoluce „frameworku“ v praxi?
1
2
3
Manuální psaní kódu
Manuální příprava
metadat Strukturovaná
pravidla
„Profilu“
Specifické
Šablony Manuální
psaní kódu
Strojově
připravená
Metadata Manuální
Metadata
Strukturovaná
pravidla „Profilu“
Manuální
kódování
Generické
Šablony

16. 16
Automatizace datových řešení – analogie
s vyplňováním adres na dopisní obálky
Všechno, co je
v řešení proměnlivé /
dynamické bude
obsaženo v metadatech
Všechno, co je
v řešení statické
bude definováno
v šablonách
Pre-skriptivní
metadata
Datový model
Číselníky Mapování
Orchestrační
workflow
Šablony
Generátor

17. 17
ŘEŠENÍFRAMEWORK
Build & Run
Nastavení
frameworku
Rozvoj
a rozšíření
frameworku
Rozvoj
cílového
datového
řešení
Prototyp cílového řešení
Provoz a podpora
„drop/create“ Standardní změnové řízení
RUNBUILD

18. 18
BI Governance = procesy
› Capacity and Resources Management
› Business Requirements Management
› Software/Solution Delivery Process
› Release Management
› Quality Assurance & Control processes
› Data Quality Management
› Reference Data Management
› Information Security Management
› Architecture Management
› Documentation & Knowledge Management
› Operations

19. 19
BI Kompetenční centrum

20. Automatizace vývojového
cyklu DWH, nástroj TAT,
praktické zkušenosti
z realizovaných datových
skladů

21. 21
Automatizace vývojového cyklu DWH, nástroj
TAT, praktické zkušenosti z realizovaných
datových skladů
Kvalita datového řešení je jednoznačně reprezentována kvalitou dat.
Ve stádiu provozu lze kvalitu dat měřit a cíleně řídit, nelze však
zapomenout na fázi vývoje a nutnost zajistit, že řešení již před
nasazením produkuje správná data.
Pojďme si ukázat na existujícím řešení, jak lze automatizovat proces
testování v prostředí DWH s využitím technologií a principů
inspirovaných v IT CICD pipelinách.

22. 22
Definice
› Testování = zhodnocení kvality softwarového řešení
› Kvalita =
– Míra souladu se specifikací (tradiční definice)
– Ztráta způsobená produktem po dodání do produkce (Genichi Taguchi)
› Ztrátou lze nazvat vše od ceny a času stráveného na opravě
až po reputační ztrátu či propad akcií v souvislosti s dopadem
chyby

23. 23
Druhy testování
› Unit testing
– Testování malé, samostatné jednotky řešení s cílem ověřit funkci
nejmenšího stavebního bloku
– V případě DWH lze za jednotku považovat transformaci, skript, tabulku
Result
Result
Result
Unit
Unit
Unit
Test
Test
Test

24. 24
Feature
Druhy testování
› Integration testing
– Testování většího celku, rozhraní mezi jednotkami
– V případě DWH lze za integrační celek považovat dodávku nové
funkce martu či reportu
Result
Unit
Unit
Unit
Unit
Test
Test
Test

25. 25
Druhy testování
› System testing
– Testování celého systému po integraci požadovaných funkcí
– V případě DWH se může jednat např. o mart či jinou konfigurační
položku podle lokální metodiky
Mart
Result
Feature
Feature
Feature
Feature
Test
Test
Test

26. 26
Druhy testování
› User Acceptance Testing
– Testování celku nebo částí s uživateli
– Při správné dekompozici, zle validovat s uživateli všechny
předchozí úrovně
Mart
Feature
Feature
Feature
Feature

27. 27
Real-Case Problém
› BI4SG / IBFS = 20 datových skladů pro 16 Afrických zemí
– Maroko, Alžír, Togo, Ivory Coast, Burkina Faso,… IBFS Group
› Vysoké časové nároky na testování
– Je nutné provést všechny testy opakovaně
› Krátká, rychle se opakující testovací kola
– Po opravě je potřeba přetestovat a ověřit, že bylo opraveno a nevznikla chyba nová
› Složité sestavení testovacího prostředí
– Cílem bylo testovat celé DWH zpracování
› Nároky na vstupní data
– V konečných fázích bylo potřeba testovat vícero časových snímků pro reporty
časových řad
› Dynamické nároky na release
– Změna scope i termínů
– Nutnost opakovat testy s jinou verzí řešení

28. 28
Řešení
› Formalizace testovacích scénářů
– Přepsání testovacích scénářů z volného textu do vykonatelného kódu
– Redukuje potřebu času na opakované kontroly dat, protože tester nemusí
opakovaně přemýšlet nad řešením testu
› Automatizace sestavení řešení
– Umožňuje rychle provést nasazení konkrétní verze řešení na vybrané
testovací prostředí
› Automatizace provedení testů
– Testovací scénáře lze vykonávat automatický bez lidského testera
› Revize governance
– Při správně navržených postupech lze dosáhnou ideální dekompozice,
testovat v rychlých intervalech a v malých jednotkách, což vede na včasnou
a rychlou identifikaci chyb
– Základem je nastavit proces, aby zpoždění mezi vývojem
a testy byl dostatečně krátký

29. Test Automation Tool
skripty
DDL
workflow
testy
datové modely
číselníky
rule tabulky
business data
Status reporty
Testing reporty
Deploy
Execute
Test
Deployment
Management Tool
Package

30. Code Management System
› Obsahuje historii změn kódu
› Obsahuje artefakty, které dohromady tvoří řešení:
› Umožňuje přechod mezi verzemi řešení
› Lze použít různá CMS, ale GIT se osvědčil nejvíce:
– je navržen pro feature-driven development
– efektivně dovoluje paralelní vývoj
– efektivně umí přidávat a odebírat funkce ve scope
– silná podpora ze strany CI toolů
– silná nástrojová podpora procesu schvalování změn

31. Task Management System
› Je nedílnou součástí governance
› Umožňuje organizaci požadavků a dílčích úkolů
› Spojuje popis požadované změny s reálnou implementací
› Dokáže generovat reporty o stavu prací či další management
reporty
› V příkladě použitá JIRA lze nahradit jiným systémem
v závislosti na lokálním prostředí

32. Test Management System
› V příkladu použitý XRAY for JIRA:
– JIRA plugin
– Organizuje testovací scénáře
– Udržuje plán testů, organizaci testů do testovacích kol
– Obsahuje exekuce testů, logy z běhů, výsledky
– Integruje se plynule s Jenkins
– Generuje testovací reporty
› Existují různé alternativy:
– Zephyr for JIRA
– Quality Center
– …

33. Další Komponenty
› Data Storage + RDM
– Obsahuje vstupní data, číselníky, testovací referenční vstupy
– Může být realizován sdíleným diskem, HADOOP či jiným
úložištěm
– Funkčně je nutné obsloužit zabezpečení, zálohování,
archivaci
› Jenkins
– Core komponenta
– Obsahuje „joby“ - hlavní kroky QA proces
– Pro účely DWH bylo potřeba vyvinout vlastní toolset
› Testovací prostředí
– Definováno lokálním prostředím
– Mělo být blízké PROD funkčně i nastavením
› MantaChecker
– Statická analýza kódu
– Detekuje nežádoucí konstrukce v kódu

34. Náhled na QA Proces
master
V1

35. Náhled na QA Proces
› Počátek práce
1. Vývojář/ analytik dostal úkol
k implementaci a provedl změnu
master
V1

36. Náhled na QA Proces
› Schválení změny – unit testing, integration testing fáze
1. Vývojář/ analytik dostal úkol
k implementaci a provedl změnu
2. Vývojář žádá o kontrolu změny
TEST
prostředí
3. Jenkins provede deployzGIT,
provede výpočet dat,
provede testovací scénáře
master
V1

37. 37
Možný CI scénář
› Základní scénář:
– Proveď „compile“
– Proveď deploy struktur
– Proveď syntax kontroly
– Proveď deploy ostatních artefaktů
› Frekvence:
– Každý commit do PR
› Výstup
– Změna je syntakticky OK nebo FAIL
– Odstraní 75% problémů z vývoje

38. Náhled na QA Proces
› Schválení změny – unit testing, integration testing fáze
1. Vývojář/ analytik dostal úkol
k implementaci a provedl změnu
2. Vývojář žádá o kontrolu změny
TEST
prostředí
3. Jenkins provede deployzGIT,
provede výpočet dat,
provede testovací scénáře
4. Na základě automatické kontroly,
revize kódu a dalších kritérii je změna
schválena a zařazena do další verze produktu
master
V1

39. Náhled na QA Proces
› Schválení release – system testing fáze
TEST
prostředí
5. Release kandidát je načten a otestován
vpotřebném množství kol
master
V1 V2-RC1

40. 40
Možný CI scénář
› Nightly scénář:
– Proveď smoke scénář
– Proveď spuštění výpočtu
– Proveď testy
› Frekvence:
– Denně ráno / OnDemand v testovacím okně
› Výstup
– Implementace v master je OK nebo FAIL z hlediska výstupů
– Odstraní zbylých 25% problémů z vývoje podle kvality(!) testů

41. Náhled na QA Proces
› Schválení release – system testing fáze
TEST
prostředí
5. Release kandidát je načten a otestován
vpotřebném množství kol
master
V1 V2-RC1 V2-RC2

42. Náhled na QA Proces
› Schválení release – system testing fáze
TEST
prostředí
5. Release kandidát je načten a otestován
vpotřebném množství kol
6. finální verze je vytvořena
ze stavu sdostatečnou kvalitou
master
V1 V2-RC1 V2-RC2 V2

43. Přínosy Řešení
› Přínosy jsou porovnatelné pro velká řešení (IBFS) i malá řešení
(KB Finance Data Solutions)
› Automatizace sestavení řešení, provedení testů 
– Převod lidských kapacit na strojové
– Možnost nočního zpracování
– Snížení chybovosti
– Zvýšení zastupitelnosti („tady zmáčkni a počkej až to skončí“)
– Standardizované výstupy
– Standardizovaný mechanizmus reportování stavu
– Průběžné testování
› Dekompozice testů do fází 
– Rapidní opakování triviálních testů
– Rychlé odezvy a opravy chyb
– Předcházení triviálních chyb ve složitějších fázích
 Redukce zpoždění, stresu a ceny testování!

44. Profinit EU, s.r.o.
Tychonova 2, 160 00 Praha 6 | Telefon + 420 224 316 016
Web
www.profinit.eu
LinkedIn
linkedin.com/company/profinit
Twitter
twitter.com/Profinit_EU
Facebook
facebook.com/Profinit.EU
Youtube
Profinit EU
Děkujeme
za pozornost

45. Backup Slides

46. 46
Automatizace v detailním pohledu
SQL Repository
DATA_FRAME
(Physical realisation
of metadata model)
Target DWH
solution
Input
METADATA
Excel sheet
Structured definitions
of models, data
surces, transformation
login, data layers, and
objects etc.
Determines the
structure of
Defines the requirements
of metadata structure
and its contents
Versioning
DWH profile
Profile templates
Examples of all
types of artefacts
Baseline
CREATE
TABLE
CREATE
PROCEDURE
EXECUTE
.SQL .XSLT
.SQL .XSLT
.SQL .XSLT
Generated
artefacts
.XSLT
.XSLT
.SQL
Defines the
types of target
solution
artefacts to be
generated
.XSLT
.XSLT
Narrative
description
of the DWH
Profile
Help to
develop the
templates
Versioning
Deployment
Orchestrates the tasks
Defines the solution architecture/design
Schedule
Generator
Metaloader
1:1

47. Business
Data model
Transformations
Data quality
IT
Methodology
Architectonic patterns
Technology templates
Meta data repository
Artifact generator
Support for orchestration
Data Warehouse
DWH Automation: DATA_FRAME Concept

48. 48
BI Solution Development Process Schema
Operations
Handover to production / Intensive care after go-live Hot-fixing Performance tuning
Deployment
Deployment packages preparations Deployment (running scripts, uploading metadata)
Historical data upload and adjustments of existing
historized data
Versions control & Documentation
Testing
Unit testing Testing data preparations
Integration testing (all developed
components across layers work together)
User acceptance testing (including
reconciliations and data/results
verifications)
Production testing
Implementation
Changes in Development framework
implemented (if necessary)
Generation of artefacts (CREATE/ALTER
data objects, ETL jobs)
Manual coding where necessary
Preparation of new orchestrations
metadata
Quality assurance of the developed
artefacts
Design
New data sources identified and/or
existing extended
New mapping rules and calculations
defined, dependencies in orchestration
process defined
New data in all layers elements added
and or modified (all data models updated)
Proposed design verified with business
analysts and the architects
Pre-scriptive metadata prepared
Analysis
Data Sufficiency Analysed and
Gaps Identified
Solution Impact Analysis
performed
New data objects in all layers
identified
New data quality checks and
reconciliation rules identified
Possible necessary extensions of
development framework identified
Everything verified back with the
business requestor and approved
by the architects
Business Requirements & Specifications
New data and reporting needs specified New terms in business glossary specified New business and calculation rules specified Other business requirements specified

49. 49
Efektivní a dlouhodobě udržitelný rozvoj rozsáhlých datových řešení, která
mohou flexibilně reagovat na potřeby a požadavky ze strany business
živatelů. Několik poskytovatelů BI týmů pomůže udržovat kontinuitu
znalostí a zároveň s v konkurenčním prostředí může utkávat o menší
i větší interní projekty v oblasti BI. Týmy by měly být vnitřně strukturovány
do vrstev (jádro týmu a další vrstvy) tak, aby bylo možno flexibilně též
reagovat na průběžně se měnící kapacitní požadavky.
Multivendor model & Team Lease
Core
3-5 FTE
Alokovaná
kapacita
Potencionální
kapacita