GitBook: [v0.10-branch] 59 pages and 40 assets modified

feast-dev · May 22, 2021 · 6d44d92 · 6d44d92
1 parent 26b8472
commit 6d44d92
Show file tree

Hide file tree

Showing 58 changed files with 262 additions and 295 deletions.
diff --git a/...age-5 (1) (1) (1) (2) (2) (5) (7) (1).png → ...5 (1) (1) (1) (2) (2) (5) (7) (7) (1).png b/...age-5 (1) (1) (1) (2) (2) (5) (7) (1).png → ...5 (1) (1) (1) (2) (2) (5) (7) (7) (1).png
diff --git a/...age-5 (1) (1) (1) (2) (2) (5) (7) (2).png → ...5 (1) (1) (1) (2) (2) (5) (7) (7) (2).png b/...age-5 (1) (1) (1) (2) (2) (5) (7) (2).png → ...5 (1) (1) (1) (2) (2) (5) (7) (7) (2).png
diff --git a/...age-5 (1) (1) (1) (2) (2) (5) (7) (3).png → ...5 (1) (1) (1) (2) (2) (5) (7) (7) (3).png b/...age-5 (1) (1) (1) (2) (2) (5) (7) (3).png → ...5 (1) (1) (1) (2) (2) (5) (7) (7) (3).png
diff --git a/...age-5 (1) (1) (1) (2) (2) (5) (7) (4).png → ...5 (1) (1) (1) (2) (2) (5) (7) (7) (4).png b/...age-5 (1) (1) (1) (2) (2) (5) (7) (4).png → ...5 (1) (1) (1) (2) (2) (5) (7) (7) (4).png
diff --git a/...age-5 (1) (1) (1) (2) (2) (5) (7) (5).png → ...5 (1) (1) (1) (2) (2) (5) (7) (7) (5).png b/...age-5 (1) (1) (1) (2) (2) (5) (7) (5).png → ...5 (1) (1) (1) (2) (2) (5) (7) (7) (5).png
diff --git a/...age-5 (1) (1) (1) (2) (2) (5) (7) (6).png → ...5 (1) (1) (1) (2) (2) (5) (7) (7) (6).png b/...age-5 (1) (1) (1) (2) (2) (5) (7) (6).png → ...5 (1) (1) (1) (2) (2) (5) (7) (7) (6).png
diff --git a/...st-page-5 (1) (1) (1) (2) (2) (5) (7).png → ...5 (1) (1) (1) (2) (2) (5) (7) (7) (7).png b/...st-page-5 (1) (1) (1) (2) (2) (5) (7).png → ...5 (1) (1) (1) (2) (2) (5) (7) (7) (7).png
diff --git a/...book/assets/feast-on-aws-3- (2) (2) (2) (2) (2) (2) (2) (2) (2) (2) (2) (4).png b/...book/assets/feast-on-aws-3- (2) (2) (2) (2) (2) (2) (2) (2) (2) (2) (2) (4).png
diff --git a/docs/.gitbook/assets/feast-online-and-offline-store-data-model.png b/docs/.gitbook/assets/feast-online-and-offline-store-data-model.png
diff --git a/docs/.gitbook/assets/image (10).png b/docs/.gitbook/assets/image (10).png
diff --git a/docs/.gitbook/assets/image (11).png b/docs/.gitbook/assets/image (11).png
diff --git a/docs/.gitbook/assets/image (12).png b/docs/.gitbook/assets/image (12).png
diff --git a/docs/.gitbook/assets/image (13).png b/docs/.gitbook/assets/image (13).png
diff --git a/docs/.gitbook/assets/image (14).png b/docs/.gitbook/assets/image (14).png
diff --git a/docs/.gitbook/assets/image (15).png b/docs/.gitbook/assets/image (15).png
diff --git a/docs/.gitbook/assets/image (16).png b/docs/.gitbook/assets/image (16).png
diff --git a/docs/.gitbook/assets/image (17).png b/docs/.gitbook/assets/image (17).png
diff --git a/docs/.gitbook/assets/image (18).png b/docs/.gitbook/assets/image (18).png
diff --git a/...) (2) (2) (2) (2) (2) (2) (3) (3) (1).png → ...) (2) (2) (2) (2) (2) (3) (3) (3) (1).png b/...) (2) (2) (2) (2) (2) (2) (3) (3) (1).png → ...) (2) (2) (2) (2) (2) (3) (3) (3) (1).png
diff --git a/...) (2) (2) (2) (2) (2) (2) (3) (3) (2).png → ...) (2) (2) (2) (2) (2) (3) (3) (3) (2).png b/...) (2) (2) (2) (2) (2) (2) (3) (3) (2).png → ...) (2) (2) (2) (2) (2) (3) (3) (3) (2).png
diff --git a/...) (2) (2) (2) (2) (2) (2) (2) (3) (3).png → ...) (2) (2) (2) (2) (2) (3) (3) (3) (3).png b/...) (2) (2) (2) (2) (2) (2) (2) (3) (3).png → ...) (2) (2) (2) (2) (2) (3) (3) (3) (3).png
diff --git a/...age (4) (2) (2) (2) (2) (2) (2) (2) (2) (2) (2) (2) (2) (2) (3) (3) (3) (4).png b/...age (4) (2) (2) (2) (2) (2) (2) (2) (2) (2) (2) (2) (2) (2) (3) (3) (3) (4).png
diff --git a/docs/.gitbook/assets/image (5).png b/docs/.gitbook/assets/image (5).png
diff --git a/docs/.gitbook/assets/image (6) (3) (3) (3) (3) (3) (3) (3) (3) (3) (2) (1) (6).png b/docs/.gitbook/assets/image (6) (3) (3) (3) (3) (3) (3) (3) (3) (3) (2) (1) (6).png
diff --git a/docs/.gitbook/assets/image (6).png b/docs/.gitbook/assets/image (6).png
diff --git a/docs/.gitbook/assets/image (7).png b/docs/.gitbook/assets/image (7).png
diff --git a/docs/.gitbook/assets/image (8).png b/docs/.gitbook/assets/image (8).png
diff --git a/docs/.gitbook/assets/image (9).png b/docs/.gitbook/assets/image (9).png
diff --git a/docs/.gitbook/assets/point_in_time_join (1) (2) (2) (3) (3) (3) (3) (5).png b/docs/.gitbook/assets/point_in_time_join (1) (2) (2) (3) (3) (3) (3) (5).png
diff --git a/.../.gitbook/assets/untitled-25-1- (2) (2) (2) (3) (3) (3) (3) (3) (3) (1) (5).jpg b/.../.gitbook/assets/untitled-25-1- (2) (2) (2) (3) (3) (3) (3) (3) (3) (1) (5).jpg
diff --git a/docs/README.md b/docs/README.md
@@ -1,12 +1,12 @@
 # Introduction
 
