In deze blogpost ga ik in op wat het schrijven van aangepaste SQL in Tableau is en de mogelijke prestatieproblemen die zich kunnen voordoen met best practices over hoe hiermee om te gaan.
Het gebruik van aangepaste SQL in Tableau verwijst in wezen naar het importeren, vormgeven en benaderen van gegevens uit een relationele database met behulp van SQL (Structured Query Language). In plaats van tabellen naar het canvas te slepen op de meer traditionele manier voor Tableau. Afhankelijk van de database verandert de SQL-syntaxis. Dit betekent dat dezelfde verklaring niet universeel kan worden gebruikt in verschillende databases.
Wanneer je verbonden bent met een relationele database zoals Oracle, PostgreSQL of Microsoft SQL Server, zie je in het venster Data Source aan de linkerkant onder de beschikbare tabellen een pijler "New Custom SQL":
Dubbelklik daarop of sleep het naar het canvas. Er verschijnt een pop-upvenster waarin u uw SQL-query kunt schrijven, zoals hieronder getoond:
De knop Preview Results in het venster opent het view data venster met de uitgevoerde query. Dit verbetert het gemak van gegevensverkenning door middel van aangepaste SQL. U hebt ook de optie Parameter invoegen. Met deze optie kunt u een nieuwe parameter maken of een bestaande parameter gebruiken in uw verklaring. Afhankelijk van de parameterkeuze zal de SQL-instructie het resultaat opvragen op basis van wat is geselecteerd. Het gebruik van parameters in aangepaste SQL kan echter problemen opleveren met betrekking tot de prestaties.
Meer over verbinding maken met aangepaste SQL-query's vindt u hier.
Zoals hierboven vermeld, kan het gebruik van parameters de prestaties van uw dashboards vertragen. Er zijn belangrijke dingen waar je rekening mee moet houden als het gaat om het gebruik van aangepaste SQL in relatie tot de prestaties van je werkmap. Dit voorbeeld is er slechts één van. In dit hoofdstuk ga ik dieper in op een aantal work arounds wanneer het gebruik van aangepaste SQL prestatieproblemen met zich meebrengt.
Allereerst staat het buiten kijf dat het gebruik van aangepaste SQL een krachtig hulpmiddel is voor het transformeren, uitvoeren van gecompliceerde logica of het benutten van bestaande queries. Het blijkt heel nuttig te zijn bij het uitvoeren van ad-hoc analyses of voor prototyping. In bepaalde productiegevallen kan het echter prestatieproblemen opleveren. De reden hiervoor is dat Tableau aangepaste SQL als een subquery gebruikt. Dit betekent dat elke query die Tableau maakt, de aangepaste SQL-statements bevat die je hebt gemaakt, omgeven door specifieke elementen van Tableau. Dit resulteert in lange en ingewikkelde query's waarvan het resultaat voor sommige databases slechter is. Het is best practice om het gebruik van Custom SQL in productiegevallen te vermijden. Er zijn echter enkele work-arounds die je kunt proberen om de prestaties te verbeteren terwijl je Custom SQL gebruikt als dat een probleem is.
Als er om verschillende redenen geen andere keuze is dan Custom SQL te gebruiken om gegevens te importeren, importeer dan alleen wat je nodig hebt. Vermijd bijvoorbeeld SELECT *. Maak daarnaast, indien mogelijk, je joins, relaties, unions en filtering via Tableau. En ten slotte, vermijd het gebruik van de ORDER BY clausule omdat Tableau dat afhandelt op basis van de structuur van de visualisaties.
Een initiële SQL-query voorkomt dat een aangepaste SQL-query meerdere keren moet worden uitgevoerd telkens wanneer je iets wijzigt in de werkbladen. Deze query is echter niet altijd beschikbaar. Initial SQL wordt alleen uitgevoerd wanneer de werkmap wordt geopend en creëert een tijdelijke tabel. Een nadeel van deze methode is dat de tijdelijke tabel ongewijzigd blijft tijdens de Tableau-sessie. Updates van de gegevens worden niet weergegeven totdat een nieuwe sessie wordt aangemaakt. Al met al kan het gebruik van tijdelijke tabellen met initiële SQL de prestaties aanzienlijk verbeteren.
Het gebruik van extracten (Hyper Extracts) kan ook nuttig zijn voor het verbeteren van prestatieproblemen. Door extracten te maken, worden gegevens in de gegevensopslag van Tableau getrokken. Hierdoor worden de query's alleen uitgevoerd bij elke verversing. Je kunt een extract maken voor elke aangepaste SQL-query die je hebt. Het nadeel is echter dat dit misschien niet de slimste manier is voor onderhoud op lange termijn. Het kan beter zijn voor je organisatie om je SQL queries op één plaats te bewaren. Dat brengt me bij mijn laatste punt.
Dit laatste punt is geen truc die je kunt uitvoeren in Tableau, maar eerder in de bron zelf. Het kan mogelijk zijn om je query als een aangepaste tabel of weergave in je database te maken en op te slaan. Tableau kan dan op dezelfde manier verbinding maken met die specifieke query als met een tabel. Deze methode kan ook helpen om de prestaties te verbeteren. Het kan echter een manier zijn waar je geen controle over hebt. De databasebeheerder of ontwikkelaars kunnen degenen zijn die dit in jouw organisatie moeten doen en zij vinden het misschien niet leuk dat er aangepaste weergaven moeten worden gemaakt die serverruimte in beslag nemen. Maar het kan nuttig zijn om erover te praten.
Bezoek onze site The Information Lab NL voor meer blogposts, training en advies over Tableau, Alteryx en Snowflake.