Schedule drift is een van de subtielere faalmodi in Power BI-omgevingen. In tegenstelling tot een harde refreshsfout is een afwijking geleidelijk en onzichtbaar, er is geen foutmelding, geen melding en geen duidelijk probleem totdat rapporten consequent te laat worden weergegeven.
Wat veroorzaakt schedule drift?
De duur van refreshes neemt in de loop van de tijd toe om verschillende voorspelbare redenen:
Groei van het datavolume: De brontabellen groeien. Een query die 2 minuten duurde voor 5 miljoen rijen, duurt 8 minuten voor 20 miljoen rijen. Zonder queryoptimalisatie of partitionering is deze groei lineair.
Concurrentie om gatewaybronnen: De on-premises data gateway verwerkt meer gelijktijdige refreshes naarmate er nieuwe datasets worden toegevoegd. Wanneer de gateway 30 gelijktijdige taken verwerkt in plaats van 10, nemen de wachttijden toe, zelfs als elke individuele taak niet trager is.
Toenemende modelcomplexiteit: Naarmate analisten meer berekende kolommen, metingen en relaties aan een dataset toevoegen, neemt de verwerkingstijd tijdens het verversen toe. Complexe beveiligingsfilters op rijniveau zorgen voor extra verwerkingsoverhead.
Geheugendruk op Premium-capaciteit: Naarmate datasets groeien of meer datasets een capaciteitsknooppunt delen, neemt het beschikbare geheugen af. Power BI kan tijdens het vernieuwen modelsegmenten verwijderen en opnieuw laden, waardoor de verwerkingstijd aanzienlijk toeneemt.
Waarom afwijkingen in de planning belangrijk zijn, naast de prestaties van het vernieuwen
Afwijkingen in de planning hebben directe gevolgen voor de bedrijfsvoering wanneer rapporten strikte SLA-vensters hebben:
- Een financieel afsluitingsrapport dat gepland staat voor middernacht, maar nu om 04:00 uur klaar is, verkleint het beoordelingsvenster vóór de opening van de markt.
- Een dagelijks operationeel dashboard dat is geconfigureerd om om 07:30 uur actueel te zijn, maar om 08:50 uur klaar is, betekent dat de ochtendstand-up op de gegevens van gisteren draait.
- Een bestuursrapport dat 3 uur nodig heeft om te verwerken, kan het voorbereidingsvenster missen als het was ingesteld op een vernieuwingstijd van 1 uur.
Afwijkingen in de planning detecteren
Het detecteren van afwijkingen vereist het bijhouden van de werkelijke voltooiingstijden over meerdere refresh en het berekenen van een trend. Een nuttige indicator is het voortschrijdend gemiddelde van de vernieuwingsduur over 7 dagen. Wanneer dit de basislijn met een aanzienlijke marge overschrijdt (bijv. 50%), is er sprake van een afwijking.
Een meer verfijnde aanpak maakt gebruik van statistische detectie: bereken de mediaan en de standaardafwijking van recente vernieuwingsduur en geef een waarschuwing wanneer een nieuwe duur meer dan 2-3 standaardafwijkingen boven de mediaan ligt. Dit is geschikt voor datasets met natuurlijke variatie in duur (bijv. refresh aan het einde van de week die meer gegevens verwerken).
Reageren op gedetecteerde afwijking
Wanneer een afwijking wordt gedetecteerd, volgt het onderzoek hetzelfde pad als bij een prestatieprobleem:
- Controleer de groei van het gegevensvolume, is de brontabel aanzienlijk groter dan 3 maanden geleden?
- Controleer de gatewaybelasting, verwerkt de gateway meer gelijktijdige taken?
- Controleer de complexiteit van het model, zijn er recent nieuwe metingen of berekende kolommen toegevoegd?
- Controleer de capaciteitsstatistieken (voor Premium), neemt de geheugenbelasting toe?
Vroege detectie van een afwijking geeft u de tijd om te optimaliseren voordat de refresh mislukt of de SLA-termijnen niet worden gehaald.