ML을 위한 데이터 사전 처리: 옵션 및 권장 사항

이 문서는 지도 학습 작업에 중점을 두고 기계 학습(ML)을 위한 데이터 엔지니어링 및 기능 엔지니어링 주제를 탐구하는 두 부분으로 구성된 시리즈 중 첫 번째입니다. 첫 번째 부분에서는 Google Cloud의 ML 파이프라인에서 데이터를 사전 처리하기 위한 권장사항을 설명합니다. 이 문서는 TensorFlow 및 오픈 소스 TensorFlow Transform ( tf.Transform ) 라이브러리를 사용하여 데이터를 준비하고, 모델을 훈련하고, 예측을 위한 모델을 제공하는 데 중점을 둡니다. 이 문서에서는 ML을 위한 데이터 사전 처리의 과제를 강조하고 Google Cloud에서 데이터 변환을 효과적으로 수행하기 위한 옵션과 시나리오를 설명합니다.

이 문서에서는 사용자가 BigQuery , Dataflow , Vertex AI , TensorFlow Keras API에 익숙하다고 가정합니다.

두 번째 문서 인 Google Cloud를 사용한 ML을 위한 데이터 사전 처리에서는 tf.Transform 파이프라인을 구현하는 방법에 대한 단계별 튜토리얼을 제공합니다.

소개

ML은 데이터에서 복잡하고 잠재적으로 유용한 패턴을 자동으로 찾는 데 도움이 됩니다. 이러한 패턴은 새로운 데이터 포인트에 사용할 수 있는 ML 모델로 압축됩니다. 이 프로세스를 예측 또는 추론 수행 이라고 합니다.

ML 모델 구축은 다단계 프로세스입니다. 각 단계에는 고유한 기술적, 개념적 과제가 있습니다. 두 부분으로 구성된 이 시리즈는 지도 학습 작업과 원본 데이터를 선택, 변환 및 강화하여 대상 변수에 대한 강력한 예측 신호를 생성하는 프로세스에 중점을 둡니다. 이러한 작업은 도메인 지식과 데이터 과학 기술을 결합합니다. 작업은 기능 엔지니어링 의 핵심입니다.

실제 ML 모델의 학습 데이터 세트 크기는 쉽게 1테라바이트(TB) 이상이 될 수 있습니다. 따라서 이러한 데이터세트를 효율적이고 분산적으로 처리하려면 대규모 데이터 처리 프레임워크가 필요합니다. ML 모델을 사용하여 예측을 수행하는 경우 새 데이터 포인트에 대한 교육 데이터에 사용한 것과 동일한 변환을 적용해야 합니다. 동일한 변환을 적용하면 모델이 예상하는 방식으로 ML 모델에 실시간 데이터세트를 제공할 수 있습니다.

이 문서에서는 기능 엔지니어링 작업의 다양한 세부 수준(인스턴스 수준, 전체 통과 및 기간 집계)에 대한 이러한 과제에 대해 설명합니다. 이 문서에서는 Google Cloud에서 ML을 위한 데이터 변환을 수행하는 옵션과 시나리오도 설명합니다.

또한 이 문서에서는 데이터 사전 처리 파이프라인을 통해 인스턴스 수준 및 전체 전달 데이터 변환을 모두 정의할 수 있는 TensorFlow용 라이브러리인 TensorFlow Transform ( tf.Transform )에 대한 개요를 제공합니다. 이러한 파이프라인은 Apache Beam 으로 실행되며 모델이 제공될 때와 마찬가지로 예측 중에 동일한 변환을 적용할 수 있는 아티팩트를 생성합니다.

ML용 데이터 전처리

이 섹션에서는 데이터 전처리 작업과 데이터 준비 단계를 소개합니다. 또한 전처리 작업의 유형과 그 세분성에 대해서도 설명합니다.

데이터 엔지니어링과 특성 엔지니어링 비교

ML을 위한 데이터 사전 처리에는 데이터 엔지니어링과 특성 엔지니어링이 모두 포함됩니다. 데이터 엔지니어링은 원시 데이터를 준비된 데이터 로 변환하는 프로세스입니다. 그런 다음 기능 엔지니어링은 준비된 데이터를 조정하여 ML 모델에서 예상하는 기능을 생성합니다. 이러한 용어의 의미는 다음과 같습니다.

원시 데이터 (또는 그냥 데이터 )

ML을 위한 사전 준비 없이 소스 형식의 데이터입니다. 이러한 맥락에서 데이터는 원시 형식(데이터 레이크)이거나 변환된 형식(데이터 웨어하우스)일 수 있습니다. 데이터 웨어하우스에 있는 변환된 데이터는 분석에 사용하기 위해 원래 원시 형식에서 변환되었을 수 있습니다. 그러나 이 맥락에서 원시 데이터는 데이터가 ML 작업을 위해 특별히 준비되지 않았음을 의미합니다. 데이터가 최종적으로 예측을 위해 ML 모델을 호출하는 스트리밍 시스템에서 전송된 경우에도 원시 데이터로 간주됩니다.

준비된 데이터

ML 작업을 위해 준비된 형식의 데이터 세트: 데이터 소스가 구문 분석되고 조인되어 표 형식으로 작성되었습니다. 준비된 데이터는 올바른 세분성으로 집계 및 요약됩니다. 예를 들어 데이터 세트의 각 행은 고유한 고객을 나타내고, 각 열은 지난 6주 동안 지출한 총액과 같은 고객에 대한 요약 정보를 나타냅니다. 준비된 데이터 테이블에서 관련 없는 열은 삭제되었으며, 유효하지 않은 레코드는 필터링되었습니다. 지도 학습 작업의 경우 대상 기능이 있습니다.

엔지니어링된 기능

모델에서 예상되는 조정된 특성이 포함된 데이터 세트입니다. 즉, 준비된 데이터 세트의 열에 대해 특정 ML 관련 작업을 수행하고 나중에 설명하는 것처럼 훈련 및 예측 중에 모델에 대한 새로운 특성을 생성하여 생성된 특성입니다. 전처리 작업 에서. 이러한 작업의 예로는 숫자 열을 0과 1 사이의 값으로 조정, 값 자르기, 원-핫 인코딩 범주형 기능 등이 있습니다.

다음 다이어그램(그림 1)은 전처리된 데이터 준비와 관련된 단계를 보여줍니다.

실제로 동일한 소스의 데이터는 준비 단계가 서로 다른 경우가 많습니다. 예를 들어 데이터 웨어하우스 테이블의 필드를 엔지니어링된 기능으로 직접 사용할 수 있습니다. 동시에 동일한 테이블의 다른 필드는 엔지니어링된 기능이 되기 전에 변환을 거쳐야 할 수도 있습니다. 마찬가지로 데이터 엔지니어링과 기능 엔지니어링 작업은 동일한 데이터 전처리 단계에서 결합될 수 있습니다.

전처리 작업

데이터 전처리에는 여러 작업이 포함됩니다. 각 작업은 ML이 더 나은 예측 모델을 구축하는 데 도움이 되도록 설계되었습니다. 이러한 전처리 작업의 세부정보는 이 문서의 범위를 벗어나지만 이 섹션에서는 일부 작업에 대해 간략하게 설명합니다.

구조화된 데이터의 경우 데이터 사전 처리 작업에는 다음이 포함됩니다.

• 데이터 정리: 원시 데이터에서 손상되거나 유효하지 않은 값이 있는 레코드를 제거 또는 수정하고, 많은 수의 열이 누락된 레코드를 제거합니다.
• 인스턴스 선택 및 분할: 입력 데이터세트에서 데이터 포인트를 선택하여 훈련, 평가(검증) 및 테스트 세트를 만듭니다. 이 프로세스에는 반복 가능한 무작위 샘플링, 소수 클래스 오버샘플링 및 계층화된 분할을 위한 기술이 포함됩니다.
• 기능 조정: 숫자 값 크기 조정 및 정규화, 누락된 값 대치, 이상값 자르기, 분포가 편향된 값 조정 등 ML 기능의 품질을 개선합니다.
• 특성 변환: 숫자 특성을 범주형 특성으로 변환( 버킷화를 통해) 및 범주형 특성을 숫자 표현으로 변환(원-핫 인코딩, 개수를 사용한 학습 , 희소 특성 임베딩 등을 통해). 일부 모델은 숫자 또는 범주형 특성에만 작동하는 반면 다른 모델은 혼합 유형 특성을 처리할 수 있습니다. 모델이 두 가지 유형을 모두 처리하는 경우에도 동일한 기능에 대한 다양한 표현(숫자 및 범주형)을 통해 이점을 얻을 수 있습니다.
• 특징 추출: PCA , 임베딩 추출, 해싱 과 같은 기술을 사용하여 더 낮은 차원의 더욱 강력한 데이터 표현을 생성하여 특징 수를 줄입니다.
• 특징 선택: 모델 훈련을 위해 입력 특징의 하위 집합을 선택하고, 필터 또는 래퍼 방법을 사용하여 관련이 없거나 중복된 특징을 무시합니다. 기능 선택에는 기능에 많은 수의 값이 누락된 경우 단순히 기능 삭제가 포함될 수도 있습니다.
• 특성 구성: 다항식 확장 (일변량 수학 함수 사용) 또는 특성 교차 (특성 상호 작용 캡처)와 같은 일반적인 기술을 사용하여 새로운 특성을 생성합니다. ML 사용 사례 도메인의 비즈니스 로직을 사용하여 기능을 구성할 수도 있습니다.

구조화되지 않은 데이터(예: 이미지, 오디오 또는 텍스트 문서)로 작업할 때 딥 러닝은 도메인 지식 기반 기능 엔지니어링을 모델 아키텍처에 통합하여 대체합니다. 컨벌루션 레이어 는 자동 기능 전처리기입니다. 올바른 모델 아키텍처를 구성하려면 데이터에 대한 경험적 지식이 필요합니다. 또한 다음과 같은 어느 정도의 전처리가 필요합니다.

• 텍스트 문서의 경우: 형태소 분석 및 원형 복원 , TF-IDF 계산, n-그램 추출, 임베딩 조회.
• 이미지의 경우: 자르기, 크기 조정, 자르기, 가우시안 흐림 및 카나리아 필터.
• 모든 유형의 데이터(텍스트 및 이미지 포함): 전이 학습 은 완전히 훈련된 모델의 마지막 레이어를 제외한 모든 레이어를 기능 엔지니어링 단계로 처리합니다.

전처리 세분성

이 섹션에서는 데이터 변환 유형의 세분화에 대해 설명합니다. 훈련 데이터에 적용되는 변환을 사용하여 예측을 위한 새로운 데이터 포인트를 준비할 때 이러한 관점이 중요한 이유를 보여줍니다.

전처리 및 변환 작업은 작업 세분성에 따라 다음과 같이 분류될 수 있습니다.

• 훈련 및 예측 중 인스턴스 수준 변환 . 이는 동일한 인스턴스의 값만 변환에 필요한 간단한 변환입니다. 예를 들어 인스턴스 수준 변환에는 기능 값을 일부 임계값으로 자르기, 다른 기능을 다항식으로 확장, 두 기능을 곱하거나 두 기능을 비교하여 부울 플래그를 생성하는 것이 포함될 수 있습니다.

  이러한 변환은 훈련 및 예측 중에 동일하게 적용되어야 합니다. 왜냐하면 모델은 원시 입력 값이 아닌 변환된 특성에 대해 훈련되기 때문입니다. 데이터가 동일하게 변환되지 않으면 훈련되지 않은 값의 분포를 가진 데이터가 제공되기 때문에 모델이 제대로 작동하지 않습니다. 자세한 내용은 전처리 문제 섹션에서 학습-제공 편향에 대한 논의를 참조하세요.

