Spark Structured Streaming 및 Databricks Feature Store를 사용하여 원시 Kafka 이벤트로부터 밀리초 단위의 온라인 피처 서빙(online feature serving)에 이르기까지, 시점(point-in-time)이 정확하고 프로덕션 등급의 피처 파이프라인(feature pipelines)을 구축합니다.

목차

• 피처 엔지니어링 (Feature Engineering) 문제
• 아키텍처 개요 (Architecture Overview)
• 피처 스토어 (Feature Store) 개념: ERD
• 환경 설정 (Environment Setup)
• 스트리밍 피처 파이프라인 (Streaming Feature Pipeline)
• 시점(Point-in-Time)이 정확한 학습 데이터셋 생성
• 온라인 스토어(Online Store)에 피처 쓰기
• 추론 시점(Inference Time)의 피처 서빙
• 피처 테이블 레퍼런스 (Feature Table Reference)
• 참고 문헌 (References)

피처 엔지니어링 (Feature Engineering) 문제

피처 엔지니어링 (Feature engineering)은 대부분의 ML 프로젝트가 프로덕션 환경에서 조용히 실패하는 지점입니다. 모델이 틀렸기 때문이 아니라, 모델이 학습 시점에 보는 피처(features)와 추론 시점에 보는 피처가 다르기 때문입니다. 이를 **학습-서빙 왜곡 (training-serving skew)**이라고 하며, 이는 ML 시스템의 가장 큰 잠재적 위협 요소입니다.

세 가지 구체적인 실패 모드가 이를 유발합니다:

1. 온라인/오프라인 불일치 (Online/offline inconsistency) — 학습 피처를 계산하는 배치(batch) 파이프라인이 추론 피처를 계산하는 실시간 서비스와 다른 로직을 사용하는 경우
2. 데이터 누수 (Data leakage) — 학습 피처에 실수로 미래의 정보가 포함되는 경우 (예: 이벤트 발생 _이후_에 생성된 레이블(label)과 조인하는 경우)
3. 피처 신선도 저하 (Feature staleness) — 30일 이동 평균으로 학습된 모델에 파이프라인 백필(backfill) 지연으로 인해 6시간 전의 오래된 피처가 제공되는 경우

Databricks Feature Store — 현재 Unity Catalog의 일부인 Unity Catalog에서의 피처 엔지니어링 (Feature Engineering in Unity Catalog) — 는 다음과 같은 방식으로 이 세 가지 문제를 모두 해결합니다:

• 데이터와 함께 피처 계산 로직을 저장 (학습과 서빙 간의 드리프트(drift) 방지)
• 학습 데이터셋 생성 시 시점(point-in-time) 조회를 강제함
• 배치 오프라인 읽기(batch offline reads)와 저지연 온라인 읽기(low-latency online reads) 모두를 위한 통합 API 제공

아키텍처 개요 (Architecture Overview)

피처 스토어 (Feature Store) 개념: ERD

피처 스토어 (Feature Store) 뒤에 있는 데이터 모델을 이해하는 것은 올바른 파이프라인 (Pipeline)을 설계하는 데 필수적입니다. 엔티티 (Entity) 간의 관계는 다음과 같습니다:

핵심적인 관계: **모델 버전 (Model Version)**은 **훈련 세트 (Training Set)**와 결합되며, 이는 정확히 어떤 피처 테이블 (Feature Table)과 어떤 시점 조회 (Point-in-time lookup)가 사용되었는지를 기록합니다. 이것이 Databricks가 재현성 (Reproducibility)을 보장하는 방식입니다. 즉, 어떤 모델 버전이라도 생성했던 정확한 훈련 데이터를 언제든지 다시 생성할 수 있습니다.

환경 설정 (Environment Setup)

# Databricks Runtime ML 13.x+ 권장
# Unity Catalog (이전의 Feature Store)에서의 피처 엔지니어링 (Feature Engineering)

...

스트리밍 피처 파이프라인 (Streaming Feature Pipeline)

스트리밍 파이프라인은 Kafka로부터 데이터를 읽고, Spark의 상태 저장 스트리밍 엔진 (Stateful streaming engine)을 사용하여 윈도우 집계 (Windowed aggregations)를 계산하며, foreachBatch를 통해 피처를 피처 스토어 (Feature Store)에 기록합니다. 이를 통해 피처 테이블을 지속적으로 최신 상태로 유지할 수 있습니다.

# ── 스트리밍 피처 파이프라인 (Streaming Feature Pipeline) ───────────────────────────

# 1단계: Kafka로부터 원시 이벤트 스키마 (Raw event schema) 정의
...

시점 정확성(Point-in-Time Correct)을 갖춘 훈련 데이터셋 생성

이것은 피처 스토어 (Feature Store)에서 가장 중요한 부분입니다. 훈련 데이터를 생성할 때, 레이블 (Label)을 피처 (Feature)와 조인 (Join)해야 하는데, 이때 현재 시간이 아니라 반드시 레이블 이벤트의 타임스탬프 (Timestamp of the label event) 시점에 조인해야 합니다. 이는 데이터 누수 (Data leakage)를 방지합니다.

