Skip to main content
원문: How Databricks Feature Store serves features with sub-second freshness 저자: Ian Ackerman, Nick Joung, Abhay Bothra 게시일: 2026년 8월 17일

​
요약

  • Databricks Feature Store가 ML 피처에 실시간 신선도를 제공합니다. Kafka로부터의 스트리밍 집계가 이제 200ms p99 지연으로 온라인 피처 스토어에 도달하여, 피처 지연을 몇 분·몇 시간에서 밀리초로 압축합니다.
  • Spark Real-Time Mode(RTM)가 밀리초 단위 피처 계산을 가능하게 합니다. RTM은 마이크로배치를 기다리는 대신 행을 지속적으로 처리하고, 이벤트마다 롤링 윈도우 집계를 갱신하며, 체크포인팅 비용을 분할 상환하여 상태 저장 스트리밍 지연을 낮게 유지합니다.
  • Lakebase가 고처리량 온라인 피처 쓰기를 가능하게 합니다. 컴퓨트와 스토리지 계층의 분리는 빈번한 소규모 업서트(upsert)에 대한 쓰기 증폭(write amplification)을 줄여, 저지연 모델 추론을 위해 신선한 피처 값을 빠르게 사용할 수 있게 합니다.
머신러닝 모델은 자신이 받는 신호(signal)만큼만 우수합니다. 사기 탐지 유스케이스는 사용자가 구매를 누르는 순간 밀리초 안에 거래를 허용할지 결정해야 합니다. 올바른 판단을 내리는 것은 불과 몇 초 전에 발생한 의심스러운 거래를 볼 수 있는지에 달려 있습니다. 사용자의 지난 30일간 평균 거래를 지난 10분간의 총 거래 금액과 결합하면 잠재적 사기가 부각됩니다. 장기 집계는 무엇이 정상인지 판단하기 위한 사용자의 기준 프로필(baseline profile)을 설정하고, 가장 최근 데이터는 이상 행동이 발생하는 바로 그 순간에 이를 드러내는 데 도움을 줍니다. 개인화(personalization)도 같은 압박에 직면합니다. 가장 신선한 신호가 사용자의 현재 의도를 포착하고 참여를 이끕니다. Spark 파이프라인은 과거 기준 피처(historic baseline feature)를 위해 레이크하우스에서 대량 데이터를 처리하는 확립된 방법입니다. 이러한 배치 잡을 정기적인 스케줄로 실행하는 것은 잘 이해되어 있지만, 몇 분에서 몇 시간의 지연을 도입합니다. 사용자에 대한 기준 신호의 경우, 이 지연은 더 단순한 인프라를 위해 치를 만한 대가입니다. 하지만 모델이 신선한 신호를 요구할 때는 이 인프라가 무너집니다. 기존 피처 스토어 플랫폼에서는 초 또는 밀리초 단위로 내려가는 것이 불가능합니다. 신선한 피처의 가치를 제공하기 위해, 데이터 사이언티스트는 이러한 집계를 처리하는 복잡한 스트리밍 전용 로직을 구현하고 맞춤형 호스팅 인프라를 세워야만 합니다. Databricks Feature Store는 피처를 한 번 정의하면 어디서나 사용할 수 있게 합니다. 동일한 정의가 오프라인의 대규모 배치 흐름과 온라인의 고신선도 피처 파이프라인을 모두 구동합니다. 이 프레임워크는 인프라 부담을 제거하며, 지속적인 스트림 처리를 위한 Spark Real-Time Mode(RTM), 스트리밍에 최적화된 온라인 스토리지를 위한 Lakebase, 대규모 조회를 위한 Model Serving을 오케스트레이션합니다. 그리고 한번 정의된 피처는 밀리초 단위로 서빙됩니다. Kafka에 이벤트가 도착하는 시점부터 온라인 피처 스토어에서 사용 가능해지는 시점까지 엔드투엔드 p99 지연이 200ms입니다.

​
아키텍처: 200ms 만에 Kafka에서 Feature Store로

