SageMaker Feature Store получил атомарное обновление отдельных признаков

Частичное изменение больше не требует цикла read-modify-write

Amazon SageMaker Feature Store получил API UpdateRecord для feature-level writes. Клиент передаёт только те признаки, которые изменились, а сервис атомарно объединяет их с существующей записью. Не указанные в запросе поля сохраняются без изменений; возможность доступна для Standard online store на Amazon DynamoDB и In-Memory tier на Amazon ElastiCache.

Раньше обновление одного risk_score через PutRecord требовало сначала прочитать всю запись с GetRecord, объединить значения в приложении и записать полный объект обратно. AWS связывает этот шаблон с лишней задержкой и расходом read capacity, а при параллельной работе нескольких pipelines — с риском lost update, когда полная запись одного производителя затирает изменения другого.

UpdateRecord убирает предварительное чтение и координацию между независимыми producers. Например, clickstream может обновлять page_views каждые несколько секунд, а ночной batch — lifetime_value в той же сущности. Атомарность здесь относится к слиянию переданных полей одной существующей записи, а не к транзакции над множеством записей или feature groups.

Запрос меняет до 100 признаков и не создаёт новую запись

В запросе указываются FeatureGroupName, RecordIdentifierValueAsString и список Features с парами FeatureName и ValueAsString. За один вызов разрешено обновить от одного до 100 признаков. Можно также передать TtlDuration, но тогда запрос обязан включать EventTime.

UpdateRecord — строго modify operation, а не upsert: целевая запись уже должна существовать. Первичное создание по-прежнему выполняется через PutRecord. Имена полей должны присутствовать в схеме feature group, а record identifier остаётся неизменяемым, поэтому новый API не заменяет изменение схемы или перенос объекта под другой ключ.

Каждое обновление online store порождает полный снимок записи для обычного replication pipeline в offline store. Это сохраняет согласованную форму обучающих наборов и исторической аналитики, хотя online-запись менялась частично. Следовательно, экономия на предварительном чтении не означает, что offline history хранит только дельту.

EventTime отклоняет устаревшие события, но его можно не менять

Если UpdateRecord передаёт EventTime, сервис сравнивает его с текущим значением записи. Более новое или равное время допускает обновление и продвигает EventTime, а более раннее отклоняется с HTTP 409 ConflictException. Так поздно пришедшее старое событие не должно переписать более свежие признаки.

Когда EventTime отсутствует, новые значения признаков применяются, а прежний EventTime записи сохраняется. AWS позиционирует этот режим для multi-pipeline architectures, где разные потоки владеют разными полями и не используют единые часы событий. Однако именно владелец системы должен решить, для каких полей отказ от временной проверки допустим.

В официальном материале есть небольшое различие формулировок: раздел request shape говорит, что новый EventTime должен быть позже существующего, а отдельный раздел temporal ordering допускает значение новее или равное. Для граничного случая с равным timestamp безопаснее проверить фактическую семантику по API Reference и интеграционным тестом, а не строить дедупликацию только на пересказе анонса.

Standard получает новый формат хранения Standard_V2

Для DynamoDB-backed Standard tier частичные записи требуют нового StorageType Standard_V2. Его можно выбрать при создании feature group. Существующие In-Memory groups отдельной миграции не требуют: feature-level writes работают для них в текущем формате.

AWS описывает два пути миграции старой Standard group. Feature Processor переносит данные в новую Standard_V2 group и оставляет исходную копию для простого rollback, но требует отдельной оплачиваемой миграции и смены имени в клиентах. Альтернатива — UpdateFeatureGroup с переключением storage type на месте, без downtime и с оплатой преобразования по мере касания записей.

In-place вариант сохраняет имя и endpoints, но необратим: холодные записи остаются в legacy serialization до следующей записи, а вернуться к прежнему формату нельзя. AWS рекомендует этот путь большинству клиентов, оставляя bulk migration для случаев, где важны обратимость, переименование или реструктуризация. Перед переключением поэтому нужен аудит rollback-требований и клиентов, которые редко обновляют данные.

IAM ограничивает обновление конкретных полей

Для fine-grained access control появились condition keys sagemaker:IsUpdateRecord и sagemaker:UpdatableFeatures. Первая позволяет отличить частичное обновление от полной записи PutRecord, вторая — перечислить поля, которые конкретный principal вправе менять. В примере AWS доступ разрешён для age, score и last_activity, но закрыт для ssn и salary.

Существующий явный deny на sagemaker:PutRecord автоматически блокирует и UpdateRecord, поэтому новый маршрут не обходит прежний запрет. При этом новая возможность полезна только после явной настройки allow conditions: широкое разрешение PutRecord не превращается само по себе в разделение ответственности между producers.

Для enterprise feature groups это позволяет закрепить владение полями за отдельными ETL, streaming и scoring pipelines. Но IAM контролирует право записи, а не смысл значения: диапазоны risk_score, формат времён и бизнес-инварианты всё равно требуют validation в producer или отдельном quality-контуре.

Цена записи не меняется, экономия возникает на чтении

AWS заявляет, что UpdateRecord использует ту же модель оплаты, что PutRecord. В Standard tier DynamoDB write capacity рассчитывается по размеру элемента после обновления, а не только по объёму переданной дельты. Прямая экономия появляется за счёт устранения GetRecord и связанных read capacity charges из каждого read-modify-write цикла.

API доступен во всех регионах, где предлагается SageMaker Feature Store. Для начала AWS предлагает создать Standard_V2 group либо использовать существующую In-Memory group, загрузить исходные записи через PutRecord и затем применять UpdateRecord к отдельным признакам.

Практическая ценность релиза — не в уменьшении размера любой записи, а в устранении опасной клиентской координации. Независимые producers могут атомарно менять принадлежащие им поля, stale events можно отклонять по EventTime, а IAM — сузить до списка признаков. Перед production-переходом остаются измерение реальной стоимости по полному item size, проверка равного EventTime и выбор обратимой либо необратимой миграции.