광고의 데이터 파이프라인을 위한 인프라 옵션(2부)

이 문서에서는 다양한 광고 플랫폼에서 일반적인 데이터 파이프라인과 머신러닝 작업을 주로 다룹니다. 이 문서는 광고 워크로드를 처리하기 위한 인프라 옵션(1부)을 보완합니다. 두 문서는 시리즈에 대한 필수 컨텍스트를 제공합니다.

이 문서는 다음 시리즈의 일부입니다.

이러한 플랫폼이 상호 작동하는 방식에 대한 개요와 이 시리즈 전반적으로 사용되는 광고 기술 용어광고 플랫폼 빌드(개요)을 참조하세요.

데이터 파이프라인에 사용되는 Datastore(1부)는 (고유한) 사용자 프로필 저장소, 컨텍스트 저장소(1부), 보고/대시보드 저장소(1부)입니다. 이러한 Datastore는 두 가지 기본 소스인 이벤트와 타사 데이터로 채워집니다. 이 문서는 이벤트 관리에 중점을 둡니다. 타사 데이터 및 사용자 데이터 풍부화에서의 용도에 대한 자세한 내용은 데이터 풍부화(4부)를 참조하세요.

이벤트 수명 주기

원시 이벤트에서 유용한 데이터로의 데이터 파이프라인은 다음과 같이 세분화할 수 있습니다.

  • 수집 및 저장(내부 데이터화): 메시징 시스템 또는 스토리지 시스템으로의 반복적인 파일 업로드를 통해 수행
  • 처리: 일괄 또는 데이터 최신 상태가 중요한 경우 실시간 처리를 위한 스트리밍 모드로 수행
  • 내보내기(또는 로드): 데이터 처리 도구에서 또는 커스텀 워크플로를 통해 수행. 목적지는 일반적으로 위에 언급된 저장소입니다.

광고 기술의 가장 일반적인 이벤트는 다음과 같습니다.

  • 광고 및 입찰 요청: 일반적으로 외부 시스템으로부터 받습니다. 요청에는 광고 선택을 위한 입력의 일부인 세부정보가 포함됩니다.
  • 노출: 웹페이지에 로드되지만 보이지 않을 수도 있는 광고 소재
  • 청구 가능 노출: 렌더링 또는 조회 가능 노출
  • 클릭: 사용자가 광고 소재를 클릭함으로써 취할 수 있는 동작
  • 전환: 타겟팅된 사용자가 광고주 웹사이트에서 수행하는 동작

실시간 입찰과 관련된 이벤트는 RTB 입찰자를 위한 인프라 옵션(4부)에서 다룹니다.

수집

이벤트는 다음에 의해 생성될 수 있습니다.

  • 광고 또는 입찰 요청 인스턴스: 요청을 받는 인스턴스는 광고 소재의 URL 또는 입찰 응답을 반환합니다.
  • 수집자 인스턴스: 노출을 로깅하기 위해 보이지 않는 픽셀을 반환하거나 타겟팅된 사용자가 광고에서 수행한 동작(클릭 또는 동영상 재생과 같은 동작)을 수집하는 인스턴스
  • Cloud Logging: 경우에 따라 이 로깅이 수집자 인스턴스와 서버 로그 파일을 대체할 수 있습니다.

이벤트는 다음에 의해 수집될 수 있습니다.

  • Pub/Sub와 같은 메시징 시스템에 이벤트를 게시하거나 로컬 로그 파일에 쓰는 커스텀 코드
  • 타사 도구 또는 웹 서버의 기본 로깅 기능
  • 선택한 타사 소프트웨어를 지원하고 Cloud Logging과 통합되는 Google Cloud 로깅 에이전트

이벤트는 다음과 같이 수집될 수 있습니다.

  • 로그 파일이 실시간에 가깝게 로컬에서 작성된 후 Cloud Storage 또는 BigQuery Capacitor와 같은 공유 저장공간에 주기적으로 복사되어 처리되는 경우. 처리에 분석 쿼리가 포함되는 경우 일반적으로 BigQuery 저장소가 사용됩니다.
  • 실시간으로 Cloud Logging을 사용하거나 수집자가 지연 시간이 짧은 Datastore 또는 Pub/Sub, Apache Kafka, RabbitMQ와 같은 메시징 시스템에 직접 쓰는 경우. 실시간 처리 시스템에서는 주로 이 옵션을 사용합니다.

