Skip to content

Commit 276fc5f

Browse files
jparthasarthygitbook-bot
authored andcommitted
GitBook: [master] 58 pages modified
1 parent 2140422 commit 276fc5f

1 file changed

Lines changed: 36 additions & 17 deletions

File tree

docs/quickstart.md

Lines changed: 36 additions & 17 deletions
Original file line numberDiff line numberDiff line change
@@ -33,23 +33,38 @@ We can bootstrap a feature repository using the `feast init` command:
3333
```text
3434
$ feast init
3535
36-
Generated feature_store.yaml and example features in example_repo.py
37-
Now try running `feast apply` to apply and `feast materialize` to
38-
sync data to the online store
36+
Creating a new Feast repository in <...>/charmed_bass.
3937
```
4038

41-
This command generates two files. Let's take a look at `feature_store.yaml`:
39+
This command generates an example repository with a random name, containing the following files:
40+
41+
```text
42+
.
43+
└── charmed_bass
44+
   ├── data
45+
   │   └── driver_stats.parquet
46+
   ├── example.py
47+
   └── feature_store.yaml
48+
```
49+
50+
Let's enter our example feature repository.
51+
52+
```
53+
# replace "charmed_bass" with your auto-generated feature repository name
54+
cd charmed_bass
55+
```
56+
57+
Next, let's take a look at the `feature_store.yaml` file, which configures how the feature store runs.
4258

4359
```yaml
44-
project: happy_ant
60+
project: charmed_bass
4561
registry: data/registry.db
4662
provider: local
4763
online_store:
48-
local:
49-
path: data/online_store.db
64+
path: data/online_store.db
5065
```
5166
52-
This file defines how the feature store is configured to run. The most important option here is `provider`, which specifies the environment that Feast will run in. We've initialized `provider=local`, indicating that Feast will run the feature store on our local machine. See [Repository Config](reference/feature-store-yaml.md) for more details.
67+
An important field to be aware of is `provider`, which specifies the environment that Feast will run in. We've initialized `provider=local`, indicating that Feast will run the feature store on our local machine. See [Repository Config](reference/feature-store-yaml.md) for more details.
5368

5469
Next, take a look at `example.py`. This file defines some example features:
5570

@@ -65,7 +80,7 @@ from feast.data_source import FileSource
6580
# production, you can use your favorite DWH, such as BigQuery. See Feast documentation
6681
# for more info.
6782
driver_hourly_stats = FileSource(
68-
path="/Users/jay/Projects/feast-10-test-2/hehe/data/driver_stats.parquet",
83+
path="<...>/data/driver_stats.parquet",
6984
event_timestamp_column="datetime",
7085
created_timestamp_column="created",
7186
)
@@ -93,7 +108,7 @@ driver_hourly_stats_view = FeatureView(
93108
94109
```
95110

96-
This file defines three objects:
111+
There are three objects defined in this file:
97112

98113
* A `DataSource`, which is a pointer to persistent feature data. In this example, we're using a `FileSource`, which points to a set of parquet files on our local machine.
99114
* An `Entity`, which is a metadata object that is used to organize and join features. In this example, our entity is `driver_id`, indicating that our features are modeling attributes of drivers.
@@ -106,7 +121,7 @@ We can register our features by running `feast apply` from the CLI.
106121
```bash
107122
$ feast apply
108123
109-
Processing <...>/feast-10-test-2/feast/example.py as example
124+
Processing <...>/charmed_bass/example.py as example
110125
Done!
111126
112127
```
@@ -130,9 +145,9 @@ entity_df = pd.DataFrame.from_dict({
130145
"driver_id": [1001, 1002, 1003, 1004],
131146
"event_timestamp": [
132147
datetime(2021, 4, 12, 10, 59, 42),
133-
datetime(2021, 4, 12, 8, 12, 10),
148+
datetime(2021, 4, 12, 8, 12, 10),
134149
datetime(2021, 4, 12, 16, 40, 26),
135-
datetime(2021, 4, 12, 15, 1, 12)
150+
datetime(2021, 4, 12, 15, 1 , 12)
136151
]
137152
})
138153
@@ -166,14 +181,18 @@ This DataFrame contains all the necessary signals needed to train a model, exclu
166181

167182
### 4. Materializing features to the online store
168183

169-
We just used Feast to generate Using the `local` provider, the online store is a SQLite database. To materialize features, run the following command from the CLI:
184+
We've just showed how we can use our features to train a model. Now, we'll populate the online store with our features to make them available for real time inference. When using the `local` provider, the online store is a SQLite database.
185+
186+
To materialize features, run the following command from the CLI:
170187

171188
```bash
172189
# Materialize feature values up until the current time
173190
feast materialize-incremental $(date -u +"%Y-%m-%dT%H:%M:%S")
191+
192+
Done!
174193
```
175194

176-
We've just populated the online store with the most up-to-date features from the offline store. Our feature values are now ready for real-time fetching.
195+
We've just populated the online store with the most up-to-date features from the offline store. Our feature values are now ready for real-time retrieval.
177196

178197
### 5. Fetching feature vectors for inference
179198

@@ -188,10 +207,10 @@ feature_vector = store.get_online_features(
188207
'driver_hourly_stats:acc_rate',
189208
'driver_hourly_stats:avg_daily_trips'
190209
],
191-
entity_rows=[{"user_id": "1001"}]
210+
entity_rows=[{"driver_id": "1001"}]
192211
).to_dict()
193212
194-
print(feature_vector)
213+
pprint(feature_vector)
195214
```
196215

197216
```text

0 commit comments

Comments
 (0)