Kafka에서 Feature Store까지의 아키텍처 Databricks Feature Store가 인프라에 구애받지 않는 Feature 정의를 어떻게 받아들여 이를 밀리초 안에 일관되게 계산하는 파이프라인을 구축하는지 내부를 살펴보겠습니다. 스트리밍 피처의 엔드투엔드 경로는 다음과 같습니다.
  • 이벤트가 Kafka에 도착합니다 — 신용카드 거래, 광고 노출, 클릭스트림 이벤트 같은 원시 데이터입니다.
  • Serverless Lakeflow Spark Delta Pipelines 위의 Spark RTM 파이프라인이 이벤트를 지속적으로 처리하며 롤링 집계를 실시간으로 계산합니다.
  • 갱신된 집계는 새로운 스트리밍 JDBC 싱크(sink)를 통해 Lakebase에 기록되어 온라인 피처 스토어에 도착합니다.
  • Model Serving 엔드포인트가 추론 시점에 Lakebase에서 최신 피처를 조회하여 모델에 자동으로 공급합니다.
이를 우리의 사기 피처, 즉 지난 10분간 사용자 거래 금액의 합계에 연결해 봅시다. 들어오는 각 이벤트는 거래 세부사항(금액, 위치, 사용자 ID, 가맹점 정보)을 담고 상태 저장(stateful) 파이프라인으로 라우팅됩니다. 파이프라인은 사용자의 누적 거래 총액을 보관하는 로컬 RocksDB 인스턴스를 참조하며, 만료 시각(expiry time)을 통해 윈도우를 지난 10분으로 유지합니다. 파이프라인은 로컬에서 값을 읽고 증가시킨 다음, 갱신된 피처 값을 Lakebase에 기록합니다. 그래서 새 거래를 승인하기 위한 쿼리가 모델에 도착하면, 최신 거래 합계가 피처 스토어에서 서브초 신선도로 제공됩니다. 이 합계 피처는 승인 판단을 위해 사용자의 과거 구매 기준(baseline)과 함께 페칭됩니다. 과거 기준을 훨씬 웃도는 합계는 모델에게 잠재적 사기를 나타내는 강력한 지표입니다. 이 파이프라인의 각 구성 요소는 들어오는 이벤트가 라우팅되고, 집계가 계산되며, 피처가 가능한 한 빠르게 온라인 스토어에 기록되도록 최적화되어 있습니다.

​
롤링 윈도우: 집계를 밀리초 안에 갱신하기

롤링 윈도우 집계 인프라를 더 깊이 들여다보기 전에, 집계 피처와 배치 동기화 패러다임에서 실시간 갱신으로의 전환에 대해 이야기해 봅시다. 시간 윈도우에 걸친 집계 피처 — 예를 들어 카운트, 합계, 평균 — 는 실시간 ML을 위한 강력하고 유연한 신호입니다. 장기 배치 피처는 일정 기간에 걸쳐 사용자에 대한 과거 기준을 설정하여 모델이 각 사용자의 행동을 적응하고 이해하게 합니다. 짧고 신선한 피처는 변화하는 상황에 빠르게 반응하여 새로운 사용자 관심이나 사기 활동을 구별합니다. 시간 윈도우는 시간 범위(예: 10분)와 함께 그 시간 범위가 시간에 따라 어떻게 진화해야 하는지(예: 겹침 또는 분리)를 정의합니다. Databricks Feature Store는 세 가지 서로 다른 시간 윈도우를 지원합니다.
  • **텀블링 윈도우(Tumbling windows)**는 벽시계 시각(wall-clock) 간격에 정렬되며, 직전 간격이 끝나는 즉시 시작됩니다. 10분 텀블링 윈도우는 12:00–12:10을 다룬 다음 12:10–12:20을 다룰 수 있습니다. 이벤트는 이러한 고정된 간격으로 묶이며, 피처 값은 간격의 끝에 방출됩니다. 이는 집계가 간격 경계에서만 신선하다는 것을 의미합니다.
  • 슬라이딩 윈도우(Sliding windows) 역시 벽시계 시각 간격에 정렬되지만 간격의 겹침을 허용합니다. 슬라이드 간격이 5분인 10분 슬라이딩 윈도우는 12:00–12:10, 그다음 12:05–12:15, 그다음 12:10–12:20을 다룰 수 있습니다.
  • **롤링 윈도우(Rolling windows)**는 벽시계 시각에 정렬되지 않고, 밀리초 해상도로 각 이벤트의 타임스탬프에서 뒤를 돌아봅니다. “현재 벽시계 시각 기준 지난 10분간의 거래 합계”는 윈도우가 새 이벤트마다 이동하기 때문에 항상 최신입니다. 이는 “지금(now)“이 항상 변하는 실시간 서빙에 RollingWindow를 자연스러운 선택으로 만듭니다.
