The Problem
Data teams need a consistent way to define, materialize, and serve feature pipelines that span batch, streaming, and online inference while avoiding leakage and duplication. Building such a platform from scratch incurs heavy engineering effort and operational debt.
What This Does
feathr delivers a production‑grade feature store originally built at LinkedIn. The core Java compute engine lives in feathr-compute/src/main/java/com/linkedin/feathr/compute/ (e.g., ComputeGraphBuilder.java, Operators.java). High‑level Pythonic APIs and documentation are packaged under docs/ and the sandbox Docker images (FeathrSandbox.Dockerfile). Build orchestration uses Gradle (build.gradle at the repo root and in feathr-compute/). CI pipelines are defined in .github/workflows/ and azure-pipelines.yml, covering unit tests, code quality, and publishing to Maven, Docker Hub, and PyPI.
How To Use It
Setup
Build the Java core and publish the local Maven artifacts ./gradlew clean build publishToMavenLocal
Build the sandbox container (Dockerfile in repo root)
docker build -f FeathrSandbox.Dockerfile -t feathr-sandbox:dev .
Configuration
Registry credentials – see docs/how-to-guides/feathr-configuration-and-env.md for required env vars (FEATHRREGISTRYURL, FEATHRCLIENTID, etc.). Azure resource provisioning – scripts in docs/how-to-guides/azureresourceprovision.sh and Bicep files under docs/how-to-guides/deployment/.
Running it
Start the sandbox (exposes UI, Jupyter, and interpret ports) docker run -it --rm -p 8888:8888 -p 8081:80 -p 7080:7080 \ -e GRANTSUDO=yes feathrfeaturestore/feathr-sandbox:releases-v1.0.0
Inside the container, the Python SDK (feathr package) can be imported; feature definitions are written as Python notebooks (see docs/samples/.ipynb). For production deployments, the deploy/start.sh script launches the Feathr service behind an Nginx proxy (deploy/nginx.conf).
Real‑World Use
A typical pipeline:
from feathr import FeathrClient, Feature, ValueType
client = FeathrClient() f = Feature(name="userspend", source="transactions", transform="sum(amount)") client.registerfeature(f) client.materializefeature("user_spend", start="2023-01-01", end="2023-01-31")
The client writes metadata to the Feathr registry (Azure Cosmos / Azure SQL supported) and materializes the feature via the Java compute graph, which can then be served online through the sandbox UI or a custom inference service.
Code Health & Issues
Low – No lockfile for Gradle – build.gradle declares dependencies without a gradle.lockfile, making reproducible builds harder. Low – Limited Python packaging – Only two Python files are present; the PyPI publishing workflow exists (publish-to-pypi.yml) but the source code for the Python SDK is missing from the repo, requiring external fetching. Medium – Sparse unit tests – 10 test files are detected, but most reside in CI workflows; core Java compute classes (ComputeGraphBuilder, Operators) have minimal test coverage. Low – Secrets in CI – Workflow files reference Azure storage keys (publish-to-azure-storage.yml) but the actual secret values are omitted, which is expected; ensure secret handling follows best practices. Low – Documentation depth – 161 Markdown files provide extensive guides; however, entry‑point documentation for the Java core is thin, which may hinder custom extensions.
Overall, the repository shows disciplined CI/CD (GitHub Actions + Azure Pipelines), a clear separation between compute (Java) and user‑facing layers (Docker sandbox, Python docs), and a mature documentation set.
The Bottom Line
feathr offers a battle‑tested, enterprise‑scale feature store with solid Java compute foundations and comprehensive Azure‑focused deployment guides. It is well‑suited for organizations that already use Azure and need a feature pipeline that can scale to PB‑level data. The main drawbacks are the lack of a reproducible Gradle lockfile and an incomplete in‑repo Python SDK, which may require extra steps for Python‑centric teams.