블로그 이미지
평범하게 살고 싶은 월급쟁이 기술적인 토론 환영합니다.같이 이야기 하고 싶으시면 부담 말고 연락주세요:이메일-bwcho75골뱅이지메일 닷컴. 조대협


Archive»


 
 


Data Preprocessing in ML Pipeline


본글은 구글 클라우드 블로그에 포스팅한 글을, 재 포스팅 허가를 받은 후 포스팅한 글입니다.

다른 좋은 글들도 많으니 아래 출처 링크를 참고해 주새요

출처 링크


머신러닝 파이프라인에서, 데이터는 모델 학습 및 서빙의 입력에 알맞게 가공되어야 한다. 이를 전처리라고 하는데, 이번 글에서는 전처리에 대한 개념과 이에 대한 구현 옵션등에 대해서 알아보도록 한다.

처리 단계별 데이터 분류

머신러닝에서 데이터 전처리는 모델 학습에 사용되는 데이터 형태로 데이터를 가공하는 과정을 이야기한다.

데이터 전처리는 여러 단계로 이루어지는데, 단계별로 처리된 데이터에 대해서 다음과 같이 명명한다. 

Raw data

초기에 수집된 원본 데이터로 분석이나, 머신러닝 학습 용도로 전혀 전처리가 되지 않은 데이터를 의미한다.

하둡과 같은 데이터 레이크에 저장된 데이터나, 기본적인 처리를 통해서 테이블 구조로 데이터 레이크에 저장된 데이터가 Raw 데이터에 해당한다.

Prepared data

Prepared data는 Data engineering 전처리에 의해서, 학습을 위한 데이터만 추출한 서브셋 데이터를 의미한다. 예를 들어 서울 20대 사용자의 구매 패턴을 머신러닝 모델로 만들고자 할때, 서울 20대 사용자 데이터만 추출한 경우 이 데이터를 Prepared data라고 한다. 단순하게 서브셋만을 추출하는 것이 아니라, 깨끗한 상태의 데이터로 정재된 데이터인데, 정재의 의미는 비어 있는 행이나 열을 삭제한 데이터를 의미한다. 

Engineered feature

이렇게 정제된 데이터는 머신러닝 학습과 서빙에 적절한 형태로 재가공 되어야 하는데 이를 Feature Engineering 이라고 한다. 예를 들어 숫자와 같은 값을 0~1 사이로 맵핑 시키거나 , 카테고리 밸류 예를 들어 남자/여자를 0,1과 같은 값으로 맵핑 시키고, 전체 데이터를 학습,평가용으로 7:3 분할하여 저장하는 것이 이에 해당 한다. 



<그림. 데이터 전처리 단계 및 단계별 생성된 데이터 >

데이터 전처리 기법

그러면, 이 데이터 전처리 과정에서 구체적으로 어떤 기법으로 데이터를 처리할까? 몇가지 대표적인 기법을 정리해보면 다음과 같다. 

  • Data cleansing : 데이터에서 값이 잘못되거나 타입이 맞지 않는 행이나 열을 제거하는 작업을 한다. 

  • Instance selection & partitioning : 데이터를 학습,평가,테스트용 데이터로 나누는 작업을 한다. 단순히 나누는 작업 뿐만 아니라, 데이터를 샘플링 할때, 그 분포를 맞추는 작업을 병행한다. 예를 들어 서울/대구/부산의 선거 투표 데이타가 있을때, 인구 비율이 9:2:3이라고 할때, 전체 인구를 랜덤하게 샘플링해서 데이타를 추출하는 것이 아니라, 서울/대구/부산의 인구 비율에 따라서 서울에서 9, 대구에서 2, 부산에서 3의 비율로 샘플링을 할 수 있다. 이를 stratified partitioning 이라고 한다. 또는 데이터 분포상에서 특정 카테고리의 데이터 비율이 적을때, 이 카테고리에 대해서 샘플의 비율을 높이는 minority classed oversampling 등의 기법을 이 과정에서 사용한다. 

  • Feature tuning : 머신러닝 피처의 품질을 높이기 위해서 0~1값으로 값을 normalization 시키거나, missing value를 제거 하거나, 아웃라이어등을 제거하는 등의 과정을 수행한다.

  • Representation transformation : 피처를 숫자로 맵핑 시키는 작업을 한다. 카레고리컬 피처를 one hot encoding 등을 통해서 숫자로 맵핑하거나, 텍스트를 embedding 을 통해서 숫자로 변환하는 작업등을 수행한다. 

  • Feature extraction : PCA와 같은 차원 감소 기법을 이용하여, 전체 피처의 수를 줄이는 작업을 수행하거나, 피처를 해시값으로 변환하여, 더 효율적인 피쳐를 사용하는 작업을 한다. . 

  • Feature selection : 여러개의 피처(컬럼)중에 머신러닝에 사용할 피처만을 선별한다. 

  • Feature construction : 기존의 피처를 기반으로 polynomial expansion 이나,  feature crossing 등의 기법을 이용하여 새로운 피처를 만들어낸다. 

데이터 전처리 단위

Instance level transformation & Full pass transformation

데이터 전처리를 할때 어떤 단위로 데이터를 전처리 할지에 대한 정의이다. 예를 들어 숫자 데이터의 값을 0~1 사이로 맵핑하고자 하면, 그 데이터의 최소/최대 값을 알아야 0~1사이로 맵핑할 수가 있는데, 최소/최대값을 추출하려면, 전체 데이터에 대한 스캔이 필요하다. 반대로 NULL 값을 0으로 변환하는 작업은 전체 데이터에 대한 스캔이 필요없고 개별 데이터만 변환하면 된다. 앞에 설명한 전체 데이터에 대한 스캔이 필요한 방식을 full pass transformation 이라고 하고, 전체 데이터를 볼 필요 없이 개별 데이터에 대해 변환하는 작업을 instance level transformation이라고 한다. 


Window aggregation

전체 데이터의 볼륨이 클 경우 이를 윈도우 단위로 잘라서 처리할 수 있는 방법이 있는데, 예를 들어 10분 단위로 데이터를 처리해서, 10분 단위로 최소/최대 값을 구하거나 또는 10분 단위로 어떤 값의 평균값을 대표값으로 사용하는 것들이 이에 해당한다. 

일반적으로 입력값은 (entity, timestamp, value) 형태가 되며, 전처리된 출력 값은 다음과 같이. (entity, time_index, aggregated_value_over_time_window) 엔터티(피쳐)에 대해서 윈도우별로 처리된 값을 저장하는 형태가 된다.  보통 이런 window aggregation 방식은 리얼 타임 스트리밍 데이터에서 시간 윈도우 단위로 데이터를 처리하는 경우에 많이 사용이 되며, Apache Beam과 같은 스트리밍 프레임워크를 이용하여 구현한다. 

구글 클라우드에서 데이터 전처리 방식

이러한 데이터 전처리는 다양한 컴포넌트를 이용해서 처리할 수 있는데, 어떤 방식이 있는지 살펴보기 전에 먼저 구글 클라우드 기반의 머신러닝 학습 파이프라인 아키텍처를 살펴보자.  아래는 일반적인 구글 클라우드 기반의 머신러닝 파이프라인 아키텍처이다. 


<그림. 구글 클라우드 플랫폼 기반의 일반적인 머신러닝 학습 파이프라인 아키텍처 >


  1. 원본 데이터는 빅쿼리에 저장된다. (테이블 형태의 데이터가 아닌 이미지나 텍스트등은 클라우드 스토리지(GCS)에 저장된다.)

  2. 저장된 원본 데이터는 Dataflow를 이용해서 머신러닝 학습에 알맞은 형태로 전처리 된다. 학습/평가/테스트 셋으로 나누는 것을 포함해서, 가능하면 텐서플로우 파일형태인 *.tfrecord 형태로 인코딩 된후에, GCS 에 저장된다. 

  3. 텐서플로우등으로 모델을 개발한 후에, trainer-package로 패키징을 하고, AI Platform 트레이닝에 이 모델을 업로드 한다. 업로드된 모델을 앞서 전처리된 데이터를 이용해서 학습이되고, 학습이 된 모델은 GCS에 저장된다. (텐서플로우에서 SavedModel로 저장한다.)

  4. GCS 에 저장된 모델은 AI Plaform 서빙 엔진에 배포되고 REST API를 이용하여 서빙된다.

  5. 클라이언트에서는 이 REST API를 이용하여 학습된 모델에 대한 서빙을 이용한다.

  6. 전체 워크플로우에 대한 파이프라인 관리는 Apache Airflow 매니지드 서비스인 Composer 를 이용한다. 또는 머신러닝에 특화된 파이프라인이기 때문에, AI Platform pipeline을 사용하는 것이 좋다.

Option A: 빅쿼리에서 데이터 전처리

일반적으로 빅쿼리를 이용한 전처리는 다음과 같은 시나리오에 유용하다.

  • Sampling : 데이터에서 랜덤하게 일부 데이터셋만 가지고 오는 용도

  • Filtering : 학습에 필요한 데이터만 WHERE 문을 이용해서 가지고 오는 용도

  • Partitioning : 데이터를 학습/평가/테스트 용도로 나누는 용도

주로 빅쿼리는 Dataflow로 데이터를 인입하기 전체 최초 전처리 용도로 사용이 되는데, 주의할점은 빅쿼리에 전처리 로직이 많을 경우 향후 서빙에서 재 구현이 필요할 수 있다. 무슨 이야기인가 하면, 서빙시에도 입력 데이터에 대한 동일한 전처리가 필요한데, 빅쿼리에서 SQL로 작성한 전처리 로직은 서빙시에는 사용할 수 없기 때문에, 자바나 파이썬으로 전처리 로직을 다시 구현해야 하는 이중작업이 될 수 있다. 물론 서빙이 빅쿼리에 있는 데이터를 사용하는 배치 서빙일 경우 문제가 없지만, 리얼타임으로 단건의 데이터에 대해서 서빙을 하는 경우에는 빅쿼리에서 서빙용 데이터를 전처리할 수 없다. 


그럼에도 불구하고 배치 서빙용인 경우 전처리를 빅쿼리를 이용할 경우 편리하고 특히 Dataflow 에 데이터를 입력하기전에 Full pass transformation 이 필요한 전체 통계 데이터 (예를 들어 평균,분산,최소/최대값)은 SQL을 통해서 쉽게 뽑아낼 수 있는 장점이 있다. 

Option B: Dataflow 에서 데이터 전처리

복잡한 데이터 변환 로직이 있는 경우등에 효율적으로 사용할 수 있는 방식인데, Instance level transformation 뿐만 아니라, full pass transformation, 그리고 window aggregation 타입 모두를 지원할 수 있다.

