|
| 1 | +# Adding a custom materialization engine |
| 2 | + |
| 3 | +### Overview |
| 4 | + |
| 5 | +Feast batch materialization operations (`materialize` and `materialize-incremental`) execute through a `BatchMaterializationEngine`. |
| 6 | + |
| 7 | +Custom batch materialization engines allow Feast users to extend Feast to customize the materialization process. Examples include: |
| 8 | + |
| 9 | +* Setting up custom materialization-specific infrastructure during `feast apply` (e.g. setting up Spark clusters or Lambda Functions) |
| 10 | +* Launching custom batch ingestion \(materialization\) jobs \(Spark, Beam, AWS Lambda\) |
| 11 | +* Tearing down custom materialization-specific infrastructure during `feast teardown` (e.g. tearing down Spark clusters, or deleting Lambda Functions) |
| 12 | + |
| 13 | +Feast comes with built-in materialization engines, e.g, `LocalMaterializationEngine`, and an experimental `LambdaMaterializationEngine`. However, users can develop their own materialization engines by creating a class that implements the contract in the [BatchMaterializationEngine class](https://github.com/feast-dev/feast/blob/6d7b38a39024b7301c499c20cf4e7aef6137c47c/sdk/python/feast/infra/materialization/batch_materialization_engine.py#L72). |
| 14 | + |
| 15 | +### Guide |
| 16 | + |
| 17 | +The fastest way to add custom logic to Feast is to extend an existing materialization engine. The most generic engine is the `LocalMaterializationEngine` which contains no cloud-specific logic. The guide that follows will extend the `LocalProvider` with operations that print text to the console. It is up to you as a developer to add your custom code to the engine methods, but the guide below will provide the necessary scaffolding to get you started. |
| 18 | + |
| 19 | +#### Step 1: Define an Engine class |
| 20 | + |
| 21 | +The first step is to define a custom materialization engine class. We've created the `MyCustomEngine` below. |
| 22 | + |
| 23 | +```python |
| 24 | +from typing import Any, Callable, Dict, List, Optional, Sequence, Tuple, Union |
| 25 | + |
| 26 | +from feast.entity import Entity |
| 27 | +from feast.feature_view import FeatureView |
| 28 | +from feast.batch_feature_view import BatchFeatureView |
| 29 | +from feast.stream_feature_view import StreamFeatureView |
| 30 | +from feast.infra.materialization import LocalMaterializationEngine, LocalMaterializationJob, MaterializationTask |
| 31 | +from feast.infra.offline_stores.offline_store import OfflineStore |
| 32 | +from feast.infra.online_stores.online_store import OnlineStore |
| 33 | +from feast.repo_config import RepoConfig |
| 34 | + |
| 35 | + |
| 36 | +class MyCustomEngine(LocalMaterializationEngine): |
| 37 | + def __init__( |
| 38 | + self, |
| 39 | + *, |
| 40 | + repo_config: RepoConfig, |
| 41 | + offline_store: OfflineStore, |
| 42 | + online_store: OnlineStore, |
| 43 | + **kwargs, |
| 44 | + ): |
| 45 | + super().__init__( |
| 46 | + repo_config=repo_config, |
| 47 | + offline_store=offline_store, |
| 48 | + online_store=online_store, |
| 49 | + **kwargs, |
| 50 | + ) |
| 51 | + |
| 52 | + def update( |
| 53 | + self, |
| 54 | + project: str, |
| 55 | + views_to_delete: Sequence[ |
| 56 | + Union[BatchFeatureView, StreamFeatureView, FeatureView] |
| 57 | + ], |
| 58 | + views_to_keep: Sequence[ |
| 59 | + Union[BatchFeatureView, StreamFeatureView, FeatureView] |
| 60 | + ], |
| 61 | + entities_to_delete: Sequence[Entity], |
| 62 | + entities_to_keep: Sequence[Entity], |
| 63 | + ): |
| 64 | + print("Creating new infrastructure is easy here!") |
| 65 | + pass |
| 66 | + |
| 67 | + def materialize( |
| 68 | + self, registry, tasks: List[MaterializationTask] |
| 69 | + ) -> List[LocalMaterializationJob]: |
| 70 | + print("Launching custom batch jobs or multithreading things is pretty easy...") |
| 71 | + return [ |
| 72 | + self._materialize_one( |
| 73 | + registry, |
| 74 | + task.feature_view, |
| 75 | + task.start_time, |
| 76 | + task.end_time, |
| 77 | + task.project, |
| 78 | + task.tqdm_builder, |
| 79 | + ) |
| 80 | + for task in tasks |
| 81 | + ] |
| 82 | + |
| 83 | +``` |
| 84 | + |
| 85 | +Notice how in the above engine we have only overwritten two of the methods on the `LocalMaterializatinEngine`, namely `update` and `materialize`. These two methods are convenient to replace if you are planning to launch custom batch jobs. |
| 86 | + |
| 87 | +#### Step 2: Configuring Feast to use the engine |
| 88 | + |
| 89 | +Configure your [feature\_store.yaml](../reference/feature-repository/feature-store-yaml.md) file to point to your new engine class: |
| 90 | + |
| 91 | +```yaml |
| 92 | +project: repo |
| 93 | +registry: registry.db |
| 94 | +batch_engine: feast_custom_engine.MyCustomEngine |
| 95 | +online_store: |
| 96 | + type: sqlite |
| 97 | + path: online_store.db |
| 98 | +offline_store: |
| 99 | + type: file |
| 100 | +``` |
| 101 | +
|
| 102 | +Notice how the `batch_engine` field above points to the module and class where your engine can be found. |
| 103 | + |
| 104 | +#### Step 3: Using the engine |
| 105 | + |
| 106 | +Now you should be able to use your engine by running a Feast command: |
| 107 | + |
| 108 | +```bash |
| 109 | +feast apply |
| 110 | +``` |
| 111 | + |
| 112 | +```text |
| 113 | +Registered entity driver_id |
| 114 | +Registered feature view driver_hourly_stats |
| 115 | +Deploying infrastructure for driver_hourly_stats |
| 116 | +Creating new infrastructure is easy here! |
| 117 | +``` |
| 118 | + |
| 119 | +It may also be necessary to add the module root path to your `PYTHONPATH` as follows: |
| 120 | + |
| 121 | +```bash |
| 122 | +PYTHONPATH=$PYTHONPATH:/home/my_user/my_custom_engine feast apply |
| 123 | +``` |
| 124 | + |
| 125 | +That's it. You should now have a fully functional custom engine! |
0 commit comments