Home > Docs > Best Practices > Feature Store on OneLake

🏪 Feature Store on OneLake¶

Last Updated: 2026-04-27 | Version: 1.0.0 | Wave: 2 (MLOps & ML/AI Production)

📑 Table of Contents¶

• 🎯 Why a Feature Store
• 🏛️ The Three Feature Store Pillars
• 🗂️ Feature Table Schema Pattern
• ⏳ Point-in-Time Correctness
• 🚦 Offline vs Online Feature Patterns
• 📝 Naming Conventions
• 🔢 Versioning Strategy
• 🔍 Discovery & Documentation
• ⚙️ Computation Patterns
• 🎰 Casino Implementation: fs_player_engagement
• 🏛️ Federal Implementation: fs_loan_applicant
• 🚢 Serving Patterns
• 🛡️ Governance
• 🧬 Lineage
• 💰 Cost Considerations
• 🚫 Anti-Patterns
• 📋 Implementation Checklist
• 📚 References

🎯 Why a Feature Store¶

Most ML teams reinvent feature engineering for every project. Two data scientists build "30-day average wager" three different ways — different filters, different joins, different windows — and end up with three different numbers. Three months later, the model trained on definition A drifts because the production scoring path uses definition B. Nobody can find the existing feature; everybody rebuilds.

A feature store is the discipline of treating features as versioned, owned, documented, reusable assets stored in OneLake — the same rigor MLOps applies to models. The store is not magic infrastructure: it's a set of conventions, a small library of helpers, and a governance model.

What "Feature Store on OneLake" Means in Fabric¶

Where the Feature Store Fits¶

The feature store sits above Silver, parallel to Gold, in its own dedicated lakehouse. It is the structured input contract for ML training and inference, the way Gold is the structured input contract for BI.

flowchart LR
    subgraph Sources["📊 Data"]
        Bronze[(🥉 Bronze)]
        Silver[(🥈 Silver)]
        Gold[(🥇 Gold<br/>BI-facing)]
    end

    subgraph FS["🏪 Feature Store (lh_features)"]
        FSO[(Offline<br/>Delta Tables)]
        FSON[(Online<br/>Mirrored SQL DB)]
    end

    subgraph ML["🤖 ML Workloads"]
        Train[Training<br/>Spark JOIN]
        Batch[Batch<br/>Inference]
        Online[Online<br/>Endpoint]
    end

    Bronze --> Silver
    Silver --> Gold
    Silver --> FSO
    Gold --> FSO
    FSO -->|mirror| FSON
    FSO --> Train
    FSO --> Batch
    FSON --> Online
    Train -->|model| Batch
    Train -->|model| Online

📝 Scope: This doc is part of the MLOps Wave 2 anchor. It defines feature-store conventions; the model lifecycle around those features lives in the anchor doc and Model Monitoring & Drift Detection.

🏛️ The Three Feature Store Pillars¶

A feature store earns its keep on three pillars. Drop any one and you've built a glorified Gold table.

The three pillars must be enforced with conventions and tooling, not hope. This document is the convention; the helper library lives in src/feature_store/ (created in Phase 14).

🗂️ Feature Table Schema Pattern¶

Every feature table is a Delta table in lh_features that follows a strict schema contract.

Required Columns¶

erDiagram
    FEATURE_TABLE {
        string entity_id PK "the thing we predict on"
        timestamp effective_from PK "row valid from"
        timestamp effective_to "row valid to (NULL = current)"
        bool _is_current "denormalized current flag"
        string source_table "lineage: upstream Delta path"
        string feature_version "semver MAJOR.MINOR.PATCH"
        timestamp last_updated "row write time"
        string computed_by "pipeline / notebook id"
        any feature_col_1 "documented business feature"
        any feature_col_2 "documented business feature"
    }

Schema Reference¶

DDL Template¶

CREATE TABLE lh_features.fs_player_engagement (
    -- Identity & bitemporal
    player_id           STRING        NOT NULL,
    effective_from      TIMESTAMP     NOT NULL,
    effective_to        TIMESTAMP,
    _is_current         BOOLEAN       NOT NULL,

    -- Features (documented in feature card)
    engagement_score    DOUBLE        COMMENT 'Composite 0-100; see fs_player_engagement.md',
    sessions_30d        INT           COMMENT 'Count of distinct sessions in trailing 30 days',
    avg_wager_30d       DECIMAL(18,2) COMMENT 'Avg per-session wager USD, trailing 30 days',
    churn_risk_score    DOUBLE        COMMENT 'Logistic 0-1; output of churn_risk_v3 model',
    ltv_estimate        DECIMAL(18,2) COMMENT '12-month LTV USD; gradient-boosted estimate',

    -- Lineage
    source_table        STRING        NOT NULL,
    feature_version     STRING        NOT NULL,
    last_updated        TIMESTAMP     NOT NULL,
    computed_by         STRING        NOT NULL
)
USING DELTA
PARTITIONED BY (DATE(effective_from))
TBLPROPERTIES (
    'delta.enableChangeDataFeed' = 'true',
    'feature_store.entity'       = 'player',
    'feature_store.owner'        = 'casino-data-science',
    'feature_store.version'      = '1.0.0'
);

The delta.enableChangeDataFeed = true setting is required to support online mirroring without full-table reloads.

⏳ Point-in-Time Correctness¶

This is the section to read twice. Point-in-time correctness is what separates a feature store from a Gold KPI table, and getting it wrong is the most common — and most damaging — feature-store bug.

The Data Leakage Problem¶

Imagine training a churn model. You have:

• A label table: player_id, event_time, churned_30d_later
• A feature table: player_id, engagement_score

Naive join:

# ❌ WRONG: Joins on player_id only — uses TODAY's engagement_score for a 6-month-old churn event
df_train = labels.join(features, on="player_id")

Today's engagement_score reflects what happened after the churn event — including the churn itself. The model learns "low engagement → churn" not because that's predictive, but because it's tautological. You'll see 0.99 AUC in training and 0.55 in production. We've all seen it.

The Fix: AS-OF JOIN¶

A feature value is only valid for a label if the feature row's effective window contains the label's event time. This requires effective_from <= event_time < effective_to.

# ✅ CORRECT: AS-OF JOIN — uses the engagement_score that was current AT the prediction event
from pyspark.sql import functions as F

labels = spark.table("lh_silver.churn_labels")     # player_id, event_time, churned_30d_later
features = spark.table("lh_features.fs_player_engagement")

df_train = (
    labels.alias("l")
    .join(
        features.alias("f"),
        (F.col("l.player_id") == F.col("f.player_id"))
        & (F.col("f.effective_from") <= F.col("l.event_time"))
        & ((F.col("f.effective_to").isNull()) | (F.col("l.event_time") < F.col("f.effective_to"))),
        how="left"
    )
    .select(
        "l.player_id",
        "l.event_time",
        "l.churned_30d_later",
        "f.engagement_score",
        "f.sessions_30d",
        "f.avg_wager_30d",
        "f.feature_version",   # capture the version each row was trained with
    )
)

SCD Type 2 Feature Evolution¶

Features change over time. A player's loyalty_tier may shift from Silver to Gold to Platinum. The feature store stores all historical versions so any past prediction event can be reconstructed.

# Daily feature compute with SCD Type 2 evolution
from delta.tables import DeltaTable
from pyspark.sql import functions as F

# 1. Compute today's feature snapshot
df_today = (
    spark.table("lh_silver.player_sessions_validated")
    .filter(F.col("session_date") >= F.date_sub(F.current_date(), 30))
    .groupBy("player_id")
    .agg(
        F.count("session_id").alias("sessions_30d"),
        F.avg("wager_amount").alias("avg_wager_30d"),
        F.sum("net_win").alias("net_win_30d"),
    )
    .withColumn("engagement_score",
        F.col("sessions_30d") * 2.5 + F.col("avg_wager_30d") / 10.0
    )
    .withColumn("effective_from", F.current_timestamp())
    .withColumn("effective_to", F.lit(None).cast("timestamp"))
    .withColumn("_is_current", F.lit(True))
    .withColumn("source_table", F.lit("lh_silver.player_sessions_validated"))
    .withColumn("feature_version", F.lit("1.0.0"))
    .withColumn("last_updated", F.current_timestamp())
    .withColumn("computed_by", F.lit(spark.conf.get("spark.fabric.run_id", "unknown")))
)

# 2. Identify changed rows (compare to current)
target = DeltaTable.forName(spark, "lh_features.fs_player_engagement")

df_current = (
    spark.table("lh_features.fs_player_engagement")
    .filter("_is_current = true")
    .select("player_id", "engagement_score", "sessions_30d", "avg_wager_30d")
    .alias("cur")
)

df_changes = (
    df_today.alias("new")
    .join(df_current, on="player_id", how="left")
    .filter(
        F.col("cur.player_id").isNull()                                            # new entity
        | (F.abs(F.col("new.engagement_score") - F.col("cur.engagement_score")) > 0.01)
        | (F.col("new.sessions_30d") != F.col("cur.sessions_30d"))
        | (F.abs(F.col("new.avg_wager_30d") - F.col("cur.avg_wager_30d")) > 0.01)
    )
    .select("new.*")
)

# 3. Expire current rows that are about to be superseded
(
    target.alias("tgt")
    .merge(
        df_changes.select("player_id").alias("chg"),
        "tgt.player_id = chg.player_id AND tgt._is_current = true"
    )
    .whenMatchedUpdate(set={
        "_is_current": "false",
        "effective_to": "current_timestamp()"
    })
    .execute()
)

# 4. Append new current rows
df_changes.write.format("delta").mode("append").saveAsTable("lh_features.fs_player_engagement")

Common Bugs to Avoid¶

🚦 Offline vs Online Feature Patterns¶

Features serve two very different traffic patterns. The store supports both, with a deliberate sync strategy.

Offline (Batch / Training / BI)¶

Online (Inference / Real-Time)¶

Synchronization Pattern: Offline-First → Mirror to Online¶

The offline store is the system of record. The online store is a derived, latency-optimized projection. Never write to online directly — always materialize from offline so the two cannot diverge.

flowchart LR
    Silver[(🥈 Silver Delta)]
    Compute[Daily / Hourly<br/>feature pipeline]
    Offline[(🏪 Offline<br/>lh_features.fs_*)]
    Mirror[Fabric Mirroring<br/>or Pipeline]
    Online[(⚡ Online<br/>SQL DB or Cache)]
    BI[📊 Direct Lake<br/>Power BI]
    Train[🧪 Training<br/>Spark]
    Endpoint[🚢 Online<br/>Endpoint]

    Silver --> Compute
    Compute --> Offline
    Offline -->|CDF| Mirror
    Mirror --> Online
    Offline --> BI
    Offline --> Train
    Online --> Endpoint

# Mirror current rows to the online SQL DB
# Triggered after each offline feature pipeline run
from pyspark.sql import functions as F

current_features = (
    spark.table("lh_features.fs_player_engagement")
    .filter("_is_current = true")
    .select(
        "player_id",
        "engagement_score",
        "sessions_30d",
        "avg_wager_30d",
        "churn_risk_score",
        "ltv_estimate",
        "feature_version",
        "last_updated",
    )
)

# Write to mirrored Fabric SQL DB (table: features_online.fs_player_engagement_current)
(
    current_features.write
    .format("jdbc")
    .option("url", spark.conf.get("spark.fabric.online_features.jdbc_url"))
    .option("dbtable", "features_online.fs_player_engagement_current")
    .option("truncate", "true")
    .mode("overwrite")
    .save()
)

💡 Tip: For features that change slowly (player loyalty tier), once-daily sync is fine. For features that change quickly (last-hour activity), use streaming features and mirror via Eventhouse → SQL DB pipeline.

📝 Naming Conventions¶

Table Names¶

fs_<entity>_<feature_group>

