stale data in Power BI zijn een van de moeilijkst te detecteren problemen, omdat de vernieuwings-API een succesrapport geeft, ongeacht of er daadwerkelijk nieuwe gegevens zijn geladen. Een dataset kan vanuit het perspectief van Power BI volledig actueel zijn, terwijl er gegevens worden weergegeven die dagen oud zijn.
De watermerkbenadering begrijpen
Een watermerk is de maximale waarde van een datumveld die aangeeft "hoe recent deze gegevens zijn". Voor een transactietabel is dit de maximale transactiedatum. Voor een logtabel is dit de maximale tijdstempel van de gebeurtenis. Voor een langzaam veranderende dimensie kan dit de maximale datum van de laatste wijziging zijn.
Na elke refresh controleert het monitoringsysteem de dataset op deze maximale waarde (met behulp van de Power BI DAX-query-API) en vergelijkt deze met de verwachte waarde op basis van het schema:
- Dagelijkse refresh om 06:00 uur: de maximale transactiedatum moet gisteren zijn (of vandaag als het een live dataset betreft)
- refresh per uur: de maximale gebeurtenistijdstempel moet binnen de laatste 2 uur vallen
- Wekelijkse refresh: de maximale datum moet binnen de afgelopen week vallen
Als de maximale datum sinds de vorige refresh niet is opgeschoven, zijn de nieuwe gegevens niet geladen, ook al is de refresh zonder fouten voltooid.
Veelvoorkomende oorzaken van stale data
Mislukte ETL-upstream: Een ADF pipeline of dbt job is stilzwijgend mislukt of heeft geen nieuwe uitvoer gegenereerd. De brontabel bevat nog steeds de gegevens van gisteren. Power BI vernieuwt deze met succes.
Bronsysteem heeft niet geëxporteerd: De brontoepassing heeft het dagelijkse exportbestand niet kunnen genereren. De stagingtabel bevat geen nieuwe rijen voor vandaag. ADF heeft nul rijen gekopieerd en meldde succes.
Fout bij incrementele refresh van partities: Een Power BI-dataset die gebruikmaakt van incrementele refresh had een verkeerd geconfigureerd beleid waardoor een oude partitie werd herladen in plaats van de huidige. De refresh is voltooid, het aantal rijen is vergelijkbaar, maar de gegevens zijn afkomstig uit een vorige periode.
Probleem met tijdzone: De ETL wordt uitgevoerd in UTC, maar laadt gegevens met behulp van een lokaal tijdfilter. Een wijziging in de tijdzoneconfiguratie zorgt ervoor dat het filter records van vandaag uitsluit.
Implementatie van watermerkbewaking
Watermerkbewaking vereist dat bekend is welke kolom de "actualiteit" voor elke dataset vertegenwoordigt. Dit verschilt per dataset en vereist doorgaans configuratie in plaats van automatische detectie.
Voor datasets met een standaard naamgevingsconventie (tabellen met kolommen zoals event_date, transaction_date of modified_at) kan bewaking automatisch watermerkkandidaten detecteren. Voor andere datasets is expliciete configuratie nodig.
Het verwachte actualiteitsvenster varieert ook: een dataset die elk uur wordt vernieuwd, moet een strakkere tolerantie hebben dan een dataset die wekelijks wordt vernieuwd. Het monitoringsysteem moet zowel het schema als de verwachte vertraging kennen om een watermerk correct te kunnen classificeren als verouderd of acceptabel oud.