• 훈련 중에는 전체 전달 변환이 수행되지만 예측 중에는 인스턴스 수준 변환이 수행됩니다 . 이 시나리오에서 변환은 미리 계산된 일부 통계를 사용하여 변환을 수행하므로 상태 저장형입니다. 훈련 중에 훈련 데이터 전체를 분석하여 예측 시 훈련 데이터, 평가 데이터 및 새 데이터를 변환하기 위한 최소값, 최대값, 평균 및 분산과 같은 수량을 계산합니다.

  예를 들어 훈련을 위해 숫자 특성을 정규화하려면 훈련 데이터 전체에 걸쳐 평균(μ)과 표준 편차(σ)를 계산합니다. 이 계산을 전체 전달 (또는 분석 ) 작업이라고 합니다. 예측을 위해 모델을 제공하면 학습 제공 편향을 방지하기 위해 새 데이터 포인트의 값이 정규화됩니다. 따라서 학습 중에 계산된 μ 및 σ 값은 다음과 같은 간단한 인스턴스 수준 작업인 특징 값을 조정하는 데 사용됩니다.

  $$ value_{scaled} = (value_{raw} - \mu) \div \sigma $$

  전체 전달 변환에는 다음이 포함됩니다.

  • 훈련 데이터 세트에서 계산된 최소 및 최대를 사용하여 MinMax 스케일링 수치 기능입니다.
  • 훈련 데이터 세트에서 계산된 μ 및 σ를 사용하는 표준 스케일링(z-점수 정규화) 수치 특징입니다.
  • 분위수를 사용하여 수치 특성을 버킷화합니다.
  • 중앙값(숫자 특성) 또는 최빈값(범주형 특성)을 사용하여 결측값을 대치합니다.
  • 입력 범주형 특성의 모든 고유 값(어휘)을 추출하여 문자열(명목 값)을 정수(색인)로 변환합니다.
  • TF-IDF를 계산하기 위해 모든 문서(인스턴스)에서 용어(특성 값)의 발생을 계산합니다.
  • 입력 특성의 PCA를 계산하여 데이터를 더 낮은 차원 공간(선형 종속 특성 포함)에 투영합니다.

  μ, σ, min 및 max 와 같은 통계를 계산하려면 훈련 데이터만 사용해야 합니다. 이러한 작업에 대한 테스트 및 평가 데이터를 추가하면 모델 교육을 위해 평가 및 테스트 데이터에서 정보가 유출 됩니다. 이는 시험 및 평가 결과의 신뢰성에 영향을 미칩니다. 모든 데이터 세트에 일관된 변환을 적용하려면 훈련 데이터에서 계산된 동일한 통계를 사용하여 테스트 및 평가 데이터를 변환합니다.

• 훈련 및 예측 중 기록 집계 . 여기에는 예측 작업에 대한 입력 신호로 비즈니스 집계, 파생 및 플래그를 생성하는 작업이 포함됩니다. 예를 들어 고객이 성향 모델을 구축할 수 있도록 최신성, 빈도 및 금전적(RFM) 지표를 생성합니다. 이러한 유형의 특성은 미리 계산되어 특성 저장소에 저장되어 모델 훈련, 일괄 채점, 온라인 예측 서비스 중에 사용할 수 있습니다. 훈련 및 예측 전에 이러한 집계에 추가 기능 엔지니어링(예: 변환 및 조정)을 수행할 수도 있습니다.

• 훈련 중에는 과거 집계가 수행되지만 예측 중에는 실시간 집계가 수행됩니다 . 이 접근 방식에는 시간 경과에 따른 실시간 값을 요약하여 기능을 생성하는 작업이 포함됩니다. 이 접근 방식에서는 집계할 인스턴스가 임시 창 절을 통해 정의됩니다. 예를 들어 지난 5분, 지난 10분, 지난 30분 및 기타 경로의 교통 지표를 기반으로 택시 여행 시간을 추정하는 모델을 학습하려는 경우 이 접근 방식을 사용할 수 있습니다. 간격. 또한 이 접근 방식을 사용하면 지난 3분 동안 계산된 온도 및 진동 값의 이동 평균을 기반으로 엔진 부품의 고장을 예측할 수 있습니다. 이러한 집계는 교육을 위해 오프라인으로 준비될 수 있지만 제공 중에 데이터 스트림에서 실시간으로 계산됩니다.

  보다 정확하게는 훈련 데이터를 준비할 때 집계된 값이 원시 데이터에 없으면 데이터 엔지니어링 단계에서 값이 생성됩니다. 원시 데이터는 일반적으로 (entity, timestamp, value) 형식으로 데이터베이스에 저장됩니다. 이전 예에서 entity 는 택시 경로의 경로 세그먼트 식별자이고 엔진 오류의 엔진 부품 식별자입니다. 창 작업을 사용하여 (entity, time_index, aggregated_value_over_time_window) 계산하고 집계 기능을 모델 교육을 위한 입력으로 사용할 수 있습니다.

  실시간(온라인) 예측을 위한 모델이 제공되면 모델은 집계된 값에서 파생된 기능을 입력으로 기대합니다. 따라서 Apache Beam과 같은 스트림 처리 기술을 사용하여 시스템으로 스트리밍되는 실시간 데이터 포인트의 집계를 계산할 수 있습니다. 스트림 처리 기술은 새로운 데이터 포인트가 도착할 때 시간 창을 기반으로 실시간 데이터를 집계합니다. 훈련 및 예측 전에 이러한 집계에 추가 기능 엔지니어링(예: 변환 및 조정)을 수행할 수도 있습니다.

Google Cloud의 ML 파이프라인

이 섹션에서는 관리형 서비스를 사용하여 Google Cloud에서 TensorFlow ML 모델을 학습시키고 제공하기 위한 일반적인 엔드 투 엔드 파이프라인의 핵심 구성요소를 설명합니다. 또한 데이터 사전 처리 작업의 다양한 범주를 구현할 수 있는 위치와 이러한 변환을 구현할 때 직면할 수 있는 일반적인 문제에 대해서도 설명합니다. tf.Transform 작동 방식 섹션에서는 TensorFlow Transform 라이브러리가 이러한 문제를 해결하는 데 어떻게 도움이 되는지 보여줍니다.

상위 수준 아키텍처

다음 다이어그램(그림 2)은 TensorFlow 모델을 훈련하고 제공하기 위한 일반적인 ML 파이프라인의 상위 수준 아키텍처를 보여줍니다. 다이어그램의 레이블 A, B, C는 데이터 전처리가 발생할 수 있는 파이프라인의 다양한 위치를 나타냅니다. 이러한 단계에 대한 자세한 내용은 다음 섹션에서 제공됩니다.

파이프라인은 다음 단계로 구성됩니다.

1. 원시 데이터를 가져온 후 테이블 형식 데이터는 BigQuery에 저장되고 이미지, 오디오, 동영상과 같은 기타 데이터는 Cloud Storage에 저장됩니다. 이 시리즈의 두 번째 부분에서는 BigQuery에 저장된 표 형식 데이터를 예로 사용합니다.
2. 데이터 엔지니어링(준비) 및 특성 엔지니어링은 Dataflow를 사용하여 대규모로 실행됩니다. 이 실행을 통해 Cloud Storage에 저장되는 ML 지원 학습, 평가, 테스트 세트가 생성됩니다. 이상적으로 이러한 데이터 세트는 TensorFlow 계산에 최적화된 형식인 TFRecord 파일로 저장됩니다.
3. TensorFlow 모델 트레이너 패키지는 Vertex AI Training에 제출됩니다. Vertex AI Training은 이전 단계에서 사전 처리된 데이터를 사용하여 모델을 학습시킵니다. 이 단계의 출력은 Cloud Storage로 내보내지는 학습된 TensorFlow SavedModel 입니다.
4. 학습된 TensorFlow 모델은 온라인 예측에 사용할 수 있도록 REST API가 포함된 서비스로 Vertex AI Prediction에 배포됩니다. 일괄 예측 작업에도 동일한 모델을 사용할 수 있습니다.
5. 모델이 REST API로 배포된 후 클라이언트 앱과 내부 시스템은 일부 데이터 포인트가 포함된 요청을 보내고 예측이 포함된 모델로부터 응답을 받아 API를 호출할 수 있습니다.
6. 이 파이프라인을 조정하고 자동화하려면 Vertex AI Pipelines를 스케줄러로 사용하여 데이터 준비, 모델 학습, 모델 배포 단계를 호출할 수 있습니다.

Vertex AI Feature Store를 사용하여 입력 특성을 저장하여 예측할 수도 있습니다. 예를 들어 최신 원시 데이터에서 엔지니어링된 특성을 주기적으로 만들고 Vertex AI Feature Store에 저장할 수 있습니다. 클라이언트 앱은 Vertex AI Feature Store에서 필요한 입력 기능을 가져와 모델에 전송하여 예측을 받습니다.

전처리를 수행할 위치

그림 2에서 라벨 A, B, C는 데이터 사전 처리 작업이 BigQuery, Dataflow 또는 TensorFlow에서 수행될 수 있음을 보여줍니다. 다음 섹션에서는 이러한 각 옵션의 작동 방식을 설명합니다.

옵션 A: BigQuery

일반적으로 로직은 다음 작업을 위해 BigQuery에서 구현됩니다.

• 샘플링: 데이터에서 무작위로 하위 집합을 선택합니다.
• 필터링: 관련이 없거나 유효하지 않은 인스턴스를 제거합니다.
• 파티셔닝: 데이터를 분할하여 훈련, 평가 및 테스트 세트를 생성합니다.

BigQuery SQL 스크립트는 그림 2의 데이터 처리 단계인 Dataflow 사전 처리 파이프라인의 소스 쿼리로 사용할 수 있습니다. 예를 들어 시스템이 캐나다에서 사용되고 데이터 웨어하우스에 전 세계의 트랜잭션이 있는 경우 캐나다 전용 학습 데이터를 얻는 것은 BigQuery에서 가장 잘 수행됩니다. BigQuery의 특성 추출은 간단하고 확장 가능하며 인스턴스 수준 및 기록 집계 특성 변환 구현을 지원합니다.

하지만 일괄 예측(점수)을 위해 모델을 사용하는 경우 또는 특성이 BigQuery에서 사전 계산되었지만 온라인 예측 중에 사용하기 위해 Vertex AI Feature Store에 저장되는 경우에만 특성 추출에 BigQuery를 사용하는 것이 좋습니다. 온라인 예측을 위해 모델을 배포할 계획이고 온라인 특성 저장소에 엔지니어링된 특성이 없는 경우 SQL 사전 처리 작업을 복제하여 다른 시스템이 생성하는 원시 데이터 포인트를 변환해야 합니다. 즉, 로직을 두 번 구현해야 합니다. 한 번은 BigQuery에서 학습 데이터를 전처리하기 위해 SQL에서, 두 번째는 예측을 위한 온라인 데이터 포인트를 전처리하기 위해 모델을 사용하는 앱의 로직에서 구현해야 합니다.

예를 들어 클라이언트 앱이 Java로 작성된 경우 Java로 논리를 다시 구현해야 합니다. 이 문서 뒷부분에 나오는 전처리 문제 의 학습 제공 편향 섹션에 설명된 대로 구현 불일치로 인해 오류가 발생할 수 있습니다. 또한 두 가지 서로 다른 구현을 유지하는 데 추가 오버헤드가 발생합니다. 학습 데이터를 사전 처리하기 위해 SQL의 로직을 변경할 때마다 제공 시 데이터를 사전 처리하도록 Java 구현을 변경해야 합니다.

일괄 예측(예: Vertex AI 일괄 예측 사용)에만 모델을 사용하고 점수 매기기 데이터가 BigQuery에서 가져온 경우 이러한 사전 처리 작업을 BigQuery SQL 스크립트의 일부로 구현할 수 있습니다. 이 경우 동일한 전처리 SQL 스크립트를 사용하여 훈련 및 채점 데이터를 모두 준비할 수 있습니다.

전체 전달 상태 저장 변환은 BigQuery 구현에 적합하지 않습니다. 전체 전달 변환에 BigQuery를 사용하는 경우 숫자 특성을 확장하기 위한 평균 및 분산과 같은 상태 저장 변환에 필요한 수량을 저장하는 보조 테이블이 필요합니다. 또한 BigQuery에서 SQL을 사용하여 전체 전달 변환을 구현하면 SQL 스크립트의 복잡성이 증가하고 학습 및 채점 SQL 스크립트 간에 복잡한 종속성이 생성됩니다.

옵션 B: 데이터 흐름

그림 2에 표시된 것처럼 Apache Beam에서 계산 비용이 많이 드는 사전 처리 작업을 구현하고 Dataflow를 사용하여 대규모로 실행할 수 있습니다. Dataflow는 일괄 및 스트림 데이터 처리를 위한 완전 관리형 자동 확장 서비스입니다. Dataflow를 사용하면 BigQuery와 달리 데이터 처리를 위해 외부 특수 라이브러리를 사용할 수도 있습니다.

