Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat: Adding 'SortedFeatureView' type to support Range Queries #168

Merged
merged 5 commits into from
Feb 11, 2025

Conversation

Manisha4
Copy link
Collaborator

@Manisha4 Manisha4 commented Feb 11, 2025

What this PR does / why we need it:

Updating the feast protos with a new FeatureView type 'SortedFeatureView' used specifically for range series support.

@Manisha4 Manisha4 changed the title Adding 'SortedFeatureView' type to support Range Queries featAdding 'SortedFeatureView' type to support Range Queries Feb 11, 2025
@Manisha4 Manisha4 changed the title featAdding 'SortedFeatureView' type to support Range Queries feat: Adding 'SortedFeatureView' type to support Range Queries Feb 11, 2025
// System-populated metadata for this feature view.
FeatureViewMeta meta = 2;
}

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This empty line can be removed.

import "feast/core/DataSource.proto";
import "feast/core/Entity.proto";
import "feast/core/Feature.proto";
import "feast/core/FeatureView.proto";
Copy link

@kpulipati29 kpulipati29 Feb 11, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unused import FeatureView can be removed?

SortedFeatureViewSpec spec = 1;

// System-populated metadata for this feature view.
FeatureViewMeta meta = 2;
Copy link

@kpulipati29 kpulipati29 Feb 11, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

FeatureViewMeta definition is missing, this needs to be defined?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

FeatureViewMeta is defined in FeatureView.proto which is why it is imported


// Batch/Offline DataSource where this view can retrieve offline feature data.
DataSource batch_source = 7;
// Streaming DataSource from where this view can consume "online" feature data.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Need an empty line here? (between batch and stream source definitions)

repeated FeatureSpecV2 entity_columns = 12;

// List of sort keys for this feature view.
repeated SortKey sort_keys = 31;

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm I was thinking we decided not to allow more than one field as a sort key, we need to double check this about whether we want to allow multiple fields as sort keys or not.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We don't need to buffer the index for this field, it is a critical field for this feature view type, so just use index 13

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

+1 on using index 13. This is completely new implementation.


// Defines the sorting criteria for range-based feature queries.
message SortKey {
// Name of the feature or entity used for sorting.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Name of the feature or entity used for sorting.

Entities in feature view maps to partition key in Scylla db and not used as a sort key right? You think we should remove entity here?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yep, will remove

@@ -40,6 +41,12 @@ service RegistryServer{
rpc GetFeatureView (GetFeatureViewRequest) returns (feast.core.FeatureView) {}
rpc ListFeatureViews (ListFeatureViewsRequest) returns (ListFeatureViewsResponse) {}

// SortedFeatureView RPCs
Copy link

@kpulipati29 kpulipati29 Feb 11, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Need to check but are you sure that you need to have ApplySortedFeatureView and DeleteSortedFeatureView here? Because for example if you look at StreamFeatureView or OnDemandFeatureView RPCs below, they only have Get and List. I think it should be similar for SortedFeatureView too, isn't it?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The generic Apply and Delete rpcs should handle all feature view types, we don't need specific ones for SortedFeatureView.

@@ -277,6 +286,36 @@ message ListOnDemandFeatureViewsResponse {
repeated feast.core.OnDemandFeatureView on_demand_feature_views = 1;
}

// SortedFeatureView for range queries

message ApplySortedFeatureViewRequest {

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This can be removed if we know that Apply and Delete is not needed for SortedFeatureView.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Needed for remote registry. We should implement it for remote registry.

repeated feast.core.SortedFeatureView sorted_feature_views = 1;
}

message DeleteSortedFeatureViewRequest {

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same here, this can be removed if we know that Apply and Delete is not needed for SortedFeatureView.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Needed for Remote registry

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Remote registry already uses the generic apply and delete methods that internally handle the logic for different feature view types. I think it's best to keep this consistent and not make a special case here.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah agree, the delete looks generic for all feature view types. For example, we just need to add logic for our SortedFeatureView type here in the existing DeleteFeatureView

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We can remove ApplySortedFeatureView and DeleteSortedFeatureViews.

@@ -421,4 +460,4 @@ message ListProjectsResponse {
message DeleteProjectRequest {
string name = 1;
bool commit = 2;
}
}

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh and this is not the right place to comment, but you should also add SortedFeatureView to Registry.proto somewhere over here

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good catch, I missed that, thanks!

}

// A collection of multiple SortedFeatureViews.
message SortedFeatureViewList {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is redundant with ListSortedFeatureViewsResponse below and not needed.

@@ -217,6 +225,7 @@ message AnyFeatureView {
feast.core.FeatureView feature_view = 1;
feast.core.OnDemandFeatureView on_demand_feature_view = 2;
feast.core.StreamFeatureView stream_feature_view = 3;
feast.core.SortedFeatureView sorted_feature_view = 4;
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's leave a buffer on the index for sorted feature view in case Feast adds other feature views and we get a conflict.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agree

Copy link
Collaborator

@piket piket left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You need to add SortedFeatureView similar to the other feature view types to the Registry.proto (not RegistryServer) as well.

@Manisha4 Manisha4 merged commit 38be3e4 into master Feb 11, 2025
23 checks passed
@Manisha4 Manisha4 deleted the add/new-feature-view branch February 11, 2025 22:07
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants