Amazon SageMaker Feature Store hat die UpdateRecord-API eingeführt. Diese Erweiterung erlaubt atomare Schreiboperationen auf einzelnen Features innerhalb einer Feature-Gruppe, ohne den bisher notwendigen vollständigen Read-Modify-Write-Zyklus.
Systemarchitektur und Schnittstellen
Bisher erforderte jede Änderung eines einzelnen Feature-Werts den Aufruf von PutRecord, der den gesamten Datensatz las, im Client-Code modifizierte und vollständig zurückschrieb. Dies erzeugte unnötige Latenz, zusätzlichen Verbrauch von Read Capacity Units und erhöhte das Risiko von Race Conditions.
Die neue UpdateRecord-API adressiert diese Schicht direkt. Sie akzeptiert eine Liste von bis zu 100 Feature-Werten und wendet diese atomar auf den bestehenden Datensatz an. Nicht genannte Features bleiben unverändert. Der Datensatz muss bereits existieren – UpdateRecord ist keine Insert-Operation.
Speicherschichten und Migrationspfade
Für den Standard-Tier (DynamoDB-basiert) wurde das neue Speicherformat Standard_V2 eingeführt, das Feature-Level-Schreibvorgänge nativ unterstützt. Der In-Memory-Tier (ElastiCache) unterstützt die Funktionalität ohne Formatänderung.
Bestehende Feature-Gruppen können auf zwei definierten Pfaden migriert werden:
- Bulk-Migration über einen Feature Processor in eine neue
Standard_V2-Gruppe. - In-Place-Switchover mittels
UpdateFeatureGroup-API, der ohne Ausfallzeit arbeitet und nur tatsächlich berührte Datensätze berechnet. Dieser Pfad ist irreversibel und wird für die meisten Systeme empfohlen.
Zeitliche Kohärenz und Offline-Replikation
UpdateRecord respektiert die bestehende EventTime-Semantik. Wird eine EventTime mitgeliefert, erfolgt die Aktualisierung nur, wenn diese neuer oder gleich der aktuellen ist. Andernfalls wird ein HTTP 409 zurückgegeben. Ohne EventTime wird die bestehende Zeit beibehalten – ein Verhalten, das sich besonders für Multi-Pipeline-Architekturen eignet.
Alle Änderungen fließen über die gleiche Replikationspipeline in den Offline Store. Jede Aktualisierung erzeugt dort einen vollständigen Snapshot, um konsistente Trainingsdatensätze zu gewährleisten.
Quelle: AWS AI Blog
Häufig gestellte Fragen
Welche Voraussetzung muss ein Datensatz erfüllen, damit UpdateRecord angewendet werden kann?
Der Datensatz muss bereits in der Feature-Gruppe existieren. UpdateRecord kann keine neuen Records anlegen.
Kann der Record Identifier (Primärschlüssel) über UpdateRecord geändert werden?
Nein. Der Primärschlüssel bleibt unveränderlich. Nur Feature-Werte können aktualisiert werden.
Wie verhält sich die neue API hinsichtlich IAM-Berechtigungen?
Es wurden zwei neue Bedingungsschlüssel eingeführt (sagemaker:IsUpdateRecord und sagemaker:UpdatableFeatures), die eine feingranulare Steuerung erlauben. Bestehende Richtlinien, die PutRecord verweigern, blockieren automatisch auch UpdateRecord.
Welche Anwendungsfälle profitieren besonders von dieser Änderung?
Streaming Feature Hydration aus mehreren unabhängigen Quellen, effizientes Backfilling neuer Features, großflächige Fehlerkorrekturen sowie High-Velocity-Updates in transaktionalen Systemen wie Betrugserkennung.