피처 파이프라인 구축은(는) 무엇을 하나요?
사용 시기
- 웨어하우스/스트림 데이터에서 ML 모델을 위한 피처 엔지니어링.
- 레이블 누수 및 훈련/서빙 불일치 방지.
- 피처 스토어, 온라인 서빙 또는 과거 백필 설정.
- 일반적인 모델링/집계(예: dbt/Spark 스킬 사용)에는 사용하지 말 것. 단, ML 피처를 생성하는 경우는 예외.
워크플로우
- [ ] 각 피처를 엔티티 키와 이벤트 타임스탬프로 정의
- [ ] 시점 정확 조인(레이블 시간 기준)으로 훈련 데이터셋 구축
- [ ] 오프라인(훈련)과 온라인(서빙)에 대한 **하나의 정의** 공유
- [ ] 온라인 피처의 신선도/구체화 설정
- [ ] 훈련을 위해 과거 피처를 멱등적으로 백필
- 시점 정확성. 각 레이블의 타임스탬프 기준으로 피처를 조인합니다. 예측 시간 이전에 알려진 데이터만 사용합니다. 이는 가장 치명적인 피처 버그인 레이블 누수를 방지합니다.
- 오프라인/온라인 동등성. 훈련(오프라인, 배치)과 서빙(온라인, 저지연)에서 동일한 방식으로 피처를 계산합니다. 다른 로직은 훈련/서빙 불일치를 유발하고 프로덕션에서 조용히 성능을 저하시킵니다.
- 신선도. 온라인 피처는 모델의 허용 가능한 지연 시간을 충족하는 일정에 따라 구체화되어야 합니다.
- 멱등성 백필. 과거 피처 재계산은 반복 가능해야 합니다 (
designing-backfills-and-replays참조).
패턴
시점 정확(AS-OF) 조인 — 각 레이블 이벤트 직전의 최신 피처 값을 선택합니다:
SELECT l.entity_id, l.label_ts, f.value AS feature
FROM labels l
LEFT JOIN features f
ON f.entity_id = l.entity_id
AND f.event_ts <= l.label_ts -- 과거 데이터만; 누수 없음
QUALIFY ROW_NUMBER() OVER (
PARTITION BY l.entity_id, l.label_ts ORDER BY f.event_ts DESC) = 1;
단일 정의, 두 경로 — 피처를 한 번 정의(예: Feast FeatureView)하고 오프라인 저장소(훈련용)와 온라인 저장소(서빙용)로 구체화하여 동일한 로직을 사용합니다.
신선도 + 구체화 — 온라인 구체화를 예약하고, 다른 데이터셋 SLA와 마찬가지로 피처 신선도를 모니터링합니다(implementing-pipeline-observability).
일반적인 함정
- 레이블 누수 — 레이블 시간 이후에 계산된 피처를 조인하면 오프라인 메트릭이 부풀려지고 프로덕션에서 성능이 붕괴됩니다. 항상 AS-OF 조인을 사용하세요.
- 훈련/서빙 불일치 — 오프라인과 온라인 구현이 분리되면 점차 차이가 발생합니다. 하나의 정의를 공유하세요.
- 오래된 온라인 피처 — 모델이 오래된 값으로 서빙됩니다. 신선도를 설정하고 모니터링하세요.
- 재현 불가능한 백필 — 일관되지 않은 훈련 기록이 발생합니다. 피처 재계산을 멱등적으로 만드세요.
- 엔티티/타임스탬프 키 없음 — 시간에 걸쳐 피처를 올바르게 조인할 수 없습니다. 두 키 모두 필요합니다.
- 버전 관리되지 않은 피처 — 조용한 재정의로 모델 비교 가능성이 손상됩니다. 피처 정의에 버전을 부여하세요.