텀블링 윈도우와 슬라이딩 윈도우는 피처가 자주 변하지 않을 때 여전히 유용합니다. 이들은 더 적은 업데이트를 방출하고, 유지 비용이 저렴하며, 더 단순한 스케줄 기반 파이프라인에 자연스럽게 맞습니다. 롤링 윈도우는 그러한 효율성을 최대 신선도와 맞바꾸며, 이는 모든 새 이벤트가 모델에 서빙되는 값에 즉시 영향을 주어야 하는 신호에 가장 가치가 있습니다. Feature Store 선언형(declarative) API로 롤링 윈도우 피처를 정의하는 것이 얼마나 간단한지 다음과 같습니다.

​
Spark Real-Time Mode: 피처 계산을 위한 엔진

기저 인프라로 들어가면, 스트리밍 파이프라인이 높은 처리량에서 신선한 피처를 가능하게 하는 요소입니다. 이 파이프라인은 데이터를 Kafka에서 온라인 피처 스토어까지 전달합니다. 스트리밍 파이프라인은 Spark Structured Streaming의 근본적으로 새로운 실행 모드인 Spark Real-Time Mode(RTM)로 구동됩니다. RTM은 밀리초 신선도를 가능하게 하는 핵심 아키텍처 혁신입니다.

​
동시 스테이지와 상태 저장 처리

전통적인 마이크로배치 모드(MBM)에서 Spark는 스트리밍 데이터를 개별 배치로 처리합니다. 각 배치는 구성 가능한 간격 동안 이벤트를 수집하고, 이를 각 스테이지를 통해 순차적으로 처리하며, 체크포인트를 찍은 뒤 다음 배치를 시작합니다. 이는 지연에 하한선을 만듭니다. 공격적으로 튜닝하더라도 상태 저장 집계를 위한 MBM 파이프라인은 일반적으로 초에서 분 단위로 동작합니다. 반면 RTM은 스테이지를 동시에(concurrently) 실행합니다. 집계 연산자는 상위 스테이지가 모든 행 처리를 끝내기를 기다리지 않고, 행이 사용 가능해지는 순간 즉시(eagerly) 처리합니다. 롤링 집계에는 두 가지 중요한 스테이지가 있습니다. 첫 번째 스테이지는 데이터 처리, 스키마 검증, 데이터 병합(coalescing), 타입 캐스팅입니다. 이는 일반적인 액션 이벤트를 피처 집계에 맞는 형태로 변환하는 비즈니스 로직을 실행합니다. 두 번째 스테이지는 롤링 윈도우 집계를 계산하기 위해 엔티티별로 데이터를 집계하는 것입니다. 들어오는 각 행은 로컬 RocksDB 상태 저장소(state store)의 집계 값을 즉시 갱신하고 새 값을 하위로 방출합니다. 윈도우 만료도 행 단위로 일어납니다. 주어진 이벤트에 대해 윈도우 기간이 경과하면, 파이프라인은 그 이벤트의 기여분을 제거하고 보정된 집계를 Lakebase에 방출합니다. RocksDB는 각 실행기(executor)에서 로컬로 실행되어, 클러스터의 메모리 용량을 초과하는 상태 크기를 허용합니다.

​
서버리스 RTM의 파이프라인 상태 관리