Cloud Logging은 Compute Engine, Google Kubernetes Engine과 같은 Google Cloud 제품 및 HTTP 부하 분산에서도 직접 데이터를 캡처할 수 있으므로 이러한 태스크 대부분을 쉽게 수행할 수 있습니다. Logging은 또한 임시 분석을 위해 데이터를 BigQuery로 직접 내보내고, 알림 및 실시간 처리를 위해 Pub/Sub으로 스트리밍하고, 백업 또는 통합 분석을 위해 일괄적으로 Cloud Storage로 내보낼 수 있습니다.

이전 요점을 설명하고 작업, 비용, 데이터 최신 상태를 고려하는 몇 가지 예를 들면 다음과 같습니다.

옵션 비용 운영 오버헤드 데이터 최신 상태
bqload를 사용하여 X초마다 로그 파일을 Cloud Storage, 그 다음 BigQuery로 복사합니다. Cloud Storage 인그레스 비용 없음

BigQuery 수집 비용 없음

BigQuery 스토리지 비용
파일, 실패, 재시도, 동기화 관리 필요 거의 실시간
Cloud Functions를 사용하여 X초마다 로그 파일을 Cloud Storage, 그 다음 BigQuery로 복사합니다. Cloud Storage 인그레스 비용 없음

BigQuery 수집 비용 없음

Cloud Functions 추가 비용

BigQuery 스토리지 비용
Cloud Functions는 부하 관리를 원활하게 해줍니다. 로직은 여전히 코딩해야 합니다. 거의 실시간
Pub/Sub으로 내보내기와 함께 Cloud Logging 사용 Pub/Sub 비용 낮음 실시간
로컬 데몬을 사용하여 Kafka로 로그 스트리밍 Kafka를 실행하는 데 필요한 저장소 및 컴퓨팅 비용 Google Cloud 관리 옵션을 사용하지 않는 경우의 Kafka 설정 및 관리 Kafka 설정에 따라 거의 실시간 또는 실시간

: 컴퓨팅 인스턴스를 사용해서 이벤트를 수집하는 경우 비용을 절감하려면 컴퓨팅 플랫폼 섹션의 설명대로 항상 선점형 VM을 사용하는 것이 좋습니다.

데이터 저장

데이터를 저장하는 장소는 데이터의 형식, 데이터 액세스 및 사용 방법, 데이터 저장 비용의 영향을 받습니다. 데이터 형식이 구조화되지 않거나 처리하기 전에 저장이 필요한 경우 앞서 권장한 대로 Cloud Storage를 사용하는 것을 고려하세요. 구조화된 데이터의 경우 레코드에 액세스하기 위해 필요한 작업도 고려해야 합니다. 다음 다이어그램은 작업의 수와 비용을 최소화하기 위해 액세스 패턴을 평가하는 데 도움이 될 수 있습니다.

데이터 내보내기를 위한 권장사항

대량 읽기 저장 패턴(1부)에서는 저장 및 제공에 사용되는 옵션을 다룹니다. 이 섹션의 나머지 부분에서는 스트리밍 및 일괄 처리에 모두 사용되는 분석 데이터 저장소에 대해 설명합니다.

스트리밍에서는 원시 데이터를 저장하기 전에 처리합니다. 임시 쿼리에서 즉시 데이터를 사용할 수 있도록 하려면 BigQuery로 스트리밍하는 방법을 고려하세요. Pub/Sub부터 BigQuery에 이르기까지 이 Dataflow 템플릿을 사용하면 이 작업을 손쉽게 수행할 수 있습니다.

반복적인 일괄 처리에서는 데이터를 공유 및 확장 가능한 환경에 저장하여 통합합니다. 일반적인 패턴은 몇 분마다 한 번씩 로컬 위치의 로그 파일을 객체 스토리지로 옮기는 것입니다. 파일 이름에는 프리픽스와 서픽스가 붙는 경우가 많습니다(예: logs_serverABC_timestamp123.txt).