Dataflow는 인스턴스 수준 변환과 기록 및 실시간 집계 특성 변환을 수행할 수 있습니다. 특히 ML 모델이 total_number_of_clicks_last_90sec 와 같은 입력 기능을 예상하는 경우 Apache Beam 창 함수는 실시간(스트리밍) 이벤트 데이터(예: 클릭 이벤트)의 기간 값 집계를 기반으로 이러한 기능을 계산할 수 있습니다. 변환 세분성 에 대한 이전 논의에서는 이를 "훈련 중에는 과거 집계, 예측 중에는 실시간 집계"라고 했습니다.

다음 다이어그램(그림 3)은 거의 실시간 예측을 위해 스트림 데이터를 처리하는 데 있어 Dataflow의 역할을 보여줍니다.

그림 3에 표시된 것처럼 처리 중에 데이터 포인트 라는 이벤트가 Pub/Sub 로 수집됩니다. Dataflow는 이러한 데이터 포인트를 사용하고 시간 경과에 따른 집계를 기반으로 특성을 계산한 다음 예측을 위해 배포된 ML 모델 API를 호출합니다. 그런 다음 예측은 아웃바운드 Pub/Sub 큐로 전송됩니다. Pub/Sub에서 예측은 모니터링 또는 제어와 같은 다운스트림 시스템에서 사용되거나 원래 요청 클라이언트로 푸시백(예: 알림)될 수 있습니다. 실시간 가져오기를 위해 예측을 Cloud Bigtable 과 같은 지연 시간이 짧은 데이터 저장소에 저장할 수도 있습니다. Cloud Bigtable을 사용하면 이러한 실시간 집계를 누적하고 저장하여 예측이 필요할 때 조회할 수 있습니다.

동일한 Apache Beam 구현을 사용하여 BigQuery와 같은 오프라인 데이터 저장소에서 가져온 학습 데이터를 일괄 처리하고 온라인 예측을 제공하기 위해 실시간 데이터를 스트림 처리할 수 있습니다.

그림 2에 표시된 아키텍처와 같은 다른 일반적인 아키텍처에서는 클라이언트 앱이 온라인 예측을 위해 배포된 모델 API를 직접 호출합니다. 이 경우 학습 데이터를 준비하기 위해 Dataflow에서 사전 처리 작업을 구현하면 모델로 직접 이동하는 예측 데이터에 작업이 적용되지 않습니다. 따라서 이러한 변환은 온라인 예측을 제공하는 동안 모델에 통합되어야 합니다.

Dataflow를 사용하면 필요한 통계를 대규모로 계산하여 전체 전달 변환을 수행할 수 있습니다. 그러나 이러한 통계는 예측 데이터 포인트를 변환하기 위해 예측 중에 사용할 어딘가에 저장되어야 합니다. TensorFlow Transform( tf.Transform ) 라이브러리를 사용하면 이러한 통계를 다른 곳에 저장하는 대신 모델에 직접 포함할 수 있습니다. 이 접근 방식은 나중에 tf.Transform 작동 방식 에서 설명됩니다.

옵션 C: TensorFlow

그림 2에 표시된 것처럼 TensorFlow 모델 자체에서 데이터 전처리 및 변환 작업을 구현할 수 있습니다. 그림에 표시된 것처럼 TensorFlow 모델 학습을 위해 구현하는 전처리는 예측을 위해 모델을 내보내고 배포할 때 모델의 필수 부분이 됩니다. TensorFlow 모델의 변환은 다음 방법 중 하나로 수행할 수 있습니다.

• input_fn 함수와 serving_fn 함수에서 모든 인스턴스 수준 변환 논리를 구현합니다. input_fn 함수는 모델 학습을 위해 tf.data.Dataset API를 사용하여 데이터세트를 준비합니다. serving_fn 함수는 예측을 위한 데이터를 수신하고 준비합니다.
• Keras 전처리 레이어를 사용하거나 맞춤 레이어를 생성하여 TensorFlow 모델에 직접 변환 코드를 추가합니다.

serving_fn 함수의 변환 논리 코드는 온라인 예측을 위해 저장된 모델의 제공 인터페이스를 정의합니다. serving_fn 함수의 변환 논리 코드에서 훈련 데이터를 준비하는 데 사용된 것과 동일한 변환을 구현하면 새로운 예측 데이터 포인트가 제공될 때 동일한 변환이 적용됩니다.

그러나 TensorFlow 모델은 각 데이터 포인트를 독립적으로 또는 소규모 배치로 처리하기 때문에 모든 데이터 포인트에서 집계를 계산할 수는 없습니다. 결과적으로 TensorFlow 모델에서는 전체 전달 변환을 구현할 수 없습니다.

전처리 문제

다음은 데이터 전처리 구현의 주요 과제입니다.

• 훈련 제공 편향 . 훈련-제공 편향은 훈련 중과 제공 중 효율성(예측 성능)의 차이를 나타냅니다. 이러한 편향은 학습 파이프라인과 제공 파이프라인에서 데이터를 처리하는 방법 간의 불일치로 인해 발생할 수 있습니다. 예를 들어 모델이 로그 변환된 특성에 대해 학습되었지만 제공 중에 원시 특성이 표시되는 경우 예측 출력이 정확하지 않을 수 있습니다.

  변환이 모델 자체의 일부가 되면 앞서 옵션 C: TensorFlow 에서 설명한 대로 인스턴스 수준 변환을 처리하는 것이 간단할 수 있습니다. 이 경우 모델 제공 인터페이스( serving_fn 함수)는 원시 데이터를 예상하는 반면, 모델은 출력을 계산하기 전에 이 데이터를 내부적으로 변환합니다. 변환은 원시 훈련 및 예측 데이터 포인트에 적용된 것과 동일합니다.

• 전체 전달 변환 . TensorFlow 모델에서는 크기 조정 및 정규화 변환과 같은 전체 전달 변환을 구현할 수 없습니다. 전체 전달 변환에서는 옵션 B: 데이터 흐름 에 설명된 대로 일부 통계(예: 숫자 특성을 조정하기 위한 max 값 및 min )를 미리 학습 데이터에 대해 계산해야 합니다. 그런 다음 새 원시 데이터 포인트를 인스턴스 수준 변환으로 변환하여 학습 제공 편향을 방지하기 위해 예측을 위한 모델 제공 중에 사용할 값을 어딘가에 저장해야 합니다. TensorFlow Transform( tf.Transform ) 라이브러리를 사용하여 TensorFlow 모델에 통계를 직접 삽입할 수 있습니다. 이 접근 방식은 나중에 tf.Transform 작동 방식 에서 설명됩니다.

• 더 나은 교육 효율성을 위해 데이터를 미리 준비합니다 . 모델의 일부로 인스턴스 수준 변환을 구현하면 훈련 프로세스의 효율성이 저하될 수 있습니다. 이러한 성능 저하가 발생하는 이유는 각 시대마다 동일한 훈련 데이터에 동일한 변환이 반복적으로 적용되기 때문입니다. 1,000개의 기능이 포함된 원시 훈련 데이터가 있고 인스턴스 수준 변환을 혼합하여 10,000개의 기능을 생성한다고 가정해 보겠습니다. 이러한 변환을 모델의 일부로 구현하고 모델에 원시 훈련 데이터를 제공하는 경우 이러한 10,000개의 작업은 각 인스턴스에 N 번 적용됩니다. 여기서 N은 에포크 수입니다. 또한 가속기(GPU 또는 TPU)를 사용하는 경우 CPU가 이러한 변환을 수행하는 동안 가속기들은 유휴 상태로 유지되므로 값비싼 가속기를 효율적으로 사용하지 못합니다.

  이상적으로는 옵션 B: 데이터 흐름 에 설명된 기술을 사용하여 훈련 전에 훈련 데이터를 변환합니다. 여기서 10,000개의 변환 작업은 각 훈련 인스턴스에 한 번만 적용됩니다. 그런 다음 변환된 훈련 데이터가 모델에 제공됩니다. 더 이상 변환이 적용되지 않으며 가속기는 항상 사용 중입니다. 또한 Dataflow를 사용하면 완전 관리형 서비스를 통해 대규모 데이터를 대규모로 전처리하는 데 도움이 됩니다.

  훈련 데이터를 미리 준비하면 훈련 효율성이 향상될 수 있습니다. 그러나 모델 외부에서 변환 로직을 구현하면( 옵션 A: BigQuery 또는 옵션 B: Dataflow 에 설명된 접근 방식) 학습-제공 편향 문제가 해결되지 않습니다. 훈련과 예측 모두에 사용하기 위해 가공된 특성을 특성 저장소에 저장하지 않는 한 모델 인터페이스는 변환된 데이터를 기대하기 때문에 예측을 위해 들어오는 새 데이터 포인트에 적용할 어딘가에 변환 논리를 구현해야 합니다. TensorFlow Transform( tf.Transform ) 라이브러리는 다음 섹션에 설명된 대로 이 문제를 해결하는 데 도움이 될 수 있습니다.

tf.Transform 작동 방식

tf.Transform 라이브러리는 전체 전달이 필요한 변환에 유용합니다. tf.Transform 라이브러리의 출력은 인스턴스 수준 변환 논리와 전체 전달 변환에서 계산된 통계를 나타내는 TensorFlow 그래프로 내보내어 학습 및 제공에 사용됩니다. 훈련과 제공 모두에 동일한 그래프를 사용하면 두 단계 모두 동일한 변환이 적용되므로 편향을 방지할 수 있습니다. 또한 tf.Transform 라이브러리는 Dataflow의 일괄 처리 파이프라인에서 대규모로 실행되어 학습 데이터를 미리 준비하고 학습 효율성을 향상시킬 수 있습니다.

다음 다이어그램(그림 4)은 tf.Transform 라이브러리가 훈련 및 예측을 위해 데이터를 사전 처리하고 변환하는 방법을 보여줍니다. 프로세스는 다음 섹션에 설명되어 있습니다.

훈련 및 평가 데이터 변환

tf.Transform Apache Beam API에 구현된 변환을 사용하여 원시 학습 데이터를 사전 처리하고 Dataflow에서 대규모로 실행합니다. 전처리는 다음 단계로 수행됩니다.

• 분석 단계: 분석 단계에서는 상태 저장 변환에 필요한 통계(예: 평균, 분산, 분위수)가 전체 전달 작업을 통해 학습 데이터에 대해 계산됩니다. 이 단계에서는 변환 아티팩트( transform_fn 그래프 포함) 세트를 생성합니다. transform_fn 그래프는 변환 논리를 인스턴스 수준 작업으로 포함하는 TensorFlow 그래프입니다. 분석 단계에서 계산된 통계가 상수로 포함됩니다.
• 변환 단계: 변환 단계에서는 변환 단계에서 transform_fn 그래프가 원시 훈련 데이터에 적용됩니다. 여기서 계산된 통계는 인스턴스 수준 방식으로 데이터 레코드를 처리(예: 숫자 열 크기 조정)하는 데 사용됩니다.

이와 같은 2단계 접근 방식은 전체 전달 변환을 수행하는 전처리 문제를 해결합니다.

평가 데이터를 전처리할 때는 transform_fn 그래프의 로직과 학습 데이터의 분석 단계에서 계산된 통계를 사용하여 인스턴스 수준 작업만 적용됩니다. 즉, 평가 데이터의 숫자 특징을 정규화하기 위해 μ 및 σ와 같은 새로운 통계를 계산하기 위해 전체 전달 방식으로 평가 데이터를 분석하지 않습니다. 대신 훈련 데이터에서 계산된 통계를 사용하여 인스턴스 수준 방식으로 평가 데이터를 변환합니다.

변환된 학습 및 평가 데이터는 모델 학습에 사용되기 전에 Dataflow를 사용하여 대규모로 준비됩니다. 이 배치 데이터 준비 프로세스는 교육 효율성을 향상시키기 위해 데이터를 앞쪽으로 준비하는 전처리 과제를 해결합니다. 그림 4에서 볼 수 있듯이 모델 내부 인터페이스는 변환 된 기능을 기대합니다.

내보낸 모델에 변환을 첨부합니다