체크포인팅은 상태 저장 스트리밍의 내결함성(fault tolerance)에 필수적이며, 개별 파이프라인 워커가 실패하더라도 파이프라인이 복구할 수 있게 합니다. 하지만 체크포인팅에는 비용이 있습니다. 마이크로배치 모드에서 Spark는 모든 배치 경계에서 체크포인트를 찍고, 각 체크포인트는 클라우드 오브젝트 스토어와 상호작용하기 때문에 파이프라인에 지연을 더합니다. RTM은 다른 접근을 취합니다. 플래닝과 체크포인팅의 비용이 더 긴 간격에 걸쳐 분할 상환(amortize)됩니다. 체크포인팅의 비용은 각 배치 경계에서 파이프라인을 막는 대신 그 간격 동안 처리된 모든 행에 걸쳐 분산됩니다. 이는 내결함성을 희생하지 않습니다. 정확히 한 번(exactly-once) 처리 보장이 유지됩니다. 실패 시 파이프라인은 Kafka 소스에서 최대 5분 분량의 데이터를 재생(replay)합니다. 그 트레이드오프는 재생 볼륨의 소폭 증가 대가로 정상 상태(steady-state) 처리 지연을 크게 줄이는 것입니다. Feature Store는 서버리스 RTM 파이프라인을 Lakeflow Spark Delta Pipelines(SDP) 위에서 실행하여 클러스터 관리와 용량 계획을 완전히 없앱니다. 머신을 프로비저닝하거나, 실행기 수를 튜닝하거나, 클러스터 유지보수를 걱정할 필요가 없습니다. 인프라 업데이트가 파이프라인 재시작을 요구할 때, SDP는 핸드오프를 조율합니다. 이전 클러스터가 중지되기 전에 새 서버리스 클러스터가 프로비저닝되고 완전히 준비됩니다. 이 조율은 5분 체크포인팅 간격에 동기화되어 다운타임을 최소화하고 재처리 공백을 방지합니다. 그 결과 유지보수 기간 동안 피처 신선도에 거의 제로에 가까운 중단만 발생합니다.

​
Lakebase: 스트리밍 쓰기의 오버헤드 최소화

Databricks Feature Store는 추론용 온라인 피처 값을 저장하는 데 Lakebase를 사용합니다. 컴퓨트와 스토리지를 분리하는 Lakebase 아키텍처는 모델 추론의 가변 부하를 처리하기 위한 오토스케일링을 가능하게 합니다. 온라인 피처 스토어는 이 역량을 활용하여 초당 수만 건의 읽기를 수십 ms의 지연으로 처리하도록 확장합니다. 스트리밍 쓰기는 특히 까다로운데, Kafka 행을 받을 때마다 신선한 롤링 윈도우 값이 방출되면서 다수의 소규모 업서트로 구성되기 때문입니다. 표준 Postgres에서 이 패턴은 대량의 WAL(write-ahead log) 볼륨을 생성할 수 있는데, Postgres가 더 쉬운 복구를 위해 전체 페이지 쓰기(full page write)를 사용하기 때문입니다. 각 체크포인트 이후, 페이지에 대한 첫 수정은 작은 논리적 변경만이 아니라 전체 8KB 페이지 이미지를 WAL에 기록합니다. 자주 갱신되는 핫 엔티티 행의 경우, 이는 WAL 증폭을 쓰기 처리량, 복제, 복구 오버헤드의 병목으로 만듭니다. Lakebase는 이제 컴퓨트와 분산 스토리지의 분리를 활용하여 표준 Postgres 대비 스트리밍 쓰기 증폭을 최소화합니다. Lakebase 아키텍처는 Postgres가 전체 8KB 페이지 스냅샷을 반복적으로 WAL에 기록하는 대신 작고 압축된 변경 레코드를 기록하게 합니다. 그 압축된 레코드가 분산 safekeeper 노드의 정족수(quorum)에 의해 승인되기 때문에 내구성은 여전히 보호됩니다. 충분한 변경 레코드가 쌓인 후에는 복구를 위해 전체 페이지 스냅샷이 여전히 필요하지만, 그것은 쓰기 경로를 부풀리지 않고 스토리지 계층에서 나중에 생성됩니다. Feature Store의 경우, 그 결과 RTM은 훨씬 적은 WAL 증폭과 최소한의 추가 지연으로 신선한 피처 값을 Lakebase에 지속적으로 게시할 수 있습니다.

​
Model Serving: 대규모에서의 저지연 피처 조회