• Prefix fs_ distinguishes feature tables from facts/dimensions in joint queries.
• <entity> is the singular noun the features describe (player, machine, loan_applicant, parcel).
• <feature_group> describes the cohesive set of features (engagement, telemetry, credit_history).

Lakehouse and Schema¶

lh_features                                ← dedicated lakehouse, separate from lh_gold
└── fs_player_engagement                  ← one table per entity × feature_group
└── fs_player_lifetime_value
└── fs_machine_telemetry
└── fs_loan_applicant_credit

The dedicated lh_features lakehouse exists for governance: feature engineers own it, RBAC is scoped to it, and OneLake Catalog tags filter to it. Mixing features into lh_gold blurs ownership and makes RBAC harder.

Column Names¶

🔢 Versioning Strategy¶

Features are contracts. Consumers depend on them. Breaking changes without versioning breaks downstream models silently.

Use semantic versioning stored in the feature_version column and the table's TBLPROPERTIES('feature_store.version').

MAJOR Migration: Dual-Write¶

Never break consumers in place. Run two tables simultaneously during a deprecation window.

flowchart LR
    subgraph Phase1["Phase 1: Dual-Write (60+ days)"]
        Compute1[Pipeline]
        T1[fs_player_engagement<br/>v1.x]
        T2[fs_player_engagement_v2<br/>v2.x]
        Compute1 --> T1
        Compute1 --> T2
    end
    subgraph Phase2["Phase 2: Cutover"]
        Models[All models<br/>migrate to v2]
    end
    subgraph Phase3["Phase 3: Sunset"]
        Stop[Stop writing v1<br/>Mark v1 deprecated in catalog]
    end
    subgraph Phase4["Phase 4: Removal"]
        Drop[Drop v1 table<br/>after audit retention]
    end
    Phase1 --> Phase2 --> Phase3 --> Phase4

Per-Row vs Per-Table Version¶

The feature_version column captures the version for each row. This is deliberately redundant with the table-level TBLPROPERTIES — it lets you reconstruct what definition was active when a model was trained, even after the table itself has been bumped to v2.

# In MLflow training, log the row-level versions in the training set
versions = (
    df_train.select("feature_version").distinct().collect()
)
mlflow.log_param("feature_versions", [v["feature_version"] for v in versions])

🔍 Discovery & Documentation¶

A feature nobody can find is a feature that gets rebuilt. Discovery is enforced via three mechanisms.

OneLake Catalog Tags¶

Every feature table gets tagged in OneLake Catalog:

Feature Card Template¶

Every feature table is paired with a feature card stored at docs/features/feature-store/fs_<entity>_<feature_group>.md:

# fs_player_engagement (v1.0.0)