언급 한 바와 같이, tf.Transform 파이프 라인에 의해 생성 된 transform_fn 그래프는 내보내는 텐서 플로 그래프로 저장됩니다. 내보낸 그래프는 인스턴스 레벨 작업으로 변환 로직으로 구성되며 모든 통계는 전체 패스 변환으로 그래프 상수로 계산됩니다. 훈련 된 모델이 서빙을 위해 내보낼 때, transform_fn 그래프는 serving_fn 함수의 일부로 SaveedModel에 연결됩니다.

예측 모델을 제공하는 동안 모델 서빙 인터페이스는 데이터 포인트가 원시 형식 (즉, 변환 전에)으로 예상됩니다. 그러나 모델 내부 인터페이스는 변환 된 형식의 데이터를 기대합니다.

이제 모델의 일부인 transform_fn 그래프는 들어오는 데이터 포인트에 모든 전처리 로직을 적용합니다. 예측 중에 인스턴스 수준 작동에서 저장된 상수 (μ 및 σ와 같은 숫자 특징을 정상화)를 사용합니다. 따라서 transform_fn 그래프는 원시 데이터 포인트를 변환 된 형식으로 변환합니다. 변환 된 형식은 그림 4에 표시된 것처럼 예측을 생성하기 위해 모델 내부 인터페이스에 의해 예상되는 것입니다.

이 메커니즘은 훈련 및 평가 데이터를 변환하는 데 사용되는 동일한 논리 (구현)가 예측 서빙 중에 새로운 데이터 포인트를 변환하기 위해 적용되기 때문에 훈련-서빙 비대행의 전처리 도전을 해결합니다.

전처리 옵션 요약

다음 표는이 문서에서 논의한 데이터 전처리 옵션을 요약합니다. 테이블에서 "N/A"는 "적용 할 수 없음"을 나타냅니다.

^* Tensorflow를 사용하면 교차, 임베딩 및 1 가지 인코딩과 같은 변환은 feature_columns 열로 선언적으로 수행되어야합니다.

다음은 무엇입니까

• tf.Transform 파이프 라인을 구현하고 DataFlow를 사용하여 실행하려면이 시리즈의 2 부, Tensorflow 변환을 사용하여 ML에 대한 데이터 전처리를 읽으십시오.
• Google Cloud의 Tensorflow 와 함께 ML에서 Coursera 전문화를 수행하십시오.
• ML 규칙 의 ML 엔지니어링 모범 사례에 대해 알아보십시오.
• 더 많은 참조 아키텍처, 다이어그램 및 모범 사례를 보려면 TFX 클라우드 솔루션을 탐색하십시오.

이 문서는 감독 학습 과제에 중점을 둔 데이터 엔지니어링 및 기능 엔지니어링 주제를 탐구하는 두 부분으로 구성된 시리즈 중 첫 번째 문서입니다. 이 첫 번째 부분은 Google Cloud의 ML 파이프 라인에서 전처리 데이터에 대한 모범 사례에 대해 설명합니다. 이 문서는 Tensorflow 및 오픈 소스 Tensorflow Transform ( tf.Transform ) 라이브러리를 사용하여 데이터를 준비하고 모델을 훈련하며 예측 모델을 제공하는 데 중점을 둡니다. 이 문서는 ML에 대한 전처리 데이터의 과제를 강조하고 Google Cloud에서 데이터 변환을 효과적으로 수행하기위한 옵션 및 시나리오를 설명합니다.

이 문서는 BigQuery , DataFlow , Vertex AI 및 Tensorflow Keras API에 익숙하다고 가정합니다.

두 번째 문서 인 Google Cloud를 사용한 ML에 대한 데이터 전처리는 tf.Transform 파이프 라인을 구현하는 방법에 대한 단계별 자습서를 제공합니다.

소개

ML을 사용하면 데이터에서 복잡하고 잠재적으로 유용한 패턴을 자동으로 찾는 데 도움이됩니다. 이러한 패턴은 ML 모델로 압축되어 새로운 데이터 포인트에 사용할 수 있습니다. 예측 또는 추론 수행 이라는 프로세스입니다.

ML 모델을 구축하는 것은 다단계 프로세스입니다. 각 단계는 고유 한 기술 및 개념적 과제를 제시합니다. 이 두 부분으로 구성된 시리즈는 감독 된 학습 작업과 소스 데이터를 선택, 변환 및 증강하여 대상 변수에 대한 강력한 예측 신호를 생성하는 프로세스에 중점을 둡니다. 이러한 운영은 도메인 지식을 데이터 과학 기술과 결합합니다. 운영은 기능 엔지니어링 의 본질입니다.

실제 ML 모델에 대한 교육 데이터 세트의 크기는 하나의 Terabyte (TB)보다 쉽게 ​​동일 할 수 있습니다. 따라서 이러한 데이터 세트를 효율적이고 분배하려면 대규모 데이터 처리 프레임 워크가 필요합니다. ML 모델을 사용하여 예측을 할 때는 새로운 데이터 포인트의 교육 데이터에 사용한 것과 동일한 변환을 적용해야합니다. 동일한 변환을 적용함으로써 라이브 데이터 세트를 ML 모델에 모델이 기대하는 방식으로 제시합니다.

이 문서는 인스턴스 수준, 풀 패스 및 시간 창 집계와 같은 기능 엔지니어링 작업의 다양한 수준에 대한 이러한 과제에 대해 설명합니다. 이 문서는 또한 Google Cloud에서 ML의 데이터 변환을 수행하는 옵션 및 시나리오를 설명합니다.

이 문서는 또한 데이터 전처리 파이프 라인을 통해 인스턴스 수준 및 전체 패스 데이터 변환을 모두 정의 할 수있는 Tensorflow의 라이브러리 인 Tensorflow Transform ( tf.Transform )의 개요를 제공합니다. 이 파이프 라인은 Apache Beam 으로 실행되며 모델이 제공 될 때와 동일한 변환을 적용 할 수있는 아티팩트를 생성합니다.

ML에 대한 전처리 데이터

이 섹션에서는 데이터 전처리 작업 및 데이터 준비 단계를 소개합니다. 또한 전처리 작업의 유형과 세분성에 대해서도 설명합니다.

기능 엔지니어링과 비교하여 데이터 엔지니어링

ML의 데이터 전처리에는 데이터 엔지니어링 및 기능 엔지니어링이 모두 포함됩니다. 데이터 엔지니어링은 원시 데이터를 준비된 데이터 로 변환하는 프로세스입니다. 기능 엔지니어링은 준비된 데이터를 조정하여 ML 모델에서 예상되는 기능을 만듭니다. 이 용어에는 다음과 같은 의미가 있습니다.

원시 데이터 (또는 단지 데이터 )

ML에 대한 사전 준비없이 소스 형태의 데이터. 이와 관련하여 데이터는 원시 형태 (데이터 호수) 또는 변환 된 형태 (데이터웨어 하우스) 일 수 있습니다. 데이터웨어 하우스에있는 변환 된 데이터는 원래 원시 양식에서 분석에 사용될 수 있습니다. 그러나 이러한 맥락에서 원시 데이터는 데이터가 ML 작업을 위해 특별히 준비되지 않았 음을 의미합니다. 데이터는 예측을 위해 ML 모델을 호출하는 스트리밍 시스템에서 전송되면 원시 데이터로 간주됩니다.

준비된 데이터

ML 작업을 위해 준비된 양식의 데이터 세트 : 데이터 소스가 구문 분석, 가입 및 표 형식으로 넣었습니다. 준비된 데이터는 집계 및 오른쪽 세분성으로 요약됩니다. 예를 들어, 데이터 세트의 각 행은 고유 한 고객을 나타내고 각 열은 지난 6 주 동안의 총계와 같이 고객에 대한 요약 정보를 나타냅니다. 준비된 데이터 테이블에서, 관련없는 열이 삭제되었고, 유효하지 않은 레코드가 필터링되었습니다. 감독 된 학습 과제의 경우 대상 기능이 있습니다.

엔지니어링 된 기능

모델이 기대하는 조정 된 기능, 즉 준비된 데이터 세트의 열에서 특정 ML 특정 작업을 수행하여 작성된 기능, 나중에 설명 된대로 교육 및 예측 중 모델에 대한 새로운 기능을 만드는 데이터 세트. 전처리 작업 에서. 이러한 작업의 예로는 숫자 열을 0과 1 사이의 값으로 스케일링, 클리핑 값 및 1 hot 코딩 범주 형 기능을 포함합니다.

다음 다이어그램 인 그림 1은 전처리 데이터를 준비하는 데 관련된 단계를 보여줍니다.

실제로, 동일한 소스의 데이터는 종종 다른 준비 단계에 있습니다. 예를 들어, 데이터웨어 하우스의 테이블의 필드는 엔지니어링 된 기능으로 직접 사용할 수 있습니다. 동시에, 같은 테이블의 다른 필드는 엔지니어링 된 기능이되기 전에 변환을 거쳐야 할 수도 있습니다. 마찬가지로, 데이터 엔지니어링 및 기능 엔지니어링 작업은 동일한 데이터 전처리 단계에서 결합 될 수 있습니다.

전처리 작업

데이터 전처리에는 여러 작업이 포함됩니다. 각 작업은 ML이 더 나은 예측 모델을 구축 할 수 있도록 설계되었습니다. 이러한 전처리 작업의 세부 사항은이 문서의 범위를 벗어나지 만 일부 작업은이 섹션에서 간단히 설명되어 있습니다.

구조화 된 데이터의 경우 데이터 전처리 작업에는 다음이 포함됩니다.

• 데이터 정리 : 원시 데이터로부터 값이 손상되거나 유효하지 않은 레코드를 제거하거나 수정하고 많은 열이 누락 된 레코드를 제거합니다.
• 인스턴스 선택 및 파티셔닝 : 입력 데이터 세트에서 데이터 포인트를 선택하여 교육, 평가 (유효성 검사) 및 테스트 세트를 만듭니다. 이 프로세스에는 반복 가능한 무작위 샘플링, 소수 클래스 오버 샘플링 및 계층화 된 파티셔닝 기술이 포함됩니다.
• 기능 튜닝 : 숫자 값 스케일링 및 정규화, 결 측값의 영향, 클리핑 특이 치 및 분포가 왜곡 된 값 조정을 포함하는 ML의 기능 품질 향상.
• 기능 변환 : 숫자 기능을 범주 형 기능 ( 버킷 화를 통해)으로 변환하고 범주 형 기능을 숫자 표현으로 변환합니다 (1- 호트 인코딩, 카운트가있는 학습 , 스파스 기능 임베드 등). 일부 모델은 숫자 또는 범주 형 기능에서만 작동하는 반면 다른 모델은 혼합 유형 기능을 처리 할 수 ​​있습니다. 모델이 두 유형을 모두 처리하더라도 동일한 기능의 다른 표현 (숫자 및 범주 형)의 혜택을 누릴 수 있습니다.
• 기능 추출 : PCA , 임베딩 추출 및 해싱 과 같은 기술을 사용하여 더 낮은 차원,보다 강력한 데이터 표현을 만들어 기능의 수를 줄입니다.
• 기능 선택 : 필터 또는 래퍼 메소드를 사용하여 모델 교육을위한 입력 기능의 하위 집합을 선택하고 관련이 없거나 중복 된 것들을 무시합니다. 기능 선택에는 기능에 많은 값이 없으면 기능을 단순히 삭제하는 것도 포함될 수 있습니다.
• 기능 구성 : 다항식 확장 (일 변량 수학적 함수 사용)과 같은 일반적인 기술을 사용하여 새로운 기능을 만들거나 기능 교차 (기능 상호 작용을 포착하기 위해). ML 사용 사례의 도메인에서 비즈니스 로직을 사용하여 기능을 구성 할 수도 있습니다.

구조화되지 않은 데이터 (예 : 이미지, 오디오 또는 텍스트 문서)를 사용하면 딥 러닝은 모델 아키텍처로 접어 도메인 지식 기반 기능 엔지니어링을 대체합니다. 컨볼 루션 레이어 는 자동 기능 전 처리기입니다. 올바른 모델 아키텍처를 구성하려면 데이터에 대한 경험적 지식이 필요합니다. 또한 다음과 같은 양의 전처리가 필요합니다.

