Reminder: Monday is our community syncup meeting at 9AM PST/12 PM Eastern/6 PM Central Europe. Here is the Microsoft Teams Link to join the meeting.

Hey @Zac Policzer, Would you be able to join the meeting with Whatnot?

Yes

Meeting notes: 1. Introduce stable releases in OSS, maybe make it automated through cert a. Whenever it passes cert internally and it is running in prod, we mark it as a stable release 2. Zac to share math on to do capacity planning. Maybe we can get some input from Ali 3. Koorous to look into p99s of single and batch gets 4. Venice to check on status of clients using HTTP1 or 2 5. Publish guide on how to use Plain table for the servers 6. Does fast client have feature parity 7. Can Venice update default configs in OSS that we are using in prod? a. Can we do a one time audit now, and try to keep it up to date going forward? cc: @Sushant Mane @Sergey Makagonov @Hubert Puszklewicz

Does fast client have feature parity

Answer is yes IMO. @Manoj Nagarajan could you confirm?

Apart from client side read compute in FC, yes thats accurate. Validation of the load controller/overload protection feature is in progress.

Thanks for the notes @Koorous Vargha, they fully capture the action items. Thanks again everyone for the amazing insights. Really excited to collaborate with you!

No problem! Looking forward to working with you and your team!

@Zac Policzer btw, you mentioned that Feather fell out of favor, but Venice remains the backing for LinkedIn's feature store capabilities. Are you building a different feature store based on Venice?

Current LinkedIn people can probably attest to that, I'm not certain. But right now both in Feather and wihout feather features are stored in Venice as the DB backend

Not that I'm aware of. Venice serves all feature store usecases at LinkedIn

Isn't feature cloud (with Venice as backing store) the latest offering?

Based on the docs, feature cloud is under the feathr project

@Minh Nguyen - might have better idea

Just so we're clear. Feather===frame

Feathr is frame. Feature store is just a concept, it depends on what capabilities you want @Sergey Makagonov. I can take a closer look if you have clear requirements 😄

Thanks @Minh Nguyen . The question is more from the high-level perspective. LinkedIn open-sourced feathr which was internally backed by Venice for the online store. The github repo for feathr is practically dead, and as far as I understand - LI moved away from feathr. So the question is whether you're building another feature store (backed by Venice) to support the core capabilities of Feature Stores like point-in-time correctness, time-based aggregations, sliding window joins and etc.

@Sergey Makagonov As far as I can share, we don't have any new feature store efforts that are open-sourced or publicly announced at this time.

makes sense

Just want to chime in with info that is not fully up to date, but I would wager probably still mostly right... Frame has been developed at LI for the past 10+ years as a "virtual feature store". It is an abstraction where features can be defined and have "anchors" in various environments. Notably, the feature data can be available offline (e.g., in an Iceberg table), nearline (e.g., in a Kafka topic) or online (e.g., in Venice, but also in other online services: Pinot, Search, even REST services, etc.). So Venice is one of many systems capable of hosting and serving "online anchors", and it happened to be the most popular choice of online anchor for online feature access. A few years ago, some fraction of the Frame project (which corresponded mostly to the "offline anchors" part, NOT the online side) was carved out and copy-pasted into GitHub under the name of Feathr. There was originally an intent to migrate the internal frame-offline users over to Feathr (which at some point in time were pretty similar) but that effort was never funded in earnest. So at this point, LI's Frame and the open-source Feathr diverged, with most of the Feathr development being supported by a team at Microsoft. In other words, although the two projects are similar, LI never actually used Feathr. Later, Frame was kind of put on the backburner, and efforts have been diverted to other projects (e.g., Feature Cloud, Feature Marketplace, and a bunch more code names I don't remember). These other projects may have reused some stuff from Frame, but Frame itself was kind of put in maintenance mode. I'm not exactly sure about that part, it's just what I heard. That being said... not investing further into something, while also not investing into migrating out of it, means that there is probably still a significant internal user base of legacy use cases stranded on Frame. Unfortunately, that has become quite common at LI over the past years. LI used to be really good at orchestrating large migrations, but not so much anymore... teams and/or managers abandon projects because they don't want to invest in them, but don't invest in actually migrating out of them, so there's this wishful thinking that users will just kind of move out of their own volition, perhaps aided by the increasing friction of trying to use an unsupported system. The Venice team has historically tried hard to keep supporting whatever functionality it has users for, and to cleanly deprecate and delete stuff rather than just letting it rot, though it is a lot of work to do this right... All that to say, the above indictment of LI engineering work ethics is a general observation and should not automatically be transferred over to the Venice team and project, but it may serve to understand what is going on with some of the other LI-led projects, both internal and open-source.

Amazing! Thank you so much Felix!