Google Git
Sign in
apache / beam / eb8639b013e9d820a253970ed03ac0e7cfc6e13e
commiteb8639b013e9d820a253970ed03ac0e7cfc6e13e[log] [tgz]
authorShunping Huang <shunping@google.com>Wed Sep 18 13:14:57 2024 -0400
committerGitHub <noreply@github.com>Wed Sep 18 13:14:57 2024 -0400
tree9860639fe639610b94fd0a1b6ec68e65c95a6529
parent475c98c8779b7f332ce10d56df61ba7652aa3ab7 [diff]
Add throttling counter in gcsio and refactor retrying (#32428)

* Add retry instance that records throttling metric.

* Use retry with throttling counters by default. Add pipeline option.

* Fix lint

* Fix broken tests.

* Retrieve a more accurate throttling time from the caller frame.

* Apply yapf and linter

* Refactoring copy and delete

- Remove extra retries for copy, delete, _gcs_object.
- Remove the use of client.batch() as the function has no built-in
  retry.

* Fix a typo and apply yapf

* Use counter instead of counters in pipeline option.

Additionally, the variable name for the new retry object is changed.

Add a new pipeline option to enable the use of blob generation to
mitigate race conditions (at the expense of more http requests)

* Parameterize existing tests for the new pipeline options.

* Apply yapf

* Fix a typo.

* Revert the change of copy_batch and delete_batch and add warning in their docstring.

* Fix lint

* Minor change according to code review.

* Restore the previous tox.ini that got accidentally changed.
6 files changed
tree: 9860639fe639610b94fd0a1b6ec68e65c95a6529
  1. .github/
  2. .test-infra/
  3. buildSrc/
  4. contributor-docs/
  5. dev-support/
  6. examples/
  7. gradle/
  8. it/
  9. learning/
  10. model/
  11. playground/
  12. plugins/
  13. release/
  14. runners/
  15. scripts/
  16. sdks/
  17. vendor/
  18. website/
  19. .asf.yaml
  20. .gitattributes
  21. .gitignore
  22. .gitmodules
  23. .mailmap
  24. .pre-commit-config.yaml
  25. .yamllint.yml
  26. assembly.xml
  27. build.gradle.kts
  28. CHANGES.md
  29. CI.md
  30. CONTRIBUTING.md
  31. gradle.properties
  32. gradlew
  33. gradlew.bat
  34. LICENSE
  35. LICENSE.python
  36. local-env-setup.sh
  37. NOTICE
  38. README.md
  39. settings.gradle.kts
  40. start-build-env.sh
README.md

Apache Beam

Apache Beam is a unified model for defining both batch and streaming data-parallel processing pipelines, as well as a set of language-specific SDKs for constructing pipelines and Runners for executing them on distributed processing backends, including Apache Flink, Apache Spark, Google Cloud Dataflow, and Hazelcast Jet.

Status

Maven Version PyPI version Go version Python coverage Build python source distribution and wheels Python tests Java tests

Overview

Beam provides a general approach to expressing embarrassingly parallel data processing pipelines and supports three categories of users, each of which have relatively disparate backgrounds and needs.

  1. End Users: Writing pipelines with an existing SDK, running it on an existing runner. These users want to focus on writing their application logic and have everything else just work.
  2. SDK Writers: Developing a Beam SDK targeted at a specific user community (Java, Python, Scala, Go, R, graphical, etc). These users are language geeks and would prefer to be shielded from all the details of various runners and their implementations.
  3. Runner Writers: Have an execution environment for distributed processing and would like to support programs written against the Beam Model. Would prefer to be shielded from details of multiple SDKs.

The Beam Model

The model behind Beam evolved from several internal Google data processing projects, including MapReduce, FlumeJava, and Millwheel. This model was originally known as the “Dataflow Model”.

To learn more about the Beam Model (though still under the original name of Dataflow), see the World Beyond Batch: Streaming 101 and Streaming 102 posts on O’Reilly’s Radar site, and the VLDB 2015 paper.

The key concepts in the Beam programming model are:

  • PCollection: represents a collection of data, which could be bounded or unbounded in size.
  • PTransform: represents a computation that transforms input PCollections into output PCollections.
  • Pipeline: manages a directed acyclic graph of PTransforms and PCollections that is ready for execution.
  • PipelineRunner: specifies where and how the pipeline should execute.

SDKs

Beam supports multiple language-specific SDKs for writing pipelines against the Beam Model.

Currently, this repository contains SDKs for Java, Python and Go.

Have ideas for new SDKs or DSLs? See the sdk-ideas label.

Runners

Beam supports executing programs on multiple distributed processing backends through PipelineRunners. Currently, the following PipelineRunners are available:

  • The DirectRunner runs the pipeline on your local machine.
  • The DataflowRunner submits the pipeline to the Google Cloud Dataflow.
  • The FlinkRunner runs the pipeline on an Apache Flink cluster. The code has been donated from dataArtisans/flink-dataflow and is now part of Beam.
  • The SparkRunner runs the pipeline on an Apache Spark cluster.
  • The JetRunner runs the pipeline on a Hazelcast Jet cluster. The code has been donated from hazelcast/hazelcast-jet and is now part of Beam.
  • The Twister2Runner runs the pipeline on a Twister2 cluster. The code has been donated from DSC-SPIDAL/twister2 and is now part of Beam.

Have ideas for new Runners? See the runner-ideas label.

Instructions for building and testing Beam itself are in the contribution guide.

📚 Learn More

Here are some resources actively maintained by the Beam community to help you get started:

Contact Us

To get involved with Apache Beam: