파이프라인 배포

Apache Beam 파이프라인을 생성 및 테스트한 후에는 Cloud Dataflow 관리형 서비스를 사용하여 이를 배포 및 실행할 수 있습니다. Cloud Dataflow 서비스에서 파이프라인 코드는 Cloud Dataflow 작업이 됩니다.

Cloud Dataflow 서비스는 필요한 리소스를 자동으로 가동하고 해제하는 등 Compute EngineCloud Storage와 같은 Google Cloud Platform(GCP) 서비스를 완벽하게 관리하여 Cloud Dataflow 작업을 실행합니다. Cloud Dataflow 서비스는 Cloud Dataflow 모니터링 인터페이스Cloud Dataflow 명령줄 인터페이스와 같은 도구를 통해 작업에 가시성을 제공합니다.

파이프라인 코드에서 실행 매개변수를 설정하여 Cloud Dataflow 서비스의 작업 실행 방식 중 일부 측면을 제어할 수 있습니다. 예를 들어 실행 매개변수는 작업자 가상 머신, Cloud Dataflow 서비스 백엔드 또는 로컬에서 파이프라인 단계가 실행되는지 여부를 지정합니다.

Cloud Dataflow 서비스는 GCP 리소스 관리 외에도 분산 병렬 처리의 여러 측면을 자동으로 수행하고 최적화합니다. 이 작업에는 다음이 포함됩니다.

  • 병렬 처리 및 분산. Cloud Dataflow는 자동으로 데이터의 파티션을 나누고, 병렬 처리를 위해 Compute Engine 인스턴스에 작업자 코드를 분산합니다.
  • 최적화. Cloud Dataflow는 파이프라인 코드를 사용하여 파이프라인의 PCollection 및 변환을 나타내는 실행 그래프를 만들고, 가장 효율적인 성능 및 리소스 사용을 위해 그래프를 최적화합니다. Cloud Dataflow는 또한 데이터 집계와 같이 많은 비용이 들 수 있는 작업을 자동으로 최적화합니다.
  • 자동 조정 기능. Cloud Dataflow 서비스에는 자동 확장 및 동적 작업 재균등화와 같이 리소스 할당 및 데이터 파티션 나누기를 신속하게 조정할 수 있는 기능 몇 가지가 포함되어 있습니다. 이러한 기능을 사용하면 Cloud Dataflow 서비스가 작업을 최대한 빠르고 효율적으로 실행할 수 있습니다.

파이프라인 수명 주기: 파이프라인 코드에서 Cloud Dataflow 작업까지

Cloud Dataflow 프로그램을 실행하는 경우, Cloud Dataflow는 모든 변환 및 관련 처리 함수(예: DoFn)를 비롯하여 Pipeline 객체를 구성하는 코드에서 실행 그래프를 만듭니다. 이 단계를 그래프 생성 시간이라고 합니다. 그래프를 생성하는 동안 Cloud Dataflow는 여러 가지 오류를 검사하고 파이프라인 그래프에 부적합한 작업이 포함되어 있지 않는지를 확인합니다. 실행 그래프는 JSON 형식으로 변환되고 JSON 실행 그래프는 Cloud Dataflow 서비스 엔드포인트로 전송됩니다.

참고: 파이프라인을 로컬에서 실행하는 경우에도 그래프가 생성되긴 하지만 그래프는 JSON으로 변환되지 않으며 서비스로 전송되지 않습니다. 대신, 그래프는 Cloud Dataflow 프로그램을 실행한 곳과 동일한 머신에서 로컬로 실행됩니다. 자세한 내용은 로컬 실행 구성에 대한 문서를 참조하세요.

그런 다음, Cloud Dataflow 서비스는 JSON 실행 그래프의 유효성을 검사합니다. 그래프의 유효성이 검사되면 그래프는 Cloud Dataflow 서비스의 작업이 됩니다. Cloud Dataflow 모니터링 인터페이스를 사용하여 작업, 실행 그래프, 상태, 로그 정보를 확인할 수 있습니다.

자바: SDK 2.x

Cloud Dataflow 서비스는 사용자가 Cloud Dataflow 프로그램을 실행한 머신에 응답을 보냅니다. 이 응답은 Cloud Dataflow 작업의 jobId가 포함되어 있는 DataflowPipelineJob 객체에 캡슐화되어 있습니다. jobId를 사용하고 Cloud Dataflow 모니터링 인터페이스Cloud Dataflow 명령줄 인터페이스를 통해 작업을 모니터링 및 추적하고 문제를 해결할 수 있습니다. 자세한 내용은 DataflowPipelineJob에 대한 API 참조를 참조하세요.

Python

Cloud Dataflow 서비스는 사용자가 Cloud Dataflow 프로그램을 실행한 머신에 응답을 보냅니다. 이 응답은 Cloud Dataflow 작업의 job_id가 포함되어 있는 DataflowPipelineResult 객체에 캡슐화되어 있습니다. job_id를 사용하고 Cloud Dataflow 모니터링 인터페이스Cloud Dataflow 명령줄 인터페이스를 통해 작업을 모니터링 및 추적하고 문제를 해결할 수 있습니다.

자바: SDK 1.x

Cloud Dataflow 서비스는 사용자가 Cloud Dataflow 프로그램을 실행한 머신에 응답을 보냅니다. 이 응답은 Cloud Dataflow 작업의 jobId가 포함되어 있는 DataflowPipelineJob 객체에 캡슐화되어 있습니다. jobId를 사용하고 Cloud Dataflow 모니터링 인터페이스Cloud Dataflow 명령줄 인터페이스를 통해 작업을 모니터링 및 추적하고 문제를 해결할 수 있습니다. 자세한 내용은 DataflowPipelineJob에 대한 API 참조를 참조하세요.

실행 그래프

Cloud Dataflow는 Pipeline 객체 구성 시 사용한 변환 및 데이터를 기반으로 하여 파이프라인을 나타내는 단계 그래프를 작성합니다. 이것이 파이프라인 실행 그래프입니다.

Apache Beam SDK에 포함되어 있는 WordCount 예제 프로그램에는 각 단어의 발생 횟수와 함께 텍스트 컬렉션에서 개별 단어를 읽고, 추출하고, 계산하고, 형식을 지정하고, 작성하는 일련의 변환이 포함되어 있습니다. 다음 다이어그램에서는 WordCount 파이프라인의 변환이 실행 그래프로 확장되는 방법이 표시되어 있습니다.

WordCount 예제 프로그램의 변환을 Cloud Dataflow 서비스가 실행하는 단계의 실행 그래프로 확장
그림 1: WordCount 예제 실행 그래프

