Feast는 기능 및 기능 그룹( 기능 뷰), 온라인 및 오프라인 저장 , 오프라인에서 온라인 저장 로 데이터를 동적으로 이동하는 기능(materialization)을 정의할 수 있는 고급 FeatureStore API제공합니다. MongoDB 통합을 통해 MongoDB Feast의 온라인 및 오프라인 저장 로 모두 사용할 수 있으므로 별도의 저장 시스템을 유지 관리하지 않고도 기능을 한 번만 정의하면 모델 교육 및 온라인 추론 전반에서 일관되게 제공 할 수 있습니다.
MongoDB의 유연한 문서 모델 과 MQL 사용하면 오프라인 저장 에 필요한 복잡한 쿼리 패턴을 처리하다 할 수 있습니다. 온라인 저장 의 경우, MongoDB 빠른 읽기/쓰기, 수평적 확장 , 조인과 왕복을 최소화하는 유연한 스키마와 같은 웹 스케일 액세스 패턴에 최적화되어 있습니다.
이 통합 개요에서는 다음을 확인할 수 있습니다.
Feast의 온라인 및 오프라인 저장 인 MongoDB 소개합니다.
Feast 개념이 MongoDB 에 매핑되는 방법.
MongoDB 오프라인 및 온라인 저장 디자인에 대한 자세한 설명입니다.
Feast에서 MongoDB 스토어를 설정하기 위한 구성 예제입니다.
주요 개념
온라인 및 오프라인 스토어
온라인 저장 는 단일 MongoDB 컬렉션 으로 지원되는 키-값 저장 로, 온라인 추론 중에 엔터티별 최신 기능을 짧은 지연 시간으로 검색할 수 있도록 최적화되어 있습니다.
오프라인 저장 는 교육 데이터 세트, 점수 산정 및 구체화(데이터를 온라인 저장 로 승격)를 위해 MongoDB 컬렉션 (일반적으로 이라고 함)에 저장된 기록 기능 데이터 행을 쿼리하는 컴퓨팅 및 번역 계층입니다.
feature_history
일반적인 워크플로 패턴
일반적인 엔드 투 엔드 워크플로는 다음과 같습니다.
MongoDB 지원 컬렉션을 점 엔터티, 기능 뷰 및 데이터 소스를 정의합니다.
offline_write_batch를 통해 오프라인 저장 에 기능 데이터를 수집하면 PyArrow 테이블을 입력으로 받고 오프라인 저장 스키마 에 따라 데이터를feature_historyMongoDB 컬렉션 에 삽입합니다.get_historical_features을(를) 사용하여 교육 데이터를 생성하면 MongoDB 에 저장된 기록 기능 행에 대해 효율적인 특정 시점 조인을 실행합니다.pull_latest_from_table_or_query및online_write_batch를 사용하여 오프라인 저장 의 최신 기능 값을 온라인 저장 로 구체화합니다.직렬화된 엔터티 키로 입력되는 단일 MongoDB 컬렉션 에서 읽는 Feast의 온라인 API를 통해 온라인 기능을 제공합니다.
Feast 개념이 MongoDB 에 매핑되는 방법
MongoDB 통합은 Feast의 표준 개념 모델을 따르지만 이러한 추상화를 엔터티 중심 온라인 문서 및 추가 전용 기록 이벤트를 위해 설계된 MongoDB 스키마 에 매핑합니다.
개념 매핑
Feast 개념 | 잔치에서의 역할 | MongoDB 표현 |
|---|---|---|
실재 | 기능이 설명하는 도메인 객체 입니다(예: 운전자, 사용자). | 직렬화된 엔터티 키로 인코딩됩니다. 온라인 저장 에서는 |
조인 키 | 데이터 프레임에서 엔터티 행을 식별하는 데 사용되는 열입니다. |
|
직렬화된 엔터티 키 | 조인 키 이름과 값의 결정론적 바이너리 인코딩. | 온라인: |
기능 | 특정 점 의 명명되고 입력된 측정값입니다. |
|
FeatureView | 기능을 엔터티, 데이터 소스 및 TTL 에 바인딩합니다. 조직 단위. | 오프라인: 각 기록 문서 의 |
DataSource | 기록 기능이 있는 위치에 대한 메타데이터 포인터입니다. |
|
OfflineStore | 기록 기능 및 PIT 조인을 위한 읽기/ 쓰기 (write) 인터페이스입니다. |
|
OnlineStore | 엔티티당 최신 기능 값의 지연 시간이 짧은 저장 . | 중첩된 |
TTL | FeatureView 수준의 최신 상태 창. | 기록 기능을 계산할 때 오프라인 쿼리 및 Python 사후 필터링에 적용됩니다. 인덱스에서 |
FeatureService | 모델에 대한 기능 참조의 명명된 목록입니다. | 직접적인 MongoDB 표현이 없습니다. Feast에서 온라인 저장 에서 읽을 |
레지스트리 | 엔터티, 기능 보기 및 서비스에 대한 메타데이터 저장 . | 변경되지 않음. MongoDB 통합은 Feast 레지스트리를 대체하지 않습니다. |
RetrievalJob | 기능 테이블을 반환하는 지연 실행 래퍼입니다. | MongoDB 오프라인 저장 의 경우 MQL 집계 캡슐화하고 커서에서 화살표로 변환을 지원하는 화살표 내보내기를 노출합니다. |
구체화 | 최신 오프라인 기능을 온라인 저장 에 정기적으로 배포합니다. |
|
MongoDB 오프라인 스토어
데이터 모델
MongoDB 오프라인 저장 모든 기능 보기에 대한 추가 전용 기록 기능 행을 저장하는 단일 공유 컬렉션 ( 기본값 으로 feature_history)을 사용합니다.
각 문서 특정 이벤트 타임스탬프에서 하나의 FeatureView에 대한 하나의 엔터티에 대한 하나의 관찰을 나타냅니다.
{ "entity_id": "Binary(...)", "feature_view": "driver_stats", "event_timestamp": "ISODate(2024-01-15T12:00:00Z)", "created_at": "ISODate(2024-01-15T12:01:00Z)", "features": { "conv_rate": 0.72, "acc_rate": 0.91, "avg_daily_trips": 14 } }
주요 속성:
추가 전용: 기록 데이터는 변경할 수 없는 것으로 처리됩니다. 수정 사항은 현재 위치 업데이트가 아닌 최신
created_at타임스탬프가 있는 새 행으로 기록됩니다.Time Series 친숙한:
event_timestamp은 기능 값이 관찰된 시점을 나타냅니다.created_at은(는) 여러 관찰이 동일한 이벤트 타임스탬프를 주식 경우 타이 브레이커(tie-breaker)로 사용됩니다.FeatureView별 기능 그룹화:
feature_view는 행이 속한 FeatureView를 식별하므로 단일 컬렉션 여러 FV를 호스팅하다 할 수 있습니다.
단일 복합 인덱스 모든 주요 쿼리 패턴을 지원합니다.
(entity_id ASC, feature_view ASC, event_timestamp DESC, created_at DESC)
이 인덱스 사용하면 엔티티 및 기능 뷰에 대한 범위 스캔을 효율적으로 수행할 수 있으며 집계 중에 (entity_id, feature_view) 당 가장 최근의 관찰이 먼저 표시됩니다.
쿼리 패턴 | 인덱스 동작 |
|---|---|
|
|
| 정렬은 작동하지 않습니다 — 인덱스 순서가 정렬 순서와 일치합니다. |
| 커서는 |
|
|
이 인덱스 없으면 네 가지 쿼리 패턴이 모두 COLLSCAN로 저하됩니다. 인덱스 는 처음 사용할 때 _ensure_indexes를 통해 느리게 생성되고 프로세스 수준 _indexes_ensured 설정하다 의 연결 문자열 별로 캐시되므로 프로세스 수명당 한 번만 생성됩니다.
핵심 오프라인 운영
MongoDB 오프라인 저장 표준 Feast 오프라인 저장 인터페이스를 구현합니다.
offline_write_batch- 구성된MongoDBSource메타데이터 사용하여connection_string,database및collection를 결정하여 기능 데이터의pyarrow.Table를 기본 MongoDB 컬렉션 에 기록합니다.get_historical_features- 엔티티 및 이벤트 타임스탬프의entity_df와 FeatureViews 설정하다 가 주어지면 각 행 기능 특정 시점의 올바른 기능 값이 포함된 확장된 테이블을 반환합니다: 각(entity_id, event_timestamp)쌍에 대해event_timestamp <= entity_event_timestamp그리고 into TTL 이 선택되었습니다.pull_latest_from_table_or_query- Feast의 구체화 엔진 이 온라인 저장 시드하는 데 사용하는 시간 창 최신 기능 값을 포함하는 엔터티당 하나의 행을 반환합니다.pull_all_from_table_or_query- 동일한feature_history스키마 및 인덱스 기반으로 내보내기 또는 검사를 위해 지정된 날짜 범위 의 데이터 소스 에서 모든 행을 검색합니다.persist(RetrievalJob.persist을(를) 통해) - 기록 기능 쿼리 의 결과를feature_history와(과) 별개인SavedDatasetStorage을(를) 통해 별도의 컬렉션 또는 외부 싱크에 씁니다.
호출 경로:
FeatureStore.write_to_offline_store(feature_view_name, df) → provider.ingest_df_to_offline_store(feature_view, arrow_table) → OfflineStore.offline_write_batch(config, feature_view, table, progress)
추가전용 시맨틱: insert_many(ordered=False) 10000문서가, 문서 배치에 로 삽입됩니다. 쓰기 (write) 시 업서트 또는 중복 제거 없으며 동일한 튜플에 대해 여러 문서가 (entity_id, feature_view, event_timestamp) 허용되고 유지됩니다.
충돌 해결은 읽기 시간으로 연기됩니다.
pull_latest_from_table_or_query승리한event_timestamp그룹 내에서created_at가 가장 높은 문서 선택합니다.get_historical_features(채점 경로)는$sort … created_at DESC를 사용하므로 타임스탬프가 동률일 때$group $first도 가장 높은created_at를 선택합니다.
따라서 나중에 created_at 로 작성된 수정 사항이 삭제 또는 업데이트 작업 없이 우선합니다.
pull_latest_from_table_or_query [start_date, end_date] 창 에 가장 최근의 기능 값이 포함된 엔터티당 하나의 행을 반환합니다. entity_df 는 제공되지 않습니다.
파이프라인 단계:
$match { feature_view, event_timestamp: {$gte, $lte} } → $sort { entity_id, event_timestamp DESC, created_at DESC } → $group $first by entity_id → $project { entity_id, event_timestamp, features.* }
복합 인덱스 $match + $sort 를 효율적으로 제공합니다. $group $first 는 나머지를 구체화하지 않고 엔터티당 하나의 문서 선택합니다.
애그리게이션 구현
권장되는 오프라인 구현 MongoDBOfflineStore이라는 애그리게이션 기반 MongoDB 오프라인 저장 입니다.
주요 특성:
feature_view(으)로 구별되는 모든 FeatureView에서 공유하는 단일feature_history컬렉션 사용합니다.모든 쿼리에 대해 복합 인덱스
(entity_id, feature_view, event_timestamp, created_at)에 의존하여 전체 컬렉션 스캔을 방지합니다.서버 측
$group $first을(를) 워크로드 "점수"(엔터티당 하나의 행)에 사용하고, 엔터티 ID가 반복되는 "교육" 워크로드에는pd.merge_asof을(를) 사용하여 정확성과 성능의 균형을 맞춥니다.청킹을 통한 메모리 사용량이 제한되므로 RAM 소진하지 않고 큰
entity_df값을 처리할 수 있습니다.
벤치마크에 따르면 이 구현 대체 MongoDB 오프라인 접근 방식에 비해 처리량 과 메모리 효율성 의 최상의 조합을 제공합니다.
get_historical_features 는 핵심 Feast API 입니다. entity_df (엔티티 키 열의 N 행 + event_timestamps) 및 K개의 FeatureView 객체 기능 허용하고 각 행의 event_timestamp (포인트- 적시 정확성).
표기법:
N → 엔티티 수
M → 기능 수
P → 관측값 개수
F → 기능 조회 수
K → 단일
get_historical_features호출에서 요청된 기능 뷰의 수
채점 경로
점수 산정 경로는 entity_df 에 반복되는 엔터티 ID가 없을 때 활성화됩니다(각 행이 별개의 시점에 별개의 엔터티에 대한 기능을 요청하는 일반적인 추론 시나리오).
탐지:
scoring_path = ( entity_df[all_entity_id_cols].drop_duplicates().shape[0] == len(entity_df) )
점수를 매길 때 서버 측 $group $first 단계가 추가됩니다.
$match → $sort → $group $first → $project
$group 는 (entity_id, feature_view) 별로 그룹화하고 (event_timestamp, created_at) 가 가장 높은 문서 , 즉 인덱스 순서에서 앞의 $sort 이후 첫 번째 문서 를 선택합니다. MongoDB 기능 뷰당 각 엔터티에 대한 다른 P-1 문서를 구체화하지 않습니다. 하나의 문서 선택한 후 커서 단순히 다음 그룹 키로 이동합니다. 엔터티당 비용 은 O(P)가 아닌 O(로그 P) (인덱스 검색)입니다.
$match 은 event_timestamp: {$lte: max_ts} 을 사용하며, 여기서 max_ts 는 현재 청크 의 최대 엔터티 요청 타임스탬프입니다. 이는 보수적인 근사치('오버슈트')로, 향후 서버 일부 엔터티에 대해 문서를 약간 반환할 수 있습니다. 아래의 Python 포스트 필터는 유효하지 않은 행을 무효화하여 이 문제를 해결합니다.
# Merge on entity_id (left = entity_df rows, right = server results) merged = result[["_fv_entity_id", event_timestamp_col]].merge( fv_join, on="_fv_entity_id", how="left" ) # Null out rows where the server doc is in the future or outside TTL future_mask = merged["_fv_ts"] > merged[event_timestamp_col] if fv.ttl: ttl_mask = merged["_fv_ts"] < ( merged[event_timestamp_col] - fv.ttl ) bad_mask = future_mask | ttl_mask else: bad_mask = future_mask for feat in features: vals = merged[feat].copy() vals[bad_mask | merged["_fv_ts"].isna()] = None result[col] = vals.values
이는 단일 pd.merge 호출 후 벡터화된 부울 인덱싱 — P 및 M에 관계없이 Pandas C 코드에서 O(N) 작동합니다.
교육 경로
entity_df 에 반복된 엔터티 ID가 있는 경우(엔터티당 타임스탬프 스냅샷이 많은 교육 데이터 세트) $group 단계가 생략됩니다. 집계 각 엔터티에 대해 타임스탬프 창 에 있는 모든 문서를 반환하고, Python pd.merge_asof 를 사용하여 각 행의 event_timestamp 또는 그 이전에서 가장 최근 문서 찾습니다.
$match → (no $group)
result = pd.merge_asof( result.sort_values(event_timestamp_col), fv_df_subset.sort_values("_fv_ts"), left_on=event_timestamp_col, right_on="_fv_ts", by="_fv_entity_id", direction="backward", )
두 가지 수준의 청크는 메모리 사용량을 제어합니다.
수준 | 상수 | 목적 |
|---|---|---|
아우터 | 50,000 행 |
|
내부 | 10,000 엔티티 ID | 집계 호출당 |
CHUNK_SIZE보다 큰 entity_df 의 경우 외부 루프는 여러 _run_single 호출을 실행하고 결과를 연결합니다.
if len(working_df) <= CHUNK_SIZE: result_df = _run_single(working_df, coll) else: chunks = [ _run_single(chunk, coll) for chunk in _chunk_dataframe(working_df, CHUNK_SIZE) ] result_df = pd.concat(chunks, ignore_index=True)
따라서 최대 Python 사이드 메모리는 총 N에 관계없이 O(CHUNK_SIZE x M x K)입니다.
MongoDB features 하위 문서는 pd.json_normalize 대신 pd.apply 을 사용하여 개별 열로 확장됩니다. 이렇게 하면 json_normalize 병합되거나 손실될 복잡한 유형(지도 및 구조의 경우 딕셔너리, 배열의 경우 목록)이 보존됩니다. 프로젝션된 열 이름이 FeatureView 정의와 일치하도록 역방향 필드 매핑도 적용됩니다.
if "features" in fv_df.columns: for feat in features: src_col = reverse_fm.get(feat, feat) fv_df[feat] = fv_df["features"].apply( lambda d, _s=src_col: ( d.get(_s) if isinstance(d, dict) else None ) ) fv_df = fv_df.drop(columns=["features"])
오프라인 스토어 기능
기능 | 지원되나요? | 참고 사항 |
|---|---|---|
| 예 | 인덱싱된 애그리게이션 및 Pandas merge-asof를 사용하여 |
| 예 |
|
| 예 |
|
| 예 | 구성된 |
| 예 |
|
데이터 레이크 또는 웨어하우스로 직접 내보내기와 같은 추가 편의는 특정 RetrievalJob 구현 에 따라 달라지며 오프라인 스토어에 대한 Feast의 표준 패턴을 따를 것으로 예상됩니다.
MongoDB 온라인 스토어
데이터 모델
MongoDB 온라인 저장 직렬화된 엔터티 키로 키로 지정되는 모든 FeatureViews에 대해 단일 컬렉션 사용합니다.
_id:serialized_entity_key(entity_key), 엔터티 이름과 값을 정렬하고 바이트로 인코딩하는 Feast의 안정적인 인코딩 함수에서 생성합니다.features: 각 FeatureView가 자체 기능 네임스페이스 유지 관리하는 중첩된 하위 문서입니다.event_timestamps: 해당 FeatureView의 최신 값이 작성된 시점을 나타내는 FeatureView별 타임스탬프입니다.created_timestamp또는updated_at: TTL 인덱싱 및 진단에 유용한 부기 필드입니다.
예시(간체):
{ "_id": "b\"<serialized_entity_key>\"", "features": { "driver_stats": { "rating": 4.91, "trips_last_7d": 132 }, "pricing": { "surge_multiplier": 1.2 } }, "event_timestamps": { "driver_stats": "ISODate(2026-01-01T12:00:00Z)", "pricing": "ISODate(2026-01-21T12:00:00Z)" }, "created_timestamp": "ISODate(2026-01-21T12:00:00Z)" }
설계 근거:
단일 컬렉션 각 엔터티의 상태 하나의 문서 에 보관하며, 이는 키 기반 조회에 대한 Feast의 기대치에 부합하고 FeatureView별 컬렉션에서 상태 조각화되는 것을 방지합니다.
직렬화된 엔터티 키를
_id로 사용하면 Feast의 결정론적 인코딩을 재사용하고, 컬렉션 전체에서 프라이머리 키가 중복되는 것을 방지하고, 엔터티당 단일 키 조회로 계속 검색합니다.
오프라인 저장 ( feature_view 판별자 필드 있는 단일 feature_history 컬렉션 사용)와 마찬가지로 온라인 저장 도 모든 FeatureViews에 대해 단일 컬렉션 사용합니다.
온라인 스토어는 기본적으로 기능 보기 지향적이 아닌 엔터티 키 지향적입니다. 상위 수준 FeatureStore API 단일 FeatureView로 online_read 및 online_write_batch 를 호출하지만, Feast의 기본 저장 모델은 엔터티 키당 단일 논리적 행을 중심으로 설계되었습니다. 해당 행은 시간이 지남에 따라 여러 FeatureView의 기능을 누적할 수 있습니다.
하나의 컬렉션 사용하면 엔터티별로 통합 문서 유지 관리하고 컬렉션 간에 엔터티 키를 중복하지 않고도 관련 하위 문서(예: features.<feature_view_name>)만 원자적으로 업데이트 수 있습니다.
단일 컬렉션 디자인은 처음부터 Feast의 표준이었으며(원래 Redis용으로 설계됨) MongoDB의 장점을 활용합니다. 다음과 같은 이점이 있습니다.
쓰기 (write) 증폭 감소
간소화된 인덱스 관리 (프라이 인덱스
_id프라이머리 사용)여러 FeatureView가 동일한 엔터티를 주식 경우 컬렉션 간 조정이 필요하지 않습니다.
Feast의 키 기반 가져오기 모델을 통한 일관된 검색 시맨틱
FeatureView별 컬렉션 설계는 엔터티 상태 조각화하고, 기능이 구성된 경우 추가 조정 또는 다중 컬렉션 쿼리가 필요하고, Feast의 액세스 패턴 에 대한 성능 이점 없이 운영 오버헤드 증가시킵니다.
직렬화된 엔터티 키 _id: Feast는 예측 가능한 바이트 시퀀스를 보장하기 위해 연결 전에 엔티티 이름과 값을 명시적으로 정렬하는 안정적인 인코딩 함수인 serialize_entity_key를 제공합니다(struct.pack 로 입력하여 바이트를 생성). 즉, _id로 직접 사용할 수 있습니다.
참고
serialize_entity_key 은 안정적인 _id를 제공하지만 출력이 균일하게 분산된 되지 않으므로 샤딩 에 적합하지 않습니다. 배포서버 온라인 저장 컬렉션 샤딩 해야 하는 경우 해시 샤드 키 또는 추가 필드 고려하는 것이 좋습니다.
핵심 온라인 운영
MongoDB 온라인 저장 Feast의 표준 온라인 저장 API 구현합니다.
online_write_batch- 구체화하는 동안 Feast는 각 엔터티의 최신 기능 값을 MongoDB 문서에 씁니다. 각 배치 업서트 중첩된 관련features.<feature_view>하위 문서와event_timestamps의 해당 항목만 업데이트하여 엔터티 문서를 원자적이고 일관적인 유지합니다.online_read및get_online_features- 온라인 검색은 오프라인과 동일한 직렬화 로직을 사용하여 엔터티 키를_id값으로 해석한 다음 키 조회를 수행합니다. 각 조회는 중첩된features구조를 활용하여 엔터티에 대해 요청된 모든 기능을 한 번의 왕복으로 반환합니다.TTL 및 최신 상태 - 기능 TTL FeatureView에서 구성되며 주로 오프라인 PIT 조인에 사용됩니다. 온라인 TTL
updated_at또는 유사한 타임스탬프에 대한 인덱스 사용하여 구현할 수 있으며, 이는 오프라인 스토어는 추가 전용이고 온라인 스토어는 최신 상태 보유한다는 Feast의 개념과 일관적인 .
구성
오프라인 스토어 구성
오프라인 저장 MongoDBOfflineStoreConfig을 사용하여 구성됩니다.
class MongoDBOfflineStoreConfig(FeastConfigBaseModel): type: str = "...MongoDBOfflineStore" connection_string: str = "mongodb://localhost:27017" database: str = "feast" collection: str = "feature_history"
예 feature_store.yaml :
offline_store: type: feast.infra.offline_stores.contrib.mongodb_offline_store.mongodb.MongoDBOfflineStore connection_string: "mongodb+srv://user:pass@cluster.mongodb.net" database: feast collection: feature_history
MongoDBSource 는 해당 DataSource 입니다. 해당 name 필드 는 feature_view 모든 문서 에 저장된 판별자가 됩니다. 전체 구성 옵션은 Feast 문서에서 MongoDB 데이터 소스 참조를 참조하세요.
source = MongoDBSource( name="driver_stats", timestamp_field="event_timestamp", created_timestamp_column="created_at", )
다음 단계
Feast 빠른 시작에 따라 로컬 기능 저장 설정하다 한 다음 이 페이지의 구성 예제를 사용하여 MongoDB 에서 온라인 및 오프라인 저장 로 전환합니다.
구성 옵션, 비동기 지원 및 전체 기능 매트릭스에 대해서는 Feast 문서에서 MongoDB 온라인 스토어 참조를 검토하세요.
오프라인 저장 구성 및 지원되는 기능에 대해서는 MongoDB 오프라인 스토어 참조를 검토하세요.
옵션 및 스키마 세부 정보는 MongoDB 데이터 소스 참조를 검토합니다.
MongoDBSourceFeast 개념 가이드 에서 엔터티, 기능 뷰, 구체화와 같은 핵심 Feast 개념에 대해 알아보세요.