# Overview

### Feast project structure

The top-level namespace within Feast is a **project**. Users define one or more [feature views](https://docs.feast.dev/v0.29-branch/getting-started/concepts/feature-view) within a project. Each feature view contains one or more [features](https://docs.feast.dev/v0.29-branch/getting-started/feature-view#feature). These features typically relate to one or more [entities](https://docs.feast.dev/v0.29-branch/getting-started/concepts/entity). A feature view must always have a [data source](https://docs.feast.dev/v0.29-branch/getting-started/concepts/data-ingestion), which in turn is used during the generation of training [datasets](https://docs.feast.dev/v0.29-branch/getting-started/feature-retrieval#dataset) and when materializing feature values into the online store.

![](https://1714186716-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FbfkpmICjbK4wjNolbKV2%2Fuploads%2Fgit-blob-af58d3cf3809fcc5e69119de273668f715f27538%2Fimage%20\(7\).png?alt=media)

**Projects** provide complete isolation of feature stores at the infrastructure level. This is accomplished through resource namespacing, e.g., prefixing table names with the associated project. Each project should be considered a completely separate universe of entities and features. It is not possible to retrieve features from multiple projects in a single request. We recommend having a single feature store and a single project per environment (`dev`, `staging`, `prod`).

### Data ingestion

For *offline use cases* that only rely on batch data, Feast does not need to ingest data and can query your existing data (leveraging a compute engine, whether it be a data warehouse or (experimental) Spark / Trino). Feast can help manage **pushing** streaming features to a batch source to make features available for training.

For *online use cases*, Feast supports **ingesting** features from batch sources to make them available online (through a process called **materialization**), and **pushing** streaming features to make them available both offline / online. We explore this more in the next concept page ([Data ingestion](https://docs.feast.dev/v0.29-branch/getting-started/concepts/data-ingestion))

### Feature registration and retrieval

Features are *registered* as code in a version controlled repository, and tie to data sources + model versions via the concepts of **entities, feature views,** and **feature services.** We explore these concepts more in the upcoming concept pages. These features are then *stored* in a **registry**, which can be accessed across users and services. The features can then be *retrieved* via SDK API methods or via a deployed **feature server** which exposes endpoints to query for online features (to power real time models).

Feast supports several patterns of feature retrieval.

|                         Use case                         |                                                 Example                                                |            API            |
| :------------------------------------------------------: | :----------------------------------------------------------------------------------------------------: | :-----------------------: |
|                 Training data generation                 | Fetching user and item features for (user, item) pairs when training a production recommendation model | `get_historical_features` |
|      Offline feature retrieval for batch predictions     |                          Predicting user churn for all users on a daily basis                          | `get_historical_features` |
| Online feature retrieval for real-time model predictions |   Fetching pre-computed features to predict whether a real-time credit card transaction is fraudulent  |   `get_online_features`   |