🔵

ba2.4.1. title: 피처 저장소(‣)는 모델에 입력될 수 있는 형태의 전처리 결과물 등을 재활용할 수 있도록 만들어둔 저장소이다.

생성

🚀 prev note

♻️ prev note

ba2.5.2.2. title: 모델 학습을 위한 데이터 전처리와 서빙되는 모델을 위한 데이터 전처리 파이프라인이 다르다는 문제가 있다. 이를 학습-서빙 왜곡이라고 한다. 전처리를 독립시켜 두는 방법, 모델에게 책임을 전가하여 전처리 파이프라인을 모델에 묶는 방법, 데이터에게 책임을 전가하여 전처리가 모두 완료된 데이터를 보장하는 방법이 있다.

🚀 next note

♻️ next note

ba2.4_1.2.1. title: 머신러닝에서 온라인 작업은 실시간 추론 작업이고, 모델 학습이나 배치 처리는 오프라인 작업이다. 두 특징 저장소(‣)로 분리된 것은 레이턴시 요구사항 때문이다.

ba2.4_1.3. title: 데이터 웨어하우스(‣)와 피처 저장소(‣)는 가공된 데이터를 머신러닝 모델에 사용할 것인지, 의사결정에 사용할 것인지로 나뉜다. 사람을 기준으로 데이터 웨어하우스가 고수준이다.

14 more properties

피처 저장소(‣ Feature Store)는 모델에 입력될 수 있는 형태의 전처리 결과물 등을 재활용할 수 있도록 만들어둔 저장소이다(참고4).

그림(참고5): 피처 저장소에서 의미하는 ‘피처’ 가 무엇인가

예를 들어 원시 데이터로부터 (1)우버를 호출할 것으로 예상되는 고객의 위치, (2)그 당시 근처 우버 운전자의 위치, (3)고객과 우버 운전자의 매칭 여부가 10분간 1분 단위로 상대적 위치를 계산한 10차원 데이터(x)와 정답값(y)로 변환된 후 미켈란젤로의 피처 저장소에 자동으로 적재되는 ETL 파이프라인이 있다고 생각해 보자. 데이터 과학자들은 모델을 학습시키고자 할 때 전처리에 대한 큰 고민 없이 피처 저장소에 잘 정제된 데이터를 꺼내서 사용하기만 하면 될 것이다.

피처 저장소를 사용하면 데이터 사이언티스트와 데이터 엔지니어의 업무가 잘 분리되어 각자의 일에 더욱 집중할 수 있고, 특정 프로젝트에 의존되지 않을 수 있다는 장점이 있다(참고2,3). 피처 저장소에 데이터를 쌓아 주는 쪽은 데이터 엔지니어, 피처 저장소에 들어있는 데이터를 적극적으로 이용하는 쪽은 데이터 사이언티스트에 가깝다.

그림 (참고1)

parse me : 언젠가 이 글에 쓰이면 좋을 것 같은 재료들.

chapter5, Heavily related to KaizenML, i.e., continuously improving machine learning, is the concept of a Feature Store.

우버(uber)에서는 2017년부터 자체 머신러닝 플랫폼 Michelangelo 에 Palette라는 feature store를 개발, 현재 만개 이상의 feature를 저장하며 사내 많은 data scientist들이 공유할 수 있는 환경을 구축하였습니다. 그 외에도 Goject/Google의 Feast, Logical Clocks 의 Hopsworks 그리고 Netflix의 Mefaflow 등 다양항 형태의 feature store가 개발되고 활용이 되고 있습니다.

The real utility of a feature store shines when we need to have up-to-date features for an entity that we continually generate predictions for. For example, a user's behavior (clicks, purchases, etc.) on an e-commerce platform or the deliveries a food runner recently made today, etc. 

