Dynamic Views

Har du så mycket data i dina källsystem att allt inte kan läsas in i minnet samtidigt? I så fall är Dynamic Views ett exempel på en bra lösning att titta närmre på.



Dynamic Views låter först användaren arbeta i en app som har sitt data i minnet. Det handlar ofta om en app som är aggregerad - det vill säga att många rader summerats upp till färre rader. Om vi till exempel har en miljard rader i vår försäljningsstatistik kan man välja att summera upp försäljningen per dag, artikel och land. Antalet rader blir nu mycket färre än innan och applikationen fungerar bra även på en mindre server.


Säg nu att en användare arbetar med appen och har hittat något intressant - försäljningen för ett visst land ser ut att vara mycket låg en viss dag. Kanske saknas data? Användaren vill se alla order för den aktuella dagen för att kunna stämma av mot sitt affärssystem. Efter att ha gjort ett urval på de intressanta värdena kan användaren enkelt genom att byta till en speciell se detaljerna för det aktuella urvalet efter att de har hämtats in från datakällan.


En sammanfattning av processen ser ut så här:


Aktivera Dynamic Views i SaaS

Om man använder Qlik Sense SaaS måste först Dynamic Views aktiveras i inställningarna för miljön. Logga in som en administratör och gå till Administration. Aktivera Dynamic Views under On-demand data.



Aktivera Dynamic Views i Client-Managed

Om ni har en egen installation av Qlik Sense på Windows finns inställningen för att aktivera Dynamic Views på ett annat ställe. En administratör loggar in på Qlik Management Console, QMC, och går till On-demand apps service.



Selection-app

Det här är den app med data i minnet som användaren vanligen arbetar i. När data läses in aggregeras det ofta så att allt ska få plats i minnet. Detta sker genom vanligen genom att de SQL-satser/QVD-läsningar som ligger till grund för inläsningen görs aggregerade med group by.


I data för selection-appen ska utvecklaren skapa ett fält med hur många rader som aggregerats till en viss datarad. Detta fält används sedan för att jämföra hur många grunddatarader som användarens aktuella urval motsvarar. T.ex. kan användaren ha valt en specifik rad i selections-appen som aggregerat upp 1,000 rader i grunddatat. I bilden nedan är detta trips_count.



Utvecklaren behöver bestämma en gräns för hur många grunddatarader som användaren max ska få hämta. Antalet sätts utifrån prestandakraven (om användaren skulle läsa in samtliga rader från grunddata skulle prestandan bli lidande) och hur länge användaren kan behöva vänta (om användaren skulle läsa in samtliga rader från grunddata skulle detta kunna ta flera timmar). Gränsen jämförs sedan med det fält som säger hur många grunddatarader urvalet motsvarar.


Omladdning av Selection-appen schemaläggs med den frekvens som är lämplig - t.ex. varje natt.


När selections-appen är skapad behöver vi skapa en Details-app. När den är klar kan vi koppla ihop apparna med varandra.


Details-app

Den här appen kommer att skapas när användaren väljer att initiera Dynamic Views och antalet motsvarande grunddatarader är lägre än gränsen som utvecklaren satt. Urvalen användaren har gjort i Selection-app kommer att tas med in i Details-app som variabler och användas i scriptet vid utläsning av data. Objekt från Details-appen visas sedan inne i Selections-appen på en egen flik. Beroende på vilken typ av data fältet innehåller behöver scriptet använda olika typer av variabler för värdena i urvalet.


Totalt sett finns ett stort antal olika variabler, men de vanligaste är följande:

  • odag_: Tar med valda (gröna) värden om val är gjort och annars möjliga (vita) värden och lägger till citationstecken för text. Denna används enklast när det handlar om textvärden som ska tas med.

  • odagn_: Tar med valda (gröna) värden om val är gjort och annars möjliga (vita) värden. Denna används enklast när det handlar om numeriska värden som ska tas med.

Mer information finns på Qliks hjälpsida och vi kommer gå igenom fler alteranativ i kommande inlägg på bloggen.


När man utvecklar details-appen finns inga värden i variablerna vilket gör det svårt att testladda scriptet. Därför kan man i början på scritpet testa om man laddar om utanför eller med Dynamic Views. Om man laddar om utanför Dynamic Views kan man sätta några standardvärden i variablerna och då fungerar omladdningen.

Det går bra att kombinera data från källor som reduceras med odag-variabler med andra datakällor där man läser in all data som vanligt. När appen väl är omladdad är allt data i minnet som vanligt.


Sätta upp Dynamic Views

Nu när vi har både en Selection- och en Details-app kan vi sätta upp Dynamic Views-kopplingen. Gå till Selection-appen och gå in i Edit-läget. Klicka på Dynamic views som nu ska finnas i menyn och klicka på Create new. Om alternativet inte finns är troligen Dynamic Views inte aktiverat i inställningarna för miljön.



Ange ett egenvalt namn på kopplingen (en app kan ha flera kopplingar varvid det är viktigt att vara tydlig i namnsättningen) och välj vilken Details-app som ska vara mall.


Därefter ska ett uttryck som beräknar hur många rader i grunddatat som användarens urval motsvarar. Det är alltså det fält vi skapade i scriptet vid aggregering av data i Selection-appen. I nästa fält anges antalet rader som beräkningen ska gå under för att Dynamic Views ska aktiveras.