실행 그래프는 사용자가 파이프라인을 구성할 때 변환을 지정한 순서와 다른 경우가 많습니다. 그 이유는 Cloud Dataflow 서비스가 관리형 클라우드 리소스에서 실행되기 전에 실행 그래프에 다양한 최적화 및 융합을 수행하기 때문입니다. Cloud Dataflow 서비스는 파이프라인을 실행할 때 데이터 종속 항목을 준수합니다. 하지만 서로 간에 데이터 종속 항목이 없는 단계는 임의의 순서로 실행될 수 있습니다.

Cloud Dataflow 모니터링 인터페이스에서 작업을 선택하면 Cloud Dataflow가 파이프라인에 대해 생성한 최적화되지 않은 실행 그래프를 확인할 수 있습니다.

병렬 처리 및 분산

Cloud Dataflow 서비스는 파이프라인의 처리 논리를 자동으로 병렬 처리하여 사용자가 작업 수행을 위해 할당한 작업자에게 분산합니다. Cloud Dataflow는 프로그래밍 모델의 추상화를 사용하여 동시 처리 함수를 나타냅니다. 예를 들어 Cloud Dataflow는 ParDo 변환을 통해 DoFn으로 표현되는 처리 코드를 여러 동시 실행 작업자에게 자동으로 분산할 수 있습니다.

사용자 코드 구조화

DoFn 코드를 작고 독립적인 항목으로 생각할 수 있습니다. 많은 인스턴스가 각 머신이 다른 머신에 대해 알지 못하는 상태에서 서로 다른 머신에서 실행 중일 수 있습니다. 이와 같이 퓨어 함수(숨겨진 상태 또는 외부 상태에 따라 달라지지 않고 부작용이 관찰되지 않는 확정 함수)는 DoFn의 동시 및 분산 특성에 적합한 코드입니다.

하지만 퓨어 함수 모델은 완전히 엄격하지 않습니다. 코드가 Cloud Dataflow 서비스에서 보장하지 않는 항목에 종속되지 않는 한, 상태 정보 또는 외부 초기화 데이터는 DoFn 및 기타 함수 객체에 대해 유효할 수 있습니다. ParDo 변환을 구조화하고 DoFn을 만드는 경우 다음 가이드라인을 따르세요.

  • Cloud Dataflow 서비스는 DoFn 인스턴스에서 입력 PCollection의 모든 요소가 정확히 한 번 처리되도록 보장합니다.
  • Cloud Dataflow 서비스는 DoFn이 호출되는 횟수를 보장하지 않습니다.
  • Cloud Dataflow 서비스는 분산된 요소가 그룹화되는 방식을 보장하지 않습니다. 즉, 어떤 요소가 함께 처리되는지를 보장하지 않습니다.
  • Cloud Dataflow 서비스는 파이프라인 과정에서 생성되는 정확한 DoFn 인스턴스 수를 보장하지 않습니다.
  • Cloud Dataflow 서비스는 내결함성이므로 작업자 문제가 발생하는 경우 코드를 여러 번 재시도할 수 있습니다. Cloud Dataflow 서비스는 코드의 백업 복사본을 만들 수 있으며, 수동 부작용과 관련된 문제가 발생할 수 있습니다(예: 코드가 고유하지 않은 이름을 사용하는 임시 파일을 사용하거나 만드는 경우).
  • Cloud Dataflow 서비스는 DoFn 인스턴스별 요소 처리를 직렬화합니다. 코드는 스레드로부터 완전히 안전하지 않아도 되지만 여러 DoFn 인스턴스 사이에 공유되는 상태는 스레드로부터 안전해야 합니다.

사용자 코드 빌드에 대한 자세한 내용은 프로그래밍 모델 문서의 사용자 제공 함수에 대한 요구사항을 참조하세요.

오류 및 예외 처리

데이터를 처리하는 동안 파이프라인에서 예외가 발생할 수 있습니다. 이러한 오류의 일부는 일시적 오류(예: 외부 서비스 액세스 시의 일시적인 어려움)이지만 일부는 영구 오류(예: 계산 중 null 포인터 또는 손상되거나 파싱할 수 없는 입력 데이터로 인한 오류)입니다.

Cloud Dataflow는 임의 번들에서 요소를 처리하고 번들의 요소에 오류가 발생하면 전체 번들을 재시도합니다. 일괄 모드에서 실행하면 실패 항목이 포함된 번들은 4번 재시도됩니다. 단일 번들이 4번 실패하면 파이프라인이 완전히 실패합니다. 스트리밍 모드에서 실행하는 경우 실패 항목이 포함된 번들은 무제한으로 재시도되므로 파이프라인이 영구적으로 중단될 수 있습니다.

융합 최적화

파이프라인 실행 그래프의 JSON 형식의 유효성을 검사하면 Cloud Dataflow 서비스는 최적화를 수행하기 위해 그래프를 수정할 수 있습니다. 이러한 최적화에는 파이프라인 실행 그래프의 여러 단계 또는 변환을 단일 단계로 융합하는 작업이 포함될 수 있습니다. 단계를 융합하면 Cloud Dataflow 서비스가 메모리와 처리 오버헤드 면에서 많은 비용이 들 수 있는 파이프라인의 모든 중간 PCollection을 구체화할 필요가 없게 됩니다.

파이프라인 구성에서 지정한 모든 변환이 서비스에서 실행되지만 다른 순서로 실행되거나 파이프라인을 가장 효율적으로 실행하도록 더 큰 융합 변환의 일부로 실행될 수 있습니다. Cloud Dataflow 서비스는 실행 그래프의 단계 간 데이터 종속 항목을 준수하지만 그렇지 않은 경우에는 단계를 임의 순서로 실행할 수 있습니다.

융합 예

다음 다이어그램은 자바용 Apache Beam SDK가 포함되어 있는 WordCount 예의 실행 그래프가 효율적으로 실행되도록 Cloud Dataflow 서비스에서 최적화 및 융합되는 방법을 보여줍니다.

WordCount 예제 프로그램의 실행 그래프가 최적화되고 Cloud Dataflow 서비스에서 단계 융합
그림 2: 실행 그래프를 최적화한 WordCount 예

융합 방지

파이프라인에서 Cloud Dataflow 서비스가 융합 최적화를 수행하지 않도록 해야 하는 몇 가지 경우가 있습니다. Cloud Dataflow 서비스가 파이프라인에서 최적의 작업 융합 방법을 잘못 추론하는 경우가 여기에 해당되며, 이 경우 Cloud Dataflow 서비스가 이용 가능한 모든 작업자를 제대로 사용하지 못할 수 있습니다.

예를 들어 융합으로 인해 Cloud Dataflow의 작업자 사용 최적화 기능이 제한될 수 있는 한 가지 경우는 '높은 팬아웃' ParDo입니다. 이러한 작업에서는 입력 컬렉션의 요소 수가 상대적으로 적음에도 ParDo에서 수백 또는 수천 배 더 많은 요소가 있는 출력을 생성한 다음 다른 ParDo가 수행될 수 있습니다. Cloud Dataflow 서비스가 ParDo 작업을 융합하면 중간 PCollection에 더 많은 요소가 포함되어 있는 경우에도 이 단계의 병렬 처리가 입력 컬렉션에 있는 항목 수 이하로 제한됩니다.

