이 글은 아래 글을 읽은 사람을 대상으로 쓰여졌습니다.

• 1편 : Feature Store - why?

1. 개요

• 모든 Feature store의 특성상 모든 feature store가 가지고 있는 핵심 개념들이 있다.
• 이 개념들은 각각의 feature store에서 명칭만 살짝식 다를 뿐 대부분 가지고 있는 개념이다.
• 이러한 개념들에 대해 알아보자.

2. Feature Key

• Feature를 저장한 후 사용하려면 feautre에 대한 key가 존재해야 한다.

• 이 Feature key를 사용자가 알아서 보관하는 것이 아닌 Feature store에서 관리해야 하는 걸까?

• Feature key가 존재해야 하는 이유는 Serving에 있다.

• 대규모의 데이터속에서 서빙환경의 요구사항인 특정 데이터를 빠르게 가져오기 위해서는 key-value 기반 nosql이 적절하다.

• 때문에 online store에서는 get 명령어를 제외하고 SQL과 같은 쿼리를 날리기는 힘들다.

• 모델이 production에서 서빙될 때에는 유저 id 1번에 대해서 feature가 필요하거나, 뉴스기사 id 1번에 대해서 feature가 필요할 것이다.

• 이때 어떤 key로 feature를 가져올지 알아야 feature store에 해당 key로 Online store에 데이터를 효율적으로 저장할 수 있다.

• 그래서 보통 feature store는 key를 feature마다 정해두고 서빙할 때 가져오게 된다.
  

• 이 feature key는 꼭 online store가 아니더라도 offline store에서도 충분히 쓰일 수 있다.

3. Feature group

• Feature group은 RDS로 비유 하자면 하나의 테이블 단위이다.
• 같은 Feature Key를 사용하는 데이터들을 저장하는 단위이다.
• Feature group은 feature key와 key에 해당하는 feature 값들이 저장되어야 한다.
• Feature group은 또한 feature에 대한 meta 정보들도 저장할 수 있는데, 예를 들어 feature 그룹의 생성시각, online store와의 sync 여부 등이 있다.

4. Event time

event time은 feature store라는 개념을 처음 접할 때 제일 헷갈리는 개념이다.
반드시 정확하게 알아두자.

• 설명을 위해 상황을 가정해보자
  • 광고 추천 시스템을 만드려고 하고 있음
  • User의 뷰티 광고 한달간 클릭 횟수를 Feature로 쓰려고 함
  • 이때에 Feautre Key는 user_id, Feature 값은 한달간 뷰티 광고 클릭 횟수가 된다.
• 유저의 과거 history를 기반으로 Feature를 만들어 냈다.
• 어제는 1번 클릭했지만 오늘은 3번 클릭했다면 오늘 시점에서 클릭 횟수가 변하기 때문에 어제와 오늘의 값이 다르기 때문이다.
• 즉 이 Feature는 시점마다 다른 Feature 값을 가지게 된다.
• Event time은 이 시점과 관련 있는 용어로, Feature를 쓸 수 있게된 시점을 뜻한다.
  • Event time은 Feature가 생성되어서 쓸 수 있게된 시점이다.
  • 학습 로그이 Time보다 Event time이 더 크다면, Training 시점에 Test 데이터를 보는 즉 Data Leakage가 일어난 것이다.

4-1 online vs offline

online store에는 가장 최근의 feature 값만, offline store에는 모든 시점(Event time) 에서의 데이터가 필요하다.

4-1-1 상황

• 아래 처럼 유저가 활동했다고 가정해보자
  

• 그럼 유저의 User의 뷰티 광고 한달간 클릭 횟수 Feature는 아래와 같이 변화 한다.
  

• 각 행동에서는 아래 처럼 시점 별로 Feature store에 Feature Value를 저장하게 된다.
  

4-1-2 Online store

• 이때 Serving 환경에서는 과거 이력이 필요 없다. 즉 Feature Store에서는 가장 최근에 만들어진 Feature Value만 가지고 있으면 된다.
  
• 매 시점에서 추천을 위해 Feature를 쓰려면 가장 최근의 Feature Value만 있으면 된다 필요하다.

• 즉 Online store 에서는 용량이 적은 nosql key value 스토어의 스펙을 생각해서 모든 데이터를 들고 있을 필요가 없다. 가장 최신의 데이터만 가지고 있으면 된다.
• 또한 Event time 즉 Feature가 생성된 시점별 데이터를 전부 다 Online 스토어에서 가지고 있어도 쓰는 사람 입장에서는 오히려 편의성이 떨어진다.
  • 서빙시 Get을 할 때 최신 데이터만 들고 있으면 User_id로만 key로 하여 get을 하면 된다.
  • 하지만 모든 시점 데이터가 있다면 key에 시점 정보도 넣어줘야 한다.
  • 문제는 어느 시점이 최신인지 서버에서 정보를 알아야 하기 때문에 오히려 쓰기 힘들어진다.

4-1-3 Offline Store

• offline store에서는 모든 시점의 데이터를 가지고 모델을 학습하게 된다.
• 따라서 offline store는 online store와 달리 모든 feature가 만들어진 시점에서의 feature 데이터를 가지고 있어야 한다.
• 그래야 데이터를 학습 시킬 때 모든 row에 대해 적절한 feature 값을 매핑 시킬 수 있기 때문이다.

5. point-in-time join

• point-in-time join 설명은 Feast에서도볼 수 있다.
• Offline Data를 Raw log와 Join해야 데이터의 Feature를 Raw data와 연결하여 학습을 할 수 있다.
• 이때 join 조건으로 단순히 Feature Key만 걸어주게 되면 미래에서 쓸 수 있는 Feature를 현재 쓰게 되는 Data Leak이 발생 할 수 있다.
  
• 그래서 시간 까지 생각해서 Join을 해줘야 하는데 그것이 point-in-time Join이다.
• 해당 시점에 Data Leak이 안 발생하며 쓸 수 있는 Feature 값중 가장 최신의 데이터를 쓸 수 있도록 Join 하는 것이다.
• 이 point-in-time join 은 기능을 제공해주는 Feature store도 있고 그냥 Event-time만 기록하게 하는 Feature store도 있다.
  • 하지만 기능을 제공해주더라도 Spark 등과 함께 쓰다 보면 직접 구현하는 것이 속편할 수 있고, 보통은 직접 이 Join을 구현하게 될 것 같다.
  • 기능을 제공하든 안 하든 개념 자체는 Feature store 유저에게 매우 중요하니 꼭 이해해두자.