Repository navigation
feat: Batch DynamoDB online reads across feature views - #7134
Merged
ntkathole merged 1 commit intoNov 12, 2026
Merged
Conversation
|
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #7134 +/- ##
==========================================
+ Coverage 51.88% 52.06% +0.18%
==========================================
Files 458 459 +1
Lines 57726 57881 +155
Branches 8486 8506 +20
==========================================
+ Hits 29950 30137 +187
+ Misses 25745 25705 -40
- Partials 2031 2039 +8
... and 8 files with indirect coverage changes Continue to review full report in Codecov by Harness.
🚀 New features to boost your workflow:
|
ntkathole
force-pushed
the
feat/dynamodb-batched-online-read
branch
from
November 12, 2026 03:59
bb3b127 to
4342d12
Compare
ntkathole
approved these changes
Nov 12, 2026
The generic OnlineStore._read_features_per_fv loop reads one feature view after another, so a sync request spanning N feature views costs at least N sequential BatchGetItem round trips, and an async one at least N concurrent requests. Redis and Postgres already override that seam to batch; DynamoDB now does too. Each feature view lives in its own DynamoDB table, and a single BatchGetItem request can read from several tables at once. The override resolves every view's entity ids up front, packs all of the keys into as few requests as possible (at most batch_size keys each, across all of their tables), sends those requests in parallel (a thread pool capped at max_read_workers on the sync path, asyncio.gather on the async path) and then splits the returned items back apart by table and entity id. Each table keeps its own ProjectionExpression and ConsistentRead setting. BatchGetItem rejects a request that repeats a key within a table, so views that map to the same table, such as one feature view requested under two aliases, are read once with the union of their requested features. Following the Postgres implementation, a single-view request keeps the generic path, and requests larger than the new max_batched_result_rows setting (entity rows x feature views, default 2048, 0 disables batching) also fall back to it. Past that size each view already fills requests of its own, so packing saves at most one partially filled request per view while holding every view's items at once. The item parsing in _process_batch_get_response moves into a shared _to_read_row helper so the batched and per-view paths decode items identically. Refs feast-dev#3259 Signed-off-by: NopeCharon <115794254+NopeCharon@users.noreply.github.com>
ntkathole
force-pushed
the
feat/dynamodb-batched-online-read
branch
from
November 12, 2026 06:49
4342d12 to
51b75b5
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What this PR does / why we need it:
The generic
OnlineStore._read_features_per_fvloop reads one feature view after another. For DynamoDB that means a syncget_online_featurescall spanning N feature views costs at least N sequentialBatchGetItemround trips, and the async path sends at least N separate requests. Redis and PostgreSQL already override this seam to batch. This PR does the same for DynamoDB, as discussed in #3259, where per-store overrides were agreed as the approach.DynamoDB keeps each feature view in its own table, and one
BatchGetItemrequest can read from several tables. The override:batch_sizekeys per request across all of its tables. Each table keeps its ownProjectionExpressionandConsistentRead;max_read_workerson the sync path,asyncio.gatheron the async path;grouped_refsorder.For example, a request for 10 feature views and 5 entities now needs 1
BatchGetItemcall instead of 10.BatchGetItemrejects a request that lists the same key twice for a table. So views that map to the same table, such as one feature view requested under two aliases, are read once, projecting the union of their requested features. Extra features in a row are already ignored when the response is filled.The gating follows the PostgreSQL implementation (#6832):
max_batched_result_rowssetting (entity rows × feature views, default2048) also take the generic path. At that size each view already fills requests of its own, so packing saves at most one partly filled request per view, while holding every view's items at once raises peak memory.max_batched_result_rows: 0turns batching off.Error and throttling behaviour does not change: any exception from
batch_get_itemstill propagates, andUnprocessedKeysare handled the same way as in the per-view path. The item decoding in_process_batch_get_responsemoves into a shared_to_read_rowhelper, so both paths parse items the same way.Docs: the DynamoDB online store reference (new option plus a performance note) and the online server performance tuning guide.
Which issue(s) this PR fixes:
Refs #3259
Checks
git commit -s)Testing Strategy
New tests are in
sdk/python/tests/unit/infra/online_store/test_dynamodb_batched_read.py. They run against moto-backed tables, and each one covers both the sync and the async override:batch_size.max_batched_result_rows: 0, or a request over the limit falls back to oneonline_readper view.The existing DynamoDB unit tests still pass.
Misc
Release note: The DynamoDB online store now packs the reads of every feature view in a request into shared BatchGetItem calls, so requests that span several feature views need fewer round trips. The new
max_batched_result_rowsoption controls this.