Cloud Dataflow 서비스가 중간 PCollection을 강제로 구체화도록 파이프라인에 작업을 추가하여 이러한 융합을 방지할 수 있습니다. 다음 작업 중 하나를 사용해 보세요.

  • GroupByKey를 삽입하고 첫 번째 ParDo 후에 그룹화 해제할 수 있습니다. Cloud Dataflow 서비스는 집계에서 ParDo 작업을 융합하지 않습니다.
  • 중간 PCollection부차 입력으로 다른 ParDo에 전달할 수 있습니다. Cloud Dataflow 서비스는 항상 부차 입력을 구체화합니다.

최적화 결합

집계 작업은 대규모 데이터 처리에서 중요한 개념입니다. 집계는 개념상 멀리 떨어져 있는 데이터를 모으기 때문에 상관 관계 설정에 매우 유용합니다. Cloud Dataflow 프로그래밍 모델은 집계 작업을 GroupByKey, CoGroupByKey, Combine 변환으로 나타냅니다.

Cloud Dataflow의 집계 작업은 여러 작업자에 걸쳐 분산되어 있을 수 있는 데이터를 포함하여 모든 데이터 세트 전반의 데이터를 결합합니다. 이러한 집계 작업 중에는 인스턴스 전반에서 데이터를 결합하기 전에 최대한 많은 양의 데이터를 로컬에서 결합하는 것이 가장 효율적인 경우가 많습니다. GroupByKey 또는 다른 집계 변환을 적용하면 Cloud Dataflow 서비스는 기본 그룹화 작업을 수행하기 전에 부분 결합을 로컬에서 자동으로 수행합니다.

부분 또는 다중 레벨 결합을 수행할 때 Cloud Dataflow 서비스는 파이프라인이 일괄 또는 스트리밍 데이터를 사용하는지 여부에 따라 다른 결정을 내립니다. 제한된 데이터의 경우 이 서비스는 효율성을 우선시하고 최대한 많은 로컬 결합을 수행합니다. 제한되지 않은 데이터의 경우, 서비스는 짧은 지연 시간을 우선시하므로 지연 시간을 증가시킬 수 있는 부분 결합을 수행하지 않을 수 있습니다.

자동 조정 기능

Cloud Dataflow 서비스에는 실행 중인 Cloud Dataflow 작업을 더욱 동적으로 최적화할 수 있는 자동 조정 기능 몇 가지가 포함되어 있습니다. 이러한 기능에는 자동 확장동적 작업 재균등화가 포함됩니다.

자동 확장

자동 확장을 사용하는 경우 Cloud Dataflow 서비스는 작업을 실행하는 데 필요한 적합한 작업자 인스턴스 수를 자동으로 선택합니다. Cloud Dataflow 서비스는 작업 특성을 고려하여 런타임 중에 더 많거나 적은 작업자를 동적으로 다시 할당할 수도 있습니다. 파이프라인의 특정 부분은 다른 부분보다 더 많은 연산을 필요로 할 수 있습니다. Cloud Dataflow 서비스는 이와 같은 작업 단계 중에 추가 작업자를 자동으로 가동하고 더 이상 필요하지 않을 때 종료할 수 있습니다.

자바: SDK 2.x

자동 확장은 모든 일괄 Cloud Dataflow 작업에서 기본적으로 사용됩니다. 파이프라인을 실행할 때 --autoscalingAlgorithm=NONE 옵션을 명시적으로 지정하여 자동 확장을 사용 중지할 수 있습니다. 이렇게 하면 Cloud Dataflow 서비스는 --numWorkers 옵션에 따라 작업자 수를 설정합니다. 기본값은 3입니다.

Cloud Dataflow 작업이 SDK 이전 버전을 사용하는 경우 파이프라인을 실행할 때 --autoscalingAlgorithm=THROUGHPUT_BASED 옵션을 지정하여 자동 확장을 사용 설정할 수 있습니다.

Python

자동 확장은 Python용 Apache Beam SDK 버전 0.5.1 이상을 사용하여 만든 모든 일괄 Cloud Dataflow 작업에서 기본적으로 사용 설정됩니다. 파이프라인을 실행할 때 --autoscaling_algorithm=NONE 옵션을 명시적으로 지정하여 자동 확장을 사용 중지할 수 있습니다. 이렇게 하면 Cloud Dataflow 서비스는 --num_workers 옵션에 따라 작업자 수를 설정합니다. 기본값은 3입니다.

Cloud Dataflow 작업이 SDK 이전 버전을 사용하는 경우 파이프라인을 실행할 때 --autoscaling_algorithm=THROUGHPUT_BASED 옵션을 지정하여 자동 확장을 사용 설정할 수 있습니다.

자바: SDK 1.x

자동 확장은 자바용 Cloud Dataflow SDK 버전 1.6.0 이상을 사용하여 만든 모든 일괄 Cloud Dataflow 작업에서 기본적으로 사용됩니다. 파이프라인을 실행할 때 --autoscalingAlgorithm=NONE 옵션을 명시적으로 지정하여 자동 확장을 사용 중지할 수 있습니다. 이렇게 하면 Cloud Dataflow 서비스는 --numWorkers 옵션에 따라 작업자 수를 설정합니다. 기본값은 3입니다.

Cloud Dataflow 작업이 SDK 이전 버전을 사용하는 경우 파이프라인을 실행할 때 --autoscalingAlgorithm=THROUGHPUT_BASED 옵션을 지정하여 자동 확장을 사용 설정할 수 있습니다.

일괄 자동 확장

일괄 모드의 제한된 데이터의 경우, Cloud Dataflow는 파이프라인 각 단계의 작업량과 해당 단계의 현재 처리량을 기준으로 하여 작업자 수를 자동으로 선택합니다.

파이프라인이 사용자가 구현한 커스텀 데이터 소스를 사용하는 경우 사용자는 Cloud Dataflow 서비스의 자동 확장 알고리즘에 더 많은 정보를 제공하고 성능을 개선할 수 있는 몇 가지 방법을 구현할 수 있습니다.

자바: SDK 2.x

  • BoundedSource 하위 클래스에서 getEstimatedSizeBytes 메소드를 구현합니다. Cloud Dataflow 서비스는 파이프라인에 사용할 초기 작업자 수를 계산할 때 getEstimatedSizeBytes를 사용합니다.
  • BoundedReader 하위 클래스에서 getFractionConsumed 메소드를 구현합니다. Cloud Dataflow 서비스는 읽기 진행률을 추적하고 읽기 중 사용할 올바른 작업자 수를 수렴하는 데 getFractionConsumed를 사용합니다.

