Post-Summit Databricks upgrades veranderen hoe je jobs falen — je alerts weten dat nog niet

De Data+AI Summit 2026 community thread trok 339 reacties. Dat soort betrokkenheid wijst op iets specifieks: teams plannen al adoptiesprints voor serverless compute uitbreiding, Lakehouse//RT, Unity AI Gateway governance en de Lakeflow Jobs rebranding. De geschiedenis vertelt wat er daarna gebeurt.

Na Summit 2024 migreerden teams naar Unity Catalog en ontdekten dat jobs die gebruikmaakten van legacy metastore-rechten stilletjes faalden toen de workspace-level fallback werd uitgeschakeld. Na Summit 2025 schoot serverless compute adoptie omhoog en leerden teams dat hun cluster-log-gebaseerde alerting niet meer werkte, omdat serverless driver logs niet op dezelfde manier blootstelt.

Het patroon herhaalt zich omdat het adoptiepad en het monitoring pad los van elkaar staan. Een team schakelt serverless compute in voor workflows tijdens een sprint op dinsdag. De alerting pipeline die Spark driver logs verwerkte om OOM-fouten te detecteren, draait nog steeds. Hij vindt alleen geen matches meer. Er vuurt geen alert. Er verschijnt geen fout. De job slaagt misschien zelfs na een retry dankzij auto-optimization, dat stilletjes de VM-grootte verhoogt na een geheugenfout. De oorspronkelijke failure wordt begraven in run metadata die niemand bekijkt, want de job is uiteindelijk groen geworden.

Dit is geen Databricks tekortkoming. Auto-optimization en auto-retry zijn echte verbeteringen voor betrouwbaarheid. Het probleem is dat monitoring systemen die zijn gebouwd voor expliciete failure modes niet meepassen wanneer het platform zichzelf begint te herstellen. Een job die drie keer faalt en de vierde keer slaagt, ziet er gezond uit in een pass/fail dashboard. Op je cloud-rekening ziet hij er niet gezond uit, en ook niet wanneer die vierde retry je downstream refresh 47 minuten na de SLA duwt.

Serverless compute voor workflows bevat auto-optimization dat standaard is ingeschakeld. Als een taak geen geheugen meer heeft, detecteert het platform de failure, herstart de taak op een grotere VM en gaat verder met de run. Databricks adviseert dit aan te laten. Ze hebben gelijk: het voorkomt onnodige job failures.

Maar bedenk wat dit betekent voor observability. Vóór auto-optimization produceerde een OOM-fout een gefaalde taak met een expliciete foutmelding: java.lang.OutOfMemoryError: Java heap space of The spark driver has stopped unexpectedly and is restarting. Your notebook will be automatically reattached. Je alert matchte op die strings. Nu, met auto-optimization, faalt de taak intern kort, wordt opnieuw gepland op een krachtigere node en slaagt. De run-level status is SUCCEEDED. De task-level status is SUCCEEDED. De interne retry is alleen zichtbaar als je de pogingsgeschiedenis van de taak bekijkt via de Jobs API.

Om deze gemaskeerde retries aan de oppervlakte te brengen, moet je het Jobs API runs/get eindpunt bevragen en het attempt_number veld op elke taak inspecteren. Als attempt_number groter is dan 0, heeft de taak minstens eenmaal gefaald voordat hij slaagde. De API-aanroep ziet er zo uit:

GET /api/2.2/jobs/runs/get?run_id=<run_id>&include_resolved_values=true

Parseer tasks[].attempt_number en tasks[].run_duration_ms uit de response. Een taak met attempt_number: 2 en een duur die drie keer zijn historisch gemiddelde is, geeft een duidelijk signaal dat auto-optimization een falende workload heeft gered. De workload zelf is aan het verslechteren. Zonder deze controle vlieg je blind op geheugendruk trends totdat de workload de grootste beschikbare serverless VM overtreft en echt faalt. Tegen die tijd zijn je data uren verouderd.

