From f690334d96dc154a392434a6e5553f32b2b57469 Mon Sep 17 00:00:00 2001 From: Francisco Arceo Date: Wed, 7 Aug 2024 23:52:03 -0400 Subject: [PATCH] docs: Adding some content about the push vs pull model (#4385) * docs: Adding some content about the push vs pull model Signed-off-by: Francisco Javier Arceo * checking in progress...all of this was mostly autogenerated Signed-off-by: Francisco Javier Arceo * updated Signed-off-by: Francisco Javier Arceo * Update push-vs-pull-model.md * Update push-vs-pull-model.md * Update push-vs-pull-model.md --------- Signed-off-by: Francisco Javier Arceo --- docs/README.md | 12 ++++++++++- docs/SUMMARY.md | 1 + .../architecture-and-components/README.md | 4 ++++ .../push-vs-pull-model.md | 20 +++++++++++++++++++ 4 files changed, 36 insertions(+), 1 deletion(-) create mode 100644 docs/getting-started/architecture-and-components/push-vs-pull-model.md diff --git a/docs/README.md b/docs/README.md index eea372ded0..d391069429 100644 --- a/docs/README.md +++ b/docs/README.md @@ -6,7 +6,7 @@ Feast (**Fea**ture **St**ore) is a customizable operational data system that re- Feast allows ML platform teams to: -* **Make features consistently available for training and serving** by managing an _offline store_ (to process historical data for scale-out batch scoring or model training), a low-latency _online store_ (to power real-time prediction)_,_ and a battle-tested _feature server_ (to serve pre-computed features online). +* **Make features consistently available for training and low-latency serving** by managing an _offline store_ (to process historical data for scale-out batch scoring or model training), a low-latency _online store_ (to power real-time prediction)_,_ and a battle-tested _feature server_ (to serve pre-computed features online). * **Avoid data leakage** by generating point-in-time correct feature sets so data scientists can focus on feature engineering rather than debugging error-prone dataset joining logic. This ensure that future feature values do not leak to models during training. * **Decouple ML from data infrastructure** by providing a single data access layer that abstracts feature storage from feature retrieval, ensuring models remain portable as you move from training models to serving models, from batch models to realtime models, and from one data infra system to another. @@ -16,6 +16,16 @@ Feast allows ML platform teams to: ![](assets/feast_marchitecture.png) +{% hint style="info" %} +**Note:** Feast uses a push model for online serving. This means that the feature store pushes feature values to the +online store, which reduces the latency of feature retrieval. This is more efficient than a pull model, where the model +serving system must make a request to the feature store to retrieve feature values. See +[this document](getting-started/architecture-and-components/push-vs-pull-model.md) for a more detailed discussion. +{% endhint %} + +{% hint style="info" %} +{% endhint %} + ## Who is Feast for? Feast helps ML platform teams with DevOps experience productionize real-time models. Feast can also help these teams build towards a feature platform that improves collaboration between engineers and data scientists. diff --git a/docs/SUMMARY.md b/docs/SUMMARY.md index 92fa3c692b..87c3626254 100644 --- a/docs/SUMMARY.md +++ b/docs/SUMMARY.md @@ -20,6 +20,7 @@ * [Architecture](getting-started/architecture-and-components/README.md) * [Overview](getting-started/architecture-and-components/overview.md) * [Language](getting-started/architecture-and-components/language.md) + * [Push vs Pull Model](getting-started/architecture-and-components/push-vs-pull-model.md) * [Registry](getting-started/architecture-and-components/registry.md) * [Offline store](getting-started/architecture-and-components/offline-store.md) * [Online store](getting-started/architecture-and-components/online-store.md) diff --git a/docs/getting-started/architecture-and-components/README.md b/docs/getting-started/architecture-and-components/README.md index c364744bc6..050a430c97 100644 --- a/docs/getting-started/architecture-and-components/README.md +++ b/docs/getting-started/architecture-and-components/README.md @@ -8,6 +8,10 @@ [overview.md](overview.md) {% endcontent-ref %} +{% content-ref url="push-vs-pull-model.md" %} +[push-vs-pull-model.md](push-vs-pull-model.md) +{% endcontent-ref %} + {% content-ref url="registry.md" %} [registry.md](registry.md) {% endcontent-ref %} diff --git a/docs/getting-started/architecture-and-components/push-vs-pull-model.md b/docs/getting-started/architecture-and-components/push-vs-pull-model.md new file mode 100644 index 0000000000..a1f404221b --- /dev/null +++ b/docs/getting-started/architecture-and-components/push-vs-pull-model.md @@ -0,0 +1,20 @@ +# Push vs Pull Model + +Feast uses a [Push Model](https://en.wikipedia.org/wiki/Push_technology), i.e., +Data Producers push data to the feature store and Feast stores the feature values +in the online store, to serve features in real-time. + +In a [Pull Model](https://en.wikipedia.org/wiki/Pull_technology), Feast would +pull data from the data producers at request time and store the feature values in +the online store before serving them (storing them would actually be unneccessary). +This approach would incur additional network latency as Feast would need to orchestrate +a request to each data producer, which would mean the latency would be at least as long as +your slowest call. So, in order to serve features as fast as possible, we push data to +Feast and store the feature values in the online store. + +The trade-off with the Push Model is that strong consistency is not gauranteed out +of the box. Instead, stong consistency has to be explicitly designed for in orchestrating +the updates to Feast and the client usage. + +The significant advantage with this approach is that Feast is read-optimized for low-latency +feature retrieval. \ No newline at end of file