Python

  • BoundedSource 하위 클래스에서 estimate_size 메소드를 구현합니다. Cloud Dataflow 서비스는 파이프라인에 사용할 초기 작업자 수를 계산할 때 estimate_size를 사용합니다.
  • RangeTracker 하위 클래스에서 fraction_consumed 메소드를 구현합니다. Cloud Dataflow 서비스는 읽기 진행률을 추적하고 읽기 중 사용할 올바른 작업자 수를 수렴하는 데 fraction_consumed를 사용합니다.

자바: SDK 1.x

  • BoundedSource 하위 클래스에서 getEstimatedSizeBytes 메소드를 구현합니다. Cloud Dataflow 서비스는 파이프라인에 사용할 초기 작업자 수를 계산할 때 getEstimatedSizeBytes를 사용합니다.
  • BoundedReader 하위 클래스에서 getFractionConsumed 메소드를 구현합니다. Cloud Dataflow 서비스는 읽기 진행률을 추적하고 읽기 중 사용할 올바른 작업자 수를 수렴하는 데 getFractionConsumed를 사용합니다.

스트리밍 자동 확장

자바: SDK 2.x

스트리밍 자동 확장을 사용하면 Cloud Dataflow 서비스에서 로드 및 리소스 사용률의 변화에 따라 스트리밍 파이프라인을 실행하는 데 사용되는 작업자 수를 적절하게 변경할 수 있습니다. 스트리밍 자동 확장은 무료 기능이며 스트리밍 파이프라인을 실행할 때 사용되는 리소스의 비용을 절감하도록 설계되었습니다.

자동 확장을 사용하지 않는 경우 --numWorkers를 지정하여 파이프라인을 실행하는 고정된 작업자 수를 선택하게 됩니다. 시간에 따라 입력 작업 부하가 달라지므로 이 숫자는 너무 높거나 낮아질 수 있습니다. 너무 많은 작업자를 프로비저닝하면 불필요한 추가 비용이 발생하고, 너무 적은 작업자를 프로비저닝하면 데이터 처리 지연 시간이 길어집니다. 자동 확장을 사용하면 필요한 경우에만 리소스가 사용됩니다.

자동 확장은 작업자의 바쁨 정도와 이러한 작업자가 입력 스트림을 처리할 수 있는지 여부를 평가하는 몇 가지 신호를 사용하여 확장 결정을 내립니다. 주요 신호에는 CPU 사용률, 처리량, 백로그가 있습니다. 목표는 작업자 사용률 및 처리량을 최대화하면서 백로그를 최소화하고 부하 급증에 빠르게 대처하는 것입니다. 자동 확장을 사용하면 최대 부하에 대비한 프로비저닝과 최신 결과 중 무엇을 선택할지 고민할 필요가 없습니다. CPU 사용률 및 백로그가 증가하면 작업자가 추가되고, 감소하면 작업자가 제거됩니다. 따라서 필요한 항목에만 비용을 지불하면 되며 작업이 최대한 효율적으로 처리됩니다.

파이프라인에서 제한되지 않은 커스텀 소스를 사용하는 경우 이 소스가 Cloud Dataflow 서비스에 백로그에 대해 알려야 합니다. 백로그는 아직 소스에서 처리하지 않은 입력 추정치입니다(단위: 바이트). 서비스에 백로그에 관한 정보를 제공하려면 UnboundedReader 클래스에서 다음 메소드 두 개 중 하나를 구현합니다.

  • getSplitBacklogBytes() - 현재 소스 분할에 대한 백로그입니다. 서비스는 모든 분할에 걸쳐 백로그를 집계합니다.
  • getTotalBacklogBytes() - 모든 분할에 걸친 전체 백로그입니다. 각 분할에 대한 백로그가 제공되지 않고 모든 분할에 대해서만 계산할 수 있는 경우도 있습니다. 첫 번째 분할(분할 ID ‘0’)만 전체 백로그를 제공해야 합니다.
Apache Beam 저장소에는 UnboundedReader 클래스를 구현하는 여러 가지 커스텀 소스 가 있습니다.
스트리밍 자동 확장 사용

자동 확장을 사용하려면 파이프라인을 시작할 때 다음 실행 매개변수를 설정합니다.

--autoscalingAlgorithm=THROUGHPUT_BASED
--maxNumWorkers=<N>

자동 확장은 파이프라인을 실행하는 동안 작업자 수 N/15~N개 사이에서 변동될 수 있습니다. 여기서 N은 --maxNumWorkers의 값입니다. 예를 들어 파이프라인에 안정 상태인 작업자가 3개 또는 4개 필요한 경우 --maxNumWorkers=15를 설정할 수 있으며 파이프라인은 작업자 1~15개 사이에서 자동으로 확장됩니다.

스트리밍 파이프라인은 --maxNumWorkers와 같은 수로 영구 디스크의 고정 풀과 함께 배포됩니다. --maxNumWorkers를 지정할 때 이 점을 고려하여 이 값이 파이프라인에 충분한 디스크 수인지 확인합니다.

사용량 및 가격

Compute Engine 사용량은 평균 작업자 수를 기준으로 하며, 영구 디스크 사용량은 --maxNumWorkers의 정확한 수를 기준으로 합니다. 영구 디스크는 각 작업자에게 동일한 수의 연결된 디스크가 할당되도록 재분배됩니다.

위 예(--maxNumWorkers=15)에서는 Compute Engine 인스턴스 1~15개 사이 및 영구 디스크 15개에 대한 요금이 청구됩니다.

Python

이 기능은 아직 Python용 Apache Beam SDK에서 지원되지 않습니다.

자바: SDK 1.x

스트리밍 자동 확장을 사용하면 Cloud Dataflow 서비스에서 로드 및 리소스 사용률의 변화에 따라 스트리밍 파이프라인을 실행하는 데 사용되는 작업자 수를 상황에 맞게 변경할 수 있습니다. 스트리밍 자동 확장은 무료 기능이며 스트리밍 파이프라인을 실행할 때 사용되는 리소스의 비용을 절감하도록 설계되었습니다.

자동 확장을 사용하지 않는 경우 --numWorkers를 지정하여 파이프라인을 실행하는 고정된 작업자 수를 선택하게 됩니다. 시간에 따라 입력 작업 부하가 달라지므로 이 숫자는 너무 높거나 낮아질 수 있습니다. 너무 많은 작업자를 프로비저닝하면 불필요한 추가 비용이 발생하고, 너무 적은 작업자를 프로비저닝하면 데이터 처리 지연 시간이 길어집니다. 자동 확장을 사용하면 필요한 경우에만 리소스가 사용됩니다.