• 텍스트 문서의 경우 : 줄기 및 레마 화 , TF-IDF 계산 및 N- 그램 추출, 삽입 조회.
• 이미지 : 클리핑, 크기 조정, 자르기, 가우스 블러 및 카나리아 필터.
• 모든 유형의 데이터 (텍스트 및 이미지 포함) : 전송 학습은 완전히 훈련 된 모델의 모든 계층을 기능 엔지니어링 단계로 취급합니다.

전처리 과립

이 섹션에서는 데이터 변환 유형의 세분성에 대해 설명합니다. 교육 데이터에 적용되는 변환을 사용하여 예측을 위해 새로운 데이터 포인트를 준비 할 때이 관점이 중요한 이유를 보여줍니다.

전처리 및 변환 작업은 작동 입도에 기초하여 다음과 같이 분류 할 수 있습니다.

• 교육 및 예측 중 인스턴스 수준 변환 . 이들은 간단한 변환이며, 동일한 인스턴스의 값 만 변환에 필요합니다. 예를 들어, 인스턴스 수준 변환에는 기능의 값을 일부 임계 값으로 클리핑하고, 다른 기능을 다항식으로 확장하거나, 두 가지 기능을 곱하거나, 두 가지 기능을 비교하여 부울 플래그를 생성하는 것이 포함될 수 있습니다.

  모델은 원시 입력 값이 아닌 변환 된 기능에 대해 교육을 받기 때문에 이러한 변환은 훈련 및 예측 중에 동일하게 적용되어야합니다. 데이터가 동일하게 변환되지 않으면 모델은 훈련되지 않은 값의 분포가있는 데이터가 표시되기 때문에 제시되지 않기 때문에 모델이 잘못 작동합니다. 자세한 내용은 전처리 과제 섹션에서 훈련-서빙 왜곡에 대한 논의를 참조하십시오.

• 훈련 중에 전체 통과 변환이지만 예측 중 인스턴스 수준 변환 . 이 시나리오에서는 변환이 전환 된 통계를 사용하여 변환을 수행하기 때문에 변환이 상태입니다. 훈련하는 동안 교육 데이터의 전신을 분석하여 교육 데이터 변환, 평가 데이터 및 예측 시간에 새로운 데이터를위한 최소, 최대, 평균 및 차이와 같은 수량을 계산합니다.

  예를 들어, 훈련을위한 숫자 기능을 정상화하려면 전체 교육 데이터에서 평균 (μ) 및 표준 편차 (σ)를 계산합니다. 이 계산을 풀 패스 (또는 분석 ) 작업이라고합니다. 예측 모델을 제공 할 때, 훈련-보존 왜곡을 피하기 위해 새로운 데이터 포인트의 값이 정규화됩니다. 따라서 훈련 중에 계산 된 μ 및 σ 값은 기능 값을 조정하는 데 사용됩니다. 이는 다음과 같은 간단한 인스턴스 수준 작동입니다.

  $$ value_{scaled} = (value_{raw} - \mu) \div \sigma $$

  전체 통과 변환에는 다음이 포함됩니다.

  • Minmax 스케일링 교육 데이터 세트에서 계산 된 Min 및 Max를 사용한 숫자 기능.
  • 훈련 데이터 세트에서 계산 된 μ 및 σ를 사용한 표준 스케일링 (z- 점수 정규화) 수치 특징.
  • Quantiles를 사용한 수치 기능 버킷
  • 중앙값 (숫자 특징) 또는 모드 (범주 형 기능)를 사용하여 결 측값을 전가합니다.
  • 입력 범주 형 기능의 모든 고유 한 값 (어휘)을 추출하여 문자열 (공칭 값)을 정수 (인덱스)로 변환합니다.
  • TF-IDF에 대해 계산하기 위해 모든 문서 (인스턴스)에서 용어 (기능 값)의 발생을 계산합니다.
  • 입력 기능의 PCA를 계산하여 데이터를 낮은 차원 공간으로 투사합니다 (선형 종속 기능 포함).

  훈련 데이터 만 사용하여 μ, σ, min 및 max 와 같은 통계를 계산해야합니다. 이러한 작업에 대한 테스트 및 평가 데이터를 추가하면 모델을 훈련시키기 위해 평가 및 테스트 데이터에서 정보를 유출하는 것 입니다. 그렇게하면 테스트 및 평가 결과의 신뢰성에 영향을 미칩니다. 모든 데이터 세트에 일관된 변환을 적용하려면 교육 데이터에서 계산 된 동일한 통계를 사용하여 테스트 및 평가 데이터를 변환합니다.

• 훈련과 예측 중 역사적 집계 . 여기에는 예측 작업에 대한 입력 신호로 비즈니스 집계, 파생 및 플래그를 생성하는 것이 포함됩니다. 예를 들어, 고객이 성향 모델을 구축 할 수 있도록 성, RFM (RFM) 메트릭을 생성합니다. 이러한 유형의 기능은 모델 교육, 배치 스코어링 및 온라인 예측 서빙 중에 사용할 수있는 기능 저장소에 미리 계산 및 저장 될 수 있습니다. 훈련 및 예측 전에 이러한 집계에 추가 기능 엔지니어링 (예 : 변환 및 튜닝)을 수행 할 수도 있습니다.

• 훈련 중 역사적 집계이지만 예측 중 실시간 집계 . 이 접근법에는 시간이 지남에 따라 실시간 값을 요약하여 기능을 작성하는 것이 포함됩니다. 이 접근법에서, 집계 할 인스턴스는 시간적 창 절을 통해 정의된다. 예를 들어, 지난 5 분, 지난 30 분, 마지막 30 분 동안 경로의 트래픽 메트릭을 기준으로 택시 여행 시간을 추정하는 모델을 훈련하려면이 접근 방식을 사용할 수 있습니다. 간격. 이 접근법을 사용하여 지난 3 분 동안 계산 된 온도 및 진동 값의 이동 평균을 기준으로 엔진 부품의 고장을 예측할 수 있습니다. 이러한 집계는 훈련을 위해 오프라인으로 준비 될 수 있지만 서빙 중에 데이터 스트림에서 실시간으로 계산됩니다.

  보다 정확하게, 교육 데이터를 준비 할 때, 집계 된 값이 원시 데이터에 있지 않으면 데이터 엔지니어링 단계에서 값이 생성됩니다. 원시 데이터는 일반적으로 (entity, timestamp, value) 형식의 데이터베이스에 저장됩니다. 이전 예제에서 entity 택시 경로의 경로 세그먼트 식별자 및 엔진 고장의 엔진 부품 식별자입니다. 창화 작업을 사용하여 컴퓨팅 (entity, time_index, aggregated_value_over_time_window) 을 컴퓨팅하고 모델 교육의 입력으로 사용할 수 있습니다.

  실시간 (온라인) 예측 모델이 제공되면 모델은 집계 된 값에서 파생 된 기능이 입력으로 예상됩니다. 따라서 Apache Beam과 같은 스트림 처리 기술을 사용하여 시스템에 스트리밍 된 실시간 데이터 포인트에서 집계를 계산할 수 있습니다. 스트림 처리 기술은 새로운 데이터 포인트가 도착함에 따라 시간 Windows를 기반으로 실시간 데이터를 집계합니다. 훈련 및 예측 전에 이러한 집계에 추가 기능 엔지니어링 (예 : 변환 및 튜닝)을 수행 할 수도 있습니다.

Google Cloud의 ML 파이프 라인

이 섹션에서는 전형적인 엔드 투 엔드 파이프 라인의 핵심 구성 요소에 대해 설명하여 관리 서비스를 사용하여 Google Cloud에서 Tensorflow ML 모델을 교육하고 제공합니다. 또한 다양한 범주의 데이터 전처리 작업을 구현할 수있는 위치와 이러한 변환을 구현할 때 직면 할 수있는 일반적인 과제에 대해 설명합니다. TF.Transform Works 섹션은 TensorFlow Transform 라이브러리가 이러한 과제를 해결하는 데 도움이되는 방법을 보여줍니다.

상위 수준 아키텍처

다음 다이어그램 인 그림 2는 Tensorflow 모델을 훈련하고 제공하기위한 일반적인 ML 파이프 라인의 높은 수준의 아키텍처를 보여줍니다. 다이어그램의 레이블 A, B 및 C는 데이터 전처리가 발생할 수있는 파이프 라인의 다른 위치를 나타냅니다. 이 단계에 대한 세부 사항은 다음 섹션에 제공됩니다.

파이프 라인은 다음 단계로 구성됩니다.

1. 원시 데이터를 가져 오면 표 형식 데이터가 BigQuery에 저장되며 이미지, 오디오 및 비디오와 같은 다른 데이터는 클라우드 스토리지에 저장됩니다. 이 시리즈의 두 번째 부분은 예를 들어 BigQuery에 저장된 표 형 데이터를 사용합니다.
2. 데이터 엔지니어링 (준비) 및 기능 엔지니어링은 DataFlow를 사용하여 규모로 실행됩니다. 이 실행은 클라우드 스토리지에 저장된 ML 준비 교육, 평가 및 테스트 세트를 생성합니다. 이상적 으로이 데이터 세트는 Tfrecord 파일로 저장되며 Tensorflow 계산을위한 최적화 된 형식입니다.
3. Tensorflow 모델 트레이너 패키지는 이전 단계에서 전처리 된 데이터를 사용하여 모델을 훈련시키는 Vertex AI Training에 제출됩니다. 이 단계의 출력은 클라우드 스토리지로 내보내는 훈련 된 Tensorflow SavedModel 입니다.
4. 훈련 된 Tensorflow 모델은 REST API가있는 서비스로 Vertex AI 예측에 배치되어 온라인 예측에 사용할 수 있습니다. 동일한 모델을 배치 예측 작업에도 사용할 수도 있습니다.
5. 모델이 REST API로 배포 된 후 클라이언트 앱 및 내부 시스템은 일부 데이터 포인트가 포함 된 요청을 보내고 예측과 함께 모델로부터 응답을 수신하여 API를 호출 할 수 있습니다.
6. 이 파이프 라인을 조정하고 자동화하려면 정점 AI 파이프 라인을 스케줄러로 사용하여 데이터 준비, 모델 교육 및 모델 배포 단계를 호출 할 수 있습니다.

Vertex AI 기능 저장소를 사용하여 입력 기능을 저장하여 예측할 수도 있습니다. 예를 들어, 최신 원시 데이터에서 주기적으로 엔지니어링 된 기능을 작성하여 Vertex AI 기능 저장소에 저장할 수 있습니다. 클라이언트 앱은 Vertex AI 기능 저장소에서 필요한 입력 기능을 가져 와서 모델로 보내 예측을받습니다.

전처리를 수행 할 곳

도 2에서 레이블 A, B 및 C는 데이터 전처리 작업이 BigQuery, DataFlow 또는 Tensorflow에서 수행 될 수 있음을 보여준다. 다음 섹션에서는 이러한 각 옵션이 어떻게 작동하는지 설명합니다.

옵션 A : BigQuery

일반적으로 논리는 다음 작업을 위해 BigQuery에서 구현됩니다.

• 샘플링 : 데이터에서 하위 집합을 무작위로 선택합니다.
• 필터링 : 관련이 없거나 잘못된 인스턴스 제거.
• 분할 : 교육, 평가 및 테스트 세트를 생성하기 위해 데이터를 분할.

BigQuery SQL 스크립트는 그림 2의 데이터 처리 단계 인 DataFlow Preprocessing Pipeline의 소스 쿼리로 사용할 수 있습니다. 예를 들어, 캐나다에서 시스템을 사용하고 데이터웨어 하우스가 전 세계의 트랜잭션이있는 경우 필터링됩니다. 캐나다 전용 교육 데이터는 BigQuery에서 가장 잘 수행됩니다. BigQuery의 기능 엔지니어링은 간단하고 확장 가능하며 인스턴스 수준 및 과거 집계 기능 변환을 구현하는 지원을 지원합니다.

그러나 배치 예측에 모델을 사용하거나 기능이 BigQuery에서 미리 계산되지만 온라인 예측 중에 사용할 Vertex AI 기능 저장에 저장된 경우에만 기능 엔지니어링에 BigQuery를 사용하는 것이 좋습니다. 온라인 예측을 위해 모델을 배포 할 계획이고 온라인 기능 저장소에 엔지니어링 된 기능이없는 경우 SQL 전처리 작업을 복제하여 다른 시스템이 생성하는 원시 데이터 포인트를 변환해야합니다. 다시 말해, BigQuery에서 SQL에서 SQL에서 한 번, 예측을 위해 온라인 데이터 포인트를 전처리하기 위해 모델을 소비하는 앱의 논리에서 두 번째로 논리를 두 번 구현해야합니다.

