Managing Feast

Feast Management Skill

Manage and monitor Feast feature store entities, feature views, and materialization.

MANDATORY: Discovery-First Pattern

Always inspect the feature store registry before modifying features or running materialization.

Phase 1: Discovery

#!/bin/bash

FEAST_REPO="${FEAST_REPO_PATH:-.}"

echo "=== Feast Version ==="
feast version 2>/dev/null

echo ""
echo "=== Feature Store Config ==="
cat "${FEAST_REPO}/feature_store.yaml" 2>/dev/null | head -20

echo ""
echo "=== Entities ==="
feast -c "$FEAST_REPO" entities list 2>/dev/null | head -15

echo ""
echo "=== Feature Views ==="
feast -c "$FEAST_REPO" feature-views list 2>/dev/null | head -15

echo ""
echo "=== Data Sources ==="
feast -c "$FEAST_REPO" data-sources list 2>/dev/null | head -15

echo ""
echo "=== On-Demand Feature Views ==="
feast -c "$FEAST_REPO" on-demand-feature-views list 2>/dev/null | head -10

Core Helper Functions

#!/bin/bash

FEAST_REPO="${FEAST_REPO_PATH:-.}"

# Feast CLI wrapper
feast_cmd() {
    feast -c "$FEAST_REPO" "$@" 2>/dev/null
}

# Feast registry API (if using Feast server)
feast_api() {
    local endpoint="$1"
    curl -s "${FEAST_SERVER_URL:-http://localhost:6566}/${endpoint}"
}

# Check materialization status
feast_materialize_status() {
    feast_cmd feature-views list | while read -r fv; do
        echo "$fv: $(feast_cmd feature-views describe "$fv" 2>/dev/null | grep -i 'materialization' | head -1)"
    done
}

Output Rules

• TOKEN EFFICIENCY: Target ≤50 lines per output
• Use Feast CLI for registry operations
• Use REST API or Python SDK output for serving queries
• Never dump full feature view definitions -- extract key fields

Common Operations

Entity Management

#!/bin/bash
echo "=== All Entities ==="
feast_cmd entities list

ENTITY="${1:-}"
if [ -n "$ENTITY" ]; then
    echo ""
    echo "=== Entity Details: $ENTITY ==="
    feast_cmd entities describe "$ENTITY"
fi

Feature View Inspection

#!/bin/bash
echo "=== Feature Views ==="
feast_cmd feature-views list

FV_NAME="${1:-}"
if [ -n "$FV_NAME" ]; then
    echo ""
    echo "=== Feature View Details: $FV_NAME ==="
    feast_cmd feature-views describe "$FV_NAME"
fi

echo ""
echo "=== Feature Services ==="
feast_cmd feature-services list 2>/dev/null | head -10

Materialization

#!/bin/bash
START_DATE="${1:?Start date required (YYYY-MM-DD)}"
END_DATE="${2:?End date required (YYYY-MM-DD)}"
DRY_RUN="${3:-true}"

echo "=== Materialization Plan ==="
echo "Date range: $START_DATE to $END_DATE"
echo ""
echo "Feature views to materialize:"
feast_cmd feature-views list 2>/dev/null

if [ "$DRY_RUN" = "true" ]; then
    echo ""
    echo "DRY RUN: Would materialize features from $START_DATE to $END_DATE"
    echo "To execute, call with dry_run=false"
else
    echo ""
    echo "=== Running Materialization ==="
    feast_cmd materialize "$START_DATE" "$END_DATE" 2>&1 | tail -20
fi

Online Serving Test

#!/bin/bash
FEATURE_SERVICE="${1:?Feature service name required}"

echo "=== Feature Service: $FEATURE_SERVICE ==="
feast_cmd feature-services describe "$FEATURE_SERVICE" 2>/dev/null

echo ""
echo "=== Online Store Status ==="
# Check if online store is accessible 'type:' "${FEAST_REPO}/feature_store.yaml" 2>/dev/null | grep -A1 'online_store' | tail -1 | awk '{print $2}')
echo "Online store type: ${ONLINE_STORE_TYPE:-unknown}"

echo ""
echo "=== Sample Online Fetch ==="
echo "Use feast_cmd get-online-features or the Python SDK to fetch features:"
echo "  from feast import FeatureStore"
echo "  store = FeatureStore('${FEAST_REPO}')"
echo "  features = store.get_online_features("
echo "      features=['${FEATURE_SERVICE}:feature_name'],"
echo "      entity_rows=[{'entity_id': 'value'}]"
echo "  ).to_dict()"

Registry and Data Source Audit

#!/bin/bash
echo "=== Registry Summary ==="
echo "Entities:"
feast_cmd entities list 2>/dev/null | wc -l | xargs -I{} echo "  {} entities"
echo "Feature Views:"
feast_cmd feature-views list 2>/dev/null | wc -l | xargs -I{} echo "  {} feature views"
echo "Data Sources:"
feast_cmd data-sources list 2>/dev/null | wc -l | xargs -I{} echo "  {} data sources"

echo ""
echo "=== Data Sources ==="
feast_cmd data-sources list

echo ""
echo "=== Feature Store Config ==="
cat "${FEAST_REPO}/feature_store.yaml" 2>/dev/null | head -30

Safety Rules

• NEVER delete feature views with active consumers -- downstream models depend on feature availability
• NEVER run materialization without verifying date ranges -- overlapping materializations can cause data inconsistencies
• Always apply registry changes (feast apply) before materialization -- unapplied definitions are not materialized
• Check online store capacity before large materializations -- Redis/DynamoDB may need scaling
• Verify data source freshness before materializing -- stale sources produce outdated features

Output Format

Present results as a structured report:

Managing Feast Report
═════════════════════
Resources discovered: [count]

Resource       Status    Key Metric    Issues
──────────────────────────────────────────────
[name]         [ok/warn] [value]       [findings]

Summary: [total] resources | [ok] healthy | [warn] warnings | [crit] critical
Action Items: [list of prioritized findings]

Target ≤50 lines of output. Use tables for multi-resource comparisons.

Anti-Hallucination Rules

1. NEVER assume resource names — always discover via CLI/API in Phase 1 before referencing in Phase 2.
2. NEVER fabricate metric names or dimensions — verify against the service documentation or --help output.
3. NEVER mix CLI commands between service versions — confirm which version/API you are targeting.
4. ALWAYS use the discovery → verify → analyze chain — every resource referenced must have been discovered first.
5. ALWAYS handle empty results gracefully — an empty response is valid data, not an error to retry.

Counter-Rationalizations

Common Pitfalls

• Registry sync: Multiple Feast instances sharing a registry must use a centralized registry (SQL, GCS, S3) -- local file registries cause conflicts
• Materialization gaps: Incremental materialization requires contiguous date ranges -- gaps cause missing features in online serving
• TTL expiration: Features with TTL set will expire from the online store -- ensure materialization runs frequently enough
• Entity key types: Entity key types must match between feature views and retrieval requests -- type mismatches cause silent null returns
• Offline vs online schemas: Feature data types must be consistent between offline and online stores -- schema drift causes serving errors
• Feast apply order: Dependencies matter -- entities must be registered before feature views that reference them
• Point-in-time joins: Offline retrieval uses point-in-time correct joins -- incorrect event timestamps cause feature leakage
• Provider compatibility: Not all features are available in all providers (GCP, AWS, local) -- check provider documentation