다음 스토리지 시스템에서 분석 워크로드를 실행할 수 있습니다.

  • Cloud Storage: 표준, Nearline, Coldline 스토리지 클래스를 사용하여 데이터를 빠른 액세스, 백업 또는 보관하도록 저장할 수 있습니다. 가능한 경우 분석에 적합한 옵션인 표준 스토리지를 리전 버킷으로 설정합니다. 데이터를 처리하는 컴퓨팅 리소스와 같은 리전에 스토리지를 설정합니다. Dataproc, Dataflow, Dataprep by Trifacta, BigQuery를 포함한 대부분의 Google Cloud 제품에서 Cloud Storage에 액세스할 수 있습니다.
  • BigQuery: BigQuery는 강력한 쿼리 엔진 이상의 기능을 제공합니다. Capacitor라는 자체 스토리지도 있습니다. Capacitor를 사용하면 엑사바이트 단위의 데이터를 저장할 수 있으며 Dataproc, Dataflow, BigQuery 쿼리 엔진에서 BigQuery 스토리지에 액세스할 수 있습니다. BigQuery의 장기 스토리지를 사용하면 90일 동안 편집되지 않은 파티션의 스토리지 비용이 약 50% 절감됩니다.
  • Cloud Bigtable: 매일 수백만 개의 이벤트가 수집되고 몇 밀리초 수준에서 많은 쓰기와 많은 읽기가 모두 필요한 경우 Cloud Bigtable이 적합합니다. HBase API 및 기타 클라이언트에서 액세스할 수 있습니다. 또한 그래프, 시계열, 분석을 위해 Cloud Bigtable을 빅데이터 생태계와 함께 사용할 수도 있습니다.

일반적인 권장사항은 다음과 같습니다.

  • 원시 데이터를 다른 처리 작업과 병렬로 BigQuery에 저장합니다. 여기서 매 시간, 매일, 매주 또는 매월 손쉽게 롤업할 수 있습니다. 로드 옵션은 요구사항에 따라 달라집니다. 자세한 내용은 BigQuery 데이터 로드 문서를 참조하세요.
  • 비용이 중요한 경우 bq load, Cloud Functions, 작업 API 또는 연합 쿼리를 사용하여 비용 없이 또는 스트리밍보다 더 낮은 비용으로 Cloud Storage에 저장된 데이터를 BigQuery로 로드할 수 있습니다. 처음 두 가지 옵션에는 할당량이 적용됩니다.
  • 쿼리 시간 및 비용을 최소화하려면 파티션클러스터링과 같은 BigQuery의 스토리지 기능을 사용합니다.

이벤트 처리

처리 파이프라인을 빌드하기 위한 기술을 선택하는 경우 다음 사항을 고려하세요.

  • 지연: 어느 데이터를 실시간으로 처리해야 하는지를 결정합니다. 예를 들어 예산 카운터를 최대한 빠르게 계산해야 할 수 있습니다.
  • 정확성: 일부 값은 반드시 즉각 계산할 필요는 없더라도 정확한 계산이 필요합니다. 예를 들어 청구 금액이 있습니다.
  • 고가용성: 매일 수십억 회의 데이터 입력이 수행되는 상황에서 몇 분의 다운타임은 심각한 재무적 영향으로 이어질 수 있습니다.
  • 운영 오버헤드: 기술 리소스를 '단순 유지 업무'에 투입하는 것은 리소스를 사용하는 최선의 방법이 아닐 수 있습니다.

다음 예시를 참조하세요.

  • HTTP 부하 분산 로그는 Cloud Logging을 통해 실시간으로 수집됩니다.
  • 일부 로그는 잔여 예산을 계산하도록 즉각 처리되어야 합니다.
  • 노출수는 매 시간 집계 및 필요합니다. 캠페인 빈도에는 매일 한도가 적용됩니다.

기업에서는 데이터 처리 파이프라인의 균형을 위해 일반적으로 람다 아키텍처를 도입합니다.

  • 실시간 처리 파이프라인을 통한 빠른 근접
  • 부가적인 오프라인 일괄 처리 파이프라인을 통한 정확성