Dataflow는 Apache Beam 오픈소스 기반의 런타임이지만, 다양한 구현 방식을 지원하고 있다.

  • Apache Beam을 사용하는 방법 : 가장 일반적인 방식으로 Apache Beam Java/Python SDK 을 이용하여 데이터 변환 로직을 구현할 수 있다.  

  • Tensorflow Transformation 을 사용하는 방법 : 텐서플로우의 경우 Tensorflow Transformation (이하 TFT) 이라는 이름으로 데이터 변환 프레임워크를 제공한다. TFT는 Apache Beam 기반으로 동작하는데, 텐서플로우 코드를 기반으로 하기 때문에, 머신러닝 개발자 입장에서는 접근이 상대적으로 쉬운 장점이 있다. 

  • Dataflow SQL을 사용하는 방법 : 앞의 두 방식의 경우에는 Java나 Python 기반의 코딩이 필요한데, 이런 코딩 없이 Window aggregation이나, 기타 복잡한 로직을 구현하고자 할때 사용할 수 있는 방식이 Dataflow SQL이다.SQL을 사용하여 구현하지만, Dataflow의 함수등을 사용할 수 있는 장점이 있다. 

  • Dataflow Template + UDF를 사용 하는 방법 : 복잡한 변환이 아니라 단순한 맵핑이나 문자열 변환들을 어렵지 않게 구현하는 방식으로 Dataflow는 Pre-built in 된 Template을 제공한다. 이 템플릿 중에는 비즈니스 로직을 자바스크립트로 넣을 수 있는 UDF 라는 방식을 지원하는데, Apache Beam 형태로 구현할 필요 없이 단순한 변환 로직을 자바스크립트로 구현하여 GCS에 파일을 저장하고, 설정 정보에서 자바 스크립트 파일만 지정하면되기 때문에, 쉽게 사용할 수 있다. 


서빙시에도 다양한 아키텍처 구현이 가능한데, Pub/Sub 큐를 통해서 데이터를 실시간으로 인입한 데이터를 머신러닝 모델로 서빙한후에, Pub/Sub으로 내보내는 near realtime 서빙이 가능하고 또는 bigtable에 서빙 결과를 저장하여 마치 serving 결과에 대한 캐쉬식으로 사용하는 구조도 가능하다.




<그림. 스트림 데이터를 이용하여 서빙을 제공하는 아키텍처>

Option C: Tensorflow 모델 내에서 데이터 전처리

아니면 데이터 전처리를 Tensorflow 모델 코드내에서 하는 방식이 있다.

  • feature_column 를 이용하여 피처를 임베딩하거나, 버킷화 하는 방식이 있고

  • 아니면 데이터를 피딩하는  input functions(train_input_fn, eval_input_fn, and serving_input_fn) 안에 데이터 전처리 로직을 구현하는 방법이 있다. 

  • Custom estimator를 사용하는 경우에는 model_fn 자체에 데이터 전처리 로직을 넣을 수 있다. 

이렇게 텐서 플로우 코드단에 전처리 기능을 넣는 경우는 Instance level transformation은 가능하지만 다른 방식에 대해서는 불가능하다. 그렇지만 이미지 데이터를 학습전에 rotation하거나 flip 하는 argumentation 등은 텐서플로우 코드에서 하게 되면 동적으로 데이터를 학습 단계에 argumentation할 수 있기 때문에 효율이 좋은 장점이 있다. 

Option D: DataPrep을 이용한 데이터  전처리

구글 클라우드 플랫폼에서는 데이터의 특성을 분석하고 간단한 변환을 지원하기 위한 wrangling 도구로 DataPrep을 제공한다. Engineered feature 단계까지 데이터를 가공하는 것은 어려울 수 있겠지만, Raw data를 Prepared data 형태로 cleansing 하는 용도로는 충분히 사용할 수 있으며, 특히 시각화를 통한 데이터 분포나 아웃라이어 분석이나 단순 변환등에는 효과적으로 사용할 수 있다.


<그림 DataPrep 을 이용한 Wrangling 과정 예시> 

Option E: DataProc을 이용한 데이터 전처리

DataProc은 Hadoop/Spark 에 대한 구글 매니지드 서비스이다. Apache Beam을 사용하는 Dataflow와 같이 코딩을 기반으로 한다는 점은 같지만, 기존에 Hadoop/Spark 에코 시스템에 익숙한 사용자들의 경우에는 기존의 에코 시스템과 개발 코드를 재활용할 수 있다는 장점을 가지고 있다. 

데이터 전처리시 고려할점

그러면 이러한 기술을 이용해서 데이터를 전처리할때, 고려해야하는 점은 무엇이 있을까?

학습/서빙 데이터에 대한 스큐(skew)

모델을 학습하여, 서비스에 배포한후에, 향후 들어오는 데이터로 서빙을 하게 되는데, 이때 학습에서 사용한 데이터와 서빙시 사용한 데이터의 특성이 다를때 이를 training-serving skew 라고 한다. 

예를 들어 피처 A가 학습시에 범위가 1~255 였는데, 서빙시에 1~500 사이로 들어오게 되면 이 모델의 서빙 결과는 정확하지 못하게 된다.

(참고 : 이런 문제를 해결하기 위해서 데이터의 분포나, 수학적 통계값을 저장해 놓은 후에, 서빙전에 검증하는 방식을 사용할 수 있으며 이는 Tensorflow data validation으로 구현이 가능하다. )

Full pass transformation

Option C의 텐서플로우 모델내의 데이터 변환 로직은 Full pass transformation을 지원하지 않기 때문에, feature scaling이나, normalization 적용이 불가능하다. 이러한 전처리 기법은 최소/최대값등의 통계 데이터가 필요한데, 이러한 데이터는 모델 학습전에 계산되어야 하고, 계산된 데이터는 어디에든 저장되어 있어야 하며, 학습과/서빙 단계에 모두 일관되게 사용될 수 있어야 한다. 