예를 들어, 클라이언트 앱이 Java로 작성된 경우 Java의 논리를 상환해야합니다. 이 문서의 후반부에서 전처리 문제 의 훈련-서빙 왜곡 섹션에 설명 된 바와 같이 구현 불일치로 인한 오류가 발생할 수 있습니다. 또한 두 가지 다른 구현을 유지하기 위해 여분의 오버 헤드입니다. 교육 데이터를 전처리하기 위해 SQL의 논리를 변경할 때마다 서빙 시간시 전처리 데이터에 따라 Java 구현을 변경해야합니다.

배치 예측에만 모델을 사용하는 경우 (예 : Vertex AI 배치 예측 사용), 스코어링 데이터가 BigQuery에서 공급되는 경우 BigQuery SQL 스크립트의 일부로 이러한 전처리 작업을 구현할 수 있습니다. 이 경우 동일한 전처리 SQL 스크립트를 사용하여 교육 및 점수 데이터를 모두 준비 할 수 있습니다.

전체 통과 상태 변환은 BigQuery에서 구현에 적합하지 않습니다. 전체 패스 변환에 BigQuery를 사용하는 경우 수단 ​​및 차이와 같은 상태의 변형에 필요한 수량을 저장하려면 보조 테이블이 필요합니다. 또한, BigQuery에서 SQL을 사용하여 풀 패스 변환을 구현하면 SQL 스크립트에서 복잡성이 증가하고 교육과 스코어링 SQL 스크립트간에 복잡한 의존성을 만듭니다.

옵션 B : 데이터 플로우

그림 2와 같이, Apache Beam에서 계산적으로 비싼 전처리 작업을 구현하고 DataFlow를 사용하여 규모로 실행할 수 있습니다. DataFlow는 배치 및 스트림 데이터 처리를위한 완전히 관리되는 자동화 서비스입니다. DataFlow를 사용하면 BigQuery와 달리 데이터 처리에 외부 전문 라이브러리를 사용할 수도 있습니다.

DataFlow는 인스턴스 수준 변환과 과거 및 실시간 집계 기능 변환을 수행 할 수 있습니다. 특히 ML 모델이 total_number_of_clicks_last_90sec 와 같은 입력 기능을 기대하면 Apache Beam Windows 기능은 실시간 (스트리밍) 이벤트 데이터의 시간 값을 집계하는 데 기반하여 이러한 기능을 계산할 수 있습니다 (예 : 클릭 이벤트). 변형의 세분성 에 대한 초기 논의에서, 이것은 "훈련 중 역사적 집합이지만 예측 중 실시간 집계"라고 불 렸습니다.

다음 다이어그램 인 그림 3은 거의 실시간 예측을위한 스트림 데이터 처리에서 데이터 흐름의 역할을 보여줍니다.

도 3에 도시 된 바와 같이, 처리 중에, 데이터 포인트 라는 이벤트는 PUB/Sub 에 섭취된다. DataFlow는 이러한 데이터 포인트를 소비하고 시간이 지남에 따라 집계를 기반으로 기능을 계산 한 다음 배포 된 ML 모델 API를 예측할 수 있습니다. 그런 다음 예측은 아웃 바운드 펍/하위 대기열로 전송됩니다. PUB/SUB에서 모니터링 또는 제어와 같은 다운 스트림 시스템에서 예측을 소비하거나 원래 요청 클라이언트로 다시 밀어 넣을 수 있습니다 (예 : 알림). 예측은 또한 실시간 페치를 위해 Cloud Bigtable 과 같은 저도 데이터 저장소에 저장 될 수 있습니다. 클라우드 bigtable은 또한 이러한 실시간 집계를 축적하고 저장하는 데 사용하여 예측에 필요할 때 찾을 수 있습니다.

동일한 Apache Beam 구현을 사용하여 온라인 예측을 위해 BigQuery 및 스트림 프로세스 실시간 데이터와 같은 오프라인 데이터 스토어에서 나오는 교육 데이터를 배치하는 데 사용될 수 있습니다.

그림 2에 표시된 아키텍처와 같은 다른 일반적인 아키텍처에서 클라이언트 앱은 온라인 예측을 위해 배포 된 모델 API를 직접 호출합니다. 이 경우 교육 데이터를 준비하기 위해 전처리 작업을 데이터 플로우에서 구현하는 경우 작업은 모델로 직접 이동하는 예측 데이터에 적용되지 않습니다. 따라서 이와 같은 변환은 온라인 예측을 위해 서비스하는 동안 모델에 통합되어야합니다.

DataFlow는 필요한 통계를 규모로 계산하여 전체 패스 변환을 수행하는 데 사용될 수 있습니다. 그러나 이러한 통계는 예측 데이터 포인트를 변환하기 위해 예측 중에 사용될 어딘가에 저장해야합니다. Tensorflow Transform ( tf.Transform ) 라이브러리를 사용하면 다른 곳에 저장하는 대신 모델에 이러한 통계를 직접 포함시킬 수 있습니다. 이 접근법은 TF.Transform의 작동 방식 에서 뒷부분에 설명되어 있습니다.

옵션 C : 텐서 플로우

그림 2에 표시된 것처럼 Tensorflow 모델 자체에서 데이터 전처리 및 변환 작업을 구현할 수 있습니다. 그림에서 볼 수 있듯이, 훈련을 위해 구현 한 전처리는 모델을 내보내고 예측을 위해 배포 될 때 모델의 필수 부분이됩니다. 텐서 플로우 모델의 변환은 다음 중 하나로 달성 할 수 있습니다.

• input_fn 함수 및 serving_fn 함수에서 모든 인스턴스 수준 변환 로직을 구현합니다. input_fn 함수는 모델 훈련을 위해 tf.data.Dataset api를 사용하여 데이터 세트를 준비합니다. serving_fn 함수는 예측을위한 데이터를 수신하고 준비합니다.
• Keras Preprocessing Layers를 사용하거나 사용자 정의 레이어를 생성하여 Tensorflow 모델에 직접 변환 코드를 배치합니다.

serving_fn 함수의 변환 로직 코드는 온라인 예측을 위해 SavedModel의 서빙 인터페이스를 정의합니다. serving_fn 함수의 변환 로직 코드에서 교육 데이터를 준비하는 데 사용 된 것과 동일한 변환을 구현하면 서비스가 제공 될 때 동일한 변환이 새로운 예측 데이터 포인트에 적용되도록합니다.

그러나 Tensorflow 모델은 각 데이터 포인트를 독립적으로 또는 작은 배치로 처리하기 때문에 모든 데이터 포인트에서 집계를 계산할 수는 없습니다. 결과적으로 Tensorflow 모델에서는 전체 패스 변환을 구현할 수 없습니다.

전처리 도전

다음은 데이터 전처리 구현의 주요 과제입니다.

• 훈련-서빙 꼬치 . 훈련-서빙 왜곡은 훈련 중 및 서빙 중 효과 (예측 성능)의 차이를 나타냅니다. 이 기울기는 교육의 데이터를 처리하는 방법과 서빙 파이프 라인 사이의 불일치로 인해 발생할 수 있습니다. 예를 들어, 모델이 로그 변환 된 기능에 대해 교육을받은 경우 서빙 중에 원시 기능이 제시되면 예측 출력이 정확하지 않을 수 있습니다.

  변환이 모델 자체의 일부가되면 옵션 C : Tensorflow 에 앞서 설명한 것처럼 인스턴스 수준 변환을 처리하는 것이 간단 할 수 있습니다. 이 경우 모델 서브 서브 인터페이스 ( serving_fn 함수)는 원시 데이터를 예상하는 반면, 모델은 출력을 계산하기 전에 내부적 으로이 데이터를 변환합니다. 변환은 원시 교육 및 예측 데이터 포인트에 적용된 변환과 동일합니다.

• 전체 통과 변환 . You can't implement full-pass transformations such as scaling and normalization transformations in your TensorFlow model. In full-pass transformations, some statistics (for example, max and min values to scale numeric features) must be computed on the training data beforehand, as described in Option B: Dataflow . The values then have to be stored somewhere to be used during model serving for prediction to transform the new raw data points as instance-level transformations, which avoids training-serving skew. You can use the TensorFlow Transform ( tf.Transform ) library to directly embed the statistics in your TensorFlow model. This approach is explained later in How tf.Transform works .

• Preparing the data up front for better training efficiency . Implementing instance-level transformations as part of the model can degrade the efficiency of the training process. This degradation occurs because the same transformations are repeatedly applied to the same training data on each epoch. Imagine that you have raw training data with 1,000 features, and you apply a mix of instance-level transformations to generate 10,000 features. If you implement these transformations as part of your model, and if you then feed the model the raw training data, these 10,000 operations are applied N times on each instance, where N is the number of epochs. In addition, if you're using accelerators (GPUs or TPUs), they sit idle while the CPU performs those transformations, which isn't an efficient use of your costly accelerators.

  Ideally, the training data is transformed before training, using the technique described under Option B: Dataflow , where the 10,000 transformation operations are applied only once on each training instance. The transformed training data is then presented to the model. No further transformations are applied, and the accelerators are busy all of the time. In addition, using Dataflow helps you to preprocess large amounts of data at scale, using a fully managed service.

  Preparing the training data up front can improve training efficiency. However, implementing the transformation logic outside of the model (the approaches described in Option A: BigQuery or Option B: Dataflow ) doesn't resolve the issue of training-serving skew. Unless you store the engineered feature in the feature store to be used for both training and prediction, the transformation logic must be implemented somewhere to be applied on new data points coming for prediction, because the model interface expects transformed data. The TensorFlow Transform ( tf.Transform ) library can help you to address this issue, as described in the following section.

How tf.Transform works

The tf.Transform library is useful for transformations that require a full pass. The output of the tf.Transform library is exported as a TensorFlow graph that represents the instance-level transformation logic and the statistics computed from full-pass transformations, to be used for training and serving. Using the same graph for both training and serving can prevent skew, because the same transformations are applied in both stages. In addition, the tf.Transform library can run at scale in a batch processing pipeline on Dataflow to prepare the training data up front and improve training efficiency.

The following diagram, figure 4, shows how the tf.Transform library preprocesses and transforms data for training and prediction. The process is described in the following sections.

Transform training and evaluation data

You preprocess the raw training data using the transformation implemented in the tf.Transform Apache Beam APIs, and run it at scale on Dataflow. The preprocessing occurs in the following phases:

• Analyze phase: During the analyze phase, the required statistics (like means, variances, and quantiles) for stateful transformations are computed on the training data with full-pass operations. This phase produces a set of transformation artifacts, including the transform_fn graph. The transform_fn graph is a TensorFlow graph that has the transformation logic as instance-level operations. It includes the statistics computed in the analyze phase as constants.
• Transform phase: During the transform phase, the transform_fn graph is applied to the raw training data, where the computed statistics are used to process the data records (for example, to scale numerical columns) in an instance-level fashion.

A two-phase approach like this addresses the preprocessing challenge of performing full-pass transformations.

When the evaluation data is preprocessed, only instance-level operations are applied, using the logic in the transform_fn graph and the statistics computed from the analyze phase in the training data. In other words, you don't analyze the evaluation data in a full-pass fashion to compute new statistics, such as μ and σ, to normalize numeric features in evaluation data. Instead, you use the computed statistics from the training data to transform the evaluation data in an instance-level fashion.

The transformed training and evaluation data are prepared at scale using Dataflow, before they are used to train the model. This batch data-preparation process addresses the preprocessing challenge of preparing the data up front to improve training efficiency. As shown in figure 4, the model internal interface expects transformed features.

Attach transformations to the exported model

As noted, the transform_fn graph that's produced by the tf.Transform pipeline is stored as an exported TensorFlow graph. The exported graph consists of the transformation logic as instance-level operations, and all of the statistics computed in the full-pass transformations as graph constants. When the trained model is exported for serving, the transform_fn graph is attached to the SavedModel as part of its serving_fn function.

While it's serving the model for prediction, the model serving interface expects data points in the raw format (that is, before any transformations). However, the model internal interface expects the data in the transformed format.

