Feature store - Basic Architecture

hsh·2021년 9월 1일
1
post-thumbnail

Preliminaries

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

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 등 기능이 추가 되어야할 것이다.
profile
Machine Learning Engineer: recsys, mlops

0개의 댓글