람다 데이터 처리 파이프라인

이 섹션에서는 람다 및 카파 데이터 처리 아키텍처와 Dataflow를 구현하는 데 사용할 수 있는 몇 가지 Google Cloud 제품을 설명합니다.

  • Dataproc(일괄 처리 및 스트림): 이미 기존 Hadoop 또는 Spark 작업 및 스크립트가 있는 경우 Dataproc, Google Cloud 관리 Spark 또는 Hadoop에 그대로 마이그레이션할 수 있습니다.
  • Dataflow(일괄 처리 및 스트림): 새 워크로드가 있고 고급 스트리밍 기능을 사용하거나 통합 모델 프로그래밍 모델이 필요한 경우를 위해 Dataflow는 Google에서 오픈소스로 제공하는 Apache Beam을 실행하는 완전 관리형 서비스를 제공합니다. Dataflow는 Pub/Sub 및 Kafka와 같은 여러 입력/출력도 지원합니다. Dataflow는 단 1회 처리를 지원하는, 스트리밍 및 일괄 처리 데이터를 위한 통합 프로그래밍 모델을 제공합니다.
  • BigQuery(일괄 처리): ELT(Extract, Load, Transform) 접근 방법을 고려하거나 데이터 웨어하우스에 데이터가 로드된 후 후속 변환을 수행하는 경우 SQL 변환에 BigQuery를 사용할 수 있습니다. 관리형이며, 사용자 정의 함수도 제공합니다. 이러한 쿼리를 조정하는 데 관리형 Apache AirflowCloud Composer를 사용하는 것이 좋습니다.
  • 타사 도구: Hadoop 생태계의 도구 또는 Storm과 같은 도구를 Compute Engine 또는 Google Kubernetes Engine(GKE)에 설치 및 관리할 수 있습니다.

다음 아키텍처는 이러한 요구사항을 기반으로 한 권장사항을 설명합니다.

  • 실시간으로 이벤트 내부 데이터화
  • 매 초 일부 카운터 계산
  • 매 시간 노출 수 전체보기
  • 일일 광고 클릭율 계산

Pub/Sub을 사용하는 데이터 처리 파이프라인

데이터 처리 흐름은 다음과 같습니다.

  1. 이벤트가 Pub/Sub에 기록됩니다.
  2. Dataflow가 이벤트 레벨 데이터를 BigQuery에 직접 씁니다.
  3. 또한 Dataflow는 데이터를 1초 간격으로 분할해서 필요한 집계를 수행하고 지역 Cloud Bigtable 인스턴스에 카운터를 씁니다.
  4. BigQuery는 반복적으로 쿼리를 실행하여 데이터를 롤업하고 결과를 구체화합니다. 크론 작업을 통해 또는 Cloud Composer를 통해 Apache Airflow 예약 옵션을 사용하여 이를 예약할 수 있습니다.
  5. 사용자 프런트엔드는 BigQuery를 OLAP 데이터베이스로 사용할 수 있습니다. 자세한 내용은 보고(1부)를 참조하세요.
  6. 지역 광고 서버는 가까운 Cloud Bigtable 인스턴스를 쿼리하여 신속하게 카운터를 검색합니다.

데이터 처리 파이프라인 빌드의 일반 권장사항을 따르세요.

  • Pub/Sub를 사용하여 운영 오버헤드를 최소화하거나 Google Cloud에서 관리형 서비스로 Apache Kafka를 실행하는 것이 좋습니다.
  • 통합 프로그래밍 모델을 통해 일괄 처리 및 스트리밍에 접근하려면 Apache Beam을 사용하여 파이프라인을 작성하는 방법을 고려하세요.
  • Cloud Dataflow에서 Apache Beam을 실행하면 작업 수명 동안 작업자 수를 자동 확장하고 동적으로 작업을 분산하여 작업의 전체 처리 시간을 단축할 수 있는 완전 관리형 서비스의 이점을 누릴 수 있습니다.

분석을 위해 시각적으로 탐색, 정리, 준비하려는 이벤트 또는 다른 데이터가 있으면 Dataprep을 사용하는 것이 좋습니다. 코드를 작성할 필요가 없으며 Dataprep에서 재사용 및 예약 가능한 Dataflow 템플릿을 내보낼 수 있습니다.