Databricks hernoemde Workflows naar Lakeflow Jobs. De UI veranderde, de documentatie veranderde en (cruciaal voor monitoring) sommige API response-structuren en console-paden verschoven. Als je monitoring scripts de workspace UI scrapen of vertrouwen op specifieke URL-patronen om deep-links naar gefaalde runs te maken, kunnen die links nu 404 geven of doorverwijzen.

Subtieler is het geval van teams die monitoring hebben gebouwd rondom het jobs/runs/list eindpunt. Zij moeten controleren of hun filters nog correct werken met de nieuwe taaktypen die Lakeflow Jobs ondersteunt. De introductie van Lakeflow Declarative Pipelines (voorheen Delta Live Tables) als first-class taaktypen binnen een Lakeflow Job betekent dat een enkele job run nu een mix kan bevatten van notebook tasks, Python script tasks en pipeline update tasks. Elk taaktype geeft fouten op een andere manier weer.

Een notebook task plaatst zijn fout in het error veld van de task run output. Een pipeline update task begraaft zijn fouten in het eigen event log van de pipeline, toegankelijk via het pipelines/events API eindpunt, niet de jobs API. Als je monitoring alleen de jobs API controleert, verschijnen pipeline task failures binnen een Lakeflow Job als een generieke FAILED status met een bericht als Pipeline update failed. Geen root cause, geen tabelnaam, geen data quality assertion detail.

Om de werkelijke fout te krijgen, heb je een tweede API-aanroep nodig:

GET /api/2.0/pipelines/<pipeline_id>/events?filter=level='ERROR'&max_results=10

Teams die deze tweede aanroep niet doen, eindigen met alerts die zeggen "pipeline gefaald" en verder niets. De on-call engineer opent de Databricks UI, navigeert naar de pipeline, leest het event log en ontdekt dat een schema verwachting is geschonden op een enkele tabel. Die handmatige triage stap kost 15 minuten. Vermenigvuldig met het aantal nachtelijke pipeline tasks en je hebt een on-call dienst gebouwd rondom UI-klikken.

De fix is mechanisch maar makkelijk over het hoofd te zien tijdens een feature-adoptiesprint: update je monitoring om pipeline-type tasks binnen job runs te detecteren en fan out naar de pipelines API voor foutdetails.

Summit 2026 kondigde Automatic Identity Management (AIM) voor Entra ID aan als GA op AWS en GCP, met AIM voor Okta in Public Preview. AIM synchroniseert automatisch gebruikers en groepen van je identity provider naar je Databricks account. Dit lost een reëel pijnpunt op. SCIM-provisioning handmatig beheren is fragiel en foutgevoelig.

Maar AIM verandert het failure surface voor jobs die de "Run As" configuratie gebruiken. Een veelvoorkomend productie failure-patroon ziet er vandaag zo uit: een teamlid maakt een job aan via de UI, die standaard de "Run As" instelt op zijn eigen identiteit. De job draait maandenlang goed. Die persoon verlaat het bedrijf, zijn identity provider account wordt gedeactiveerd, SCIM deprovisioneert hem uiteindelijk uit Databricks en de job faalt met een permissions-fout bij de eerstvolgende geplande run.

Met AIM gaat identity deprovisioning sneller en betrouwbaarder. Dat is goed voor security. Het betekent ook dat het tijdvenster tussen "medewerker vertrekt" en "job faalt" krimpt van dagen of weken naar uren. Als je incident response proces ervan uitging dat je tijd zou hebben om het te merken en jobs opnieuw toe te wijzen, dan is die aanname nu gebroken.

De specifieke fout die je ziet is doorgaans PERMISSION_DENIED: User does not have permission to access resource of INVALID_STATE: Run-as user is not active. Met de snellere sync van AIM verschijnen deze fouten eerder na het offboarden.

Het defensieve patroon is om productie-jobs te configureren met een service principal als "Run As" identiteit in plaats van een persoonlijk account. Databricks raadt dit al jaren aan, maar de urgentie neemt toe nu identity lifecycle management automatisch wordt. Controleer je bestaande jobs met het list eindpunt van de Jobs API en bekijk het run_as veld op elke job definitie. Elke job waarbij run_as.user_name een persoonlijk e-mailadres is, tikt als een tijdbom.