자동 확장은 작업자의 바쁨 정도와 이러한 작업자가 입력 스트림을 처리할 수 있는지 여부를 평가하는 몇 가지 신호를 사용하여 확장 결정을 내립니다. 주요 신호에는 CPU 사용률, 처리량, 백로그가 있습니다. 목표는 작업자 사용률 및 처리량을 최대화하면서 백로그를 최소화하고 부하 급증에 빠르게 대처하는 것입니다. 자동 확장을 사용하면 최대 부하에 대비한 프로비저닝과 최신 결과 중 무엇을 선택할지 고민할 필요가 없습니다. CPU 사용률 및 백로그가 증가하면 작업자가 추가되고, 감소하면 작업자가 제거됩니다. 따라서 필요한 항목에만 비용을 지불하면 되며 작업이 최대한 효율적으로 처리됩니다.

파이프라인에서 제한되지 않은 커스텀 소스를 사용하는 경우 이 소스가 Cloud Dataflow 서비스에 백로그에 대해 알려야 합니다. 백로그는 아직 소스에서 처리하지 않은 입력 추정치입니다(단위: 바이트). 서비스에 백로그 정보를 제공하려면 UnboundedReader 클래스에서 다음 메소드 두 개 중 하나를 구현합니다.

  • getSplitBacklogBytes() - 현재 소스 분할에 대한 백로그입니다. 서비스는 모든 분할에 걸쳐 백로그를 집계합니다.
  • getTotalBacklogBytes() - 모든 분할에 걸친 전체 백로그입니다. 각 분할에 대한 백로그가 제공되지 않고 모든 분할에 대해서만 계산할 수 있는 경우도 있습니다. 첫 번째 분할(분할 ID ‘0’)만 전체 백로그를 제공해야 합니다.
스트리밍 자동 확장 사용

자동 확장을 사용하려면 파이프라인을 시작할 때 다음 실행 매개변수를 설정합니다.

--autoscalingAlgorithm=THROUGHPUT_BASED
--maxNumWorkers=<N>

자동 확장은 파이프라인을 실행하는 동안 작업자 수 N/15~N개 사이에서 변동될 수 있습니다. 여기서 N은 --maxNumWorkers의 값입니다. 예를 들어 파이프라인에 안정 상태인 작업자가 3개 또는 4개 필요한 경우 --maxNumWorkers=15를 설정할 수 있으며 파이프라인은 작업자 1~15개 사이에서 자동으로 확장됩니다.

스트리밍 파이프라인은 --maxNumWorkers와 같은 수로 영구 디스크의 고정 풀과 함께 배포됩니다. --maxNumWorkers를 지정할 때 이 점을 고려하여 이 값이 파이프라인에 충분한 디스크 수인지 확인합니다.

현재 PubsubIO은 스트리밍 파이프라인에서 자동 확장을 지원하는 유일한 소스입니다. 모든 SDK 제공 싱크가 지원됩니다. 이 베타 출시 버전에서는 소규모 배치(batch)로 게시된 주제에 연결된 Cloud Pub/Sub 구독에서 읽어오는 경우와 지연 시간이 낮은 싱크에 쓰는 경우에 자동 확장이 가장 원활하게 작동합니다. 극단적인 경우(예: 대규모 게시 배치가 있는 Cloud Pub/Sub 구독 또는 지연 시간이 매우 긴 싱크)에는 자동 확장이 그다지 세밀하지 않은 것으로 알려져 있습니다. 이 점은 향후 출시 버전에서 개선될 예정입니다.

사용량 및 가격

Compute Engine 사용량은 평균 작업자 수를 기준으로 하며, 영구 디스크 사용량은 --maxNumWorkers의 정확한 수를 기준으로 합니다. 영구 디스크는 각 작업자에게 동일한 수의 연결된 디스크가 할당되도록 재분배됩니다.

위 예(--maxNumWorkers=15)에서는 Compute Engine 인스턴스 1~15개 사이 및 영구 디스크 15개에 대한 요금이 청구됩니다.

스트리밍 파이프라인 수동 확장

자바: SDK 2.x

스트리밍 모드에서 자동 확장을 일반적으로 사용할 수 있을 때까지는 Cloud Dataflow의 업데이트 기능을 사용하여 스트리밍 파이프라인을 실행 중인 작업자 수를 수동으로 확장하는 해결 방법을 사용할 수 있습니다.

실행 중에 스트리밍 파이프라인을 확장해야 하는 경우 파이프라인을 시작할 때 다음 실행 매개변수를 설정했는지 확인합니다.

  • --maxNumWorkers를 파이프라인에 제공할 최대 작업자 수와 동일하게 설정합니다.
  • 파이프라인을 실행할 때 --numWorkers를 사용할 파이프라인의 작업자 초기 수와 동일하게 설정합니다.

파이프라인이 실행되면 파이프라인을 업데이트하고 --numWorkers 매개변수를 사용하여 새 작업자 수를 지정할 수 있습니다. 새 --numWorkers에 설정한 값은 N--maxNumWorkers 사이여야 합니다. 여기서 N--maxNumWorkers/15와 같습니다.

업데이트하면 실행 중인 작업이 새 작업으로 바뀝니다. 이 때 새 작업자 수가 사용되지만 이전 작업과 연관된 모든 상태 정보는 유지됩니다.

Python

이 기능은 아직 Python용 Apache Beam SDK에서 지원되지 않습니다.

자바: SDK 1.x

스트리밍 모드에서 자동 확장을 일반적으로 사용할 수 있을 때까지는 Cloud Dataflow의 업데이트 기능을 사용하여 스트리밍 파이프라인을 실행 중인 작업자 수를 수동으로 확장하는 해결 방법을 사용할 수 있습니다.

실행 중에 스트리밍 파이프라인을 확장해야 하는 경우 파이프라인을 시작할 때 다음 실행 매개변수를 설정했는지 확인합니다.

  • --maxNumWorkers를 파이프라인에 제공할 최대 작업자 수와 동일하게 설정합니다.
  • 파이프라인을 실행할 때 --numWorkers를 사용할 파이프라인의 작업자 초기 수와 동일하게 설정합니다.

파이프라인이 실행되면 파이프라인을 업데이트하고 --numWorkers 매개변수를 사용하여 새 작업자 수를 지정할 수 있습니다. 새 --numWorkers에 설정한 값은 N--maxNumWorkers 사이여야 합니다. 여기서 N--maxNumWorkers/15와 같습니다.

업데이트하면 실행 중인 작업이 새 작업으로 바뀝니다. 이 때 새 작업자 수가 사용되지만 이전 작업과 연관된 모든 상태 정보는 유지됩니다.

동적 작업 재균등화

Cloud Dataflow 서비스의 동적 작업 재균등화 기능을 사용하면 서비스가 런타임 조건에 따라 작업의 파티션을 동적으로 다시 나눌 수 있습니다. 이러한 조건에는 다음이 포함될 수 있습니다.

  • 작업 할당의 불균형
  • 작업자의 완료 시간이 예상보다 오래 걸림
  • 작업자가 예상보다 빨리 완료

