← 返回首页
Compute Engines | Feast: the Open Source Feature Store
GitBook Assistant
GitBook Assistant
GitBook Assistant
arrow-up-right-and-arrow-down-left-from-center
GitBook Assistant
Good night

I'm here to help you with the docs.

What is this page about?What should I read next?Can you give an example?
Ctrli
AI Based on your context
Send
On this page
For the complete documentation index, see llms.txt. This page is also available as Markdown.
GitBook AssistantAsk
On this page
  1. Reference

🧠Compute Engines

The ComputeEngine is Feast’s pluggable abstraction for executing feature pipelines — including transformations, aggregations, joins, and materializations/get_historical_features — on a backend of your choice (e.g., Spark, PyArrow, Pandas, Ray).

It powers both:

  • materialize() – for batch and stream generation of features to offline/online stores

  • get_historical_features() – for point-in-time correct training dataset retrieval

This system builds and executes DAGs (Directed Acyclic Graphs) of typed operations, enabling modular and scalable workflows.

🧠 Core Concepts

Component
Description
API

ComputeEngine

Interface for executing materialization and retrieval tasks

link

FeatureBuilder

Constructs a DAG from Feature View definition for a specific backend

link

FeatureResolver

Resolves feature DAG by topological order for execution

link

DAG

Represents a logical DAG operation (read, aggregate, join, etc.)

link

ExecutionPlan

Executes nodes in dependency order and stores intermediate outputs

link

ExecutionContext

Holds config, registry, stores, entity data, and node outputs

link

Feature resolver and builder

The FeatureBuilder initializes a FeatureResolver that extracts a DAG from the FeatureView definitions, resolving dependencies and ensuring the correct execution order. The FeatureView represents a logical data source, while DataSource represents the physical data source (e.g., BigQuery, Spark, etc.). When defining a FeatureView, the source can be a physical DataSource, a derived FeatureView, or a list of FeatureViews. The FeatureResolver walks through the FeatureView sources, and topologically sorts the DAG nodes based on dependencies, and returns a head node that represents the final output of the DAG. Subsequently, the FeatureBuilder builds the DAG nodes from the resolved head node, creating a DAGNode for each operation (read, join, filter, aggregate, etc.). An example of built output from FeatureBuilder:

GitBook AssistantAskCopy
- Output(Agg(daily_driver_stats)) - Agg(daily_driver_stats) - Filter(daily_driver_stats) - Transform(daily_driver_stats) - Agg(hourly_driver_stats) - Filter(hourly_driver_stats) - Transform(hourly_driver_stats) - Source(hourly_driver_stats)

Diagram

feature_dag.png

✨ Available Engines

🔥 SparkComputeEngine

Spark (contrib)
  • Distributed DAG execution via Apache Spark

  • Supports point-in-time joins and large-scale materialization

  • Integrates with SparkOfflineStore and SparkMaterializationJob

🌊 FlinkComputeEngine

Apache Flink
  • Distributed DAG execution through Apache Flink's PyFlink Table API

  • Supports materialization and historical retrieval with Feast offline stores

  • Integrates with FlinkMaterializationJob and FlinkDAGRetrievalJob

⚡ RayComputeEngine (contrib)

  • Distributed DAG execution via Ray

  • Intelligent join strategies (broadcast vs distributed)

  • Automatic resource management and optimization

  • Integrates with RayOfflineStore and RayMaterializationJob

  • See Ray Compute Engine documentation for details

🧪 LocalComputeEngine

https://github.com/feast-dev/feast/blob/v0.64-branch/docs/reference/compute-engine/local.md
  • Runs on Arrow + Specified backend (e.g., Pandas, Polars)

  • Designed for local dev, testing, or lightweight feature generation

  • Supports LocalMaterializationJob and LocalHistoricalRetrievalJob

🧊 SnowflakeComputeEngine

  • Runs entirely in Snowflake

  • Supports Snowflake SQL for feature transformations and aggregations

  • Integrates with SnowflakeOfflineStore and SnowflakeMaterializationJob

Snowflake

LambdaComputeEngine

AWS Lambda (alpha)

🛠️ Feature Builder Flow

Each step is implemented as a DAGNode. An ExecutionPlan executes these nodes in topological order, caching DAGValue outputs.

🧩 Implementing a Custom Compute Engine

To create your own compute engine:

  1. Implement the interface

  1. Create a FeatureBuilder

  1. Define DAGNode subclasses

    • ReadNode, AggregationNode, JoinNode, WriteNode, etc.

    • Each DAGNode.execute(context) -> DAGValue

  2. Return an ExecutionPlan

    • ExecutionPlan stores DAG nodes in topological order

    • Automatically handles intermediate value caching

🚧 Roadmap

  • Modular, backend-agnostic DAG execution framework

  • Spark engine with native support for materialization + PIT joins

  • PyArrow + Pandas engine for local compute

  • Native multi-feature-view DAG optimization

  • DAG validation, metrics, and debug output

  • Scalable distributed backend via Ray or Polars

Last updated 22 days ago

Was this helpful?