내보내기

이벤트가 내부 데이터화 및 처리될 때 결과를 다음과 같이 내보낼 수 있습니다.

  • 롤업 및 분석을 포함한 오프라인 처리를 위해 BigQuery와 같은 오프라인 저장소 또는 Cloud Storage
  • Cloud Bigtable, Datastore, Memorystore, 타사 저장소와 같은 제공 저장소. 프런트엔드 서버는 이러한 저장소를 사용하여 예를 들어 광고 선택 시 사용자 프로필에 대한 정보를 검색하고 카운터를 업데이트합니다.
  • 데이터에 추가 다운스트림 처리가 필요하거나 예를 들어 예산 관리 시 데이터를 알림으로 전송해야 하는 경우 Pub/Sub 또는 Kafka와 같은 메시징 시스템

데이터 복제는 또 다른 내보내기 사용 사례입니다. 예를 들어 데이터가 프런트엔드 서버 가까이 위치하거나 그 서버에 위치해야 하는 경우 두 가지 접근 방법이 있습니다.

  • 선택하는 기술에서 지원한다면 기본 복제 기능을 사용할 수 있습니다. Redis 및 Aerospike와 같은 일부 기술은 지역 내에서 복제를 지원합니다. 그러나 리전 간 복제는 더 어려울 수 있습니다.
  • 다른 기술에서 복제를 지원하지 않을 수 있습니다. 이러한 경우 Compute Engine 또는 Pub/Sub에서 실행되는 메시징 시스템과 프로세서로 복제를 구현할 수 있습니다.

다음 다이어그램에서 몇 가지 방법을 보여줍니다.

Google Cloud 저장소를 통한 데이터 복제 구조

데이터는 Dataflow를 사용하여 실시간으로, 그리고 BigQuery를 사용하여 오프라인으로 처리되며 이후에는 다음이 수행됩니다.

  • Dataflow는 Apache Beam Redis IO를 사용하여 Redis 클러스터에 직접 데이터를 씁니다. 그러면 데이터가 로컬 작업자로 복제됩니다.
  • Dataflow가 Pub/Sub에 메시지를 게시합니다. 그런 다음 메시지는 자동 확장되는 구독자 풀에 의해 읽히고 Compute Engine에 배포되며, 이후 Compute Engine에서 실행되는 Aerospike 클러스터에 작성됩니다.
  • Cloud Composer를 통해 예약되는 BigQuery 오프라인 작업의 레코드는 Redis 및 Aerospike 클러스터로 내보내집니다.

데이터를 내보낼 때 다음을 권장합니다.

  • 선택한 데이터 저장소가 읽기 및 쓰기 패턴을 모두 처리할 수 있는지 확인합니다. 그렇지 않은 경우 읽기 인프라를 분리하는 방법을 고려하세요. 자세한 내용은 대량 읽기 저장 패턴(1부)을 참조하세요.
  • 애널리틱스의 경우 쿼리 비용과 기간을 최소화하려면 BigQuery를 클러스터링파티션 나누기와 함께 사용합니다.
  • 한 자릿수 밀리초 읽기 및 쓰기를 위해서는 Cloud Bigtable을 사용하는 것을 고려하세요. 고가용성을 위해 복제를 사용 설정합니다.
  • BigQuery로 실시간 쓰기의 경우 Apache Beam BigQuery IO의 기본 스트리밍 API를 사용합니다. Apache Beam 자바 SDK를 사용하면 FILE_LOADS로 Cloud Storage를 통해 마이크로 배치로 작성하여 비용을 절감할 수 있습니다.
  • 1밀리초 미만의 대량 쓰기의 경우 Compute Engine 또는 Pub/Sub에 설치된 타사 Datastore를 사용하는 것이 좋습니다.

자동화

데이터 파이프라인에는 다음을 위한 여러 오프라인 흐름 중 하나가 사용될 수 있습니다.

