commit | 277832ee9e5084e10434b22eb724042d999bea1c | [log] [tgz] |
---|---|---|
author | Saavan Nanavati <66381097+saavannanavati@users.noreply.github.com> | Thu Aug 06 11:45:33 2020 -0500 |
committer | GitHub <noreply@github.com> | Thu Aug 06 09:45:33 2020 -0700 |
tree | 3abb5e777da598265327b8af5ac02b8d48c99441 | |
parent | 18503a642950cf109c52f6026730571aa41aeb2f [diff] |
[BEAM-10258] Support type hint annotations on PTransform's expand() (#12009) * [BEAM-10258] Support type hint annotations on PTransform's expand() * Fixup: apply YAPF * Moving PCollectionTypeConstraint to typehints.py * Uses Generic[T] instead of PCollectionTypeConstraint * Fixup: apply YAPF * Remove unused imports * Force user to wrap typehints in PCollections * Add unit tests for various usages of typehints on PTransforms * Add tests that use typehints on real pipelines * Fixup: apply YAPF * Fix bad merge * Support PDone, PBegin, and better handling of error cases * Fix test syntax * Refactors strip_pcoll_input() and strip_pcoll_output() to a shared function * Add unit tests * Add more tests * Add website documentation * Fix linting issues * Fix linting issue by using multi-line function annotations * Fix more lint errors * Fix import order, and other changes for PR * Fix ungrouped-imports error * Alphabetically order the imports * Fixup: apply YAPF * Fixes a bug where a type can have an empty __args__ attribute * Fix bug in website snippet code * Fixup: apply YAPF * Fixup: apply YAPF * Fix NoneType error * Fix NoneType error part 2 * Use classes instead of strings during typecheck, and add tests * Resolve circular import error and fix readability issues * Fix lint errors * Add back accidentally removed test * Support None as an output annotation * Show incorrect type in error message Co-authored-by: Udi Meiri <udim@users.noreply.github.com> * Allow Pipeline as an input * Fix import bug * Alphabetically order imports inside function (but really this is just to force re-run the tests) * Display warning instead of throwing error for oddly formed type hints * Convert to Beam types * Add test for generic TypeVars * Fix bug by skipping DoOutputsTuple * Fix typo * Add test for DoOutputsTuple * Fix lint errors Co-authored-by: Udi Meiri <udim@users.noreply.github.com>
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.
Lang | SDK | Dataflow | Flink | Samza | Spark |
---|---|---|---|---|---|
Go | --- | --- | |||
Java | |||||
Python | --- | ||||
XLang | --- | --- |
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.
The model behind Beam evolved from a number of 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.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 JIRA.
Beam supports executing programs on multiple distributed processing backends through PipelineRunners. Currently, the following PipelineRunners are available:
DirectRunner
runs the pipeline on your local machine.DataflowRunner
submits the pipeline to the Google Cloud Dataflow.FlinkRunner
runs the pipeline on an Apache Flink cluster. The code has been donated from dataArtisans/flink-dataflow and is now part of Beam.SparkRunner
runs the pipeline on an Apache Spark cluster. The code has been donated from cloudera/spark-dataflow and is now part of Beam.JetRunner
runs the pipeline on a Hazelcast Jet cluster. The code has been donated from hazelcast/hazelcast-jet and is now part of Beam.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 JIRA.
To learn how to write Beam pipelines, read the Quickstart for [Java, Python, or Go] available on our website.
To get involved in Apache Beam:
Instructions for building and testing Beam itself are in the contribution guide.