Add a Chronon service module to add support for serving features

piyush-zlai commented 2 weeks ago

Summary

This PR adds a module to the project to spin up a service that wraps the Fetcher code and allows us to serve features. This module leverages the Vert.x project. Vert.x is a high performance service toolkit that allows us to build http / grpc services - as the serving layer can be on the hot path for some use-cases, the high perf nature of Vert.x will hopefully be a good starting point. Vert.x core is Java based and given we have 3 Scala versions to support in the Chronon project, I've chosen the path of writing the service in Java rather than dealing with the interop and the multi-version compat story for now.

The service as such adds a couple of HTTP endpoints that allow us to serve groupBys and joins (each returning a json payload). We can extend things in the future with an equivalent set of grpc endpoints if needed. Endpoints look like:

/ping -> Health check
/config -> Returns the svc config
/v1/features/join/<joinName> -> Bulk get request for a given join
/v1/features/groupby/<groupByName> -> Bulk get request for a given group by

Why / Goal

Currently users getting going on the project have to take on the additional work of writing a feature serving layer of their own (or rely on a set of disparate clients calling and using the Fetcher libs directly). This makes it painful to set up and this burden is exacerbated for users that don't natively work on JVM languages. Hooking up the fetcher code in other languages is non-trivial as it requires rewriting a lot of the core fetcher logic and maintaining parity across as things change over time. Including a service module within the project aims to lower that barrier of entry as it allows users to package the service and have their non-JVM services hit it and get feature data over the wire.

Test Plan

[X] Added Unit Tests
[ ] Covered by existing CI
[X] Integration tested

(Readme in the service module directory has some details / instructions on how you can spin up the project and test against the quickstart mongo api)

Checklist

[ ] Documentation update

Reviewers

@caiocamatta-stripe @mickjermsurawong-openai

caiocamatta-stripe commented 3 days ago

Hey @piyush-zlai - could you comment on why Vert.x vs alternatives?

piyush-zlai commented 3 days ago

@caiocamatta-stripe - called out in the PR description but I'll expand more:

Vertx is a fairly high performance web service framework. A few benchmarks have found it to be better than others such as Play - Link, Link.
Play is Scala native but the challenge is that as Chronon is using a bunch of different older Scala versions - 2.10, 2.11 and 2.12, we need to deal with this licensing issue - Licensing. Support for older Scala versions requires us to use the Akka fork of Play (Play 2.9.x). If Chronon were on Scala 2.13 we could go with Play 3.x (which is on Pekko).
Vertx being a Java based framework also makes life easier as we don't need to deal with building / cross compiling across 3 Scala versions.
Vertx has a fairly rich set of docs and pretty good support for tracing, testing, grpc etc so the rails from a web service framework are fairly extensible.

piyush-zlai commented 1 day ago

@caiocamatta-stripe thanks for taking a look. I'll tag some folks in the coming days (feel free to loop in others at Stripe as well if you'd like more eyes on this).

One final thing that still wasn't clear to me - how does the service get the schemas for GroupBys it's serving? Or is that purely the Fetcher's responsibility?

Yeah this is done as part of the GroupByUpload jobs and the MetadataUpload (join schemas) - https://chronon.ai/getting_started/Tutorial.html#uploading-data (you need to have these upload to the same KV store as you're using in your fetcher)

If you have those two sets of jobs then your KV store is primed with GroupByUploads (which contains one row which is your GroupByServingInfo data) and the join schema.

airbnb / chronon