엔드 투 엔드 자동화 및 실패 관리를 위해서는 Apache Airflow용 Cloud Composer를 사용하는 것을 고려하세요. Airflow는 Google Cloud에서 워크플로를 관리하는 데 권장되는 오픈소스 기술입니다. DAG는 수동으로 또는 이벤트에 의해 트리거되거나 반복적으로 실행되도록 예약될 수 있습니다.

비교적 간단한 이벤트 기반 작업이 필요한 경우 Cloud Storage에 생성되는 새 파일 또는 Pub/Sub에 게시되는 새로운 이벤트에서 Cloud Functions를 트리거할 수 있습니다. Cloud Functions는 완전 관리형이므로 운영 오버헤드를 없애줍니다. 더 맞춤화된 서버리스 옵션의 경우 서버리스 워크로드를 빌드, 배포, 관리하기 위한 유망한 Kubernetes 기반 부가기능인 Knative에 대해 읽어보세요.

분석

BigQuery는 다음과 같은 이유로 분석 처리 및 임시 쿼리를 위해 권장되는 데이터 웨어하우스입니다.

  • 완전 관리형입니다.
  • 최적화된 스토리지 레이어와 확장 가능한 쿼리 엔진을 제공합니다.
  • 윈도우 함수UDF를 포함한 표준 SQL을 사용하여 테라바이트 단위의 데이터에 대한 임시 쿼리를 사용 설정합니다.
  • 주문형 또는 정액제를 통해 쿼리 사용량에 적용되는 가격 정책 옵션을 제공합니다.
  • 장기 요금으로 장기 스토리지 가격을 제공합니다.
  • BigQuery ML을 통한 머신러닝 기능을 제공합니다.
  • 통합 모니터링비용 관리가 있습니다.

팁:

BigQuery 승인 뷰 사용을 고려하세요. 승인된 뷰를 사용하면 기반 테이블에 대한 액세스 권한을 부여하지 않고도 쿼리 결과를 공유하고 사용자가 쿼리할 수 있는 열을 제한할 수 있습니다.

Hive에서의 이전에 관심이 있는 경우 BigQuery로 Parquet 파일을 로드하는 방법을 고려하세요.

분석 및 SQL 기반 오프라인 처리에 BigQuery를 사용하는 것이 좋지만 Google Cloud에는 다른 옵션도 있습니다.

  • Apache Spark, Hive, Pig를 포함한 Hadoop 워크로드에는 Dataproc을 사용하는 것이 좋습니다. Dataproc 커넥터를 사용하면 Apache Spark 및 Hadoop 작업을 Cloud Storage에서 실행할 수 있으며 데이터 고가용성, 다른 Google Cloud 서비스와의 상호 운용성, HDFS 호환성을 비롯한 여러 가지 이점을 누릴 수 있습니다.
  • Compute Engine 또는 Pub/Sub에서 타사 도구를 설치 및 관리할 수 있습니다. Druid는 프런트엔드 사용자를 위한 저지연 OLAP 데이터베이스로 BigQuery 이외에 부가적으로 사용되는 경우가 많습니다.

머신러닝 기능 구축

이벤트 처리는 정리와 집계가 전부가 아닙니다. 데이터 파이프라인에 머신러닝 기능을 추가하면 모델 특성으로 사용 가능한 더 나은 광고 권장, 가상 사용자 세그먼트 생성과 같은 인텔리전스를 추가할 수 있습니다. Google Cloud는 다음을 포함한 다양한 머신러닝 AI 구성 요소를 제공합니다.

Cloud Storage 든 BigQuery든 수십억 개의 일별 이벤트가 데이터 레이크 또는 웨어하우스에 수집 및 저장되는 상황에서 이 데이터를 사용하여 입찰과 관련된 강력한 모델을 학습시킬 수 있습니다. 예를 들면 다음과 같습니다.

  • 입찰할지 여부를 결정합니다.
  • CTR을 추정합니다.
  • 입찰 가격을 최적화합니다.
  • 고객을 세그먼트화합니다.
  • 고객평생가치(LTV)를 계산합니다.
  • 선택할 광고를 권장합니다.