Cloud Dataflow 서비스는 이러한 조건을 자동으로 감지하고 사용되지 않았거나 사용률이 낮은 작업자에 작업을 동적으로 다시 할당하여 작업의 전체 처리 시간을 줄일 수 있습니다.

제한사항

동적 작업 재균등화는 Cloud Dataflow 서비스가 병렬로 입력 데이터 일부를 처리 중인 경우에만 발생합니다. 즉, 외부 입력 소스에서 데이터를 읽는 경우, 구체화된 중간 PCollection으로 작업하는 경우, GroupByKey와 같은 집계의 결과에 대해 작업하는 경우에만 발생합니다. 작업의 많은 단계가 융합되면 작업의 중간 PCollection이 줄어들고 동적 작업 재균등화는 소스의 구체화된 PCollection의 요소 수로 제한됩니다. 동적 작업 재균등화를 파이프라인의 특정 PCollection에 적용할 수 있도록 하려면 몇 가지 동적 동시 처리 방법으로 융합을 방지하면 됩니다.

동적 작업 재균등화는 데이터를 단일 레코드보다 더 미세하게 다시 병렬 처리할 수 없습니다. 데이터에 처리 시간을 상당히 지연시키는 개별 레코드가 포함되어 있는 경우 Cloud Dataflow는 개별 '핫' 레코드를 더 작게 나누어 여러 작업자에게 다시 분산할 수 없기 때문에 작업이 지연될 수 있습니다.

자바: SDK 2.x

파이프라인의 최종 출력에 고정된 수의 샤드를 설정(예: TextIO.Write.withNumShards를 사용하여 데이터 작성)한 경우 선택한 샤드 수에 따라 병렬 처리가 제한됩니다.

Python

파이프라인의 최종 출력에 샤딩을 고정된 수로 설정한 경우(예: beam.io.WriteToText(..., num_shards=...)를 사용하여 데이터 작성) Cloud Dataflow는 선택한 샤딩 수에 따라 동시 처리를 제한합니다.

자바: SDK 1.x

파이프라인의 최종 출력에 고정된 수의 샤드를 설정(예: TextIO.Write.withNumShards를 사용하여 데이터 작성)한 경우 선택한 샤드 수에 따라 병렬 처리가 제한됩니다.

고정 샤드 제한은 일시적인 것으로 간주될 수 있으며 Cloud Dataflow 서비스의 향후 출시 버전에서는 변경될 수 있습니다.

커스텀 데이터 소스 작업

자바: SDK 2.x

파이프라인에서 사용자가 제공하는 커스텀 데이터 소스를 사용하는 경우 splitAtFraction 메소드를 구현하여 소스가 동적 작업 재균등화 기능으로 작업할 수 있도록 해야 합니다.

Python

파이프라인에서 사용자가 제공하는 커스텀 데이터 소스를 사용하는 경우 RangeTrackertry_claim, try_split, position_at_fraction, fraction_consumed를 구현하여 소스가 동적 작업 재균등화 기능으로 작업할 수 있도록 해야 합니다.

자세한 내용은 RangeTracker에 대한 API 참조 정보를 참조하세요.

자바: SDK 1.x

파이프라인에서 사용자가 제공한 커스텀 데이터 소스를 사용하는 경우 소스가 동적 작업 재균등화 기능을 사용하여 작업할 수 있도록 하려면 splitAtFraction 메소드를 구현해야 합니다.

리소스 사용 및 관리

Cloud Dataflow 서비스는 작업별로 GCP의 리소스를 완벽하게 관리합니다. 여기에는 Compute Engine 인스턴스(작업자 또는 VM이라고도 함) 가동과 종료, 프로젝트의 Cloud Storage 버킷에 액세스하여 I/O 및 임시 파일 스테이징 등이 포함됩니다. 하지만 파이프라인이 BigQueryCloud Pub/Sub와 같은 GCP 데이터 스토리지 기술과 상호작용하는 경우에는 이러한 서비스의 리소스와 할당량을 관리해야 합니다.

Cloud Dataflow는 특히 파일 스테이징을 위해 Cloud Storage 내에서 사용자가 제공한 위치를 사용합니다. 이 위치는 사용자가 제어할 수 있으므로 이 위치에서 읽는 작업이 있으면 위치의 수명 주기가 유지되도록 해야 합니다. SDK에서 기본 제공되는 캐싱은 작업 시작 시간을 단축할 수 있으므로 동일한 스테이징 위치를 여러 작업 실행에 재사용할 수 있습니다.

작업

GCP 프로젝트별로 Cloud Dataflow 작업을 최대 25개까지 동시에 실행할 수 있습니다.

현재 Cloud Dataflow 서비스는 크기가 20MB 이하인 JSON 작업 요청만 처리하도록 제한되어 있습니다. 작업 요청 크기는 특히 파이프라인의 JSON 표현과 관련되어 있습니다. 파이프라인이 클수록 요청이 커집니다.

파이프라인의 JSON 요청 크기를 예측하려면 다음 옵션을 사용하여 파이프라인을 실행합니다.

자바: SDK 2.x

--dataflowJobFile=< path to output file >

Python

--dataflow_job_file=< path to output file >

자바: SDK 1.x

--dataflowJobFile=< path to output file >

이 명령어는 작업의 JSON 표현을 파일에 작성합니다. 직렬화된 파일 크기는 요청 크기의 예상치에 가깝습니다. 실제 크기는 요청에 포함된 추가 정보로 인해 약간 더 커집니다.

자세한 내용은 '413 요청 개체가 너무 큼'/'파이프라인의 직렬화된 JSON 표현 크기가 허용 한도를 초과함' 문제해결 페이지를 참조하세요.

또한 작업의 그래프 크기가 10MB를 초과해서는 안 됩니다. 자세한 내용은 '작업 그래프가 너무 큽니다. 더 작은 작업 그래프로 다시 시도하거나, 작업을 더 작은 작업 두 개 이상으로 분할하세요.' 문제해결 페이지를 참조하세요.

작업자

Cloud Dataflow 서비스는 현재 작업당 Compute Engine 인스턴스 최대 1000개를 허용합니다. 일괄 작업의 기본 머신 유형은 n1-standard-1이고 스트리밍의 경우에는 n1-standard-4입니다. 따라서 기본 머신 유형을 사용하면 Cloud Dataflow 서비스는 코어를 작업당 최대 4000개까지 할당할 수 있습니다.

Cloud Dataflow는 n1 시리즈 작업자와 커스텀 머신 유형을 지원합니다. 파이프라인을 만들 때 적합한 실행 매개변수를 설정하여 파이프라인의 머신 유형을 지정할 수 있습니다.

자바: SDK 2.x

머신 유형을 변경하려면 --workerMachineType 옵션을 설정합니다.

Python

머신 유형을 변경하려면 --worker_machine_type 옵션을 설정합니다.

자바: SDK 1.x

