YP AI-logo
Data & Analytics

Hoe vangen AI werknemers problemen in het datawarehouse binnen het uur op?

Een AI werknemer voor de gezondheid van uw datapijplijn, gekoppeld aan uw datawarehouse en GitHub. Elk uur controleert het de versheid van tabellen, afwijkingen in rijaantallen en schemaverschuivingen, waarschuwt het Slack, en stelt het een GitHub issue op met de vermoedelijke oorzaak. De data wordt nooit aangeraakt.

YP×SlackGitHub
Wanneer
Elk uur
Systemen
WarehouseSlackGitHub
Modus
Alleen lezen: waarschuwt en stelt een issue op, meer niet
Probleem

De gezondheid van een datawarehouse kondigt zichzelf niet aan. Een laadtaak kan mislukken zonder foutmelding als die is gebouwd om een slechte batch over te slaan en door te gaan. Een tabel kan verouderen omdat een bovenliggende planning is uitgeschakeld, niet omdat er iets is vastgelopen. Een schema kan verschuiven omdat een API van een bron een veld heeft toegevoegd, waarna de laadtaak nog steeds 'slaagt' maar simpelweg weglaat of op null zet wat die niet herkent. Elk van deze gevallen ziet er van buitenaf prima uit, totdat een query verderop iets verkeerds teruggeeft, en meestal is de eerste die het merkt degene wiens rapport er vreemd uitziet in een overleg met belanghebbenden. De gebruikelijke aanpakken houden geen stand. Dashboards die op de data zijn gebouwd, kunnen u niet vertellen dat de data zelf kapot is. Ze tonen wat er is, juist of niet. Een controle van het type 'is de taak gedraaid' bevestigt dat het proces met code nul is afgesloten, niet dat de tabel die het schreef er ook echt goed uitziet. Iemand die met het oog naar rijaantallen kijkt, merkt het uiteindelijk, meestal nadat een rapport verderop al verkeerd naar buiten is gegaan. Dit is een ander soort storing dan een applicatie die midden in een verzoek een fout geeft: de pijplijn kan slagen terwijl het datawarehouse toch ongezond is.

Wat het doet

Elk uur leest de AI werknemer voor de gezondheid van de datapijplijn het datawarehouse alleen uit en controleert elke bewaakte tabel aan de hand van de SLA voor versheid, vergelijkt het rijaantal van vandaag met de eigen voortschrijdende basislijn van de tabel, vergelijkt het huidige schema met de laatst waargenomen vorm, en zoekt naar laadtaken die zijn mislukt of stilletjes zijn blijven hangen. Wanneer het iets buiten de grenzen aantreft, plaatst het een waarschuwing in het Slackkanaal van het datateam met de betrokken tabel, de afwijking en de meest waarschijnlijke oorzaak, en stelt het een GitHub issue op met dezelfde diagnose zodat het incident wordt bijgehouden. Er wordt nooit naar het datawarehouse geschreven. De waarschuwing en het opgestelde issue zijn de enige uitvoer.

Hoe het werkt

Zie precies hoe het werk wordt gedaan.

Draait elk uur, vanuit de actuele stand

Een geplande run start eens per uur en herberekent elke controle vanuit de actuele stand van het datawarehouse. Er wordt niets meegenomen tussen runs, zodat versheid, rijaantallen en schema altijd worden gemeten aan de hand van wat er live staat.

Neemt uw gezondheidsregels mee

Wat als verouderd geldt, hoe een normale trend in rijaantallen eruitziet, en welke vorm elk schema hoort te hebben, reizen mee als vaardigheden en geheugen: SLA's voor versheid per tabel, de tabellen die met pieken groeien versus gestaag, en eerdere incidenten die de moeite waard zijn om nieuwe afwijkingen tegen af te zetten. Scherp een SLA aan of noteer een legitiem wekelijks gat en de controles passen zich aan.

Leest het datawarehouse, met rechten die u instelt

Het leest de versheid van tabellen (het meest recente laadtijdstip per tabel, getoetst aan de SLA), rijaantallen (het aantal van vandaag ten opzichte van de voortschrijdende basislijn van de tabel), de schemastatus (de huidige kolommen en typen, vergeleken met de laatst waargenomen vorm), en de laadgeschiedenis (recente taakruns, om een mislukte of vastgelopen laadtaak op te merken). Inloggegevens blijven in het geheugen, worden nooit naar schijf geschreven en worden nooit aan het model getoond.

Waarschuwt en stelt op, herstelt nooit

Wanneer een controle buiten de grenzen terugkomt, plaatst het een bericht in Slack met de tabel, de afwijking en de beste inschatting van de oorzaak, en stelt het een GitHub issue op met dezelfde diagnose, zodat het incident als een te volgen concept binnenkomt en niet als een samengevoegde wijziging. Het raakt de pijplijn, het schema of de data niet aan.

Alleen lezen, geen uitzonderingen

Het heeft geen schrijftoegang tot welke tabel, welk schema of welke pijplijnconfiguratie dan ook. Het kan alleen observeren en rapporteren. De uitvoer is precies tweeledig: de waarschuwing in Slack en het opgestelde GitHub issue. Het datateam beslist wat er wordt hersteld; er verandert niets uit zichzelf.

Waarborgen

Draait in uw eigen omgeving

Elke run is geïsoleerd binnen uw eigen infrastructuur en bereikt alleen het datawarehouse waarvoor het bereik is ingesteld; uw data verlaat uw omgeving nooit, en alleen de waarschuwing in Slack en het opgestelde issue verlaten de run.

Rechten die u instelt

De inloggegevens voor het datawarehouse en het GitHub token maken verbinding met de rechten die u instelt, worden in het geheugen gehouden, tijdens de run ingevoegd, en nooit naar schijf geschreven of aan het model getoond.

Alleen lezen, geen uitzonderingen

De verbinding met het datawarehouse is alleen lezen. Het kan geen rij wijzigen, geen schema aanpassen en geen pijplijn aanraken. Het kan alleen waarschuwen en opstellen.

Opstellen, niet beslissen

Het GitHub issue is een concept met een diagnose eraan, nooit automatisch gesloten of toegewezen. Vanaf daar is een aangewezen persoon eigenaar van het incident.

De regels zijn van u

De SLA's, de basislijnen en de rechten per systeem zijn van u, met versiebeheer en aangepast op uw voorwaarden, niet in het dashboard van een leverancier.

Het resultaat

Problemen in het datawarehouse die vroeger pas opdoken als een verkeerd getal in iemands dashboard, verschijnen nu als een gezondheidscontrole per uur met een specifieke tabel, een specifieke afwijking en een vermoedelijke oorzaak, al in Slack en al opgesteld als issue. De AI werknemer leest en rapporteert; het datateam beslist wat er wordt hersteld.

Elk uur

Versheid, rijaantallen en schema opnieuw gecontroleerd tegen het live datawarehouse

Alleen lezen

Niets geschreven naar welke tabel, welk schema of welke pijplijn dan ook

2 uitvoeren

Een waarschuwing in Slack en een opgesteld GitHub issue, meer niet

Weet u niet waar u moet beginnen?

Onze gratis AI-audit laat zien waar AI kansen biedt voor uw bedrijf, welke risico's daarbij komen kijken, en zet meteen uw eerste AI werknemer aan het werk.

Klaar om uw bedrijf te transformeren?

Klaar om uw eigen AI werknemers in actie te zien?