Tableau news: Hyper multi table storage

5 november 2018

Början på något nytt!

I denna bloggpost ska vi titta närmare på något nytt i Hyper, Tableaus hjärta, som kan hjälpa dig att spara en massa megabyte!

Stefan har redan listat sina 5 favoriter med 2018.3, men om jag får välja är det en som sticker ut. Det är något jag tror är första steget för Hyper mot att bli en fullfjädrad databas, nämligen multiple-table-storage.

Redan när vi mötte teamet som ansvarade för Tableaus databas Hyper på TC17 berättade de om att de hade massor av idéer för utvecklingen av den nya motorn som från och med 10.5 ersatte de gamla extrakten. Flera av dessa nya idéer har att göra med att Hyper är en riktig databas och inte bara ett filformat som de förra extrakten. I och med det kan man börja göra en massa smarta funktioner.

Först ut är multiple-table-storage och när man väljer det vid skapande av ett extrakt lagras datat i samma struktur som i källsystemet. I vissa fall kan detta göra att extrakten blir både mindre och snabbare, något vi ska titta närmare på här.

Hur fungerar det?

Tidigare har det data som laddats till Tableau lagrats som en kombinerad tabell med all data från de källtabeller som laddats. I och med denna nya funktion kan man välja att istället lagra sitt data som separata tabeller i Hyper, Men alla i samma fysiska fil med ändelsen .hyper.

I Tableau kan man enkelt se hur olika detta blir genom att ta ett exempel med tre tabeller.

Gör man ett vanligt extrakt med detta och öppnar, kan man se att de tre tabellerna kombinerats till en.

Gör man istället ett ”multi table” extrakt och öppnar ser man att det fortfarande är 3 olika tabeller i filen.

 

När ska man använda det?

Det klassiska svaret ”det beror på” är högst relevant här. I stort kan sägas att det främst är i scenarion med många-till-många relationer mellan de tabeller som ska laddas som det kommer till användning. Men både den nya ”multi table” och det tidigare sättet med bara en tabell har sina fördelar och scenarion där de fungerar bäst. Det handlar i stort sett om tre variabler: Tid för att skapa extrakt, storlek på extrakt och arbete för Tableau. Och i slutändan behöver man testa för att se vilka variabler som blir bäst/viktigast för just sin lösning, men ska försöka hjälpa till att förklara dem.

Tid för att skapa extrakt

En effekt av att använda sig av ”multi table” är att laddningen av data till extraktet kan gå snabbare. Detta eftersom man tar bort jobbet att kombinera data, göra en s.k. join, från databasen och istället bara läser ut tabellerna i sitt råa format.

Viktigt att tänka på här är dock att det inte går att filtrera data som laddas till ett ”multi table”. En effekt av detta blir att alla medlemmar i t.ex. en dimension laddas och inte bara de som hör till de faktarader som laddats. Det måste istället lösas i databasen, t.ex. med hjälp av en custom query eller en vy i databasen.

Storlek på extrakt

Det scenario där ”multi table” framför allt är optimalt och man kan se att storlek på extrakt optimeras är när relationer mellan tabeller kan leda till att data blåses upp och multipliceras, s.k. många-till-många relationer. Ett konkret exempel på detta är när man definierar säkerhet och vill definiera vilka användare som har rätt till vilka transaktionsrader. I exemplet nedan kan man t.ex. se att kopplingen mellan en användare och transaktioner inte är 1-1 då t.ex. både Sammy och Stefan är kopplade till Sverige.

Resultatet av ovan när det laddats i det tidigare filformatet skulle då bli enligt nedan, 7 transaktioner istället för 4, inte helt optimalt då transaktionerna duplicerats beroende på vem som har en koppling till dem.

Inte toppen om man har ett system med miljontals transaktioner. Så det är här man kan spara in på megabyten då bara samma data som i databasen lagras.

I det nya ”multi table” formatet skulle detta inte ske utan data skulle laddas i sina separata tabeller och sedan kombineras specifikt när en användare behöver dem. Detta gör framför allt att storleken på datat inte blåses upp och man får en Hyper-fil som tar mindre plats och i de flesta fall är snabbare. Allt för att mindre data behöver processas.

Arbete för Tableau

På samma sätt som vi sparar tid när vi skapar extrakten genom att databasen får arbeta mindre blir det istället mer jobb för Tableau och Hyper när vi har flera tabeller. Detta eftersom jobbet att kombinera data, join, istället behöver göras av Tableau för varje fråga/viz som visas på datat. Det gör att det inte är självklart att det blir bättre med flera tabeller utan även här är något man får prova sig fram med.

Finns det några nackdelar?

Detta är en första version av denna funktionalitet och vissa saker så som inkrementella laddningar och extraktfilter finns fortfarande inte.

Har man ett scenario med laddningar av stora volymer där det t.ex. finns ett behov att kunna ladda dagliga deltan fungerar inte multi-table än.

Behöver man filtrera sitt data går inte det i gränssnittet. Ett tips är att då istället använda custom-frågor eller vyer där datat filtreras. Detta kan vara viktigt för att inte ta in mer data än man tänkt sig till Tableau då det data som naturligt försvinner i en join inte gör det i ”multi-table”.

Så vad är det som gäller?

För att summera, inga raka svar utan ”det beror på”. Fundera på din situation utifrån vad jag beskrivit ovan och prova dig fram. Om du idag inte upplever några egentliga prestanda- eller storleksproblem med dina extrakt eller behöver implementera mer avancerad radsäkerhet i Tableau så kan du nog vänta med att använda ”multi table”. Står du däremot inför en utmaning att implementera en lösning där du t.ex. vill kunna definiera exakt vem som ska se vad i Tableau eller har extrakt som bygger på många tabeller och börjar bli problematiska att ladda kan detta vara något att börja testa.