När kopplingen är tillagd syns alla objekt från Details-appen och utvecklaren kan använda dessa på en ny flik inne i Selections-appen.



Använda Dynamic Views som användare

Nu är själva kopplingen klar och vi kan testa av att det fungerar som det ska. Gå in i Selection-appen utan Edit-läge. När användaren gör urval reduceras antalet motsvarande rader i grunddata vilket man som utvecklare behöver visa för användaren om man vill att det ska vara tydligt. Exempelvis kan man ha ett KPI-objekt (sum(trips_count)).



Om en användare besökaren detaljfliken innan urvalet är tillräckligt snävt kommer inte data att hämtas och uppdateras. Istället får användaren ett meddelande "Your current selections exceed the contraints set for this view".


Observera att användaren inte får reda på vilken gräns som är satt och därför är detta bra att visa någonstans, till exempel i ett textobjekt:


='Limit is 25000 rows. Currently ' & sum(trips_count) & ' rows are in the selection.'



När antalet motsvarande rader understiger den valda gränsen för Dynamic Views så hämtas data från datakällan, t.ex. BigQuery, för urvalet och visas. Beroende på hur mycket data som ska läsas in och hur snabb uppkopplingen är kommer detta ta lite olika lång tid. I mitt exempel där jag läser in 15,000 taxiresor från BigQuery tog detta ca 10 sekunder.


Exempel med försäljningsdata

I det här exemplet har vi en större webbshop som har en miljard orderrader i sin data. Användaren behöver normalt inte se alla detaljer utan studerar trender på en högre nivå. Data består av information som ordernummer, orderdatum, kundnummer, kundens adress, artikelnummer, artikelbeskrivning, produktgrupp, pris och antal enheter. Exemplet är förenklat - i verkligheten skulle vi har fler dimensioner och mätetal som t.ex. marginal.


Selection-app

I vårt exempel har vi en miljard rader för vår försäljning. En miljard rader kan läsas in i minnet på en större server, men i detta fall har kunden inget behov av att alltid se alla detaljer och därför valt att aggregera data så att mindre prestanda krävs av servern.


Utvecklarna skapar en vanlig Qlik Sense-app som heter Försäljningsstatistik. Vid inläsning av data till appen väljer man att aggregera informationen:


SQL SELECT OrderDate, CustomerZip, CustomerType, ItemNo, sum(Price*Quantity) as SalesAmount, sum(Quantity) as Quantity, count(distinct OrderNo) as NoOfOrders, sum(1) as NoOfRows FROM SalesData inner join CustomerData on SalesData.CustomerNo = CustomerData.CustomerNo GROUP BY OrderDate, CustomerZip, CustomerType, ItemNo


Koden säger att vi läser in data för dimensionerna Orderdatum, Kundens postnummer. Kundtyp (företag/privat) och Artikelnummer samt mätetalen försäljningsbelopp, antal enheter, antal order och antal rader. Vi lägger in kundens postnummer och kundtypen istället för kundnummer då vi i normalfallet inte behöver veta exakt vem kunden är i denna analys, men vi vill veta var kunden finns och om det är privat/företag.


Till detta kopplas dimensionstabeller som vanligt. Från en artikeltabell kan vi komplettera försäljningen med artikelns beskrivning och produktgrupp. Vi skapar som vanligt en kalendertabell som innehåller alla dagar från det minsta till det största orderdatumet i modellen.


Allt detta läses in i minnet schemalagt en gång per dygn då användarna inte är intresserade av vad som hänt under dagen. Användarna arbetar i denna app som vanligt - de gör urval, analyserar och tar fram rapporter.


Details-app

Nu arbetar en användare i Selections-appen och har en fundering som inte kan lösas i det aggregerade datat. Användaren tittar på en specifik artikel som av någon anledning har ett mycket lågt snittpris trots att den borde kosta mer. Efter lite analys ser man att priset varit felaktigt inlagt som ett EUR-belopp trots att det skulle vara SEK. Således har en enhet kostat ungefär 1/10 av korrekt pris. Användaren vill nu veta exakt vilka kunder som köpt artikeln.


Användaren har gjort ett urval på artikelnumret och ser att det motsvarar 9,475 rader i grunddata. Utvecklaren har i Dynamic View-inställningarna satt en gräns om max 20,000 rader, vilket alltså användaren ligger under. Således uppdateras en detaljtabell på en detaljflik när användaren går dit. Uppdateringen tar ca 5 sekunder. Nu kan användaren se exakt vilka orderrader som artikeln ingår på.


Skriven av: Morgan Kejerhag

Morgan Kejerhag har arbetat med Qlik-plattformen sedan 2005 och är en av Sveriges mest erfarna konsulter. Under åren har Morgan arbetat med flertalet multinationella bolag där han lett arbetet i att bygga upp stora Qlik-miljöer såväl som små kunder. LinkedIn Kontaktuppgifter

Vill du har mer information?

Kontakta oss via informationen på vår kontakt-sida.

DrakeStone AB
Teknikringen 10

583 30 Linköping

Org: 556986-6956

© 2020 Drake Analytics