머신러닝 플랫폼을 선택할 때 자문해야 할 사항은 다음과 같습니다.

  • 내 데이터를 얼마나 잘 아는가?
  • 얼마나 많은 데이터가 있는가?
  • 학습에 사용될 데이터의 양은 얼만큼인가?
  • 학습은 온라인과 오프라인 중 어느 방식으로 하는가?
  • 예측은 온라인과 오프라인 중 어느 방식으로 하는가?
  • 제공이 예측으로부터 독립적일 수 있는가?

다음 다이어그램은 아래 단계에 따르는 일반적인 머신러닝 흐름을 보여줍니다.

  1. BigQuery로 데이터세트를 정리/준비합니다.
  2. 학습 및 평가 데이터세트를 Cloud Storage로 내보냅니다.
  3. AI Platform으로 모델을 학습합니다.
  4. Cloud Storage로 모델을 내보냅니다.
  5. 작업자가 초기화되면 Cloud Storage에서 모델을 가져옵니다.
  6. 로컬에서 TensorFlow 모델을 사용하여 짧은 지연 시간으로 예측을 수행합니다.

일반적인 머신러닝 흐름

데이터 및 특성 추출 준비

데이터를 머신러닝 모델에 공급하기 전에 다음 작업을 수행하세요.

  1. 데이터세트를 탐색하여 당면한 작업에서 데이터의 적합성을 파악합니다.
  2. 여러 테이블의 데이터를 조인하고 해당되지 않는 레코드를 필터링하여 데이터세트를 정리 및 준비합니다.
  3. 특성을 추출, 빌드, 선택하여 관찰 대상에 관한 정보를 제공하는, 구분되는 속성을 만듭니다.

BigQuery는 BigQuery에 저장된 데이터와 외부의 제휴 데이터 소스를 대상으로 이러한 작업을 수행하기에 적합합니다. 필터링 및 선택한 데이터 세트를 특성 추출을 위해 Cloud Storage로 내보내기 전에 BigQuery를 사용하여 데이터를 쿼리 및 탐색할 수 있습니다.

: 데이터 탐색에 BigQuery를 사용하는 것 외에 Dataprep을 BigQuery에 연결하여 데이터를 샘플링하고 시각적으로 프로파일링할 수 있습니다.

다음 태스크에서는 일반적으로 예측을 온라인으로 할지 오프라인으로 할지를 고려해야 합니다. 온라인 예측을 수행하는 경우 예측의 요청 데이터에서 특성이 추출되는 방법을 고려하는 것이 중요합니다.

  • 온라인 예측의 경우 편향을 방지하려면 학습 및 예측 중에 동일한 기능 생성 단계를 수행해야 합니다. tf.Transform을 사용하면 이러한 사전 처리 단계를 정의하고 학습 및 평가 중에 Apache Beam을 사용하여 대규모로 이 작업을 수행할 수 있습니다. 또한 TensorFlow 그래프의 일부로 단계를 내보내 예측을 제공할 수 있습니다. 이 블로그에서는 이 프로세스의 작동 방식에 대한 유용한 정보를 제공합니다.
  • 오프라인 예측의 경우 학습 및 예측 단계 중에 동일한 접근 방법을 사용할 수 있습니다. BigQuery를 사용하여 일괄 사전 처리의 일부로 특성을 생성할 수 있습니다. 예를 들어 해시 함수를 사용하여 특성을 벡터화하거나 조인을 통해 연관 값을 찾을 수 있습니다.

학습 및 평가

Google Cloud는 모델 학습 및 평가용으로 다음과 같은 여러 가지 옵션을 제공합니다.

  • AI Platform을 사용하여 XGboost, Scikit-Learn, TensorFlow 학습 및 평가 작업을 완전 관리형 환경에서 실행합니다. AI Platform은 자동 초매개변수 미세 조정분산 학습과 같은 부가 기능도 제공합니다.

  • Compute Engine 인스턴스에서 학습 및 평가 작업을 직접 실행. 원하는 소프트웨어 패키지를 설치해야 합니다. 또한 비용과 처리 시간을 절약하도록 GPU, TPU 또는 선점형 VM을 사용할 수 있습니다.

  • Kubeflow를 사용하여 Kubernetes의 컨테이너화된 환경에서 TensorFlow 및 노트북과 같은 많은 머신러닝 도구를 설치하고 실행

  • SQL 인터페이스에서 바로 BigQuery ML을 사용하여 구조화된 데이터에 대한 오프라인 학습