Summit-enthousiasme valt vaak samen met Databricks Runtime (DBR) versie-upgrades. Teams adopteren een nieuwe feature, merken dat die een nieuwere runtime vereist, upgraden het cluster of schakelen over naar serverless (dat altijd de nieuwste ondersteunde runtime gebruikt) en worden plotseling geconfronteerd met gedragswijzigingen waar ze niet op hadden gerekend.

DBR maintenance updates kunnen Spark defaults wijzigen, UDF-gedrag deprecaten of veranderen hoe Delta Lake omgaat met gelijktijdige writes. De ConcurrentDeleteDeleteException (met zijn bericht This transaction attempted to delete one or more files that were deleted by a concurrent update) duikt regelmatig op na runtime upgrades die de conflict resolution defaults van Delta wijzigen.

Op serverless compute kies je je runtime versie niet. Databricks beheert die. Dat betekent dat een job die vorige week prima draaide op een vastgezette DBR 14.x cluster, anders kan presteren op serverless, omdat serverless een nieuwere engine versie gebruikt. De failure hoeft niet eens een harde fout te zijn, het kan een prestatieverslechtering zijn waarbij een query die 3 minuten duurde nu 25 minuten nodig heeft, omdat de Spark optimizer een andere join-strategie koos.

Monitoring voor zulke regressies vereist duration-based alerting, niet alleen pass/fail. Houd execution_duration_ms bij vanuit de Jobs API voor elke taak per run. Stel alerts in wanneer de duur een voortschrijdend percentieldrempel overschrijdt, de p95 van de laatste 30 runs is een redelijk startpunt. Een taak die historisch in 180 seconden klaar is maar plotseling 900 seconden nodig heeft, is een failure, ook als hij technisch slaagt.

De combinatie van feature adoptie, runtime wijzigingen en identity management updates creëert een samengesteld risico. Elke wijziging afzonderlijk is beheersbaar. Gestapeld in een twee weken durende post-summit sprint produceren ze failure modes die geen enkele alertregel afzonderlijk detecteert, omdat elke regel is ontworpen voor één variabele tegelijk.

Het patroon achter al deze failure modes is hetzelfde: het platform verbeterde, maar het monitoring contract ging uit van een statisch platform. Dit oplossen vereist monitoring behandelen als een first-class workload die wordt bijgewerkt naast de features die het bewaakt.

Begin met drie concrete wijzigingen na het adopteren van een nieuwe Databricks feature:

Ten eerste: bevraag het attempt_number veld op elke taak in elke voltooide run. Een waarde boven 0 betekent dat het platform de taak opnieuw heeft geprobeerd. Log deze retries apart van harde failures. Ze zijn je vroege waarschuwing voor workloads die hun huidige resource allocatie ontgroeien.

Ten tweede: voor elke job met pipeline-type tasks, implementeer een fan-out patroon dat foutdetails ophaalt uit de pipelines/events API wanneer de taakstatus FAILED is. Sla de pipeline-fout op naast de job-level failure zodat je alerting de werkelijke root cause bevat: welke tabel, welke verwachting, welke schema change, en niet alleen "pipeline update gefaald".

Ten derde: stel een baseline van taakduren vast voor je serverless inschakelt of runtimes upgradet. Vergelijk duren na de wijziging met de baseline. Een 3x toename in duur met een SUCCEEDED status is geen succes. Het is een regressie die zich verstopt achter een groen vinkje.

MetricSign bewaakt Databricks job runs en geeft failures weer met root cause context, inclusief het detecteren van duurregressies en verborgen retries die pass/fail dashboards missen. Wanneer een taak die normaal 3 minuten duurt plotseling 25 minuten nodig heeft, markeert MetricSign de anomalie en groepeert die met gerelateerde wijzigingen in je pipeline, zodat je de impact ziet voordat je stakeholders verouderde data zien.

De volgende summit kondigt meer features aan. Het platform blijft verbeteren. Je monitoring evolueert mee, of het wordt zelf het ding dat faalt.