6.6. Feature Store

※ 이 포스트는 머신러닝 디자인 패턴을 기반으로 작성되었습니다.

 

Feature store

Feature store는 말 그대로 feature를 저장하는 공간이다. 여기서 feature란 개별적으로 측정가능한 특성을 의미하며, 효율적인 ML 알고리즘을 만들기 위해 중요한 요소이다. Feature는 raw data로부터 feature engineering을 통해 얻어지며, 일관된 방식으로 계산되도록 ML엔지니어보다는 도메인 지식을 가진 사람이 제어하는 것이 좋다. 프로젝트의 규모가 커지고 데이터가 많아질수록 ad-hoc 방식에는 한계가 생긴다. 이러한 한계점을 해결하기 위해 feature store를 사용하며, feature engineering을 feature사용(모델링)에서 분리하여, feature 개발 및 생성이 모델 개발에서 feature를 사용하는 것과 독립적이게 된다. 

ah-hoc 방식의 한계

- 쉽게 재사용되지 못한다.

- 각 ML프로젝트가 민감한 데이터의 특징을 다르게 계산하면 데이터 거버넌스 측면에서 문제가 생길 수 있다.

  (데이터 거버넌스란 데이터의 정확성, 가용성, 보안 등을 보장하기 위해 정해진 정책을 의미한다.)

- feature가 팀이나 프로젝트간에 쉽게 공유되지 않는다. 이럴 경우, 각 팀마다 동일한 원본 데이터에 대해 다르게 feature를 정의할 수 있으며 불필요한 중복작업으로 이어질 수 있다.

- feature의 일관성을 보장하지 못한다. 학습용 파이프라인과 서빙 파이프라인이 완전히 동일하지 않다면(라이브러리, 전처리 코드, 언어 등이 다르다면) 학습이 편향되어 제공될 위험이 있다.

- 학습과 동일한 feature를 production환경에서 사용하기 어렵다. 온라인 서빙과 오프라인 모델 학습을 동시에 지원하는 표준화된 프레임워크가 없다.

 

구조

일반적인 featue store는 두 가지 주요한 디자인 특성에 의해서 구축된다. 첫째는 큰 데이터셋을 빠르게 처리하기 위한 도구로써의 측면, 둘째는 특징을 어떤 목적으로 사용할 것인지에 대한 측면이다. 추론에 사용한다면 짧은 지연 시간 액세스를 지원하는 방식, 모델 학습용으로는 대규모 일괄 액세스를 지원하는 방식을 선택하는 것이다. 

일반적인 데이터나 ML 엔지니어의 워크플로우는 다음과 같다. 원본데이터를 읽는다 → 데이터 처리 프레임워크를 사용하여 다양한 데이터 변환 → 변환된 특징을 특징 저장소에 저장.

전체 워크플로우를 이미지로 보면 위의 이미지와 같다. 각 단계별로 사용되는 프레임워크를 보자.

먼저 전체적인 feature store를 구성할 때 사용되는 프레임워크는 Feast, Hopsworks Feature Store이다. 여기에 데이터 웨어하우스인 BigQuery, Snowflake, Redshfit등을 연결하거나, stream 데이터는 Kafka, Kinesis 등을 연결할 수 있다. 데이터를 가공하기 위해서 Apache Beam, Flink, Spark와 같은 프레임워크를 이용한다. 이렇게 추출된 feature는 feature store에 저장되는데 이 store로 사용되는 것이 온라인을 위한 것은 Cassandra, Redis이고, 대규모 배치는 Hive, BigQuery이다. 

 

다양한 feature store 프레임워크는 아래 링크에서 확인할 수 있다. 비교까지 할 수 있게 되어있어서 참고하기 좋을 듯.

Feature Store Comparison