Diepgaande artikelen over data observability, lineage en incidentrespons — voor data engineers die Power BI, ADF, Databricks, Fabric en dbt beheren.
Read in English →De PDF connector in Power Query werkt prima tijdens development. Hij faalt bij scheduled refresh, op het moment dat niemand toekijkt terwijl de column mappings verdwijnen.
Custom visuals zoals PBIGenie's Hammerhead maken actual-versus-budget vergelijkingen leesbaar. Ze maken de onderliggende data nog niet betrouwbaar.
Copilot schrijft een DAX-query die je dataset refresh laat time-outen. Het error log zegt timeout. Het zegt niet waarom die query überhaupt bestond.
Synced tables, scale-to-zero session drops en metrics die nul rapporteren terwijl de data er nog is. Lakebase introduceert failure modes die niet aansluiten op je bestaande Databricks monitoring.
Een Databricks job mislukt om 03:00 uur. Het cluster is beëindigd. De driver log is overschreven. Het downstream dbt model is gewoon uitgevoerd, op de data van gisteren. Zo bouw je het audit trail dat Databricks standaard niet geeft.
Query-gebaseerde connectoren in Databricks zijn afhankelijk van Delta Lake-snapshots die ongemerkt kunnen verouderen, waardoor downstream-gebruikers gegevens lezen die er actueel uitzien, maar dat niet zijn.
Je hebt een melding ingesteld voor je Power BI omzetkaart. Drie weken later gaat de pipeline kapot, geeft de kaart het cijfer van gisteren weer en krijgt niemand een melding.
Je Fabric capaciteit bereikte vanochtend om 06:12 uur 100% benutting. De app Capaciteitsstatistieken zal dit pas over 15 minuten weergeven. Tegen die tijd zijn interactieve zoekopdrachten al vertraagd.
Je exemplaar van Lakehouse gaf een groene melding. De bezettingsgraad bedraagt 84%. Direct Lake heeft het rapport op tijd aangeleverd. De cijfers kloppen nog steeds niet en wegen €1,4 miljoen niet.
Leveranciers noemen vrijwel alles een observatietool. Dit zijn de vijf functionaliteiten die bepalen of een tool je team echt helpt of dat het gewoon weer een dashboard is dat je kunt negeren.
Azure Monitor is uitstekend in één ding: het laat je weten wanneer het CPU-gebruik stijgt. De problemen die datateams 's nachts wakker maken, leven in de gaten tussen wat het bewaakt en wat de business ziet.
De meeste systemen voor datamonitoring bestaan uit een Slack-kanaal, een paar cronjobs en een flinke dosis hoop. De teams die betrouwbare data leveren, zijn de teams die de vier onderstaande lagen bouwen – in deze volgorde.
Een tool voor het bewaken van de datakwaliteit laat je weten wanneer een kolom een door jou opgestelde regel overtreedt. Het is de goedkoopste en snelste verbetering die de meeste datateams kunnen doorvoeren. Maar hier houden de meeste teams het bij, en daar beginnen de problemen.
Power BI meldt dat de refresh is geslaagd. ADF meldt dat de pipeline is uitgevoerd. Databricks toont alle voltooide taken. je gebruikers bekijken de cijfers van gisteren.
De meeste vergelijkingen missen de vraag die ertoe doet: dekt het platform daadwerkelijk jouw stack?
Je dbt-taak is voltooid. Je ADF-pipeline is uitgevoerd. Je Power BI dashboard toont de cijfers van vorige week. Niemand heeft een melding ontvangen.
Fabric biedt drie niveaus van pipeline-waarschuwingen: op activiteitsniveau, item niveau en werkruimteniveau. Geen van deze niveaus beantwoordt echter van nature de vraag "Is het bestand op tijd aangekomen?".
Vijf faallagen, geen enkele standaardtool die ze allemaal afdekt, en een correlatieprobleem waardoor elk incident op drie lijkt.
Je refresh zegt succeeded. Je gebruikers zien verkeerde data. Dit zijn de vier signalen die een data observability tool bewaakt en die de meeste Power BI-monitoring setups missen.
Een mislukte refresh meldt zich. Onjuist geladen gegevens melden zich niet.
Een praktische checklist voor teams die data-issues willen vangen voordat hun gebruikers ze zien — zonder direct een volledige data observability tool aan te schaffen.
Power BI meldt 'refresh geslaagd'. Het rapport toont lege data. Ergens tussen je ADF pipeline en de Fabric lakehouse is een kolom hernoemd. Je kunt niet achterhalen welke van je 32 datasets afhankelijk is van die kolom.
De meeste lineage-tools laten zien wat er is gebeurd. Lineage tijdens het compileren laat zien wat er misgaat.
Rocky, een op Rust gebaseerd beheerplatform voor datawarehouses, berekent de kolomherkomst tijdens de compilatie in plaats van na de uitvoering. Dit verschil bepaalt of je een defecte join ontdekt voordat of nadat je stakeholders dat doen.
Zonder een overzicht van je dataketen moet elk onderzoek helemaal opnieuw beginnen.
Datamonitoringssoftware vertelt je wat er kapot is gegaan. Lineage vertelt je waarom en wat het allemaal meesleurt.
Tijdens migratie bewaak je niet één omgeving — je bewaakt er twee. Veel datamonitoring software is gebouwd om één stack te bewaken, niet twee stacks die naast elkaar draaien.
Drie generaties ETL-tools, één datastack — behoud van overzicht, zelfs wanneer de tools voortdurend veranderen.
Je R-code wordt foutloos uitgevoerd. De cell is klaar. Het plotgebied is leeg. Databricks vertelt je niet waarom — want vanuit het perspectief van de runtime is er niets fout gegaan.
SharePoint-lijsten importeren in een DirectQuery-model klinkt pragmatisch. De storage engine denkt daar anders over.
Het tabblad 'Compute' verdwijnt geruisloos wanneer de machtigingen onjuist zijn. Drie instellingen bepalen of je gebruikers het kunnen zien, en geen van deze instellingen geeft een foutmelding.
De consultant van je leverancier heeft op vrijdagmiddag om 16:00 uur per ongeluk een productienotebook overschreven. Zo voorkomt je met behulp van maprechten, service principals en Git-mappen dat dit nogmaals gebeurt.
Er zijn zes Spark-eigenschappen die de verbinding vormen tussen je Databricks-cluster en een Iceberg-tabel die is geregistreerd in AWS Glue. Als er één fout is, krijgt je de foutmelding TABLE_OR_VIEW_NOT_FOUND, zonder enige aanwijzing welke eigenschap de fout heeft veroorzaakt.
Een UNION ALL in de USING-clausule lijkt correct totdat twee brontabellen een rij voor dezelfde sleutel aanleveren. Delta verwerpt de ambiguïteit direct.
Het splitsen en ophalen van items werkt perfect met voorbeeldgegevens. Productiestrings bevatten echter spaties aan het einde, ingesloten scheidingstekens en ontbrekende velden, waardoor je kolommen zonder waarschuwing null worden.
Als je al je bronnen samenvoegt tot één bron, zal Spark je straffen met een foutmelding over een onduidelijke overeenkomst, tenzij je eerst de duplicaten verwijdert.
Standaardmeldingen missen de fouten die daadwerkelijk problemen veroorzaken. Hieronder een vergelijking van de belangrijkste Power BI monitoringtools op het gebied van detectie, correlatie en implementatietijd.
De native Azure Monitor detecteert fouten in de pipeline. Deze mist echter de copy activity die is geslaagd met een onjuist schema – en dat is nu juist de activiteit waarover je belanghebbenden contact zullen opnemen.
Het verschil in uitvoeringstijd tussen PySpark en Scala wordt niet gemeten door de meeste benchmarks. De echte kosten zitten hem in de serialisatiegrenzen, het procesmodel van de executor en de plek waar je UDF's worden uitgevoerd.
De tutorial toont een groen vinkje. In de productieomgeving is een halfvolle Lakehouse-tabel te zien en vraagt een belanghebbende waarom de omzet van gisteren ontbreekt.
Power BI heeft ingebouwde meldingen voor mislukte refreshen. Deze zijn echter niet voldoende voor de meeste productieomgevingen.
Als handmatige refresh werkt en geplande refresh mislukt, ligt het probleem niet bij de datasource. Het ligt aan de omgeving die de geplande uitvoering gebruikt.
Een gateway die om 02:00 uur offline gaat en om 09:00 uur weer online is, kan tientallen geplande refreshen ongemerkt laten mislukken terwijl iedereen slaapt.
Wat doe je als het 3 uur 's nachts is en je belangrijkste dataset net gefaald is in de refresh? Een data-pipeline-managementplaybook voor het moment dat monitoring zijn eerste alert afgeeft.
Reconciliatietaken vergelijken twee grote datasets rij voor rij. Wanneer die vergelijking nooit convergeert, verbruikt je cluster onnodig veel rekenkracht totdat iemand het opmerkt of het budget op is.
Je dbt-run is om 04:12 voltooid. Drie modellen zijn mislukt. Het foutenlogboek meldt 'huidige transactie is afgebroken'. Power BI heeft de gegevens van gisteren al bijgewerkt.
Je ADF-pipeline is om 03:42 mislukt met een UserError-code die op zichzelf niets zegt. De Power BI refresh die ervan afhankelijk is, vindt over twee uur plaats. Hier lees je hoe je de foutklasse kunt interpreteren en direct naar de oplossing kunt gaan.
Je DAX-query retourneert 11.000 rijen in DAX Studio en 6.000 via VBA. Geen foutmelding. Geen waarschuwing. Alleen ontbrekende gegevens die je stakeholders eerder zullen ontdekken dan jij.
Je DAX-query levert 11.000 rijen op in DAX Studio, maar slechts 6.000 via VBA. De query zelf is niet fout. De onderliggende ADODB-implementatie is dat wel.
De installatiewizard lijkt eenvoudig. Vier stappen, een paar opgeslagen procedures, klaar. Maar de database-installatie mislukt zonder aan te geven welke voorwaarde daadwerkelijk is gecontroleerd en afgewezen.
Je geplande refresh is om 06:00 uur mislukt. Het foutbericht bevat een AADSTS-code. Hier lees je wat elke code betekent.
Een DM_GWPipeline-fout betekent dat de gateway een deel van het probleem is. Hier lees je hoe je kunt achterhalen welk deel precies.
De verbindingstest slaagt. De pipeline run mislukt met foutcode 403. Dat zijn niet dezelfde dingen.
DRIVER_NOT_RESPONDING is een symptoom. De oorzaak is bijna altijd geheugenoverbelasting of een GC-pauze. Hier lees je hoe je de oorzaak kunt opsporen en het probleem kunt oplossen.
Het model werkt lokaal. De implementatie in productie mislukt. Het verschil zit hem bijna altijd in machtigingen, inloggegevens of de SQL-dialect.
MetricSign monitort uw Power BI-datasets, ADF-pipelines, Databricks-jobs, Fabric Pipelines en dbt-modellen — en meldt incidenten met context vóórdat uw stakeholders het merken.
Gratis aan de slag →