성능 향상을 위한 Up front data loading 

Option C 텐서플로우 모델내에 데이터 변환 로직을 구현할때, 고려해야 하는 사항이다.

모델 코드 상에 데이터 전처리 로직이 있을 경우, 아래 그림과 같이 데이터 변환 작업이 끝나면, 그 데이터로 모델을 학습 시키는 구조가 된다. 


<그림. 데이터 전처리가 모델 학습전에 발생하여, 대기하는 현상>


이 경우에 데이터가 전처리되고 있는 동안에는 학습이 이루어지지 않기 때문에 자원이 낭비되는 문제가 발생하고, 모델의 학습 시간에 전처리 시간까지 포함되기 때문에 전체 학습시간이 상대적으로 오래걸린다. 


Option B의 데이터 플로우를 사용하는 것처럼 미리 여러 학습에 사용될 데이터를 전처리를 해놓거나 아니면 아래 그림과 같이 병렬적으로 데이터 플로우에서 데이터를 전처리하면서 모델은 학습에만 전념하도록 하면, 모델의 전체학습 시간을 줄일 수 있다. 


<그림. 병렬로 데이타 전처리를 해서 모델 학습을 최적화 하는 방식>

이를 up front data loading 이라고 하는데, 텐서플로우에서는 Prefetching, Interleave, Parallel mapping 등을 tf.data.DataSet에서 다양한 방식으로 이를 지원하고 있다. 


Tensorflow Transform

텐서플로우 프레임웍은 이러한 데이터 변환을 위해서 Tensorflow Transform (이하 TFT) 라는 프레임웍을 데이터 전처리 기능을 제공한다. 이 TFT를 구글 클라우드에서 실행하게 되면, Dataflow를 기반으로 실행할 수 있다. (Option B) 

tf.Transform 이라는 패키지로 제공된다. TFT는 instant level transformation 뿐만 아니라, full pass transformation, window aggregation 을 지원하는데, 특히 full pass transformation을 지원하기 위해서 데이터를 변환하기 전에 Analyze 라는 단계를 거치게 된다. 

아래 그림이 TFT가 작동하는 전반적인 구조를 기술한것인데,



Analyze 단계에서는 데이터의 통계적인 특성 (최소,최대,평균 값등)을 추출하고, Transform 단계에서는 이 값을 이용하여, 데이터 변환을 수행한다. 각 단계는 tft_beam.AnalyzeDataset , tft_beam.TransformDataset 로 실행될 수 있으며, 이 두 단계를 tft_beam.AnalyzeAndTransformDataset 로 합쳐서 한번에 실행하는 것도 가능하다. 


  • Analyze 단계 : Analyze 단계에서는 통계적인 값을 Full pass operation 을 통해서 계산해내는 것이외에도, transform_fn을 생성해내는 작업을 한다. transform_fn은 텐서플로우 그래프로, 데이터 변환에 대한 instance level operation 을 계산해낸 통계값을 사용해서 수행한다. 

  • Transform 단계 : 데이터 변환 단계에서는 transform fn을 인입 데이터에 적용하여, instance level로 데이터를 변환하는 작업을 수행한다. 


모델 학습시 데이터에 대한 전처리는 학습 데이터뿐만 아니라, 평가 (Eval) 데이터에도 동일하게 적용이 되어야 하는데, Analyze는 학습데이터에만 적용되서 데이터의 특성을 추출하고, 평가 데이터에는 별도로 Analyze를 수행하지 않고, 학습 데이터에서 추출된 데이터 특성을 그대로 사용한다

TFT pipeline export  

transform_fn으로 구성된 데이터 변환 파이프라인은 내부적으로 텐서 플로우 그래프로 변환이 되는데, 학습된 텐서플로우 모델을 export 하여 SavedModel로 저장할때, 이 transform_fn 그래프가  서빙용 데이터 입력함수인 serving_input_fn에 붙어서 같이 export 된다. 이 말은, 학습에서 사용한 데이터 전처리 로직인 transform_fn이 그대로 서빙단에도 같이 적용된다는 이야기이다. 물론 full-pass transformation에서 계산한 통계값도 상수형태로 저장하게 된다. 그래서 입력값에 대해서 학습과 서빙시 같은 변환 로직을 사용할 수 있게 된다.

데이터 전처리 옵션 정리

앞서 설명한 데이터 변환 전처리 옵션을 Instance level transformation, full pass level transformation, window aggregation 에 따라 정리해보면 다음과 같다. 


Disclaimer

본 글의 작성자는 Google 직원입니다. 그러나 본 글의 내용은 개인의 입장에서 작성된 글이며, Google의 입장을 대변하지 않으며, Google이 본 컨텐츠를 보장하지 않습니다.


References






Instance-level transformation

(stateless transformation)

Full pass during training

instance -level during serving

(stateful transformation)

Real-time (window) aggregations

during training and serving 

(streaming transformation)

배치 서빙

온라인 서빙

배치 서빙

온라인 서빙

배치 서빙

온라인 서빙

BigQuery (SQL)

OK

같은 데이터 변환 로직을 학습과 서빙 단계에 적용 가능

가능은 하지만 권장하지 않음


서빙시에는 BigQuery가 아니라 다른 방식으로 데이터 변환 로직을 구현해야 하기 때문에 결과적으로 학습/서빙 Skew를 유발할 수 있음

가능


BigQuery에서 수학적 통계값(최소/최대)를 계산하여, 이 값을 이용하면 가능하다.

그러나 계산된 값을 별도로 저장해서 학습/서빙시에 사용해야 하기 때문에 구현이 번거롭다.

