Je dashboard is traag, en het dashboard is niet het probleemJe dashboard is traag, en het dashboard is niet het probleem

Iemand vraagt waarom het verkoopdashboard vier minuten nodig heeft om te laden. De BI-tool is wat ze kunnen zien, dus de BI-tool krijgt de schuld. Er wordt gesproken over een snellere licentie. Soms wordt die zelfs gekocht.

Dat helpt zelden, want die vier minuten gingen niet op aan het tekenen van grafieken. Ze gingen op aan werk dat uren eerder had moeten gebeuren, en dat bij elke verversing opnieuw wordt gedaan.

Wat een traag dashboard meestal aan het doen is

Open de query achter een traag rapport en je vindt meestal dezelfde patronen. Hij koppelt vijf brontabellen op het moment van lezen. Hij zet tekstkolommen om naar datums omdat niemand de types eerder in de keten heeft gecorrigeerd. Hij filtert op een berekende expressie, dus geen enkele index kan helpen. Hij ontdubbelt rijen, wat betekent dat de bron duplicaten heeft die nooit zijn opgelost. En hij doet dit allemaal opnieuw voor elke gebruiker, elke ochtend, op hetzelfde moment.

Niets daarvan is een visualisatieprobleem. Het is een probleem in de datavoorbereiding dat steeds verder vooruit is geschoven, tot het zichtbaar werd.

Verplaats het werk, herhaal het niet

De gelaagde aanpak die mensen Bronze, Silver en Gold noemen is weinig glamoureus, en juist hier bewijst hij zijn waarde. Bronze is wat binnenkwam, bewaard zoals het binnenkwam. Silver is die data, één keer opgeschoond, getypeerd en ontdubbeld. Gold is de vorm die de vraag echt nodig heeft: een feitentabel met zijn dimensies, al geaggregeerd tot het detailniveau waarnaar mensen vragen.

Het gaat niet om de namen. Het gaat erom dat elke dure bewerking één keer gebeurt, volgens een schema, in plaats van één keer per kijker per verversing. Een rapport dat een Gold-tabel leest, doet bijna geen werk: filteren, aggregeren, tekenen.

Als een berekening voor elke gebruiker hetzelfde is, hoort die niet per gebruiker te draaien.

De incrementele vraag

Het tweede dat rapporten traag maakt, is het opnieuw verwerken van historie. Een pipeline die elke nacht drie jaar aan orders opnieuw opbouwt om die van gisteren toe te voegen, wordt elke nacht trager, voorgoed, puur door hoe hij is gebouwd.

Incrementeel laden lost dat op, en het komt vooral neer op het kunnen beantwoorden van twee vragen: wat is er nieuw sinds de vorige keer, en wat betekent het om dit twee keer te draaien. Voor de eerste heb je een watermerk nodig: een betrouwbare updated-at-kolom, een change feed, een volgnummer. Voor de tweede moet het laden idempotent zijn, en dat onderwerp is groot genoeg voor een eigen stuk.

Wat je echt moet controleren

• Hoe lang duurt de traagste query achter het rapport op zichzelf, buiten de BI-tool?
• Leest het een voorbereide tabel, of koppelt het ruwe bronnen op het moment van lezen?
• Verwerkt de nachtelijke job alles opnieuw, of alleen wat veranderd is?
• Worden types één keer eerder in de keten gecorrigeerd, of omgezet in elke query die de kolom raakt?
• Hoeveel mensen starten binnen dezelfde tien minuten dezelfde dure verversing?

Als de antwoorden naar eerder in de keten wijzen, en dat doen ze meestal, dan redt geen enkele dashboardinstelling je. Het goede nieuws is dat de oplossing blijvend is. Werk dat naar een pipeline is verplaatst, blijft daar.