# ── 시점 정확성을 갖춘 훈련 데이터셋 (Point-in-Time Correct Training Dataset) ──────────

# 1단계: 레이블 데이터셋 (Label dataset) 로드
...

온라인 스토어 (Online Store)에 피처 쓰기

실시간 추론 (Real-time inference)을 위해 모델은 밀리초 (Milliseconds) 단위의 피처가 필요합니다. Delta Lake를 쿼리하는 데 걸리는 초 단위의 시간으로는 부족합니다. Databricks Feature Store는 저지연 읽기 (Low-latency reads)를 위해 피처를 온라인 스토어 (Online store) (DynamoDB, Cosmos DB, MySQL 등)에 게시할 수 있습니다.

── 피처를 온라인 스토어 (Online Store)에 게시 ─────────────────────────────────────────

온라인 스토어는 피처 테이블(feature table)별로 구성됩니다.

여기서는 5ms 미만의 조회를 위해 user_activity_features를 DynamoDB에 게시합니다.

...

추론 시점 (Inference Time)에서의 피처 서빙 (Serving Features)

추론 시점 (Inference time)에 Feature Store SDK는 자동 피처 조회 (feature lookups)를 수행하며, 들어오는 요청 데이터와 온라인 스토어의 피처를 조인 (join)한 후 이를 모델에 전달합니다.

# ── 추론 시점의 실시간 피처 서빙 (Real-Time Feature Serving) ────────────────────────────────────

import requests, json
...

피처 테이블 참조 (Feature Table Reference)

우리 파이프라인에 포함된 피처 테이블의 요약, 업데이트 주기, 그리고 ML 생명주기 (ML lifecycle)에서의 역할은 다음과 같습니다:

피처 테이블 (Feature Table)	기본 키 (Primary Key)	타임스탬프 키 (Timestamp Key)	업데이트 방법 (Update Method)	지연 시간 (Latency)	사용처 (Used In)
user_activity_features	user_id	feature_ts	Spark Structured Streaming	~5분	실시간 이탈 예측 (churn), 추천 (recommendation)
...

신선도(Freshness)와 비용 간의 트레이드오프 (tradeoff): 스트리밍 피처 (Streaming features)를 계산하는 비용은 배치 피처 (batch features)보다 약 10배 더 비쌉니다 (지속 실행 클러스터 vs 예약된 작업). 모델의 성능이 오래된 데이터(stale data)로 인해 유의미하게 저하되는 경우에만 피처를 스트리밍으로 전환하십시오. 이를 위해 먼저 오프라인 절제 연구 (offline ablation study)를 통해 검증해야 합니다.

핵심 요약 (Key Takeaways)

• **Training-serving skew (학습-서빙 왜곡)**는 운영 중인 ML의 소리 없는 살인자입니다. Feature Store는 피처 계산 로직을 한 번만 인코딩하여 학습(training)과 서빙(serving) 경로 모두에서 사용함으로써 이를 제거합니다.
• timestamp_lookup_key를 통한 **Point-in-time correct joins (시점별 정확한 조인)**는 시계열 데이터로 학습된 모든 모델에 있어 타협할 수 없는 필수 요소입니다. 레이블(label) 테이블에 event_timestamp가 누락되는 것은 데이터 누수(data leakage) 버그가 발생하기를 기다리는 것과 같습니다.
• fe.log_model()은 올바른 모델 로깅 호출 방식이며, mlflow.sklearn.log_model()이 아닙니다. 이는 피처 리니지(feature lineage)를 기록하여 재현 가능한 재학습(re-training)과 서빙 시점의 자동 피처 조회를 가능하게 합니다.
• Structured Streaming의 **Watermarks (워터마크)**는 상태 저장 집계(stateful aggregations)에 있어 매우 중요합니다. 워터마크가 없으면 Spark는 상태를 무기한 축적하며, 결국 작업이 OOM(Out of Memory) 오류로 중단됩니다. 허용 가능한 최대 지연 데이터(late-data) 윈도우로 설정하십시오.
• **Online stores (온라인 스토어)**는 SLA가 약 100ms 미만일 때만 운영 비용을 들일 가치가 있습니다. 배치 스코어링(batch scoring) 작업이나 500ms 이상의 예산이 있는 API의 경우, 오프라인 Delta 테이블에서 직접 읽으십시오.
• **fe.score_batch()**는 주기적인 배치 추론(batch inference)을 실행하는 가장 깔끔한 방법입니다. 이는 PIT(Point-in-time) 피처 조회를 자동으로 처리하고, 추론 로직을 DRY(Don't Repeat Yourself)하게 유지하며, 결과를 Delta에 기록하여 다운스트림 소비자에게 전달합니다.

References (참고 문헌)

1. Databricks — Feature Engineering in Unity Catalog (Overview)
   🔗 [https://docs.databricks.com/en/machine-learning/feature-store/uc/feature-tables-uc.html](https://docs.databricks.com/en/machine-l