The transform_fn graph, which is now part of the model, applies all the preprocessing logic on the incoming data point. It uses the stored constants (like μ and σ to normalize the numeric features) in the instance-level operation during prediction. Therefore, the transform_fn graph converts the raw data point into the transformed format. The transformed format is what is expected by the model internal interface in order to produce prediction, as shown in figure 4.

This mechanism resolves the preprocessing challenge of the training-serving skew, because the same logic (implementation) that is used to transform the training and evaluation data is applied to transform the new data points during prediction serving.

Preprocessing options summary

The following table summarizes the data preprocessing options that this document discussed. In the table, "N/A" stands for "not applicable."

^* With TensorFlow, transformations like crossing, embedding, and one-hot encoding should be performed declaratively as feature_columns columns.

What's next

• To implement a tf.Transform pipeline and run it using Dataflow, read part two of this series, Data preprocessing for ML using TensorFlow Transform .
• Take the Coursera specialization on ML with TensorFlow on Google Cloud .
• Learn about best practices for ML engineering in Rules of ML .
• For more reference architectures, diagrams, and best practices, explore the TFX Cloud Solutions .

This document is the first in a two-part series that explores the topic of data engineering and feature engineering for machine learning (ML), with a focus on supervised learning tasks. This first part discusses the best practices for preprocessing data in an ML pipeline on Google Cloud. The document focuses on using TensorFlow and the open source TensorFlow Transform ( tf.Transform ) library to prepare data, train the model, and serve the model for prediction. This document highlights the challenges of preprocessing data for ML, and it describes the options and scenarios for performing data transformation on Google Cloud effectively.

This document assumes that you're familiar with BigQuery , Dataflow , Vertex AI , and the TensorFlow Keras API.

The second document, Data preprocessing for ML with Google Cloud , provides a step-by-step tutorial for how to implement a tf.Transform pipeline.

소개

ML helps you automatically find complex and potentially useful patterns in data. These patterns are condensed in an ML model that can then be used on new data points—a process called making predictions or performing inference .

Building an ML model is a multistep process. Each step presents its own technical and conceptual challenges. This two-part series focuses on supervised learning tasks and the process of selecting, transforming, and augmenting the source data to create powerful predictive signals to the target variable. These operations combine domain knowledge with data science techniques. The operations are the essence of feature engineering .

The size of training datasets for real-world ML models can easily be equal to or greater than one terabyte (TB). Therefore, you need large-scale data processing frameworks in order to process these datasets efficiently and distributedly. When you use an ML model to make predictions, you have to apply the same transformations that you used for the training data on the new data points. By applying the same transformations, you present the live dataset to the ML model the way that the model expects.

This document discusses these challenges for different levels of granularity of feature engineering operations: instance-level, full-pass, and time-window aggregations. This document also describes the options and scenarios to perform data transformation for ML on Google Cloud.

This document also provides an overview of TensorFlow Transform ( tf.Transform ), a library for TensorFlow that lets you define both instance-level and full-pass data transformation through data preprocessing pipelines. These pipelines are executed with Apache Beam , and they create artifacts that let you apply the same transformations during prediction as when the model is served.

Preprocessing data for ML

This section introduces data preprocessing operations and stages of data readiness. It also discusses the types of the preprocessing operations and their granularity.

Data engineering compared to feature engineering

Preprocessing the data for ML involves both data engineering and feature engineering. Data engineering is the process of converting raw data into prepared data . Feature engineering then tunes the prepared data to create the features that are expected by the ML model. These terms have the following meanings:

Raw data (or just data )

The data in its source form, without any prior preparation for ML. In this context, the data might be in its raw form (in a data lake) or in a transformed form (in a data warehouse). Transformed data that's in a data warehouse might have been converted from its original raw form to be used for analytics. However, in this context, raw data means that the data hasn't been prepared specifically for your ML task. Data is also considered raw data if it's sent from streaming systems that eventually call ML models for predictions.

Prepared data

The dataset in the form ready for your ML task: data sources have been parsed, joined, and put into a tabular form. Prepared data is aggregated and summarized to the right granularity—for example, each row in the dataset represents a unique customer, and each column represents summary information for the customer, like the total spent in the last six weeks. In a prepared data table, irrelevant columns have been dropped, and invalid records have been filtered out. For supervised learning tasks, the target feature is present.

Engineered features

The dataset with the tuned features that are expected by the model—that is, features that are created by performing certain ML-specific operations on the columns in the prepared dataset, and creating new features for your model during training and prediction, as described later in Preprocessing operations . Examples of these operations include scaling numerical columns to a value between 0 and 1, clipping values, and one-hot-encoding categorical features.

The following diagram, figure 1, shows the steps that are involved in preparing preprocessed data:

In practice, data from the same source is often at different stages of readiness. For example, a field from a table in your data warehouse might be used directly as an engineered feature. At the same time, another field in the same table might need to go through transformations before it becomes an engineered feature. Similarly, data engineering and feature engineering operations might be combined in the same data preprocessing step.

Preprocessing operations

Data preprocessing includes several operations. Each operation is designed to help ML build better predictive models. The details of these preprocessing operations are outside the scope of this document, but some operations are briefly described in this section.

For structured data, data preprocessing operations include the following:

• Data cleansing: removing or correcting records that have corrupted or invalid values from raw data, and removing records that are missing a large number of columns.
• Instances selection and partitioning: selecting data points from the input dataset to create training, evaluation (validation), and test sets . This process includes techniques for repeatable random sampling, minority classes oversampling, and stratified partitioning.
• Feature tuning: improving the quality of a feature for ML, which includes scaling and normalizing numeric values, imputing missing values, clipping outliers, and adjusting values that have skewed distributions.
• Feature transformation: converting a numeric feature to a categorical feature (through bucketization ), and converting categorical features to a numeric representation (through one-hot encoding, learning with counts , sparse feature embeddings, etc.). Some models work only with numeric or categorical features, while others can handle mixed type features. Even when models handle both types, they can benefit from different representations (numeric and categorical) of the same feature.
• Feature extraction: reducing the number of features by creating lower-dimension, more powerful data representations using techniques such as PCA , embedding extraction, and hashing .
• Feature selection: selecting a subset of the input features for training the model, and ignoring the irrelevant or redundant ones, using filter or wrapper methods . Feature selection can also involve simply dropping features if the features are missing a large number of values.
• Feature construction: creating new features by using typical techniques, such as polynomial expansion (by using univariate mathematical functions) or feature crossing (to capture feature interactions). Features can also be constructed by using business logic from the domain of the ML use case.

When you work with unstructured data (for example, images, audio, or text documents), deep learning replaces domain-knowledge-based feature engineering by folding it into the model architecture. A convolutional layer is an automatic feature preprocessor. Constructing the right model architecture requires some empirical knowledge of the data. In addition, some amount of preprocessing is needed, such as the following:

• For text documents: stemming and lemmatization , TF-IDF calculation, and n-gram extraction, embedding lookup.
• For images: clipping, resizing, cropping, Gaussian blur, and canary filters.
• For all types of data (including text and images): transfer learning , which treats all-but-last layers of the fully trained model as a feature engineering step.

Preprocessing granularity

This section discusses the granularity of types of data transformations. It shows why this perspective is critical when preparing new data points for predictions using transformations that are applied on training data.

Preprocessing and transformation operations can be categorized as follows, based on operation granularity:

• Instance-level transformations during training and prediction . These are straightforward transformations, where only values from the same instance are needed for the transformation. For example, instance-level transformations might include clipping the value of a feature to some threshold, polynomially expanding another feature, multiplying two features, or comparing two features to create a Boolean flag.

  These transformations must be applied identically during training and prediction, because the model will be trained on the transformed features, not on the raw input values. If the data isn't transformed identically, then the model behaves poorly because it is presented with data that has a distribution of values that it wasn't trained with. For more information, see the discussion of training-serving skew in the Preprocessing challenges section.

• Full-pass transformations during training, but instance-level transformations during prediction . In this scenario, transformations are stateful, because they use some precomputed statistics to perform the transformation. During training, you analyze the whole body of training data to compute quantities such as minimum, maximum, mean, and variance for transforming training data, evaluation data, and new data at prediction time.

  For example, to normalize a numeric feature for training, you compute its mean (μ) and its standard deviation (σ) across the whole of the training data. This computation is called a full-pass (or analyze ) operation. When you serve the model for prediction, the value of a new data point is normalized to avoid training-serving skew. Therefore, μ and σ values that are computed during training are used to adjust the feature value, which is the following simple instance-level operation:

  $$ value_{scaled} = (value_{raw} - \mu) \div \sigma $$

  Full-pass transformations include the following:

  • MinMax scaling numerical features using min and max computed from the training dataset.
  • Standard scaling (z-score normalization) numerical features using μ and σ computed on the training dataset.
  • Bucketizing numerical features using quantiles.
  • Imputing missing values using the median (numerical features) or the mode (categorical features).
  • Converting strings (nominal values) to integers (indexes) by extracting all the distinct values (vocabulary) of an input categorical feature.
  • Counting the occurrence of a term (feature value) in all the documents (instances) to calculate for TF-IDF.
  • Computing the PCA of the input features to project the data into a lower dimensional space (with linearly dependent features).

  You should use only the training data to compute statistics like μ, σ, min , and max . If you add the test and evaluation data for these operations, you are leaking information from the evaluation and test data to train the model. Doing so affects the reliability of the test and evaluation results. To ensure that you apply a consistent transformation to all datasets, you use the same statistics computed from the training data to transform the test and evaluation data.

• Historical aggregations during training and prediction . This involves creating business aggregations, derivations, and flags as input signals to the prediction task—for example, creating recency, frequency, and monetary (RFM) metrics for customers to build propensity models. These types of features can be precomputed and stored in a feature store to be used during model training, batch scoring, and online prediction serving. You can also perform additional feature engineering (for example, transformation and tuning) to these aggregations before training and prediction.

• Historical aggregations during training, but real-time aggregations during prediction . This approach involves creating a feature by summarizing real-time values over time. In this approach, the instances to be aggregated are defined through temporal window clauses. For example, you can use this approach if you want to train a model that estimates the taxi trip time based on the traffic metrics for the route in the last 5 minutes, in the last 10 minutes, in the last 30 minutes, and at other intervals. You can also use this approach to predict the failure of an engine part based on the moving average of temperature and vibration values computed over the last 3 minutes. Although these aggregations can be prepared offline for training, they are computed in real time from a data stream during serving.

  More precisely, when you prepare training data, if the aggregated value isn't in the raw data, the value is created during the data engineering phase. The raw data is usually stored in a database with a format of (entity, timestamp, value) . In the previous examples, entity is the route segment identifier for the taxi routes and the engine part identifier for the engine failure. You can use windowing operations to compute (entity, time_index, aggregated_value_over_time_window) and use the aggregation features as an input for your model training.

  When the model for real-time (online) prediction is served, the model expects features derived from the aggregated values as an input. Therefore, you can use a stream-processing technology like Apache Beam to compute the aggregations from the real-time data points streamed into your system. Stream-processing technology aggregates real-time data based on time windows as new data points arrive. You can also perform additional feature engineering (for example, transformation and tuning) to these aggregations before training and prediction.

ML pipeline on Google Cloud

This section discusses the core components of a typical end-to-end pipeline to train and serve TensorFlow ML models on Google Cloud using managed services. It also discusses where you can implement different categories of the data preprocessing operations, and common challenges that you might face when you implement such transformations. The How tf.Transform works section shows how the TensorFlow Transform library helps to address these challenges.

상위 수준 아키텍처

The following diagram, figure 2, shows a high-level architecture of a typical ML pipeline for training and serving TensorFlow models. The labels A, B, and C in the diagram refer to the different places in the pipeline where data preprocessing can take place. Details about these steps are provided in the following section.

The pipeline consists of the following steps:

