Add an interface for TransformationService and a basic implementation #1932
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,67 @@ | ||
| /* | ||
| * Copyright 2021 The Feast Authors | ||
| * | ||
| * Licensed under the Apache License, Version 2.0 (the "License"); | ||
| * you may not use this file except in compliance with the License. | ||
| * You may obtain a copy of the License at | ||
| * | ||
| * https://www.apache.org/licenses/LICENSE-2.0 | ||
| * | ||
| * Unless required by applicable law or agreed to in writing, software | ||
| * distributed under the License is distributed on an "AS IS" BASIS, | ||
| * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. | ||
| * See the License for the specific language governing permissions and | ||
| * limitations under the License. | ||
| */ | ||
|
|
||
| syntax = "proto3"; | ||
|
|
||
| package feast.serving; | ||
|
|
||
| option java_package = "feast.proto.serving"; | ||
| option java_outer_classname = "TransformationServiceAPIProto"; | ||
| option go_package = "github.com/feast-dev/feast/sdk/go/protos/feast/serving"; | ||
|
|
||
| service TransformationService { | ||
| rpc GetTransformationServiceInfo (GetTransformationServiceInfoRequest) returns (GetTransformationServiceInfoResponse); | ||
|
|
||
| rpc TransformFeatures (TransformFeaturesRequest) returns (TransformFeaturesResponse); | ||
| } | ||
|
|
||
| message ValueType { | ||
| oneof value { | ||
| // Having a oneOf provides forward compatibility if we need to support compound types | ||
| // that are not supported by arrow natively. | ||
| bytes arrow_value = 1; | ||
| } | ||
| } | ||
|
|
||
| message GetTransformationServiceInfoRequest {} | ||
|
|
||
| message GetTransformationServiceInfoResponse { | ||
| // Feast version of this transformation service deployment. | ||
| string version = 1; | ||
|
|
||
| // Type of transformation service deployment. This is either Python, or custom | ||
| TransformationServiceType type = 2; | ||
|
|
||
| string transformation_service_type_details = 3; | ||
| } | ||
|
|
||
| message TransformFeaturesRequest { | ||
| string on_demand_feature_view_name = 1; | ||
| string project = 2; | ||
|
|
||
| ValueType transformation_input = 3; | ||
|
Collaborator
There was a problem hiding this comment. Assuming that this input is WIP? since you call .arrow_value below on this, which ValueType doesn't have. Are you envisioning the FTS would communicate with the registry? My preference is probably to start without to have as many stateless servers as possible
Collaborator
There was a problem hiding this comment. unless of course we run into performance issues, in which case having a cached registry would be needed
Member
Author
There was a problem hiding this comment. It would have to get the registry at least once because that's how it would unpickle the transformations, right?
Collaborator
There was a problem hiding this comment. hm yeah it needs the udf definition which we currently store in the FTS. no strong feelings. an alternative would be to pass the udf directly in the request so the FTS becomes purely about execution. though at that point, we may consider using a ray cluster directly instead of managing an FTS. If both this and the FTS can pull the registry, wondering if there can now be synchronization issues where e.g. a feature server that calls into this has a different version of the registry than what is on the FTS.
Member
Author
There was a problem hiding this comment. Passing in the UDF seems like a performance and dependency nightmare - I think we should stick with a simple approach for now assuming access to the registry. If we don't want to do that then yea we can farm out to a ray cluster from the client directly. Re: sync issues, i think it's possible, but I don't know if we want to solve that problem now.
Collaborator
There was a problem hiding this comment. sgtm for the first cut unclear imo though whether udf passing would be more complex. |
||
| } | ||
|
|
||
| message TransformFeaturesResponse { | ||
| ValueType transformation_output = 3; | ||
| } | ||
|
|
||
| enum TransformationServiceType { | ||
| TRANSFORMATION_SERVICE_TYPE_INVALID = 0; | ||
| TRANSFORMATION_SERVICE_TYPE_PYTHON = 1; | ||
|
|
||
| TRANSFORMATION_SERVICE_TYPE_CUSTOM = 100; | ||
| } | ||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this makes sense for the most advanced user.
for a user just getting started, i'd want maybe an "EMBEDDED" mode too where transformations happen on the feature server itself?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You mean in the python feature server, right? How would that be different from just running
get_online_featurespointing to a python feature server API, which should look up the values and do the transformation?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
maybe the earlier question is what is the BATCH or ONLINE mode used for? seems like in both cases, we're applying the same row-level udf to all values?