AWS tilføjer Batch
WriteRecord og ListRecords til SageMaker Feature Store
Amazon har løftet sløret for to nye data-API’er til Amazon SageMaker Feature Store: BatchWriteRecord og ListRecords. De er målrettet to konkrete driftspunkter, som mange ML-platforme har stødt panden mod: lav gennemstrømning med ét-record kald og fravær af en simpel måde at browse online-data i In‑Memory‑tieren. Det interessante er, hvor lavpraktisk forbedringen er. Mindre snak om “magien” i ML, mere fokus på at få bitsene rigtigt igennem røret.
Hvad er SageMaker Feature Store
SageMaker Feature Store er en fuldt administreret, purpose-bygget repositorie til at lagre, dele og styre features til ML-modeller. Den leverer lav latenstid i et online‑lag til realtidsinference og et offline‑lag til historik og træningsdata. Begge indtagsmønstre er understøttet: streaming og batch. Det er kernen i, at træning og inferens kan hænge sammen uden at opfinde de samme features to gange.
Strukturen er velkendt for større ML‑installationer: en online store til hurtige opslag, en offline store til længere tilbageblik og audit, og en ramme om konsistente feature‑definitioner. Ikke noget hokuspokus. Bare et system, der prøver at gøre det kedelige rigtigt.
Hvorfor PutRecord blev en flaskehals
Indtil nu har standardmønsteret været PutRecord i et loop. Ét API‑kald pr. record pr. feature‑gruppe. Det skalerer dårligt. Hvert kald har forbindelsesoverhead og lægger pres på både klient og netværk. AWS’ eget eksempel er til at tage og føle på: 10.000 records pr. sekund fordelt over fem feature‑grupper kræver 50.000 PutRecord‑kald pr. sekund for blot at holde features friske.
Den slags tal er ikke usædvanlige i forebyggelse af svindel, annoncematching eller personalisering, hvor flere feature‑grupper skal opdateres samtidigt. Konsekvensen er, at teams har brugt tid på connection pools, aggressiv batching i applikationslaget og hjemmelavede kø‑mønstre, som hører hjemme tættere på datalagets API end i hver microservice.
Hvad BatchWriteRecord konkret ændrer
BatchWriteRecord samler op til 25 records i ét kald og kan målrette flere feature‑grupper samtidig. Hvert record behandles uafhængigt, så API’et understøtter partial‑success. Det er vigtigt, fordi en enkelt fejl ikke vælter hele læsset. Ordningen bevarer de samme EventTime‑garantier som PutRecord, og man kan styre TTL pr. record. Med andre ord: færre netværksrundture, samme semantik.
BatchWriteRecord i praksis
For at tage API’et i brug kræves en opdateret klient: Boto3 i seneste udgave eller SageMaker Python SDK 3.8.0 eller nyere. IAM skal give adgang til Feature Store data plane‑kald, og execution‑rollen for SageMaker skal have adgang til S3 og AWS Glue, når eksemplerne fra AWS’ vejledning følges. Det rammer pipeline‑definitioner og IaC‑skabeloner, hvor roller ofte er stramme.
Implementeringen kræver få, men vigtige ændringer i ingestion‑koden: skift loops fra enkelt‑record til batch, introducer idempotent nøglehåndtering for at undgå dubletter ved retry, og hent per‑record fejl ud af svaret for målrettet genafspilning. Partial‑success betyder også, at observability skal op i gear. Man får ikke én binær status pr. batch, men et sæt per‑record resultater, der kræver tællere, alarmer og måske dead‑letter‑køer.
Fejlretning, retries og backpressure
Batch‑skrivninger flytter ansvaret for fejlhåndtering højere op. Når et kald returnerer 23 succes’er og 2 fejl, skal klienten vide præcis, hvad der nu sker: retry med exponential backoff, selektiv re‑batching eller parkering i en fejlkø med idempotent nøgling. Uden disciplin risikerer man huller i features, som først opdages ved inferens. Det er den slags fejl, der lugter af koldsved kl. 02.17.
Et robust mønster er at logge korreleret med record‑id og EventTime, holde styr på retry‑tællere per record og at måle fejlrate per feature‑gruppe. Overskrides tærskler, drosles upstream. Backpressure er kedeligt, men bedre end stiltiende datatab. Overvej også et lille “retry budget” pr. minut, så spikes ikke eksploderer ind i permanent kø‑opbygning.
ListRecords og hvorfor browse gør en forskel
ListRecords gør det muligt at enumerere record‑id’er i en feature‑gruppe med pagination. Det virker både med Standard‑tieren (DynamoDB‑backed) og In‑Memory‑tieren (Redis‑backed). Den praktiske forskel er størst i In‑Memory, hvor teams tidligere stod uden et net til at opdage, hvad der fandtes i online‑butikken, hvis identifikatorer var røget på gulvet efter en fejl.
Nu kan man genopbygge en manglende mapping eller verificere, at en replay rent faktisk fik de rigtige nøgler i online‑laget. Recovery‑procedurer ændrer sig: fra håb og scripts til en kontrolleret enum‑scanning med selektiv genafspilning. Det er ikke smukt, men det er drift. Og det er en reel forbedring.
Hvad ListRecords betyder for governance og audit
Muligheden for at gennemløbe id’er åbner for mere fornuftig audit på online‑data. Man kan tage stikprøver, sammenholde med offline‑lageret og fange skævheder, hvor online‑laget løber fra offline. Det afklarer også data lineage ved at pege på præcis hvilke entiteter, der blev opdateret i et givent tidsrum (kombineret med EventTime og egen logging).
Men der er et men. Store feature‑grupper kan være tunge at liste. Uden klare performance‑tal fra AWS bør scanninger gøres defensivt, pagineret og uden for hot paths. Tænk “nattetid” eller “on‑demand” i en recovery‑playbook, ikke som en del af request‑kritiske flows.
Standard eller In‑Memory og de reelle tradeoffs
Browse‑evnen i In‑Memory ændrer ikke ved grundvilkårene: Standard‑tieren giver holdbarhed via DynamoDB og et stærkere sikkerhedsnet i samspil med offline‑lageret, mens In‑Memory går efter lav latenstid og midlertidig karakter. Valget afhænger af krav til holdbarhed, konsistens, pris og fejlscenarier. Det er fristende at vælge In‑Memory “fordi det er hurtigt”, men når en nøgle ryger, vil man stadig gerne have et bagtæppe i offline‑laget.
Manglende benchmarks og det åbne spørgsmål
AWS’ eksempel illustrerer skalaproblemet — 50.000 kald/s — men der foreligger ikke uafhængige målinger af gevinsten med BatchWriteRecord under realistiske netværksforhold. Uden disse ender vurderingen let i fingerfølelse. Det kan være fint, men ikke når en platform skal hårdt i drift.
Et sobert næste skridt er at køre A/B‑målinger: identiske workloads med PutRecord vs. BatchWriteRecord, samme VPC‑miljø, samme connection pools og latenser målt i percentiler. Gør det i staging først, men vælg dataprofil, der ligner produktion. Små syntetiske tests lyver ofte pænt.
SDK, IAM og deployment‑konsekvenser
For at følge AWS’ eksempler kræves en aktiv AWS‑konto, en SageMaker execution‑rolle med adgang til S3 og AWS Glue samt rettigheder til Feature Store data plane‑kald. Minimum i IAM‑politikken omfatter BatchWriteRecord, PutRecord og ListRecords på feature‑gruppe‑ressourcer. Deployment‑pipelines skal opdatere disse roller, og driftshåndbøger bør opdatere least‑privilege‑kontroller, så ListRecords ikke åbnes bredere end nødvendigt.
SDK‑opdateringen er lavpraktisk, men vigtig: pin versioner i requirements og containers, og byg en lille “feature‑store client”‑wrapper, så batch‑mønsteret er konsistent på tværs af services. Det gør rollback nemmere, hvis noget opfører sig underligt i prod.
Monitoring, alarmer og idempotency
BatchWriteRecord ændrer dine metrikker. Overvåg ikke kun HTTP‑fejl pr. kald. Overvåg fejl pr. record, andel af partial‑success og gennemsnitlig batch‑størrelse (faldende batch‑størrelse kan indikere upstream‑jitter). Log desuden de uprocesserede records, som API’et returnerer, i en struktureret kanal, så genafspilning er deterministisk.
Idempotency bør forankres i record‑nøgler og EventTime, så retries ikke skaber dobbeltopdateringer. Hvis der bruges TTL, dokumentér levetid pr. feature‑gruppe. Det hjælper både drift og revision, når noget skal forklares tre måneder senere.
Praktiske næste skridt
Start i staging. Kør en målrettet PoC på en enkelt højtrafikeret feature‑gruppe. Mål p50/p90/p99 latenstid, CPU/netværk på indtageren, fejlrate pr. record og batch‑størrelse. Test fejlsituationer bevidst: throttling, valideringsfejl og IAM‑afslag, og verificér at partial‑success bliver håndteret uden tavst tab.
Opdater IAM‑politikkerne til det mindst nødvendige, og begræns ListRecords til de roller, der faktisk udfører recovery og audit. Sæt alarmer på stigende partial‑failure‑andel og på DLQ‑opbygning. Dokumentér replay‑procedurer: hvordan hentes tabte id’er via ListRecords, hvordan selekteres til re‑ingestion, og hvilke SLA’er gælder under recovery.
Et kort perspektiv udefra
Batched I/O er ikke særligt for Feature Store. Man ser det i andre tunge datastrømme, fx ensemble‑kørsel i vejrforskning, hvor koordineret batching og iterator‑mønstre er afgørende for throughput. Pointen her er enkel: når datalaget tilbyder native batching, bør applikationslaget ikke opfinde sin egen. Det gør arkitekturen enklere og mere forudsigelig.
Hvad det samlet set betyder for ML‑drift
De to API’er peger på en modningsfase i produktions‑ML: mindre friktion i I/O, flere værktøjer til recovery og et lille, men vigtigt, skridt mod bedre operationaliserbarhed. Det er ikke en sølvkugle. Der mangler benchmarks, cost‑guidance og mere håndfast vejledning til transaktionel sikkerhed ved partial‑success.
Alligevel er retningen rigtig. Mindre rammeværkssnak. Flere sporskifter tæt på data. Man opdager forskellen, når man sidder med det i hænderne — eller når nattens første alarm ikke kommer.
Kilder og videre læsning
Primær kilde: AWS’ gennemgang af BatchWriteRecord og ListRecords med kodeeksempler, forudsætninger og IAM‑minimum. Supplerende perspektiv: erfaringer fra domæner, hvor batching og koordineret I/O er normen, som i ensemble‑beregninger, kan inspirere til testdesign og måleprogram, men er ikke direkte evidens for Feature Store‑ydelse.
Der anbefales egne benchmarks i jeres miljø før ændringer rulles bredt ud. Lav målesæt, gem rådata og dokumentér konfigurationer. Ellers er det svært at gentage forbedringen, når den først er fundet.