머신 유형을 변경하려면 --workerMachineType 옵션을 설정합니다.

리소스 할당량

Cloud Dataflow 서비스는 작업을 실행하여 작업을 시작하고 최대 작업자 인스턴스 수로 확장하는 데 필요한 Compute Engine 리소스 할당량이 GCP 프로젝트에 있는지 확인합니다. 사용 가능한 리소스 할당량이 충분하지 않으면 작업을 시작할 수 없습니다.

Cloud Dataflow의 자동 확장 기능은 프로젝트의 가용 Compute Engine 할당량에 따라 제한됩니다. 작업 시작 시 할당량이 충분하지만 다른 작업이 프로젝트의 가용 할당량 중 나머지를 사용하면 첫 번째 작업은 실행되지만 완전히 확장될 수 없습니다.

하지만 Cloud Dataflow 서비스는 프로젝트의 리소스 할당량을 초과하는 작업의 할당량 증가를 관리하지 않습니다. 사용자는 추가 리소스 할당량을 위해 필요한 모든 요청을 수행해야 하며 이를 위해 Google Cloud Platform Console을 사용할 수 있습니다.

영구 디스크 리소스

Cloud Dataflow 서비스는 현재 스트리밍 작업 실행 시 작업자 인스턴스당 영구 디스크를 15개로 제한됩니다. 각 영구 디스크는 개별 Compute Engine 가상 머신에 대해 로컬입니다. 작업에 영구 디스크보다 많은 작업자가 있을 수 없습니다. 작업자와 디스크 간 1:1 비율이 최소 리소스 할당입니다.

각 영구 디스크의 기본 크기는 일괄 모드에서 250GB이고 스트리밍 모드에서 400GB입니다.

위치

기본적으로 Cloud Dataflow 서비스는 us-central1 지역의 us-central1-f 영역에 Compute Engine 리소스를 배포합니다. --region 매개변수를 지정하여 이 설정을 재정의할 수 있습니다. 리소스에 특정 영역을 사용해야 하는 경우 파이프라인을 만들 때 --zone 매개변수를 사용합니다. 하지만 지역만 지정하고 영역은 지정하지 않는 것이 좋습니다. 이렇게 하면 Cloud Dataflow 서비스가 작업 생성 요청 시 사용 가능한 영역 용량을 기준으로 지역 내에서 가장 적합한 영역을 자동으로 선택합니다. 자세한 내용은 지역 엔드포인트 문서를 참조하세요.

스트리밍 엔진

현재 Cloud Dataflow 파이프라인 실행기는 작업자 가상 머신에서 스트리밍 파이프라인 단계 전체를 실행하고 작업자 CPU, 메모리, Persistent Disk 스토리지를 사용합니다. Cloud Dataflow의 스트리밍 엔진은 작업자 VM에서 Cloud Dataflow 서비스 백엔드로 파이프라인 실행을 이동합니다.

스트리밍 엔진의 이점

스트리밍 엔진 모델에는 다음과 같은 이점이 있습니다.

  • 작업자 VM에서 사용되는 CPU, 메모리, Persistent Disk 스토리지 리소스가 감소합니다. 스트리밍 엔진은 더 작은 작업자 머신 유형(n1-standard-4 대신 n1-standard-2)에서 가장 잘 작동하며 작은 작업자 부팅 디스크에서의 요구 이상의 Persistent Disk를 필요로 하지 않으므로 리소스와 할당량을 적게 사용합니다.
  • 수신 데이터 볼륨 변화에 대응하여 응답성이 높은 자동 확장을 수행합니다. 스트리밍 엔진은 더욱 원활하고 세분화된 작업자 확장을 제공합니다.
  • 파이프라인을 다시 배포하여 서비스 업데이트를 적용할 필요가 없으므로 지원 가능성이 향상됩니다.

대부분의 작업자 리소스 감소는 작업 부하를 Cloud Dataflow 서비스로 이전하면 발생합니다. 이러한 이유로 스트리밍 엔진을 사용하면 관련 요금이 청구됩니다. 하지만 스트리밍 엔진을 사용하는 Cloud Dataflow 파이프라인의 총 청구액은 이 옵션을 사용하지 않는 Cloud Dataflow 파이프라인의 총 비용과 거의 동일할 수 있습니다.

스트리밍 엔진 사용

현재 스트리밍 엔진을 다음 리전의 스트리밍 파이프라인에 사용할 수 있습니다. 향후 다른 리전에서도 사용할 수 있습니다.

  • us-central1(아이오와)
  • europe-west1(벨기에)
  • europe-west4(네덜란드)
  • asia-northeast1(도쿄)

자바: SDK 2.x

스트리밍 파이프라인에 스트리밍 엔진을 사용하려면 다음 매개변수를 지정합니다.

  • --enableStreamingEngine - 자바용 Apache Beam SDK 버전 2.11.0 이상을 사용하는 경우
  • --experiments=enable_streaming_engine - 자바용 Apache Beam SDK 버전 2.10.0을 사용하는 경우

파이프라인에 Cloud Dataflow 스트리밍 엔진을 사용하는 경우에는 --zone 매개변수를 지정하지 마세요. 대신 --region 매개변수를 지정하고 값을 현재 스트리밍 엔진을 사용할 수 있는 리전 중 하나로 설정합니다. 그러면 Cloud Dataflow가 지정된 리전의 영역을 자동으로 선택합니다. --zone 매개변수를 지정하고 사용 가능한 리전 외부의 영역으로 설정하면 Cloud Dataflow에서 오류가 보고됩니다.

스트리밍 엔진은 작은 작업자 머신 유형에서 가장 잘 작동하므로 --workerMachineType=n1-standard-2로 설정하는 것이 좋습니다. 또한 스트리밍 엔진에 작업자 부팅 이미지와 로컬 로그용 공간만 있으면 되므로 --diskSizeGb=30으로 설정하면 됩니다. 명시적으로 값을 설정하지 않으면 이러한 값이 기본값입니다.

Python

이 기능은 아직 Python용 Apache Beam SDK에서 지원되지 않습니다.

자바: SDK 1.x

스트리밍 엔진은 자바용 Cloud Dataflow SDK 버전 1.x에서 지원되지 않습니다. 이 기능을 사용하려면 자바용 Apache Beam SDK 2.8.0 이상을 사용해야 합니다.

Cloud Dataflow Shuffle

Cloud Dataflow Shuffle은 GroupByKey, CoGroupByKey, Combine과 같은 Cloud Dataflow 변환의 기반이 되는 작업입니다. Cloud Dataflow Shuffle 작업은 확장 가능하고 효율적이며 내결함성이 있는 방식으로 키를 사용하여 데이터를 분할 및 그룹화합니다. 현재 Cloud Dataflow는 작업자 가상 머신에서 전적으로 실행되고 작업자 CPU, 메모리, Persistent Disk 스토리지를 사용하는 셔플 구현을 사용합니다. 일괄 처리 파이프라인에만 사용할 수 있는 서비스 기반 Cloud Dataflow Shuffle 기능은 셔플 작업을 작업자 VM에서 Cloud Dataflow 서비스 백엔드로 이동시킵니다.