Q. Does it make sense to have a feature store for pure image classification/segmentation models? A. If you are doing pure image classification/segmentation, I would say no. Q. What features should be stored in the feature store? Output of convolution layers? but then they cannot be reused during the training since during training these will be rebuild by the convolution layers. A. I would not store the output of convolution layers, noramlly. In principle, the output of models can be stored in the feature store, however 

from : 과거의 어떤 생각이 이 생각을 만들었는가?

•

피처 스토어는 메모이제이션 패턴과 연관이 있다고 생각할수도 있다. 앞선 글에서 설명하는대로 TF-IDF행렬이 미리 만들어서 피처 스토어에 저장되어 있다면 이것을 그냥 불러와 사용하기만 될 것이다.

supplementary : 어떤 새로운 생각이 이 문서에 작성된 생각을 뒷받침하는가?

ba2.5.2.2. title: 모델 학습을 위한 데이터 전처리와 서빙되는 모델을 위한 데이터 전처리 파이프라인이 다르다는 문제가 있다. 이를 학습-서빙 왜곡이라고 한다. 전처리를 독립시켜 두는 방법, 모델에게 책임을 전가하여 전처리 파이프라인을 모델에 묶는 방법, 데이터에게 책임을 전가하여 전처리가 모두 완료된 데이터를 보장하는 방법이 있다.

opposite : 어떤 새로운 생각이 이 문서에 작성된 생각과 대조되는가?

None

to : 이 문서에 작성된 생각이 어떤 생각으로 발전되고 이어지는가?

ba2.4_1.2.1. title:
머신러닝에서 온라인 작업은 실시간 추론 작업이고, 모델 학습이나 배치 처리는 오프라인 작업이다. 두 특징 저장소(‣)로 분리된 것은 레이턴시 요구사항 때문이다.

ba2.4_1.3. title:
데이터 웨어하우스(‣)와 피처 저장소(‣)는 가공된 데이터를 머신러닝 모델에 사용할 것인지, 의사결정에 사용할 것인지로 나뉜다. 사람을 기준으로 데이터 웨어하우스가 고수준이다.

참고 : 레퍼런스

Figure 2: Data preparation pipelines push data into the Feature Store tables and training data repositories.

데이터 엔지니어: Hadoop, SQL, 프로그래밍 등 대량의 데이터에서 필요한 부분을 추출하는 능력(ETL)이 발달된 유형. 보통 개발에 집중된 유형이다 보니 데이터분석이나 머신러닝 분야의 능력을 기대하지 않았음. 데이터 사이언티스트: 머신러닝, 파이썬, 통계 등의 다양한 방법을 활용해 대량의 데이터에서 인사이트를 뽑아낼 수 있는 유형. 데이터를 다루는 스킬과 데이터를 분석해 의미를 도출하는 스킬에 능한, 다양한 업무를 담당할 수 있는 사람.

머신러닝 분야에서 feature란 계량할 수 있는 현상의 특성이나 성질을 의미합니다. 센서로 부터 얻은 측정값에서 부터 social media 데이터를 분석하여 추출한 통계값에 이르기까지 다양한 유형의 feature가 존재합니다. … Feature store는 data engineer와 data scientist의 업무를 매개해주는 중앙 창고로 볼 수 있습니다. 과거에는 모델 개발자가 원시 데이터에서 feature를 추출하는 업무에서 부터 모델 학습, 배포의 업무까지 구분없이 모두 수행하곤 했습니다.

In addition, we added a layer of data management, a feature store that allows teams to share, discover, and use a highly curated set of features for their machine learning problems.

in ML, a feature is data used as an input signal to a predictive model. For example, if a credit card company is trying to predict whether a transaction is fraudulent, a useful feature might be whether the transaction is happening in a foreign country, or how the size of this transaction compares to the customer’s typical transaction. When we refer to a feature, we’re usually referring to the concept of that signal (e.g. “transaction_in_foreign_country”), not a specific value of the feature (e.g. not “transaction #1364 was in a foreign country”).