chore: Update Feast documentation to add information about write patterns and feature transformations

[franciscojavierarceo]

What this PR does / why we need it:

This PR updates the Feast documentation to:

1. Outline how clients/services/data producers should write to Feast.
   • This is an important trade off decision that needs to be outlined to end users to clarify how to best optimize their service performance and minimize their feature latency.
2. Defines feature transformation and feature transformation engine and how they should work
3. Moves folder structure to separate Architecture from Feast Components
4. Updated broken links where I found them

Which issue(s) this PR fixes:

N/A

Misc

@tokoko @HaoXuAI @shuchu

[tokoko]

Can you clarify what you're referring to here? Are there multiple ways to push features to online using feature server API?

[franciscojavierarceo]

https://en.wikipedia.org/wiki/Message_passing#Synchronous_versus_asynchronous_message_passing

Synchronous messaging is analogous to a synchronous function call; just as the function caller waits until the function completes, the sending process waits until the receiving process completes. This can make synchronous communication unworkable for some applications. For example, large, distributed systems may not perform well enough to be usable. Such large, distributed systems may need to operate while some of their subsystems are down for maintenance, etc.

..
With asynchronous message passing the receiving object can be down or busy when the requesting object sends the message. Continuing the function call analogy, it is like a function call that returns immediately, without waiting for the called function to complete. Messages are sent to a queue where they are stored until the receiving process requests them. The receiving process processes its messages and sends results to a queue for pickup by the original process (or some designated next process).

Do you want me to link to that source?

[tokoko]

No, I meant link these to actual feast implementations. afaik, on the server-side all endpoints are synchronous.

P.S. of course a user might use client-side async handling, but I don't think that's what you're referring to here.

[franciscojavierarceo]

P.S. of course a user might use client-side async handling, but I don't think that's what you're referring to here.

Actually, this is exactly what I am referring to!

Sounds like I need to make this more explicit if it wasn't obvious.

[franciscojavierarceo]

@tokoko take a look, I updated.

[tokoko]

How can one precompute values during write-to-online-store? Are you referring to stream feature views?

[franciscojavierarceo]

This is going to be true once #4376 is done, which I plan on starting (this week probably) after I make this documentation change.

[tokoko]

sure, but my understanding from that ticket and the discussion on the call was that we were talking about "persisting" values during get_online_features, not during write_to_online_store.

[franciscojavierarceo]

Again the write_to_online_store: bool parameter would dictate whether this ODFV would write to the online store and the force_compute: bool would dictate whether the ODFV would always recalculate the features. There's an argument to be made that we could skip the write_to_online_store in the FeatureView declaration but this metadata would be useful to have in the registry for users.

The ODFV computations were meant to happen when writing to the online store, as outlined in this document.

I should have written this document first, I suppose.

Let me know if that makes more sense for you.

[tokoko]

Maybe we can move these new docs to a new section called "Design" right after the Architecture one. Mixing these with very concrete feast component definitions (Online Store, Offline Store, ...) feels odd.

[franciscojavierarceo]

I like that! I'll move it over to System Design

[franciscojavierarceo]

Okay I ended up changing it to instead split architecture-and-components to architecture and components and moved the relevant material accordingly. I also updated some broken links I found.

[HaoXuAI]

nice, lgtm！