| Field | Value |
|-------|-------|
| **Entity** | player_id |
| **Grain** | One row per player per change event (SCD2) |
| **Owner** | casino-data-science (Slack: #casino-ds) |
| **Refresh** | Daily, 02:00 UTC, ~25 min |
| **Source tables** | lh_silver.player_sessions_validated, lh_silver.dim_player |
| **Consumers** | casino-churn-prediction-lightgbm v3.x, casino-ltv-forecast-prophet v2.x |
| **PII class** | derived (no direct PII; derived from player_id which is hashed) |
| **Freshness SLA** | < 26 hours from session occurrence |
| **Online available** | Yes — features_online.fs_player_engagement_current |
| **Deprecation policy** | 90-day notice + 60-day dual-write |

## Features

### engagement_score (DOUBLE, 0-100)
Composite engagement metric. `sessions_30d * 2.5 + avg_wager_30d / 10`.
Higher = more engaged. Used as input to churn and LTV models.

### sessions_30d (INT)
Distinct sessions in trailing 30 days. NULL → 0 by convention.

[... one section per feature ...]

## Computation Notes

[... how the table is built, edge cases, known issues ...]

## Change Log

- 2026-04-27: v1.0.0 — Initial release.

Purview Cross-Reference¶

The feature card is registered in Purview as a glossary term, with its source tables linked as upstream assets and consumer models linked as downstream. See Lineage below.

⚙️ Computation Patterns¶

Three patterns by data velocity. Pick by the SLA the consuming model needs.

Streaming Features (Eventhouse → Materialized View)¶

For features that need < 1-minute freshness (real-time fraud, hot-path personalization).

# Eventhouse KQL: 5-minute rolling features published as materialized view
# .create-or-alter materialized-view with (backfill=true) FsMachineRecentActivity on table SlotEvents
# {
#     SlotEvents
#     | summarize
#         events_5m = count(),
#         coin_in_5m = sum(coin_in),
#         distinct_players_5m = dcount(player_id)
#       by machine_id, bin(event_time, 5m)
# }

# Mirror to feature store via streaming pipeline
df_stream = (
    spark.readStream
    .format("eventhouse")
    .option("table", "FsMachineRecentActivity")
    .load()
    .withColumn("effective_from", F.col("event_time"))
    .withColumn("effective_to", F.col("event_time") + F.expr("INTERVAL 5 MINUTES"))
    .withColumn("_is_current", F.lit(True))
    .withColumn("feature_version", F.lit("1.0.0"))
)

(
    df_stream.writeStream
    .format("delta")
    .outputMode("append")
    .option("checkpointLocation", "Files/_checkpoints/fs_machine_telemetry")
    .toTable("lh_features.fs_machine_telemetry")
)

Batch Features (Pipeline → Delta)¶

The default. Used for daily / hourly aggregations.

# Daily batch feature pipeline
import os
from datetime import datetime
from pyspark.sql import functions as F

AS_OF = datetime.fromisoformat(os.environ["AS_OF_DATE"])  # explicit, supports backfill

df = (
    spark.table("lh_silver.player_sessions_validated")
    .filter(F.col("session_date").between(F.lit(AS_OF) - F.expr("INTERVAL 30 DAYS"), F.lit(AS_OF)))
    .groupBy("player_id")
    .agg(
        F.count("*").alias("sessions_30d"),
        F.avg("wager_amount").alias("avg_wager_30d"),
        F.sum("net_win").alias("net_win_30d"),
    )
    .withColumn("engagement_score",
        F.col("sessions_30d") * 2.5 + F.coalesce(F.col("avg_wager_30d"), F.lit(0.0)) / 10.0
    )
    .withColumn("effective_from", F.lit(AS_OF))
    .withColumn("effective_to", F.lit(None).cast("timestamp"))
    .withColumn("_is_current", F.lit(True))
    .withColumn("source_table", F.lit("lh_silver.player_sessions_validated"))
    .withColumn("feature_version", F.lit("1.0.0"))
    .withColumn("last_updated", F.current_timestamp())
    .withColumn("computed_by", F.lit(os.environ.get("FABRIC_RUN_ID", "manual")))
)

# SCD Type 2 merge — see Point-in-Time Correctness section above

On-Demand Features (Computed at Request Time)¶

Some features cannot be precomputed because they depend on the request itself. Examples: user_age (depends on the timestamp of the request), distance_to_nearest_event_km, time_since_last_login.

# Inference-time on-demand feature
def score_request(request: dict, online_features: dict) -> dict:
    # On-demand: time_since_last_session
    last_session = online_features["last_session_time"]  # from online store
    on_demand_features = {
        "minutes_since_last_session": (request["request_time"] - last_session).total_seconds() / 60,
        "is_weekend": request["request_time"].weekday() >= 5,
    }
    full_features = {**online_features, **on_demand_features}
    return model.predict(full_features)

🎰 Casino Implementation: fs_player_engagement¶

Cohesive feature group describing player behavior. Consumed by churn, LTV, and marketing-uplift models.

Compliance Note¶

fs_player_engagement derives from session data that includes wager amounts. It is not a direct PII feature, but its outputs influence marketing decisions, so it must comply with the casino's responsible-gaming policy: any consumer model that uses it must implement the Responsible AI Framework self-exclusion check before scoring.

Notebook¶

See notebooks/ml/feature_store/01_fs_player_engagement_compute.py (Phase 14 deliverable).

🏛️ Federal Implementation: fs_loan_applicant¶

SBA underwriting feature group. Consumed by the SBA loan-default-risk model — a regulated use case under ECOA.

Demographic Features (Restricted)¶

Demographic features (applicant_age_band, applicant_minority_indicator) are stored in a separate restricted table fs_loan_applicant_demographics with a higher access tier. They are never used as model inputs — they exist solely for fairness evaluation by the Responsible AI Framework gate.

# Fairness evaluation reads demographic features in a separate, audited path
df_fairness = (
    df_predictions.alias("p")
    .join(
        spark.table("lh_features.fs_loan_applicant_demographics").alias("d"),
        on="application_id",
        how="inner"
    )
    .select("p.application_id", "p.score", "d.applicant_minority_indicator")
)
demographic_parity_ratio(df_fairness)  # gate

Compliance Note¶

ECOA prohibits using protected-class membership as a feature. The two-table split makes this enforceable: fs_loan_applicant_credit is open to all underwriting models; fs_loan_applicant_demographics is open only to the fairness-eval pipeline, audited in Purview.

🚢 Serving Patterns¶

Training (Offline → Spark)¶

# Pull labels and features in one AS-OF JOIN
labels = spark.table("lh_silver.churn_labels_30d")
features = spark.table("lh_features.fs_player_engagement")

train_df = (
    labels.alias("l").join(
        features.alias("f"),
        (F.col("l.player_id") == F.col("f.player_id"))
        & (F.col("f.effective_from") <= F.col("l.event_time"))
        & ((F.col("f.effective_to").isNull()) | (F.col("l.event_time") < F.col("f.effective_to"))),
        "left"
    )
)

Online (REST / GraphQL / SQL)¶

The mirrored online table features_online.fs_player_engagement_current is queryable through three paths:

# Inference handler: fetch features from online store before scoring
def get_online_features(player_id: str) -> dict:
    sql = """
    SELECT engagement_score, sessions_30d, avg_wager_30d,
           churn_risk_score, ltv_estimate, feature_version
    FROM features_online.fs_player_engagement_current
    WHERE player_id = ?
    """
    return execute_sql(sql, params=[player_id]).fetchone()

Mirroring (Offline → Online SQL DB)¶

Fabric Mirroring keeps the online SQL DB in sync. CDC from the Delta CDF feed → SQL DB upsert. See the mirroring doc for setup.

🛡️ Governance¶

Ownership (RACI)¶

Deprecation Process¶

1. Announce (T-90): RFC posted; consumers notified by name; deprecation tag in OneLake Catalog.
2. Dual-write (T-90 → T-30): Old + new tables both populated.
3. Cutover (T-30 → T-0): Consumers migrate models; verify in MLflow that no production models reference the old version.
4. Sunset (T+0): Stop populating the old table; mark deprecated in catalog and feature card.
5. Remove (T+0 + audit retention): Drop table after compliance retention window passes.

Access Control¶

• Lakehouse permissions: lh_features is owned by the platform team; feature engineers have Contributor; consumers have Read-only.
• Workspace Identity: All compute uses Workspace Identity — no user credentials in pipelines.
• OneLake Security: Restricted feature tables (e.g., fs_loan_applicant_demographics) use OneLake security roles to limit access to the fairness-eval pipeline only.
• PII features: Hashing rules from data-governance-deep-dive.md apply unchanged — no raw PII in any fs_* table.

🧬 Lineage¶

What Purview Captures¶

lh_silver.player_sessions_validated
       └─▶ lh_features.fs_player_engagement (v1.0.0)
              └─▶ casino-churn-prediction-lightgbm (model v3.2)
              └─▶ casino-ltv-forecast-prophet (model v2.1)
              └─▶ features_online.fs_player_engagement_current (mirror)
                     └─▶ slot-revenue-personalization-endpoint (online)

Purview ingests Delta lineage automatically, but the feature → model edge must be registered explicitly. MLflow does this when you log the feature table as input data:

mlflow.log_input(
    mlflow.data.from_pandas(
        train_df.toPandas(),
        source="lh_features.fs_player_engagement@v1.0.0",
        name="player_engagement_features"
    ),
    context="training"
)

Querying Lineage in-Fabric (Semantic Link)¶

import sempy.fabric as fabric
# Find all models consuming a given feature table
consumers = fabric.evaluate_dax(
    dataset="MLOps Lineage Model",
    dax_string="""
    EVALUATE
    FILTER(
        Models,
        CONTAINSSTRING(Models[input_features], "fs_player_engagement")
    )
    """
)

See Semantic Link for in-Fabric lineage queries.

💰 Cost Considerations¶

Cost Attribution¶

Tag every feature pipeline run:

spark.conf.set("spark.fabric.cost_center", "casino-data-science")
spark.conf.set("spark.fabric.feature_table", "fs_player_engagement")
spark.conf.set("spark.fabric.feature_version", "1.0.0")

Roll up via FinOps governance — feature pipelines should be a distinct cost line, not absorbed into "Spark misc."

🚫 Anti-Patterns¶

📋 Implementation Checklist¶

Before promoting any feature table to lh_features and tagging it certified in OneLake Catalog:

• Table follows naming convention: lh_features.fs_<entity>_<feature_group>
• Schema includes entity_id, effective_from, effective_to, _is_current, source_table, feature_version, last_updated, computed_by
• Bitemporal SCD Type 2 implemented (no overwrite-in-place)
• Each feature column has a COMMENT describing definition + units
• Feature card published at docs/features/feature-store/fs_<...>.md
• Feature card lists owner, refresh SLA, source tables, consumers, PII class
• Tagged in OneLake Catalog: asset_type=feature_table, entity, domain, tier, freshness_sla, pii_class
• Registered as a Purview glossary term with upstream lineage
• AS-OF JOIN pattern tested on a known label set (no train-serving skew on holdout)
• Online store materialization defined (or marked offline-only)
• CI test asserts feature_version matches TBLPROPERTIES('feature_store.version')
• CI test asserts no _is_current = true row has a non-NULL effective_to
• Cost tags configured (cost_center, feature_table, feature_version)
• Workspace Identity used for all writes (no user credentials)
• Deprecation policy documented in feature card (announce / dual-write / sunset / remove)
• If PII-class != none: hashing/masking rules verified, restricted-tier RBAC applied
• If used in a regulated model: fairness-eval features stored separately

📚 References¶

Microsoft Fabric Documentation¶

• Delta Lake change data feed
• Fabric Mirroring
• OneLake security
• Direct Lake
• Fabric SQL Database
• GraphQL API for Fabric

Industry & Patterns¶

• Tecton — Feature Store Architecture (point-in-time correctness)
• Uber — Michelangelo Feature Store (offline / online split)
• Featureform — MLOps versioning patterns
• Kimball Group — Slowly Changing Dimensions Type 2

Related Wave 2 Docs¶

• MLOps for Fabric Production — Wave 2 anchor
• Model Monitoring & Drift Detection — drift signals on feature distributions
• Responsible AI Framework — fairness, demographics, restricted features
• LLM Cost Tracking — cost discipline patterns reused here

Related Best Practices¶

• Medallion Architecture Deep Dive — Bronze/Silver/Gold; feature store sits parallel to Gold
• Data Modeling & Star Schema — dimensional patterns; SCD Type 2 reference
• Data Governance Deep Dive — PII handling, sensitivity labels
• Identity & RBAC Patterns — Workspace Identity for pipelines
• FinOps Cost Governance — cost attribution for feature pipelines
• Incremental Refresh & CDC — change-driven feature recompute

Related Features¶

• Semantic Link — in-Fabric lineage queries
• Direct Lake — BI-facing feature exploration
• OneLake Catalog — discovery + tagging
• Mirroring — offline → online sync
• Fabric SQL Database — online store backend
• API for GraphQL — typed online lookup contracts

⬆️ Back to Top | 📚 Best Practices Index | 🏠 Home