Use the Dataflow Portable Runner

When you use Dataflow to run your pipeline, the Dataflow runner uploads your pipeline code and dependencies to a Cloud Storage bucket and creates a Dataflow job. This Dataflow job runs your pipeline on managed resources in Google Cloud.

  • For batch pipelines that use the Apache Beam Java SDK versions 2.54.0 or later, the Portable Runner is enabled by default.
  • For pipelines that use the Apache Beam Java SDK, the Portable Runner is required when running multi-language pipelines, using custom containers, or using Spanner or Bigtable change stream pipelines. For high-scale Java streaming pipelines, use the Streaming Java (default) Runner.
  • For pipelines that use the Apache Beam Python SDK versions 2.21.0 or later, the Portable Runner is enabled by default. For pipelines that use the Apache Beam Python SDK versions 2.45.0 and later, the Dataflow Portable Runner is the only Dataflow runner available.
  • For the Apache Beam SDK for Go, the Portable Runner is the only Dataflow runner available.

The Portable Runner uses a services-based architecture that benefits many pipelines:

Limitations and restrictions

The Dataflow Portable Runner has the following requirements and limitations:

  • Portable-only features: The following features are only supported on the Portable Runner:
    • Managed transforms and RunInference in Java.
    • Custom containers.
    • ARM-based worker VMs.
    • Splittable DoFns. Support for the Non-Portable runner is being explored.
  • The Dataflow Portable Runner requires Streaming Engine for streaming jobs.
  • Because the Dataflow Portable Runner requires Streaming Engine for streaming jobs, any Apache Beam transform that requires the Dataflow Portable Runner also requires the use of Streaming Engine for streaming jobs. For example, the Pub/Sub Lite I/O connector for the Apache Beam SDK for Python is a cross-language transform that requires the Dataflow Portable Runner. If you try to disable Streaming Engine for a job or template that uses this transform, the job fails.
  • For streaming pipelines that use the Apache Beam Java SDK, the classes MapState and SetState are not supported with the Portable Runner. To use the MapState and SetState classes with Java pipelines, enable Streaming Engine, disable the Portable Runner, and use the Apache Beam SDK version 2.58.0 or later.
  • For batch and streaming pipelines that use the Apache Beam Java SDK, the class AfterSynchronizedProcessingTime isn't supported.
  • While the Portable Runner scales better than the Non-Portable runner in many cases, the memory usage might be higher for fixed sharding.
  • Dataflow classic templates can't be run with a different version of the Dataflow runner than they were built with. This means that Google-provided classic templates can't enable the Portable Runner. To enable the Portable Runner for custom templates, set the appropriate flag when you build the template. This flag depends on the SDK version you're using:
    • Beam SDK versions 2.74 and later: --experiments=enable_portable_runner.
    • Beam SDK versions 2.73 and earlier: --experiments=use_runner_v2.

  • Due to a known autoscaling issue, the Portable Runner is disabled by default for batch Java pipelines that require stateful processing. You can still enable the Portable Runner for those pipelines (see Enable the Portable Runner), but pipeline performance might be severely bottlenecked.

  • In some pipelines, the Portable Runner can increase the frequency of consistency failures. You might see the following error in the log files: "Internal consistency check failed, the output is likely incorrect. Please retry the job". A possible mitigation is to add a Reshuffle transform after the Join/GrouByKey step. If the failure rate is not tolerable and the mitigation does not solve the issue, try disabling the Portable Runner.

Enable the Portable Runner

To enable the Dataflow Portable Runner, follow the configuration instructions for your Apache Beam SDK.

Java

The Dataflow Portable Runner requires the Apache Beam Java SDK versions 2.30.0 or later, with version 2.44.0 or later being recommended.

For batch pipelines that use the Apache Beam Java SDK versions 2.54.0 or later, the Portable Runner is enabled by default.

To enable the Portable Runner, run your job with the experiment value that corresponds with your Beam SDK version and pipeline type:

  • Beam SDK versions 2.74 and later: enable_portable_runner (batch) or enable_streaming_java_runner (streaming).
  • Beam SDK versions 2.73 and earlier: use_runner_v2.

For more information, see Set experimental pipeline options.

Python

For pipelines that use the Apache Beam Python SDK versions 2.21.0 or later, the Portable Runner is enabled by default.

The Dataflow Portable Runner isn't supported with the Apache Beam Python SDK versions 2.20.0 and earlier.

In some cases, your pipeline might not use the Portable Runner even though the pipeline runs on a supported SDK version. To run the job with the Portable Runner, set the experiment value that corresponds with your Beam SDK version:

  • Beam SDK versions 2.74 and later: enable_portable_runner.
  • Beam SDK versions 2.73 and earlier: use_runner_v2.

For more information, see Set experimental pipeline options.

Go

The Dataflow Portable Runner is the only Dataflow runner available for the Apache Beam SDK for Go. The Portable Runner is enabled by default.

Disable the Portable Runner

To disable the Dataflow Portable Runner, follow the configuration instructions for your Apache Beam SDK.

Java

To disable the Portable Runner, set the experiment value that corresponds with your Beam SDK version:

  • Beam SDK versions 2.74 and later: disable_portable_runner.
  • Beam SDK versions 2.73 and earlier: disable_runner_v2.

This will default the job to the Non-Portable Runner (Streaming Java Runner for streaming). For more information, see Set experimental pipeline options.

Python

Disabling the Portable Runner is not supported with the Apache Beam Python SDK versions 2.45.0 and later.

For earlier versions of the Python SDK, if your job is identified as using the auto_runner_v2 experiment, you can disable the Portable Runner by setting the disable_runner_v2 experiment. For more information, see Set experimental pipeline options.

Go

The Dataflow Portable Runner can't be disabled in Go. The Portable Runner is the only Dataflow runner available for the Apache Beam SDK for Go.

Monitor your job

Use the monitoring interface to view Dataflow job metrics, such as memory utilization, CPU utilization, and more.

Worker VM logs are available through the Logs Explorer and the Dataflow monitoring interface. Worker VM logs include logs from the runner harness process and logs from the SDK processes. You can use the VM logs to troubleshoot your job.

Troubleshoot the Portable Runner

To troubleshoot jobs using the Dataflow Portable Runner, follow standard pipeline troubleshooting steps. The following list provides additional information about how the Dataflow Portable Runner works:

  • Jobs that use the Dataflow Portable Runner run two types of processes on the worker VM: SDK process and the runner harness process. Depending on the pipeline and VM type, there might be one or more SDK processes, but there is only one runner harness process per VM.
  • SDK processes run user code and other language-specific functions. The runner harness process manages everything else.
  • The runner harness process waits for all SDK processes to connect to it before starting to request work from Dataflow.
  • Jobs might be delayed if the worker VM downloads and installs dependencies during the SDK process startup. If issues occur during an SDK process, such as when starting up or installing libraries, the worker reports its status as unhealthy. If the startup times increase, enable the Cloud Build API on your project and submit your pipeline with the following parameter: --prebuild_sdk_container_engine=cloud_build.
  • Because Dataflow Portable Runner uses checkpointing, each worker might wait for up to five seconds while buffering changes before sending the changes for further processing. As a result, latency of approximately six seconds is expected.
  • To diagnose problems in your user code, examine the worker logs from the SDK processes. If you find any errors in the runner harness logs, contact Support to file a bug.
  • To debug common errors related to Dataflow multi-language pipelines, see the Multi-language Pipelines Tips guide.