Preliminaries

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

• 1편 : Feature Store - why?
• 2편 : Feature store 핵심 개념

0 개요

• 간단하게 Feature store의 스펙들을 생각해보며 구조를 맞춰 보자.
• 함께 심플하게 Feature store의 구조를 세워보고 나면 다른 Feature store 끼리의 비교가 쉬워질 것이라고 생각한다.
• 기존 Feature store를 파악 하고 원하는 구조가 아니라면, 자체 개발을 시작할 때 feature store 구조의 감을 잡는데 도움을 줄 수 있을 것이라고 생각한다..

1 데이터 베이스

• Feature store는 1편, 2편에서 얘기했던 것처럼 2개의 데이터 베이스가 필요하다.

• 첫번째로 배치처리에 뛰어나고 모든 시점의 데이터를 가지고 있어야할 대용량 Offline store.

• 두번째로는 latency가 매우 낮고, 최신의 데이터만 가지고 있을 streaming 데이터 처리에 뛰어난 online store

• 적절한 online store 후보는 다음과 같다.

  • Redis
  • Cassandra
  • latency가 매우 낮고 효율적이면 어떤 DB이든 상관 없다.

• 적절한 offline store는 다음과 같다.

  • AWS : S3 / Glue / Athena or Spark
  • google : Bigquery /
  • Hive
  • 대용량 데이터를 싸게 저장할 수 있고, 쿼리를 통해 배치 처리를 잘 지원하면 어떤 DB든 상관 없다.
    

2. put api

• store가 이제 Feature 데이터를 넣을 수 있게 하는 API도 있어야 한다.
• Feature store에 데이터를 넣는 API를 보통 Ingest, insert, put 등으로 부른다.
• offfline, online 양쪽에 전부 선택해서 넣을 수 있는 Feature sotre도 있고, 한쪽에만 넣을 수 있도록 하는 Feature store도 있다.
• 당연히 양쪽 다 넣을 수 있게 하는 feature store가 더 복잡하겠지...ㅜ
• 우리는 간단하게 offline store쪽에만 데이터를 넣을 수 있게하자.
  

Offline 스토어는 보통 hive 처럼 파일 기반으로 DB이기 때문에 아주 작은 단위의 데이터를 매우 높은 빈도로 쓰게 되면 성능 문제가 생긴다.

• 이런 문제 때문에 PUT API를 쓸 때에는 이런 점을 유의해야 하며 아주 작은 단위의 데이터를 매우 높은 빈도로 쓰기 위해서는 별도의 큐가 필요할 수도 있다.

3. Meta DB

• 현재 어떤 feature group들이 Feature store내부에 존재하고 있는지
  • (RDB를 예로 들면 Show tables)
• 각 feature group이 언제 만들어졌고 feature key가 어떻게 되는지
• 각 feature group의 feature 값 스키마나 타입이 어떻게 정의 되는지
• offline store의 어느 테이블에 존재하는지
• online store로 올릴 필요가 있는지 등 많은 메타 정보를 관리할 필요가 있다
• 따라서 메타를 관리할 간단한 RDS가 필요하다.
  

4. Create API

• RDS로 비유하면 일종의 create table과 같은 API 가 필요하다.
• 그래야 RDS에 관련 스키마를 기록하고 offline store에 table을 만들고 유저에게 feature group을 보여줄 수 있다.
  

5. Offline2online

• 이제 offline 데이터를 online으로 옮길 필요가 있다.
• 그래야 serving 모듈에서 쓸 수 있기 때문이다.

  자동으로 이 작업이 이뤄지는 feature store(aws)가 있기도 하고 유저가 직접 제어해야 하는 feature store(feast)도 있다.

• user가 직접 제어한다면 관련 API를 만들어야 하고 자동으로 돌아간다면 매분 또는 realtime으로 옮겨주는 작업이 필요한데, 현재 우리의 심플한 구조에서는 realtime으로 offline과 online의 동기화는 힘들 것 같다..

6. GET API

• Online 서빙을 위해서는 GET API가 필요하다
• GET API에 key관련 정보를 전해주면 관련 feature 값을 리턴해줘야 한다.
  

7. 합치면..?

• 아주 기본 기능만 나타내 보았다.
• 여기에 delete 기능 및 onlin2offline, offline GET, join 등 기능이 추가 되어야할 것이다.