Een duidelijke mislukking is eerlijk. Een stille mislukking is dat niet.
Wanneer een Power BI verversing mislukt met een fout, zijn de gevolgen beperkt. De API retourneert een foutstatus, de melding wordt binnen enkele minuten geactiveerd en een engineer start een onderzoek. Het is bekend dat de gegevens niet beschikbaar zijn. Belanghebbenden kunnen worden geïnformeerd. De schade blijft beperkt door de snelheid waarmee de fout wordt ontdekt.
Stille storingen zijn niet alleen ernstiger, maar ook van een heel andere aard. De pipeline wordt uitgevoerd. De verversing wordt voltooid. Power BI meldt succes. Niemand wordt gealarmeerd omdat er niets is om te alarmeren – het systeem gaat ervan uit dat alles in orde is. Het eerste signaal is wanneer een belanghebbende een rapport opent en actie onderneemt op basis van onjuiste cijfers. Tegen die tijd zijn de onjuiste gegevens al uren of dagen in productie en is de vraag niet langer hoe de pipeline te repareren. Het gaat erom hoeveel beslissingen er zijn genomen op basis van onjuiste informatie.
Harde storingen trekken onmiddellijk de aandacht van de technici. Stille storingen trekken die aandacht pas als de zakelijke gevolgen zichtbaar zijn. Die asymmetrie verklaart waarom stille fouten consequent meer schade veroorzaken, ondanks dat ze minder dramatisch zijn.
De ADF-pipeline werkte prima, maar laadde niets.
Hier is een scenario dat zich regelmatig voordoet in data stacks die veel gebruikmaken van Azure. Een ADF-pipeline wordt volgens het gebruikelijke schema uitgevoerd, zonder fouten voltooid en gemarkeerd als 'Geslaagd'. Power BI vernieuwt de downstream-dataset en toont de geladen gegevens. Alles in het monitoringdashboard is groen.
Wat er werkelijk is gebeurd: de bronquery had een datumfilter dat na een configuratiewijziging restrictiever werd. De pipeline werd uitgevoerd, maar kopieerde geen rijen. Het uitvoeringsmodel van ADF beschouwt dit als een succes: de pipeline deed precies wat er van verwacht werd, alleen produceerde hij geen uitvoer. De dataset in de importmodus van Power BI bevat nu de gegevens van de vorige run. Het watermerk is niet verschoven. Niemand weet wat er aan de hand is.
De eerste die het opmerkt, is een businessanalist die de cijfers van gisteren probeert te controleren en de transacties van de vorige middag niet kan vinden. Ze escaleert het probleem naar het datateam. De dienstdoende engineer logt in op ADF, ziet de groene status en begint helemaal opnieuw met het zoeken naar waar de gegevens gebleven zijn. Zonder validatie van het aantal rijen in de pipeline-output duurt het onderzoek twee tot drie uur. Met validatie zou de afwijking binnen vijftien minuten na voltooiing van de pipeline zichtbaar zijn geweest.
De kosten lopen op drie plekken op die de meeste teams niet in kaart brengen.
De meeste engineers schatten de kosten van een data-incident in op het aantal uren dat nodig is om het op te lossen. Dat is het zichtbare deel.
Een verkoopprognose gebaseerd op onvolledige data leidt tot een toewijzing van middelen die niet overeenkomt met de werkelijkheid. Een operationeel team plant personeel in op basis van vraagcijfers van twee dagen oud. Die kosten zijn reëel, maar ze komen terecht in het operationele budget, niet in het data-budget. De analyse die de verkeerde beslissing aan het licht bracht, kwam pas dagen later. De link met de pipelinefout is indirect. Niemand dient een ticket in.
Elke keer dat een stakeholder een dataprobleem ontdekt voordat het datateam dat doet, verandert er iets. Het impliciete contract – dat het datateam zijn eigen systemen monitort – is zichtbaar verbroken. Stakeholders beginnen hun eigen controles in te bouwen: rapporten dubbel controleren aan de hand van bronsystemen, parallelle spreadsheets bijhouden, beslissingen uitstellen totdat ze de cijfers kunnen bevestigen. Die overhead blijft bestaan, ook nadat de pipeline is hersteld. Het vertrouwensincident is nu onderdeel van hun mentale beeld van het datateam.
En dan is er nog de tijd die nodig is voor het onderzoek. Een stille storing die twaalf uur in productie is geweest voordat deze wordt ontdekt, vereist dat elke laag van de stack wordt getraceerd om te achterhalen waar de storing is begonnen, wat er is aangeraakt en wanneer deze is opgetreden. Zonder traceergegevens kost dit een senior engineer doorgaans twee tot vier uur. De kosten hiervan zijn nergens zichtbaar, maar ze gaan rechtstreeks ten koste van de ontwikkelcapaciteit.
De faalpatronen die data-engineers herkennen — en die gebruikers als eerste tegenkomen
Stille fouten clusteren rond een handvol patronen die zich herhalen in verschillende datasets.
De geleidelijk groeiende null-kolom is een van de meest voorkomende. Een bronsysteem begint null-waarden terug te geven voor een veld dat voorheen wel waarden bevatte – geen schemafout, maar gewoon ontbrekende gegevens. Power BI aggregeert null-waarden als nul. Een omzetkolom begint geleidelijk lagere totalen te tonen over een periode van enkele dagen. Niemand ziet een piek. De trend is zo geleidelijk dat deze niet opvalt tijdens dagelijkse controles. Tegen de tijd dat een gebruiker vraagt waarom de cijfers lager zijn, zit het probleem al een week in de data.
Het probleem met de partitiegrenzen doet zich voor in grote feitentabellen die incrementeel worden geladen. Een datumpartitie die gegevens zou moeten bevatten van 23:45 tot middernacht op een bepaalde dag, wordt voortijdig afgebroken door een timingprobleem. Het dagtotaal is iets te laag. Het gebeurt één keer en wordt niet opgemerkt. Het gebeurt drie weken later opnieuw. Het auditspoor is nu inconsistent en het datateam besteedt twee dagen aan het reconstrueren van wat een controle van tien minuten had moeten zijn.
De mismatch in het filter voor incrementele refresh is specifiek voor Power BI beleidsregels voor incrementele refresh. Een filterkolom – meestal een datumkolom die wordt gebruikt om te bepalen welke rijen 'nieuw' zijn – wordt hernoemd in de bron. Het beleid voor incrementele refresh stopt dan met het laden van nieuwe rijen. De dataset blijft de reeds aanwezige gegevens weergeven en wordt elke dag succesvol vernieuwd, zonder nieuwe gegevens te laden.
Detectie vereist monitoring van de data, niet alleen van de dataverwerking.
De detectiekloof voor stille fouten is structureel. Pipeline-API's rapporteren de uitvoeringsstatus. Refresh-API's rapporteren de voltooiing van het laden. Geen van beide is ontworpen om de correctheid van de gegevens te rapporteren. Om deze kloof te dichten, moeten controles worden toegevoegd op lagen die door geen van beide API's worden bewaakt.
Op pipelineniveau is de validatie van het aantal rijen na elke copy activity de meest directe controle. ADF ondersteunt dit standaard via de uitvoereigenschappen van activiteiten: het aantal gelezen en geschreven rijen is beschikbaar in de uitvoeringsgeschiedenis. Een pipeline die nul rijen heeft geschreven terwijl deze normaal gesproken vijftigduizend rijen schrijft, is direct detecteerbaar.
Op datasetniveau detecteert een watermerkcontrole op de primaire tijdstempelkolom verouderde gegevens die de pipeline laag niet zal weergeven. Als de maximale transactiedatum in de geladen dataset meer dan één verversingscyclus achterloopt op de huidige tijd, is er iets misgegaan met de gegevensstroom.
Op volumeniveau detecteert een vergelijking van het huidige aantal rijen met de basislijn per dag van de week de fouten waarbij gegevens daadwerkelijk ontbreken in plaats van alleen verouderd zijn. Beide controles worden binnen enkele seconden uitgevoerd via de Power BI REST API en vereisen geen wijzigingen in de pipeline of het datamodel.