Cloud Dataflow Shuffle의 이점

서비스 기반 Cloud Dataflow Shuffle에는 다음과 같은 이점이 있습니다.

  • 대부분의 파이프라인 작업 유형에 대한 일괄 파이프라인의 실행 시간 단축
  • 작업자 VM에서 소비되는 CPU, 메모리, 영구 디스크 저장소 리소스 감소
  • 더 나은 자동 확장 수행: VM이 더 이상 셔플 데이터를 보유하지 않기 때문에 더 일찍 축소할 수 있습니다.
  • 내결함성 향상: Cloud Dataflow Shuffle 데이터를 보유하는 비정상 VM이 있어도 전체 작업이 실패하지 않습니다. 하지만 이 기능을 사용하지 않으면 작업이 실패할 수 있습니다.

대부분의 작업자 리소스 감소는 셔플 작업 부하를 Cloud Dataflow 서비스로 이전하면 발생합니다. 이러한 이유로 Cloud Dataflow Shuffle 사용과 관련된 요금이 청구됩니다. 하지만 서비스 기반 Cloud Dataflow 구현을 사용하는 Cloud Dataflow 파이프라인의 총 청구액은 이 옵션을 사용하지 않는 Cloud Dataflow 파이프라인 비용 보다 작거나 같을 수 있습니다.

대부분의 파이프라인 작업 유형에서 Cloud Dataflow Shuffle은 작업자 VM에서 실행되는 셔플 구현보다 빠르게 실행됩니다. 하지만 실행 시간은 실행할 때마다 다를 수 있습니다. 중요한 기한이 있는 파이프라인을 실행하는 경우, 기한 전에 충분한 여유 시간을 할당하는 것이 좋습니다. 또한 Shuffle에 대한 할당량을 더 많이 요청하는 것을 고려해 보세요.

디스크 고려 사항

서비스 기반 Cloud Dataflow Shuffle 기능을 사용할 때 작업자 VM에 대용량 Persistent Disk를 연결할 필요가 없습니다. Cloud Dataflow는 작은 25GB 부팅 디스크를 자동으로 연결합니다. 하지만 이 작은 디스크 크기로 인해 Cloud Dataflow Shuffle을 사용할 때 주의해야 할 중요한 고려 사항이 있습니다.

  • 작업자 VM은 운영체제, 바이너리, 로그, 컨테이너에 필요한 디스크 공간(25GB)의 일부를 사용합니다. Cloud Dataflow Shuffle을 사용하는 경우 상당한 양의 디스크를 사용하여 잔여 디스크 용량을 초과하는 작업은 실패할 수 있습니다.
  • 작은 디스크의 성능으로 인해 많은 디스크 I/O를 사용하는 작업은 느려질 수 있습니다. 각 디스크 크기 간 성능 차이에 대한 자세한 내용은 Compute Engine Persistent Disk 성능 페이지를 참조하세요.

이와 같은 고려 사항이 작업에 해당되면 파이프라인 옵션을 사용하여 더 큰 디스크 크기를 지정하면 됩니다.

Cloud Dataflow Shuffle 사용

현재 서비스 기반 Cloud Dataflow Shuffle을 다음 리전에서 사용할 수 있습니다.

  • us-central1(아이오와)
  • europe-west1(벨기에)
  • europe-west4(네덜란드)
  • asia-northeast1(도쿄)

향후에 다른 리전에서도 Cloud Dataflow Shuffle을 사용할 수 있습니다.

자바: SDK 2.x

일괄 처리 파이프라인에서 서비스 기반 Cloud Dataflow Shuffle을 사용하려면 다음 매개변수를 지정합니다.
--experiments=shuffle_mode=service

파이프라인에 Cloud Dataflow Shuffle을 사용하는 경우에는 --zone 매개변수를 지정하지 마세요. 대신 --region 매개변수를 지정하고 값을 현재 Shuffle을 사용할 수 있는 리전 중 하나로 설정합니다. 그러면 Cloud Dataflow가 지정된 리전의 영역을 자동 선택합니다. --zone 매개변수를 지정하고 사용 가능한 리전 외부의 영역으로 설정하면 Cloud Dataflow에서 오류가 보고됩니다.

Python

일괄 처리 파이프라인에서 서비스 기반 Cloud Dataflow Shuffle을 사용하려면 다음 매개변수를 지정합니다.
--experiments=shuffle_mode=service

파이프라인에 Cloud Dataflow Shuffle을 사용하는 경우에는 --zone 매개변수를 지정하지 마세요. 대신 --region 매개변수를 지정하고 값을 현재 Shuffle을 사용할 수 있는 리전 중 하나로 설정합니다. 그러면 Cloud Dataflow가 지정된 리전의 영역을 자동 선택합니다. --zone 매개변수를 지정하고 사용 가능한 리전 외부의 영역으로 설정하면 Cloud Dataflow에서 오류가 보고됩니다.

자바: SDK 1.x

일괄 처리 파이프라인에서 서비스 기반 Cloud Dataflow Shuffle을 사용하려면 다음 매개변수를 지정합니다.
--experiments=shuffle_mode=service

파이프라인에 Cloud Dataflow Shuffle을 사용하는 경우에는 --zone 매개변수를 지정하지 마세요. 대신 --region 매개변수를 지정하고 값을 현재 Shuffle을 사용할 수 있는 리전 중 하나로 설정합니다. 그러면 Cloud Dataflow가 지정된 리전의 영역을 자동 선택합니다. --zone 매개변수를 지정하고 사용 가능한 리전 외부의 영역으로 설정하면 Cloud Dataflow에서 오류가 보고됩니다.

Cloud Dataflow 가변형 리소스 예약

Cloud Dataflow FlexRS는 고급 예약 기술, Cloud Dataflow Shuffle 서비스, 선점형 가상 머신(VM) 인스턴스와 일반 VM의 조합을 사용하여 일괄 처리 비용을 줄입니다. 시스템 이벤트 발생 시 Compute Engine이 선점형 VM 인스턴스를 중지하면 Cloud Dataflow가 선점형 VM과 일반 VM을 동시에 실행하여 사용자 환경을 개선시킵니다. FlexRS를 사용하면 파이프라인이 계속해서 진행되고 Compute Engine에서 선점형 VM을 선점할 때 이전 작업이 손실되지 않습니다. FlexRS에 대한 자세한 내용은 Cloud Dataflow에서 가변형 리소스 예약 사용을 참조하세요.
이 페이지가 도움이 되었나요? 평가를 부탁드립니다.

다음에 대한 의견 보내기...

도움이 필요하시나요? 지원 페이지를 방문하세요.