ML 플랫폼 선택은 요구사항에 따라 다릅니다.

  • 비용을 최소화하려면 Compute Engine을 선점형 VM과 함께 사용합니다.
  • 학습, 배포, 제공을 위한 완전 관리형 환경이 필요한 경우 AI Platform을 사용합니다.
  • 모든 Kubernetes 클러스터에서 실행 가능한 재현 가능한 확장된 ML 환경을 만들려면 Kubeflow를 사용합니다.
  • 구조화된 데이터가 있고 오프라인으로 예측을 수행하고 선형 또는 로지스틱 회귀를 구현하고자 하는 경우 BigQuery ML을 사용합니다.

예측

학습 섹션에 언급된 제품과 동일한 제품을 사용하여 오프라인 또는 온라인으로 예측을 수행합니다. Compute Engine, Kubeflow, AI Platform은 모두 TensorFlow Serving을 사용하여 예측을 수행할 수 있습니다. 이러한 옵션 간의 차이점은 작업 오버헤드, 미세 조정 옵션, 가격입니다.

낮은 지연이 중요한 요구사항인 경우 직렬화된 또는 컴파일된 모델을 직접 사용할 수 있습니다. 이는 데이터 파이프라인에서도 유용할 수 있습니다. 추가 링크는 다음 단계를 참조하세요.

제공

예측과 제공은 때때로 동일한 작업으로 간주되는데, 온라인 예측의 경우 실제로 둘은 동일한 작업입니다. 그러나 오프라인으로 예측을 수행한 다음 데이터 저장소에 그 결과를 유지하는 경우 예측이 요청될 때 이 저장소에서 예측을 제공해야 합니다.

빠른 예측 제공은 유효함과 효율성 사이의 타협입니다. 다양한 접근 방법 또는 여러 접근 방법의 조합을 사용할 수 있습니다. TensorFlow Serving을 사용하여 실시간으로 예측하려는 경우 GPU 또는 TPU와 같은 가속기를 사용하고 다음 방법 중 하나를 사용하여 모델을 제공에 최적화하는 방법을 고려하세요.

빠른 키/값 저장소의 사전 제작된 예측을 사용하려는 경우 특성의 순열을 기반으로 키를 생성해야 합니다. 대륙과 기기 유형을 기반으로 입찰할지 여부를 예측하려는 경우를 가정해 보세요.

  1. 대륙 이름과 모바일/웹의 가능한 모든 조합을 생성합니다.
  2. 이러한 조합의 예측 결과를 저장합니다.

    예측
    antarctica_mobile 0
    antarctica_web 1
    asia_mobile 1
    asia_web 0
    europe_mobile 1
    europe_web 0
    northamerica_mobile 1
    northamerica_web 1
    southamerica_mobile 1
    southamerica_web 0
    oceania_mobile 1
    oceania_web 0

    그러면 요청을 받을 때 올바른 키에서 빠른 가져오기를 수행할 수 있습니다. Redis, Aerospike, Cloud Bigtable은 이 사용 사례에 적합한 후보입니다.

구현하기 전에 다음을 유의하세요.

  • 특성이 많은 경우 조합의 크기가 허용되는 최대 키 크기보다 클 수 있습니다.
  • 많은 수의 요청과 키를 지원하려면 필요한 경우 키 분산을 고려하고 키의 일부분을 해시하여 특정 행의 부하 집중을 피하세요. Cloud Bigtable에는 이러한 문제를 진단하는 데 도움이 되는 Key Visualizer 도구가 있습니다.
  • 이러한 연속 값을 위한 범주형 데이터가 없는 경우 버킷화해야 합니다. 각 특성의 버킷 크기를 결정하는 것은 그 자체로 작업입니다.
  • 키 간 거리를 계산하려면 임베딩을 사용하세요. 키가 존재하지 않는 경우 가장 근접한 인접 항목을 찾을 수 있습니다. 로컬 구분 해싱을 만드는 방법은 여러 가지입니다. 이러한 해시를 계산하는 것은 머신러닝 작업입니다.

다음 단계