N/A

가능은 하지만 권장하지 않음


BigQuery의 윈도우 함수등을 이용하여 구현은 가능하지만, 서빙시에는 BigQuery가 아닌 다른 툴로 구현을 해야 하기 때문에 학습/서빙 Skew가 발생할 수 있음

Dataflow (Apache Beam)

OK

서빙시 데이터가 Pub/sub을 통해서 데이터 블로우로 들어오면 가능하지만, 그렇지 않은 경우 학습/서빙 데이터간 Skew가 발생할 수 있음

가능


Dataflow에서 수학적 통계값(최소/최대)를 계산하여, 이 값을 이용하면 가능하다.

그러나 계산된 값을 별도로 저장해서 학습/서빙시에 사용해야 하기 때문에 구현이 번거롭다.

OK


동일한 Apache Beam 기반의 데이터 변환 로직이 학습을 서빙시 적용이 가능함

Dataflow (Apache Beam + TFT)

권장함


학습과 서빙의 Skew를 방지할 수 있고, 학습/서빙전 데이터를 미리 준비할 수 있음

권장함


데이터 변환 로직과, 모델 학습시에 계산된 통계 결과 텐서플로우 그래프 형태로 저장되서, 서빙 모델을 export할시에 같이 저장됨

Tensorflow
(input_fn & serving_input_fn)

가능은 하지만 권장하지 않음


학습과 서빙 효율성을 생각하면, 학습전에 데이터를 변환하는게 좋음

가능은 하지만 권장하지 않음


학습과 서빙 효율성을 생각하면, 학습전에 데이터를 변환하는게 좋음

불가능

불가능


본인은 구글 클라우드의 직원이며, 이 블로그에 있는 모든 글은 회사와 관계 없는 개인의 의견임을 알립니다.

댓글을 달아 주세요

  1. pexavec 2021.04.24 17:14  댓글주소  수정/삭제  댓글쓰기

    관리자의 승인을 기다리고 있는 댓글입니다

Kubeflow pipeline 과 TFX 메모

빅데이타/머신러닝 | 2020. 11. 17. 00:27 | Posted by 조대협

Kubeflow pipeline 과 TFX 메모


TFX

TFX는 Tensorflow Extended 로, 머신러닝 파이프라인을 구현하는데 필요한 여러가지 컴포넌트들을 지원한다.

  • TFDV : 모델 Validation으로, EDA뿐만 아니라 데이터의 특성을 파악하여 저장한후에, 향후에 데이터가 들어 왔을때 Validation이 가능하다
  • TFT : 데이터 Transformation 작업을 한다
  • TFMA : 학습된 모델에 대한 평가 작업을 한다
  • TF-Serving : Prediction RunTime 엔진을 제공한다.
파이프라인 엔진
이렇게 각각의 컴포넌트가 있을때, 이 컴포넌트를 묶어서 오케스트레이션을 해야하는데, 이를 위해서 제공되는 것이 TFX pipeline이다. 실제 런타임 엔진이 있는 것이 아니라 SDK형태를 제공하고, 실제 런타임은 Kubeflow pipeline이나, Airflow를 사용한다.

TFX Standard component
이 파이프라인에서 각 TFX 컴포넌트를 손쉽게 부르려면, TFX 파이썬 라이브러리를 직접호출할 수 없으니, TFX 파이프라인에 맞도록 컴포넌트 형태로 구현을 해서 사용해야 하는데, TFX 컴포넌트들은 standard component 라는 형태로 미리 구현이 되어 있어서 불러만 쓰면 된다. 

Metadata
또한 파이프라인 각 단계별로 아웃풋 결과를 다음 태스크의 인풋으로 전달하기 위해서는 중간 저장소가 필요하고, 파이프라인의 진행 상태등을 저장할 메타 저장소가 필요한데, 이를 지원해주는 것이 metadata 스토어이다

문제점
이렇게 보면, 이미 만들어져 있는 컴포넌트들을 조합해서 파이프라인을 만들고 자동으로 메타데이타 까지 저장해주기 때문에 좋을거 같은데, 여기서 문제가 발생한다.
텐서플로우 세계에서만 좋다는것.
즉 이 프레임웍은 텐서플로우에만 최적화가 되어 있다. PyTorch, XGBoost와 같은 다른 프레임웍을 쓰거나 AWS,GCP,Azure 등의 매니지드 서비스를 호출할 수 없다. 물론 TFX Pipeline에서 Custom component 를 만들어서 호출하면 되지만, 말 그대로 만들어야 된다.

해결책
그래서 해결책으로 고려할 수 있는 것이 tfx pipeline을 사용하지 않고,kubeflow pipeline을 네이티브로 사용하는 방법이다. 이 방법을 사용하면 다른 프레임웍이나 AWS, GCP 서비스를 쉽게 사용할 수 있다. 특히 prebuilt-in 컴포넌트 형태로 이런 서비스를 컴포넌트 화를 해놓았기 때문에 사용이 편리하다. https://github.com/kubeflow/pipelines/tree/master/components
그런데, 여기서 또 다른 문제가 발생한다, 이 컴포넌트들에는 TFX 컴포넌트들이 없다 이 좋은 기능을 또 사용을 못한다는 말인데, 역시 kubeflow pipeline도 커스텀 컴포넌트를 지원한다. 
tfx에 비해서 상대적으로 컴포넌트 개발이 쉽다. python function을 컴포넌트로 정의할 수 있기 때문에 쉽게 개발이 가능하고, 찾아보면 python function 컴포넌트 형태로 TFDV,TFMA등을 호출한 사례를 심심치 않게 찾아볼 수 있다. 