-### What is Feast?
+## What is Feast?
 
 Feast \(**Fea**ture **St**ore\) is an operational data system for managing and serving machine learning features to models in production.
 
 ![](.gitbook/assets/feast_hero_010.png)
 
-### Problems Feast Solves
+## Problems Feast Solves
 
 **Models need consistent access to data:** ML systems built on traditional data infrastructure are often coupled to databases, object stores, streams, and files. A result of this coupling, however, is that any change in data infrastructure may break dependent ML systems. Another challenge is that dual implementations of data retrieval for training and serving can lead to inconsistencies in data, which in turn can lead to training-serving skew.
 
@@ -24,23 +24,23 @@ Feast solves the challenge of data leakage by providing point-in-time correct fe
 
 Feast addresses this problem by introducing feature reuse through a centralized system \(a registry\). This registry enables multiple teams working on different projects not only to contribute features, but also to reuse these same features. With Feast, data scientists can start new ML projects by selecting previously engineered features from a centralized registry, and are no longer required to develop new features for each project.
 
-### Problems Feast does not yet solve
+## Problems Feast does not yet solve
 
 **Feature engineering:** We aim for Feast to support light-weight feature engineering as part of our API.
 
 **Feature discovery:** We also aim for Feast to include a first-class user interface for exploring and discovering entities and features.
 
 **‌Feature validation:** We additionally aim for Feast to improve support for statistics generation of feature data and subsequent validation of these statistics. Current support is limited.
 