여정의 마지막 구간은 Lakebase에서 신선한 피처를 조회하여 추론 시점에 모델에 전달하는 것입니다. 이는 고 QPS·저지연 워크로드에 최적화된 완전 관리형 서빙 인프라인 Databricks Model Serving이 담당합니다. Model Serving은 실시간 ML의 처리량 요구에 맞춰 만들어졌습니다.
  • 완전 수평 확장 가능한 아키텍처: 추론 서버, 인증 계층, 프록시, 레이트 리미터가 모두 독립적으로 확장되어 CPU 엔드포인트에서 100K+ QPS를 지속합니다.
  • 빠른 탄력적 확장: 시스템은 과잉 프로비저닝 없이 트래픽 급증과 감소에 적응하여, 비용을 실제 수요에 맞춥니다.
  • 모델 거버넌스 및 모니터링: AI Gateway를 사용하여 네트워크 접근을 관리하고, 모델 엔드포인트에 대한 권한을 관리하며, 품질을 모니터링합니다.
Feature Store의 경우 통합은 매끄럽습니다. 모델이 MLflow로 로깅될 때 그 피처 종속성이 기록됩니다. 추론 시점에 Model Serving은 필요한 피처를 Lakebase에서 자동으로 조회합니다 — 맞춤 조회 코드도, 수동 배관 작업도 없습니다. RTM이 계산하여 Lakebase에 저장한 신선한 집계가 조회되어 추론 요청과 투명하게 조인됩니다.

​
스트리밍을 넘어선 Feature Store

성능 좋은 실시간 역량은 Feature Store가 해결할 수 있는 것의 일부에 불과합니다. 다른 두 가지 과제도 간략히 짚어볼 가치가 있습니다.

​
스트림 피처를 위한 학습 데이터

스트리밍 피처의 경우, 스트림의 짧은 보존 윈도우가 별도의 오프라인 스토어 유지를 요구하기 때문에 학습 데이터 생성이 어려울 수 있습니다. Databricks Feature Store는 수집된 Kafka 데이터의 오프라인 복사본을 저장함으로써 이를 해결합니다. 모델 학습을 위해, Feature Store는 스트리밍 파이프라인이 계산할 것과 동일한 피처 값을 과거 값에 대해 계산하고 시점 정확(point-in-time accurate) 조인을 수행합니다. 이 동일한 역량은 온라인 스트리밍 피처를 백필(backfill)하여 프로덕션으로 빠르게 출시할 수 있게 하는 데도 사용됩니다.

​
통합

위에서 보았듯이 Feature Store는 여러 복잡한 인프라 구성 요소를 오케스트레이션합니다. 그러한 파편화는 거버넌스, 리니지(lineage), 피처 재사용을 어렵게 만들 수 있습니다. 또한 엔지니어가 시스템 경계를 넘어 변경 사항을 조율해야 하므로 개발을 늦춥니다. Databricks에서 Feature는 Unity Catalog의 일급 객체(first-class object)입니다 — 검색 가능하고, 접근 제어로 거버넌스되며, 전체 리니지로 추적됩니다. 피처 변환은 모델과 함께 패키징되고, MLflow는 어떤 피처가 사용되었는지 캡처하며, 배포 리니지는 모델을 그 피처 종속성에 연결합니다. 이 플랫폼은 여러분의 전체 ML 스택을 개발하고, 배포하고, 거버넌스하기 위한 원스톱 상점(one stop shop)입니다. Databricks Feature Store는 Spark RTM, Lakebase, Model Serving 같은 핵심 빌딩 블록을 오케스트레이션하여, 여러분이 인프라를 직접 관리하지 않고도 동급 최고의 지연과 확장성을 얻게 합니다. 이 각각의 시스템은 스트리밍 워크로드에 맞게 정교하게 최적화되어, 머신러닝 피처를 위한 200ms 신선도를 현실로 만듭니다. 스트리밍 피처를 정의하는 방법은 Streaming Pipeline 문서를 참고하세요. 기존 피처로 실험하여, ms 수준의 신선도가 있으면 그것이 얼마나 더 강한 신호를 제공할지 확인해 보세요. 기저 기술을 더 잘 이해하고 싶다면, 더 빠른 쓰기에 관한 Lakebase 블로그와 RTM 아키텍처 분석을 참고하세요. 이러한 종류의 문제를 다루고 싶다면, 저희는 채용 중입니다!