1. After raw data is imported, tabular data is stored in BigQuery, and other data like images, audio, and video, is stored in Cloud Storage. The second part of this series uses tabular data stored in BigQuery as an example.
2. Data engineering (preparation) and feature engineering are executed at scale using Dataflow. This execution produces ML-ready training, evaluation, and test sets that are stored in Cloud Storage. Ideally, these datasets are stored as TFRecord files, which is the optimized format for TensorFlow computations.
3. A TensorFlow model trainer package is submitted to Vertex AI Training, which uses the preprocessed data from the previous steps to train the model. The output of this step is a trained TensorFlow SavedModel that is exported to Cloud Storage.
4. The trained TensorFlow model is deployed to Vertex AI Prediction as a service that has a REST API so that it can be used for online predictions. The same model can also be used for batch prediction jobs.
5. After the model is deployed as a REST API, client apps and internal systems can invoke the API by sending requests with some data points, and receiving responses from the model with predictions.
6. For orchestrating and automating this pipeline, you can use Vertex AI Pipelines as a scheduler to invoke the data preparation, model training, and model deployment steps.

You can also use Vertex AI Feature Store to store input features to make predictions. For example, you can periodically create engineered features from the latest raw data and store them in Vertex AI Feature Store. Client apps fetch the required input features from Vertex AI Feature Store and send them to the model to receive predictions.

Where to do preprocessing

In figure 2, the labels A, B, and C show that data preprocessing operations can take place in BigQuery, Dataflow, or TensorFlow. The following sections describe how each of these options work.

Option A: BigQuery

Typically, logic is implemented in BigQuery for the following operations:

• Sampling: randomly selecting a subset from the data.
• Filtering: removing irrelevant or invalid instances.
• Partitioning: splitting the data to produce training, evaluation, and test sets.

BigQuery SQL scripts can be used as a source query for the Dataflow preprocessing pipeline, which is the data processing step in figure 2. For example, if a system is used in Canada, and the data warehouse has transactions from around the world, filtering to get Canada-only training data is best done in BigQuery. Feature engineering in BigQuery is simple and scalable, and supports implementing instance-level and historical aggregations feature transformations.

However, we recommend that you use BigQuery for feature engineering only if you use your model for batch prediction (scoring), or if the features are precomputed in BigQuery, but stored in Vertex AI Feature Store to be used during online prediction. If you plan to deploy the model for online predictions, and if you don't have the engineered feature in an online feature store, you have to replicate the SQL preprocessing operations to transform the raw data points that other systems generate. In other words, you need to implement the logic twice: one time in SQL to preprocess training data in BigQuery, and a second time in the logic of the app that consumes the model to preprocess online data points for prediction.

For example, if your client app is written in Java, you need to reimplement the logic in Java. This can introduce errors due to implementation discrepancies, as described in the training-serving skew section of Preprocessing challenges later in this document. It's also extra overhead to maintain two different implementations. Whenever you change the logic in SQL to preprocess the training data, you need to change the Java implementation accordingly to preprocess data at serving time.

If you are using your model only for batch prediction (for example, using Vertex AI batch prediction ), and if your data for scoring is sourced from BigQuery, you can implement these preprocessing operations as part of the BigQuery SQL script. In that case, you can use the same preprocessing SQL script to prepare both training and scoring data.

Full-pass stateful transformations aren't suitable for implementation in BigQuery. If you use BigQuery for full-pass transformations, you need auxiliary tables to store quantities needed by stateful transformations, such as means and variances to scale numerical features. Further, implementation of full-pass transformations using SQL on BigQuery creates increased complexity in the SQL scripts, and creates intricate dependency between training and the scoring SQL scripts.

Option B: Dataflow

As shown in figure 2, you can implement computationally expensive preprocessing operations in Apache Beam, and run them at scale using Dataflow. Dataflow is a fully managed autoscaling service for batch and stream data processing. When you use Dataflow, you can also use external specialized libraries for data processing, unlike BigQuery.

Dataflow can perform instance-level transformations, and historical and real-time aggregation feature transformations. In particular, if your ML models expect an input feature like total_number_of_clicks_last_90sec , Apache Beam windowing functions can compute these features based on aggregating the values of time windows of real-time (streaming) events data (for example, click events). In the earlier discussion of granularity of transformations , this was referred to as "Historical aggregations during training, but real-time aggregations during prediction."

The following diagram, figure 3, shows the role of Dataflow in processing stream data for near real-time predictions.

As shown in figure 3, during processing, events called data points are ingested into Pub/Sub . Dataflow consumes these data points, computes features based on aggregates over time, and then calls the deployed ML model API for predictions. Predictions are then sent to an outbound Pub/Sub queue. From Pub/Sub, predictions can be consumed by downstream systems like monitoring or control, or they can be pushed back (for example, as notifications) to the original requesting client. Predictions can also be stored in a low-latency data store like Cloud Bigtable for real-time fetching. Cloud Bigtable can also be used to accumulate and store these real-time aggregations so they can be looked up when needed for prediction.

The same Apache Beam implementation can be used to batch-process training data that comes from an offline datastore like BigQuery and stream-process real-time data for serving online predictions.

In other typical architectures, such as the architecture shown in figure 2, the client app directly calls the deployed model API for online predictions. In that case, if preprocessing operations are implemented in Dataflow to prepare the training data, the operations aren't applied to the prediction data that goes directly to the model. Therefore, transformations like these should be integrated in the model during serving for online predictions.

Dataflow can be used to perform full-pass transformation, by computing the required statistics at scale. However, these statistics need to be stored somewhere to be used during prediction to transform prediction data points. By using the TensorFlow Transform ( tf.Transform ) library, you can directly embed these statistics in the model instead of storing them elsewhere. This approach is explained later in How tf.Transform works .

Option C: TensorFlow

As shown in figure 2, you can implement data preprocessing and transformation operations in the TensorFlow model itself. As shown in the figure, the preprocessing that you implement for training the TensorFlow model becomes an integral part of the model when the model is exported and deployed for predictions. Transformations in the TensorFlow model can be accomplished in one of the following ways:

• Implementing all of the instance-level transformation logic in the input_fn function and in the serving_fn function. The input_fn function prepares a dataset using the tf.data.Dataset API for training a model. The serving_fn function receives and prepares the data for predictions.
• Putting the transformation code directly in your TensorFlow model by using Keras preprocessing layers or creating custom layers .

The transformation logic code in the serving_fn function defines the serving interface of your SavedModel for online prediction. If you implement the same transformations that were used for preparing training data in the transformation logic code of the serving_fn function, it ensures that the same transformations are applied to new prediction data points when they're served.

However, because the TensorFlow model processes each data point independently or in a small batch, you can't calculate aggregations from all data points. As a result, full-pass transformations can't be implemented in your TensorFlow model.

Preprocessing challenges

The following are the primary challenges of implementing data preprocessing:

• Training-serving skew . Training-serving skew refers to a difference between effectiveness (predictive performance) during training and during serving. This skew can be caused by a discrepancy between how you handle data in the training and the serving pipelines. For example, if your model is trained on a logarithmically transformed feature, but it's presented with the raw feature during serving, the prediction output might not be accurate.

  If the transformations become part of the model itself, it can be straightforward to handle instance-level transformations, as described earlier in Option C: TensorFlow . In that case, the model serving interface (the serving_fn function) expects raw data, while the model internally transforms this data before computing the output. The transformations are the same as those that were applied on the raw training and prediction data points.

• Full-pass transformations . You can't implement full-pass transformations such as scaling and normalization transformations in your TensorFlow model. In full-pass transformations, some statistics (for example, max and min values to scale numeric features) must be computed on the training data beforehand, as described in Option B: Dataflow . The values then have to be stored somewhere to be used during model serving for prediction to transform the new raw data points as instance-level transformations, which avoids training-serving skew. You can use the TensorFlow Transform ( tf.Transform ) library to directly embed the statistics in your TensorFlow model. This approach is explained later in How tf.Transform works .

• Preparing the data up front for better training efficiency . Implementing instance-level transformations as part of the model can degrade the efficiency of the training process. This degradation occurs because the same transformations are repeatedly applied to the same training data on each epoch. Imagine that you have raw training data with 1,000 features, and you apply a mix of instance-level transformations to generate 10,000 features. If you implement these transformations as part of your model, and if you then feed the model the raw training data, these 10,000 operations are applied N times on each instance, where N is the number of epochs. In addition, if you're using accelerators (GPUs or TPUs), they sit idle while the CPU performs those transformations, which isn't an efficient use of your costly accelerators.

  Ideally, the training data is transformed before training, using the technique described under Option B: Dataflow , where the 10,000 transformation operations are applied only once on each training instance. The transformed training data is then presented to the model. No further transformations are applied, and the accelerators are busy all of the time. In addition, using Dataflow helps you to preprocess large amounts of data at scale, using a fully managed service.

  Preparing the training data up front can improve training efficiency. However, implementing the transformation logic outside of the model (the approaches described in Option A: BigQuery or Option B: Dataflow ) doesn't resolve the issue of training-serving skew. Unless you store the engineered feature in the feature store to be used for both training and prediction, the transformation logic must be implemented somewhere to be applied on new data points coming for prediction, because the model interface expects transformed data. The TensorFlow Transform ( tf.Transform ) library can help you to address this issue, as described in the following section.

How tf.Transform works

The tf.Transform library is useful for transformations that require a full pass. The output of the tf.Transform library is exported as a TensorFlow graph that represents the instance-level transformation logic and the statistics computed from full-pass transformations, to be used for training and serving. Using the same graph for both training and serving can prevent skew, because the same transformations are applied in both stages. In addition, the tf.Transform library can run at scale in a batch processing pipeline on Dataflow to prepare the training data up front and improve training efficiency.

The following diagram, figure 4, shows how the tf.Transform library preprocesses and transforms data for training and prediction. The process is described in the following sections.

Transform training and evaluation data

You preprocess the raw training data using the transformation implemented in the tf.Transform Apache Beam APIs, and run it at scale on Dataflow. The preprocessing occurs in the following phases:

• Analyze phase: During the analyze phase, the required statistics (like means, variances, and quantiles) for stateful transformations are computed on the training data with full-pass operations. This phase produces a set of transformation artifacts, including the transform_fn graph. The transform_fn graph is a TensorFlow graph that has the transformation logic as instance-level operations. It includes the statistics computed in the analyze phase as constants.
• Transform phase: During the transform phase, the transform_fn graph is applied to the raw training data, where the computed statistics are used to process the data records (for example, to scale numerical columns) in an instance-level fashion.

A two-phase approach like this addresses the preprocessing challenge of performing full-pass transformations.

When the evaluation data is preprocessed, only instance-level operations are applied, using the logic in the transform_fn graph and the statistics computed from the analyze phase in the training data. In other words, you don't analyze the evaluation data in a full-pass fashion to compute new statistics, such as μ and σ, to normalize numeric features in evaluation data. Instead, you use the computed statistics from the training data to transform the evaluation data in an instance-level fashion.

The transformed training and evaluation data are prepared at scale using Dataflow, before they are used to train the model. This batch data-preparation process addresses the preprocessing challenge of preparing the data up front to improve training efficiency. As shown in figure 4, the model internal interface expects transformed features.

Attach transformations to the exported model

As noted, the transform_fn graph that's produced by the tf.Transform pipeline is stored as an exported TensorFlow graph. The exported graph consists of the transformation logic as instance-level operations, and all of the statistics computed in the full-pass transformations as graph constants. When the trained model is exported for serving, the transform_fn graph is attached to the SavedModel as part of its serving_fn function.

While it's serving the model for prediction, the model serving interface expects data points in the raw format (that is, before any transformations). However, the model internal interface expects the data in the transformed format.

The transform_fn graph, which is now part of the model, applies all the preprocessing logic on the incoming data point. It uses the stored constants (like μ and σ to normalize the numeric features) in the instance-level operation during prediction. Therefore, the transform_fn graph converts the raw data point into the transformed format. The transformed format is what is expected by the model internal interface in order to produce prediction, as shown in figure 4.

This mechanism resolves the preprocessing challenge of the training-serving skew, because the same logic (implementation) that is used to transform the training and evaluation data is applied to transform the new data points during prediction serving.

Preprocessing options summary

The following table summarizes the data preprocessing options that this document discussed. In the table, "N/A" stands for "not applicable."

^* With TensorFlow, transformations like crossing, embedding, and one-hot encoding should be performed declaratively as feature_columns columns.

What's next

• To implement a tf.Transform pipeline and run it using Dataflow, read part two of this series, Data preprocessing for ML using TensorFlow Transform .
• Take the Coursera specialization on ML with TensorFlow on Google Cloud .
• Learn about best practices for ML engineering in Rules of ML .
• For more reference architectures, diagrams, and best practices, explore the TFX Cloud Solutions .