tak se jmenovala
přednáška, kterou jsem nabídnul pro úplně první SQL Saturday konanou na území
ČR. Akce se konala 3.12.2016. Nicméně témata bylo nabídnout o dost více
vepředu. Dnešní blog bude pro ty, kteří se přednášky nemohli zúčastnit. Ale
také bude pro ty, kteří na přednášce byli a zajímá je, jak telenovela
pokračuje/dopadla. Dopředu ale musím říct, že telenovely nikdy nekončí, vždy
jen pokračují. Jenom sem tam někdo umře na 20 dílů, aby poté ožil. Protože těch
20 dílů, to celé byl jen sen.
Úvod
Když jsem
vymýšlel téma na přednášku, několik měsíců dopředu, chtěl jsem téma nadčasové.
U technologie jako Power BI vybrat téma, které bude aktuální i za půl roku je
docela výzva. Co je však vždy aktuální je vlastní zkušenost. Do takového tématu
může člověk dostat cokoliv přes souhrn vlastností, kam se produkt za rok
posunul včetně toho, co se líbí/nelíbí. Časování tomu nahrávalo. SQL Saturday
týden po Black Friday (pátek po Díkuvzdání, svátek konzumu) – nejkritičtějším
dnu v našem retailovém byznysu. Vloni jsem shrnul zkušenosti v článku
Power BI – zkušenosti z praktického nasazení zde: http://www.neoral.cz/2015/11/power-bi-zkusenost-z-praktickeho.html
Letos jsme znali
svého nepřítele (omezení produktu dopředu). Byli jsme o rok chytřejší a produkt
o rok dospělejší. Plán byl udělat to celé lépe na základě zkušeností :)
Drobný úvod
z pohledu důležitosti dne pro náš byznys. V průběhu Black Friday se
v průběhu jednoho dne prodají několikanásobné objemy v porovnání
s dny normálními. Je to v podstatě takový další týden v roce.
Uživatelé ze strany byznysu chtějí intradenně sledovat co se děje
s prodeji a pokud bude někde nalezen problém, analyzovat detailněji
s čím konkrétně problém je, aby se dala hledat příčina a potenciálně
řešení. Vymyslím si jeden příklad, abych nastínil modelově situaci. Člověk
odpovědný za produktovou kategorii „Bílé zboží“ zjistí, že při meziročním
srovnání za ekvivalentní čas prodejů je 2% níž, než loni. Zajímá ho, o kterou
obchodní oblast se jedná. Zjišťuje největší problém u ledniček. Cena sama o
sobě mnoho nepoví. Koukne na prodané kusy. Vidí, že se jedná o konkrétní
značku. Kde se stala chyba? Jedná se o problém s dostupností zboží (málo
jsme naskladnili). Máme zboží dost, špatně nastavená cena... Může
v průběhu dne změnit cenu a podpořit prodej této problematické značky. Ve zkratce řečeno, intradenní mission critical reporting ve snaze být
s daty zpožděný co nejméně a aby mohli reagovat i lidé mimo firmu (na
prodejnách). Reporty měly být dostupné odkudkoliv.
Co jsme měli loni
Power BI
dashboard postavený metodou využívající import dat na úroveň produktu
Merchandise area (velké televize, malé televize, ledničky, sušičky, ...).
Aktualizace probíhala přes personal gateway. Musel jsem duplikovat některé
grafy (nemožnost drillthrough). Docela hojně jsme používali vlastní
vizualizace.
Problémy z loňska
na které jsme
narazili na Black Friday a poté při dennodením používání dashboardu. Limit 8
aktualizací za den a nemožnost spolehnout se na scheduler. Nemožnost sladit
aktualizaci dashboardu s ETL. Ve špičce jsme tedy skončili tak, že jsme
dashboard aktualizovali ručně. Tento byl také vysdílen v „My workspace“, takže
nulová možnost sdílení administrace (jinak než nasdílením hesla).
V průběhu roku jsme spoléhaly na automatizovanou aktualizaci 8 krát denně
(semtam se něco pokazilo a opravilo bez zjevné příčiny). V průběhu roku se
několikrát stalo, že vlastní vizualizace zmizeli, člověk musel stáhnout poslední
verzi, naimportovat do reportu a tento znovu vypublikovat. Dashboard se ale
uživatelům líbil, ale na backendu bylo spousta práce... Práce kterou jsme si
chtěli odpoustit v novém roce.
Plán na letošek
zbavit se
protivných aktualizací na které se nedalo přesně spolehnout (aktualizace
probíhá co nejblíže specifikovanému času, dle vytížení služby se může spustit
později, navíc nám nestačilo 8x za den). Použít živé připojení, které přinese
jednak možnost vynutit security model a jít až na detail produktu. Použít nové
funkce na straně vizualizací, jako například drillthrough, podmíněné
formátování, optimalizaci reportu pro mobil a další, že to ani všechno
nevyjmenuji. Dále bylo v plánu vyhnout se vlastním vizualizacím
z důvodu „mizení“. Ponechal jsem jen scroller.
Technicky jsem to
implementovali tak, že jsem vytvořil extra SSAS kostku
v multidimenzionálním provedení a zahrnul veškerou logiku potřebnou pro
dashboard v této kostce. Umožní nám to recyklovat logiku do různých
nástrojů (SSRS, Excel, Power BI) a být tak blízko reálnému času, jak nám jen
ETL dovolí. Kostka obsahovala role vynucující row level security. Dashboard byl
nasdílen do sdíleného pracovního prostoru, kvůli sdílení administrace.
Vytvořili jsme 3
dashboardy, jeden hlavní a dvě odvozené lehce modifikované verze. Vývoj kostky,
dashboardů a testování s tím spojené si vzalo několik týdnů. Dashboardy
vypadaly opravdu dobře a měl jsem z nich dobrý pocit...
Jak to šlo
a to až do úterý 22.11
odpoledne. Před peakem jsme se přesunuli s částí týmu do Londýna do
hlavního sídla firmy, abychom mohli prezentovat dashboardy uživatelům a být jim
k ruce pokud bude potřeba. Bohužel komunikace přes Power BI Enterprise
Gateway začala nepředvídatelně padat. Lítaly nám chybové hlášky, kolečko se
točilo, točilo a nedotočilo. Když dotočilo, tak chybová zpráva, ale bez popisu
chyby. Začalo ladění nejprve se supportem z Microsoft UK. Na případu se
vystřídalo několik lidí, což zpomalovalo komunikaci. Postupem času se nám
podařilo vybranými kanály poměrně rychle probouchat až k Power BI Gateway
týmu v US. Poté se začal troubleshooting vyvíjet trochu lépe, to ale
předbíhám. Na straně naší infrastruktury jsme měli vše podchycené
z pohledu disaster recovery. V podstatě mirrorovanou konfiguraci
všech serverů. Nainstalovali jsme druhou gateway, kterou jsme neměli dopředu.
Ale bohužel nefungovala komunikace ani přes tuto bránu. Server byl dostupný ze
všech ostatních nástrojů (SSRS, Excel napojený na kostku, Power BI desktop),
tudíž jsem podezříval problém na straně Power BI. Kouknu do Office 365 na
service health a skutečně vidím u Power BI „service degradation“ a že by to
mělo být vše v pohodě 24.11 odpoledne US času.... To je trochu blízko
pátku na to abych byl v klidu. S UK supportem jsme v úterý večer
a v noci nebyli schpni najít řešení problému. Bylo potřeba přijít
s plánem B a to velmi rychle. Reporting pro uživatele přistupující k datům
z firmy jsme podchycený měli (SSRS
a Excel). Jak ale poskytnout za dané situace uživatelům data mimo firmu
(manažerům jezdícím po obchodech atd.). Na nasazování nové technologie není
čas.
Plán je
následující:
a)
snažit
se rozchodit live connection
b)
udělat
verzi reportu, která bude používat data import (jak loni) aktualizovat přes
bránu
c)
pokud
bude u bodu b problém s aktualizací bránou, aktualizovat v Power BI
desktopu a přepisovat soubor
d)
to
snad nebude potřeba
23.11 ve středu
dávám cvičení Dashboard in a day. Logiku, kterou jsem implementoval měsíc do
kostky a která byla dopředu otestována, přebouchávám do reportu používajícího
data import. Metodu jednoduše přepnout nejde už kvůli výpočtům. Takže co jsem
psal v MDX, přepisuji do DAXu no prostě pěkné cvičeníčko. Já jsem
zaneprázdněn plánem B, občas přepínám k troubleshootingu plánu A, na
callech se supportem bohužel musí vysedávat šéfová
24.11 ve čtvrtek,
brána chvíli jede, chvíli ne, nicméně jí nikdo nevěří, že pojede v onen další
kritický den. Musíme se rozhodnout s čím do toho další den půjdeme. Volíme
verzi import
25.11 pátek Black
Friday je tu. Ze 3 dashboardů jsem stihnul předělat pouze ten hlavní, aby
využíval data import odvokzené verze jsou stále jako live connection. Brána
bohužel zlobí. Byl jsem dedikován na podporu uživatelů z produktové kategorie
bílé zboží. Na dotazy odpovídám z Power BI desktopu a nakonec otvírám
Excel napojený na kostku. Všechny dotazy jsem zodpovídat ve velmi rychlém
tempu, uživatelé spokojeni. Mezitím ostatní se věnují dalším týmům. S refreshem
se tak nějak střídáme a ano museli jsme sklouznout i k plánu C,
aktualizace přes bránu zlobí stejně jako živé připojení. A co hůř v pátek večer
kolem 10té hodiny dostáváme hlášku, že aktualizace nemohla proběhnout na straně
service z důvodu překročení horního limitu paměti. Problém je s vykreslováním
kumulovaného grafu za posledních 5 hodin. Narazili jsme zde na nezdokumentovaný
limit. Report s importem dat měl velikost pouhých 300 MB a 3 dny dat
(Black Friday letos, loni a 2 roky zpět). Nicméně data v DAX dotazu
přesáhla maximální velikost dat povolenou na straně service. Takže plán d byl
nakonec potřeba a vyřešili jsme to dočasně smazáním onoho grafu. Evidentně můj
DAX dotaz nebyl dostatečně efektivní :) Na ladění ve středu nějak nebyl čas.
Konečně onen den končí. Ustáli jsme největší špičku. Na backendu spousta práce,
ale uživatelé se dostali k informacím, ke kterým potřebovali a na
frontendu snad nepoznali moc rozdíl.
26.11. přesun
zpátky do Brna vyloženě v „Power BI náladě“. V týdnu přede mnou tři Power
BI prezentace :) WUG Online, přednáška na konferenci iLikeSharePoint a SQL
Saturday v Praze. Nejlepší ze všeho téma na SQL Saturday Praha – Power BI
after more than year in production. A co tam jako teď budu vykládat?
V ten den
kdy jsme Power BI nejvíce potřebovali se pokazilo skutečně co mohlo, což jsme
dali vědět i produktovému týmu. Na naší straně v tu chvíli nepanovala
velká důvěra, že si můžeme dovolit riskovat používat tuto technologii dál. Šéfová
napsala manažerovi týmu, se kterým minulý rok na Data Insights Summitu v Seattle
prezentovala naše řešení z loňska jak se cítíme s ohledem na
používání Power BI do budoucna. Zorganizoval se call kde se probrala situace,
Power BI team měl viditelně jasný cíl vyřešit náš společný problém a pracovali
opravdu velmi tvrdě a intenzivně na řešení včetně callu v šílené časy, aby
se s námi spojili (velký časový posun). Dokonce k nám poslali i
jednoho člověka z produktového týmu do kanceláře, aby s námi řešil
problém onsite.
Všechno to byla
jedna velká a zajímavá zkušenost, ladit funkci brány přímo s produktovým týmem.
Dozvěděl jsem se mnohé o tom jak gateway funguje stejně jako service na druhé
straně. Mé obavy o tom, že kód ze strany Microsoftu je generován tak často, že
prakticky znamožňuje pořádné testování u zákazníka byly trochu uklidněny.
Dozvěděl jsem se také pár bodů o tom jak funguje release cyklus. Pokud tedy
máte stejnou obavu jako já, vězte že změny jsou napřed nasazovány do Microsoft
interního tenantu, kde jsou asi týden. Microsoft testuje nástroje prvně interně
a věřím, že když dashboard nejede a stěžuje si Satya Nadela, tak takové
eskalace nejsou příjemné :) Poté změny jsou nasazeny do regionů v US a
teprve po nějaké době to upečou až k nám do regionu North Europe. Takže
kód je testovaný docela zeširoka, než se to dostane až k nám. Testování
nových verzí na straně zákazníka je však druhá věc.
V průběhu ladění
jsme zkoušeli všechno možné, privátní buildy gateway, podrobnější logování dokonce
i nový tenant v UK. Bez konzistentního úspěchu.
Minulé úterý 6.12
přišla v průběhu ladění spásná myšlenka. Zkusit na bráně změnit komunikaci
z TCP na HTTPS. Výchozí mód komunikace brány je tzv. AutoDetect. Začne na
TCP a pokud se 10 minut nedobouchá, přepíná sám na https. U nás byl však
problém, že některé dotazy prošly, ale ne všechny, takže k přepnutí na
HTTPS nedošlo vůbec. Po přepnutí na HTTPS brána začala konzistentně fungovat.
HTTPS jede, přepneme zpátky na AutoDetect, nejede, přepneme na HTTPS jede,
AutoDetect nejede, HTTPS jede. Tento test v průběhu 15 minut mluvil jasně.
HTTPS vynucení rozchodilo naši gateway. A fungovalo to celý týden v kuse.
Tak jsem začal psát tento blog, že máme konečně rozuzlení zápletky. Fungovalo
to až do pondělka 12.12. No mě už z toho asi... Cca 24 hodin to
nefungovalo včera v průběhu ladění po restartu service po konfigurační
změně opět jede. Otázka je, jestli pojede. Další velká špička (Boxing Day 26.12
před námi) a to bude většina manažerů pracovat z domu, takže Power BI.
Závěr
Jak je na mě
vidět nejen z mého blogu vidět, já mám Power BI docela rád :) Nicméně to
co se děje v posledních 3 týdnech způsobuje, že nejsem v úplné Power BI
náladě, jestli mi rozumíte :) Produkt je to dobrý, vypadá to dobře, dostupnost
odkudkoliv, relativně cenově dostupné, rychle přibývající funkce, komunita...
to všechno hovoří pro. Ono tempo vývoje je ale dvousečné. Někdo provede nějakou
změnu na straně service a vy o tom ani nevíte, natož jestli to mohlo způsobit váš
problém. Obráceně máte dlouho problém a ten časem vyšumí a vy opět nevíte,
jestli někdo něco změnil. Dalo by se trochu paušalizovat, že jak do svých
nástrojů přidáte nějakou cloudovou službu, tak nemáte plnou kontrolu... Jasně v principu
by to mělo fungovat, ale... Byť naše telenovela pokračuje, velmi si cením
podpory ze strany produktového týmu vyřešit náš problém. Doufám, že se tak s konečnou
platností podaří co nejdříve. Už tak se nám podařilo společnými silami vylepšit
produkt (odhalili jsme cestou několik bugů, které sice nezpůsobovali náš
problém, ale byly tam). Možná je problém někde v naší síti, nebo někde na
půli cesty. No uvidíme. Hlavní lekce pro všechny. Pokud je pro vás aplikace
kritická, mějte plán B a to i v případě, že využíváte cloudovou službu. A
ta by přece měla fungovat. PS: Až to bude fungovat a zjistíme, čím to bylo. Dám
update.