이 경우 고려해야 할 사항이 tfx 의 경우 SDK를  Apache Beam을 사용하기 때문에, 런타임을 Flink나 GCP Data Flow를 사용하면 스케일이 가능한데, 이 부분은 좀 연구를 해봐야 할 분야인듯..

Kubeflow pipeline으로 정리되던 파이프라인 기술이 TFX가 나오면서, 특히 TFX가 파이프라인을 구현하면서 복잡해지는 것 같은 과도기적인 느낌이 오는데, 이는 좀 더 지켜봐야하지 않을까 싶다.




본인은 구글 클라우드의 직원이며, 이 블로그에 있는 모든 글은 회사와 관계 없는 개인의 의견임을 알립니다.

댓글을 달아 주세요

  1. 2020.12.13 21:49  댓글주소  수정/삭제  댓글쓰기

    비밀댓글입니다

End2End 머신러닝 플랫폼 Kubeflow 조대협 (http://bcho.tistory.com)

머신러닝 파이프라인

머신러닝에 대한 사람들의 선입견중의 하나는 머신러닝에서 수학의 비중이 높고, 이를 기반으로한 모델 개발이 전체 시스템의 대부분 일 것이라는 착각이다.

그러나 여러 연구와 경험을 참고해보면, 머신러닝 시스템에서 머신러닝 모델이 차지하는 비중은 전체의 5% 에 불과하다.


실제로 모델을 개발해서 시스템에 배포할때 까지는 모델 개발 시간보다 데이타 분석에 소요되는 시간 그리고 개발된 모델을 반복적으로 학습하면서 튜닝하는 시간이 훨씬 더 길다.

머신러닝 파이프라인은 데이타 탐색에서 부터, 모델 개발, 테스트 그리고 모델을 통한 서비스와 같이 훨씬 더 복잡한 과정을 거친다. 이를 머신러닝 End to End 파이프라인이라고 하는데, 자세하게 그 내용을 살펴보면 다음 그림과 같다.




  • Data ingestion : 머신러닝에 필요한 학습 데이타를 외부로 부터 받아서 저장하는 단계

  • Data analytics : 수집된 데이타를 분석하여, 의미를 찾아내고,필요한 피쳐(특징)을 찾아내는 단계로 주로 빅데이타 분석 시스템이 많이 활용된다. EDA (Exploratory Data Analytics) 방법을 많이 사용하는데, 저장된 데이타를 그래프로 시각화해서 각 값간의 관계나 데이타의 분포등을 분석한다.

  • Data Transformation : 수집된 데이타에서 학습에 필요한 데이타만 걸러내고, 학습에 적절하도록 컨버팅 하는 단계. 예를 들어 이미지 데이타의 크기를 정형화하고, 크롭핑 처리를 한후에, 행렬 데이타로 변환하는 과정등이 이에 해당한다.

  • Data Validation : 변환된 데이타가 문제는 없는지 데이타 포맷이나 범위등을 검증하는 단계

  • Data Splitting : 머신러닝 학습을 위해서 데이타를 학습용,테스트용,검증용으로 나눈다.

  • Build a Model : 머신러닝 모델을 만들고 학습하는 단계

  • Model Validation : 만들어진 모델을 검증하는 단계

  • Training at scale : 더 많은 데이타를 더 큰 인프라에서 학습 시켜서 정확도를 높이고, 하이퍼 패러미터 튜닝을 통해서 모델을 튜닝하는 단계로 주로 대규모 클러스터나 GPU 자원등을 활용한다.

  • Roll out : 학습된 모델을 운영환경에 배포하는 단계

  • Serving : 배포된 모델을 통해서 머신러닝 모델을 서비스로 제공하는 형태. 유스케이스에 따라서 배치 형태로 서빙을 하거나 실시간으로 서빙하는 방법이 있다.

  • Monitoring : 머신러닝 모델 서비스를 모니터링 해서 정확도등에 문제가 없는지 지속적으로 관찰하는 단계

  • Logging : 모델에 서비스에 대한 로그 모니터링


이 과정을 데이타의 변동이 있거나 모델을 향상시키고자 하거나 정확도가 떨어지는 경우 첫번째 과정부터 반복을 한다.


위에서 설명한 파이프라인 흐름을 시스템 아키텍쳐로 표현해보면 다음과 같다.




먼저 GPU를 지원하는 인프라 위에 머신러닝 플랫폼이 올라가게 되고, 빅데이타 분석 플랫폼이 같이 사용된다.

머신러닝 플랫폼은 데이타를 분석하는 EDA 단계의 데이타 분석 플랫폼 그리고, 분석된 데이타를 변환 및 검증하고 학습,테스트,검증 데이타로 나누는 Data Processing 시스템이 붙고, 이 데이타를 이용해서, 모델을 개발한후에, 이 모델을 학습 시키기 위한 학습 (Training) 플랫폼이 필요하다. 학습된 모델을 검증하고, 이 검증 결과에 따라서 하이퍼 패러미터를 튜닝한 후에, 이를 운영환경에 배포하여 서비스 한다. 데이타 분석 및 모델 개발 학습 단계는 주로 데이타 사이언티스트에 의해서 이루어지는데, 이러한 엔지니어들이 사용할 개발 환경이 필요한데, 주로 노트북 기반 (예. 파이썬 주피터 노트북)의 환경이 많이 사용된다.

학습이 완료된 모델을 서빙하는 Inference 엔진이 필요하고, 이를 외부 API로 노출하기 위해서 API 키 인증, 오토스케일링, 로깅 및 모니터링을 위한 API Serving 플랫폼이 필요하다.


컴포넌트가 많은 만큼 여기에 사용되는 프레임웍도 많다. 먼저 모델 개발 및 학습을 위해서는 머신러닝 프레임웍이 필요한데, Tensorflow, PyTorch, Sklearn, XGBoost등 목적에 따라서 서로 다른 프레임웍을 사용하게 되며, 완성된 모델을 서빙하는 경우에도 Tensorflow Serving, Uber에서 개발한 Horovod 등 다양한 플랫폼이 있다. 또한 모델을 서빙할때 REST API등으로 외부에 서비스 하려면 보안 요건에 대한 처리가 필요하기 때문에 별도의 API 인증 메커니즘등이 추가되어야 하고, 스케일링을 위한 오토 스케일링 지원 그리고 모델의 배포와 테스트를 위한 배포 프레임웍, A/B 테스트 환경등이 준비되어야 한다.

일부만 이야기한것이지만 실제 운영 환경에서 사용되는 머신러닝 시스템은 훨씬 더 복잡하고 많은 기술을 필요로 한다.

Kubeflow comes in

이러한 복잡성 때문에 머신러닝 플랫폼은 높은 난이도를 가지고 있고, 데이타 분석과 모델 개발에 집중해야 하는 머신러닝 엔지니어 입장에서는 큰 부담이 된다. (배보다 배꼽이 크다)

그래서 이러한 복잡성을 줄이고 머신러닝 엔지니어의 원래 업인 데이타 분석과 머신러닝 모델 개발에만 집중할 수 있도록 플랫폼을 추상화 해놓은 오픈 소스 프레임웍이 Kubeflow이다.

위에서 설명한 머신러닝 파이프라인의 End to End 전체를 커버할 수 있게 하고, 모든 단계의 컴포넌트를 패키지화 해놔서, 어려운 설치 없이 머신러닝 엔지니어는 머신러닝 모델 개발의 각 단계를 손쉽게 할 수 있도록 해준다.


Kuberflow는 Kubernetes(쿠버네티스) + ml flow 를 합한 의미로, 쿠버네티스 플랫폼 위에서 작동한다.

쿠버네티스는 도커 컨테이너 관리 플랫폼으로, 이 컨테이너 기술을 이용하여 머신러닝에 필요한 컴포넌트를 패키징하여 배포한다. 쿠버네티스에 대한 자세한 설명은 링크를 참고하기 바란다.

이로 인해서 가질 수 있는 장점은 다음과 같다.

  • 클라우드나 On-Prem (데이타 센터), 개인 개발 환경에 상관 없이 동일한 머신러닝 플랫폼을 손쉽게 만들 수 있기 때문에 특정 벤더나 플랫폼에 종속되지 않는다.

  • 컨테이너 기술을 이용해서 필요한 경우에만 컨테이너를 생성해서 사용하고, 사용이 끝나면 컨테이너를 삭제하는 방식이기 때문에 자원 활용율이 매우 높다. 특히 쿠버네티스의 경우에는 스케쥴링 기능을 이용해서 비어있는 하드웨어 자원에 컨테이너를 배포해서 (꾸겨넣는 방식으로) 사용하기 때문에 집적률이 매우 높다.

  • 컨테이너로 패키징이 되어있기 때문에 내부 구조를 알필요가 없이 단순하게 컨테이너만 배포하면 된다.

또한 쿠버네티스는 오픈소스 플랫폼이기 때문에 여러 종류의 머신러닝 관련 기술들이 손쉽게 합쳐지고 있다.

Kubeflow 컴포넌트 구성

그러면 간단하게 Kubeflow의 컴포넌트 구성을 살펴보자.

IDE 환경

IDE 개발환경으로는 JupyterLab을 지원한다. JupyterLab은 Jupyter 노트북의 확장 버전으로 코드 콘솔뿐 아니라 파일 브라우져나 시각화창등 확장된 UI를 지원한다.


<출처 : https://jupyterlab.readthedocs.io/en/stable/getting_started/overview.html>


개인적으로 기존 노트북 환경에 비해서 좋은 점은 주피터 노트북을 필요할때 마다 손쉽게 생성이 가능하며, 생성할때 마다 GPU 지원 여부나 텐서플로우 버전등을 손쉽게 선택이 가능하다.


<그림. 노트북 생성시 텐서플로우와 GPU 지원 여부를 선택하는 화면>


또한 아래 그림과 같이 노트북 인스턴스의 하드웨어 스펙 (CPU, Memory, GPU)를 정의할 수 있다.



GPU 드라이버

그리고 쿠버네티스상에서 GPU를 사용할 수 있도록 GPU 드라이버를 미리 패키징 해놓았다. 머신러닝 프레임웍을 사용하면 항상 까다로운 부분이 GPU 드라이버 설정이나 업그레이드인데, 이를 미리 해놓았기 때문에 머신러닝 엔지니어 입장에서 별도의 노력없이 손쉽게 GPU를 사용할 수 있다.

머신러닝 프레임웍

머신러닝 프레임웍으로는 현재 텐서플로우, 파이토치, MxNet등을 지원하는데, 플러그인 컴포넌트 형태이기 때문에 앞으로 더 많은 프레임웍을 지원할 것으로 기대된다.

데이타 프로세싱

데이타 프로세싱에서 데이타 변환 (Transformation)과 데이타 검증 (Validation)은 텐서플로우의 확장팩인 TFX에서 지원하는 TFDV (Tensorflow Data Validation)과 TFT (Tensorflow Transform)을 이용해서 지원한다.

학습 환경

개발된 모델을 학습할때 특히 분산학습의 경우에는 텐서플로우 클러스터와 우버에서 개발된 텐서플로우용 분산 학습 플랫폼인 Hornovod를 지원한다.  

모델 검증

학습된 모델 검증은 데이타 프로세싱과 마친가지로 텐서플로우 확장팩인 TFX의 TFMA (Tensorflow Model Analysis)를 지원한다.

하이퍼 패러미터 튜닝

학습된 모델에 대한 하이퍼 패레미터 튜닝은 katLib라는 컴포넌트를 이용해서 지원한다.

모델 서빙

학습이 완료된 모델은 TFX 패키지의 일부인 Tensorflow Serving 을 사용하거나 모델 서빙 전문 플랫폼인 SeldonIO를 사용한다. SeldonIO는 텐서플로우뿐만 아니라 Sklearn, Spark 모델, H2O 모델, R 모델등 좀 더 다양한 모델을 지원한다.

API 서비스

서비스된 모델에 대한 API 키 인증이나 라우팅등을 위해서 API 게이트 웨이가 필요한데, API 게이트 웨이로 Ambassador라는 오픈 소스를 이용한다. 이를 통해서 API 키등의 인증을 지원하고, 쿠버네티스 위에 네트워크 플랫폼인 ISTIO를 사용하여, API 서비스에 대한 모니터링 및 서비스 라우팅을 지원하는데, 서비스 라우팅 기능은 새 모델을 배포했을때 새모델로 트래픽을 10%만 보내고 기존 모델로 트래픽을 90% 보내서 새모델을 테스트하는 카날리 테스트나 API 통신에 대한 보안등 여러기능을 지원한다. Istio에 대한 자세한 설명은 링크를 참조하기 바란다.

워크플로우

이러한 컴포넌트를 매번 메뉴얼로 실행할 수 는 없고, 워크플로우 흐름에 따라서 자동으로 파이프라인을 관리할 수 있는 기능이 필요한데, 이를 워크플로우 엔진이라고 하고, Kubeflow에서는 argo라는 컨테이너 기반의 워크플로우 엔진을 사용한다. 자세한 내용은 링크 참조.

그런데 argo는 일반적인 워크플로우를 위해서 디자인된 플랫폼으로 머신러닝 파이프라인에 최적화되어 있지 않다. (예를 들어 학습 단계 종료후, 학습 결과/accuracy등을 모니터링 한다던지, Tensorflow Dashboard와 통합된다던지.) 그래서 argo위해 머신러닝 기능을 확장하여 개발중인 오픈소스가 Kubeflow pipeline이 있다. Kubeflow pipeline에 대해서는 나중에 더 자세히 설명하도록 한다.

컴포넌트에 대한 정의

Kubeflow에서 사용되는 거의 모든 컴포넌트에 대해서 설명하였다. 그러면 이런 컴포넌트를 어떻게 쿠버네티스에 배포하고, 어떻게 실행을 할것인가? 매번 쿠버네티스의 설정 파일을 만들어서 하기에는 파일의 수도 많고 반복작업이면서 또한 쿠버네티스에 대한 높은 전문성을 필요로하기 때문에 어렵다.

그래서 이러한 반복작업을 줄여주고, 템플릿화하여 실행하도록 해주는 엔진이 ksonnet 이라는 오픈소스를 사용한다. ksonnet은 jsonnet 템플릿 엔진 기반으로, 위에서 나열한 컴포넌트들을 쿠버네티스에 설치할 수 있도록 해주고, 각 단계별 컴포넌트를 손쉽게 실행할 수 있도록 해준다.


이 솔루션들을 앞에서 설명한 머신러닝 플랫폼 아키텍쳐에 맵핑 시켜보면 다음과 같은 그림이 된다.




Kubeflow는 현재 개발중인 버전으로 이글을 쓰는 현재 0.4 버전이 개발중이다.

컨셉적으로 매우 훌륭하고 0.4 버전인것에 비해서는 매우 완성도가 높지만 1.0 릴리즈 전이기 때문에 다소 변화가 심하기 때문에 버전간 호환이 안될 수 있다. 이점을 염두하고 사용하기 바란다.


Kubeflow를 이해하기 위해서는 먼저 Kubeflow의 컴포넌트를 배포하고 실행하게 해주는 ksonnet에 대한 이해가 먼저 필요하다. 다음 글에서는 이 ksonnet에 대해서 알아보도록 하겠다.

본인은 구글 클라우드의 직원이며, 이 블로그에 있는 모든 글은 회사와 관계 없는 개인의 의견임을 알립니다.

댓글을 달아 주세요

  1. dongjoo 2019.01.09 14:14  댓글주소  수정/삭제  댓글쓰기

    매번 좋은내용 포스팅 해주셔서 감사합니다. 관심이 많이 있는 분야인데, 이제 프레임웍을 통째로 개발하는것보단 얼마나 잘 개발(유지)되고 있는 오픈소스를 잘 조합하고 각자에 맞게 개발해서 더 큰 value를 뽑아낼 수 있느냐가 점점 중요해지는것 같네요.

  2. 초보자 2019.04.10 17:14  댓글주소  수정/삭제  댓글쓰기

    항상 새로운 정보를 여기에서 얻는것 같네요. 매번 좋은 글 올려주셔서 감사합니다.

  3. ksmin 2020.01.09 14:01  댓글주소  수정/삭제  댓글쓰기

    안녕하세요.
    내용 중에 hyperparameter tuning을 katlib라고 하셨는데 katib 아닌가요?
    좋은 글 감사합니다.