# Overview

### Feast project structure

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

### 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/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`   |


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.feast.dev/getting-started/concepts/overview.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.