Links & Resources

• GitHub Repository: Find the complete Feast codebase on GitHub.

  • Community Governance Doc: See the governance model of Feast, including who the maintainers are and how decisions are made.

• Slack: Feel free to ask questions or say hello! This is the main place where maintainers and contributors brainstorm and where users ask questions or discuss best practices.

  • Feast users should join #feast-general or #feast-beginners to ask questions

  • Feast developers / contributors should join #feast-development

• Mailing list: We have both a user and developer mailing list.

  • Feast users should join feast-discuss@googlegroups.com group by clicking here.

  • Feast developers / contributors should join feast-dev@googlegroups.com group by clicking here.

• Community Calendar: Includes community calls and design meetings.

• Google Folder: This folder is used as a central repository for all Feast resources. For example:

  • Design proposals in the form of Request for Comments (RFC).

  • User surveys and meeting minutes.

  • Slide decks of conferences our contributors have spoken at.

• Feast Linux Foundation Wiki: Our LFAI wiki page contains links to resources for contributors and maintainers.

How can I get help?

• Slack: Need to speak to a human? Come ask a question in our Slack channel (link above).

• GitHub Issues: Found a bug or need a feature? Create an issue on GitHub.

• StackOverflow: Need to ask a question on how to use Feast? We also monitor and respond to StackOverflow.

Community Calls

General community call (biweekly)

We have a user and contributor community call every two weeks (US & EU friendly).

Frequency (every 2 weeks)

• Tuesday 10:00 am to 10:30 am PST

Links

• Zoom: https://zoom.us/j/6325193230

• Meeting notes (incl recordings): https://bit.ly/feast-notes

Developers call (biweekly)

We also have a #feast-development community call every two weeks, where we discuss contributions + brainstorm best practices.

Frequency (every 2 weeks)

• Tuesday 8:00 am to 8:30 am PST

Links

• Meeting notes (incl recordings): Feast Development Biweekly

• Zoom: https://zoom.us/j/93657748160?pwd=K3ZpdzhqejgrcXNhc3BlSjFMdzUxdz09

Feast project structure

The top-level namespace within Feast is a project. Users define one or more feature views within a project. Each feature view contains one or more features. These features typically relate to one or more entities. A feature view must always have a data source, which in turn is used during the generation of training datasets and when materializing feature values into the online store.

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)

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.