-### What Feast is not
+## What Feast is not
 
 [**ETL**](https://en.wikipedia.org/wiki/Extract,_transform,_load) **or** [**ELT**](https://en.wikipedia.org/wiki/Extract,_load,_transform) **system:** Feast is not \(and does not plan to become\) a general purpose data transformation or pipelining system. Feast plans to include a light-weight feature engineering toolkit, but we encourage teams to integrate Feast with upstream ETL/ELT systems that are specialized in transformation.
 
 **Data warehouse:** Feast is not a replacement for your data warehouse or the source of truth for all transformed data in your organization. Rather, Feast is a light-weight downstream layer that can serve data from an existing data warehouse \(or other data sources\) to models in production.
 
 **Data catalog:** Feast is not a general purpose data catalog for your organization. Feast is purely focused on cataloging features for use in ML pipelines or systems, and only to the extent of facilitating the reuse of features.
 
-### How can I get started?
+## How can I get started?
 
 {% hint style="info" %}
 The best way to learn Feast is to use it. Head over to our [Quickstart](quickstart.md) and try it out!

diff --git a/docs/concepts/architecture.md b/docs/concepts/architecture.md
@@ -2,7 +2,7 @@
 
 ![Feast 0.10 Architecture Diagram](../.gitbook/assets/image%20%284%29.png)
 
-### Functionality
+## Functionality
 
 * **Create Batch Features:** ELT/ETL systems like Spark and SQL are used to transform data in the batch store.
 * **Feast Apply:**  The user \(or CI\) publishes versioned controlled feature definitions using `feast apply`. This CLI command updates infrastructure and persists definitions in the object store registry.
@@ -13,7 +13,7 @@
 * **Prediction:** A backend system makes a request for a prediction from the model serving service.
 * **Get Online Features:** The model serving service makes a request to the Feast Online Serving service for online features using a Feast SDK.
 
-### Components
+## Components
 
 A complete Feast deployment contains the following components:
 

diff --git a/docs/concepts/feature-views.md b/docs/concepts/feature-views.md
@@ -1,6 +1,6 @@
 # Feature Views
 
-### Overview
+## Overview
 
 Feature views are objects used to define and productionize logical groups of features for training and serving.
 
@@ -17,7 +17,7 @@ Feast does not yet apply feature transformations. Feast acts as the productioniz
 
 Entities, features, and sources must be defined in order to define a feature view.
 
-### Entity
+## Entity
 
 Define an entity for the driver. Entities can be thought of as primary keys used to retrieve features. Entities are also used to join multiple tables/views during the construction of feature vectors.
 
@@ -36,9 +36,9 @@ driver = Entity(
 )
 ```
 
-### Feature
+## Feature
 
-A feature is an individual measurable property observed on an entity. For example, the amount of transactions \(feature\) a customer \(entity\) has completed. 
+A feature is an individual measurable property observed on an entity. For example, the amount of transactions \(feature\) a customer \(entity\) has completed.
 
 Features are defined as part of feature views. Since Feast does not transform data, a feature is essentially a schema that only contains a name and a type:
 
@@ -47,36 +47,35 @@ conversion_rate = Feature(
     # Name of the feature. Used during lookup of feautres from the feature store
     # The name must be unique
     name="conv_rate",
- 
+
     # The type used for storage of features (both at source and when materialized
     # into a store)
     dtype=ValueType.FLOAT
 )
 ```
 
-### Source
+## Source
 
 Indicates a data source from which feature values can be retrieved. Sources are queried when building training datasets or materializing features into an online store.
 
 ```python
-
 driver_stats_source = BigQuerySource(
     # The BigQuery table where features can be found
     table_ref="feast-oss.demo_data.driver_stats",
-    
+
     # The event timestamp is used for point-in-time joins and for ensuring only
     # features within the TTL are returned
     event_timestamp_column="datetime",
-    
+
     # The (optional) created timestamp is used to ensure there are no duplicate
     # feature rows in the offline store or when building training datasets
     created_timestamp_column="created",
 )
 ```
 
-### Feature View
+## Feature View
 
-A Feature View is a 
+A Feature View is a
 
 {% tabs %}
 {% tab title="driver\_trips\_feature\_table.py" %}

diff --git a/docs/concepts/glossary.md b/docs/concepts/glossary.md
@@ -1,26 +1,26 @@
 # Glossary
 
-#### **Entity key**
+## **Entity key**
 
 The combination of entities that uniquely identify a row. For example, a feature table with the composite entity of \(customer, country\) might have an entity key of \(1001, 5\). The key is used during lookups of feature values and for deduplicating historical rows.
 
-#### Entity timestamp
+## Entity timestamp
 
 The timestamp on which an event occurred. The entity timestamp could describe the event time at which features were calculated, or it could describe the event timestamps at which outcomes were observed.
 
 Entity timestamps are commonly found on the entity dataframe and associated with the target variable \(outcome\) that needs to be predicted. These timestamps are the target on which point-in-time joins should be made.
 
-#### Entity rows
+## Entity rows
 
 A combination of a single [entity key ](glossary.md#entity-key)and a single [entity timestamp](glossary.md#entity-timestamp).
 
-#### Entity dataframe
+## Entity dataframe
 
 A collection of [entity rows](glossary.md#entity-rows). This dataframe is enriched with feature values before being used for model training.
 
-#### Feature References
+## Feature References
 
-Feature references uniquely identify feature values throughout Feast. Feature references can either be defined as objects or as strings. 
+Feature references uniquely identify feature values throughout Feast. Feature references can either be defined as objects or as strings.
 
 The structure of a feature reference in string form is as follows:
 

diff --git a/docs/contributing/development-guide.md b/docs/contributing/development-guide.md
@@ -92,11 +92,11 @@ Feast is composed of [multiple components](https://docs.feast.dev/v/master/conce
 
 ## Making a Pull Request
 
-#### Incorporating upstream changes from master
+### Incorporating upstream changes from master
 
 Our preference is the use of `git rebase` instead of `git merge` : `git pull -r`
 
-#### Signing commits
+### Signing commits
 
 Commits have to be signed before they are allowed to be merged into the Feast codebase:
 
@@ -105,7 +105,7 @@ Commits have to be signed before they are allowed to be merged into the Feast co
 git commit -s -m "My first commit"
 ```
 
-#### Good practices to keep in mind
+### Good practices to keep in mind
 
 * Fill in the description based on the default template configured when you first open the PR
   * What this PR does/why we need it
@@ -136,7 +136,7 @@ Feast Protobuf API defines the common API used by Feast's Components:
 * Feast Protobuf API specifications are written in [proto3](https://developers.google.com/protocol-buffers/docs/proto3) in the Main Feast Repository.
 * Changes to the API should be proposed via a [GitHub Issue](https://github.com/feast-dev/feast/issues/new/choose) for discussion first.
 
-#### Generating Language Bindings
+### Generating Language Bindings
 
 The language specific bindings have to be regenerated when changes are made to the Feast Protobuf API:
 
@@ -146,5 +146,3 @@ The language specific bindings have to be regenerated when changes are made to t
 | [Main Feast Repository](https://github.com/feast-dev/feast) | Golang | Run `make compile-protos-go` to generate bindings |
 | [Feast Java](https://github.com/feast-dev/feast-java) | Java | No action required: bindings are generated automatically during compilation. |
 
-#### 
-
diff --git a/docs/contributing/release-process.md b/docs/contributing/release-process.md
@@ -28,7 +28,7 @@ When a tag that matches a Semantic Version string is pushed, CI will automatical
 
 ### Creating a change log
 
-We use an [open source change log generator](https://hub.docker.com/r/ferrarimarco/github-changelog-generator/) to generate change logs. The process still requires a little bit of manual effort. 
+We use an [open source change log generator](https://hub.docker.com/r/ferrarimarco/github-changelog-generator/) to generate change logs. The process still requires a little bit of manual effort.
 
 1. Create a GitHub token as [per these instructions](https://github.com/github-changelog-generator/github-changelog-generator#github-token). The token is used as an input argument \(`-t`\) to the change log generator. 
 2. The change log generator configuration below will look for unreleased changes on a specific branch. The branch will be `master` for a major/minor release, or a release branch \(`v0.4-branch`\) for a patch release. You will need to set the branch using the `--release-branch` argument.
@@ -61,5 +61,5 @@ docker run -it --rm ferrarimarco/github-changelog-generator \
 
 It's important to flag breaking changes and deprecation to the API for each release so that we can maintain API compatibility.
 
-Developers should have flagged PRs with breaking changes with the `compat/breaking` label. However, it's important to double check each PR's release notes and contents for changes that will break API compatibility and manually label `compat/breaking` to PRs with undeclared breaking changes. The change log will have to be regenerated if any new labels have to be  added.
+Developers should have flagged PRs with breaking changes with the `compat/breaking` label. However, it's important to double check each PR's release notes and contents for changes that will break API compatibility and manually label `compat/breaking` to PRs with undeclared breaking changes. The change log will have to be regenerated if any new labels have to be added.
 
diff --git a/docs/contributing/versioning-policy.md b/docs/contributing/versioning-policy.md
@@ -4,7 +4,7 @@ description: Versioning policies and status of Feast components
 
 # Versioning Policy
 
-### Versioning policy and branch workflow
+## Versioning policy and branch workflow
 
 Feast uses [semantic versioning](https://semver.org/).
 
@@ -19,9 +19,9 @@ A release branch should be substantially _feature complete_ with respect to the
 
 In general, unless you're committing code that only applies to a particular release stream \(for example, temporary hot-fixes, back-ported security fixes, or image hashes\), you should base changes from `master` and then merge or cherry-pick to the release branch.
 
-### Feast Component Matrix
+## Feast Component Matrix
 
-The following table shows the **status** \(stable, beta, or alpha\) of Feast components. 
+The following table shows the **status** \(stable, beta, or alpha\) of Feast components.
 
 Application status indicators for Feast:
 
@@ -59,7 +59,7 @@ Criteria for reaching **beta** status
 * API reference documentation
 * Deprecative changes must span multiple minor versions and allow for an upgrade path.
 
-### Levels of support <a id="levels-of-support"></a>
+## Levels of support <a id="levels-of-support"></a>
 
 Feast components have various levels of support based on the component status.
 
@@ -69,7 +69,7 @@ Feast components have various levels of support based on the component status.
 | Beta | The Feast community offers best-effort support for beta applications. Beta applications will be supported for at least 2 more minor releases. |
 | Alpha | The response differs per application in alpha status, depending on the size of the community for that application and the current level of active development of the application. |
 
-### Support from the Feast community <a id="support-from-the-kubeflow-community"></a>
+## Support from the Feast community <a id="support-from-the-kubeflow-community"></a>
 
 Feast has an active and helpful community of users and contributors.