Google Git
Sign in
apache / beam / 947cbb79fe4dfe4e2bc384da488043b509ffbe71
commit947cbb79fe4dfe4e2bc384da488043b509ffbe71[log] [tgz]
authorBenWhitehead <BenWhitehead@users.noreply.github.com>Wed Jul 14 00:10:10 2021 -0400
committerGitHub <noreply@github.com>Tue Jul 13 21:10:10 2021 -0700
tree54d1d5baf2005752098aa86356e9a21f2b0ecb87
parente542d1fd7deb20faf2232a33426b18df1f554890 [diff]
[BEAM-8376] Google Cloud Firestore Connector - Add Firestore v1 Read Operations (#15005)

* [BEAM-8376] Google Cloud Firestore Connector - Add Firestore v1 Read Operations

Entry point for accessing Firestore V1 read methods is `FirestoreIO.v1().read()`.

Currently supported read RPC methods:
* `PartitionQuery`
* `RunQuery`
* `ListCollectionIds`
* `ListDocuments`
* `BatchGetDocuments`

### Unit Tests

No external dependencies are needed for this suite

A large suite of unit tests have been added to cover most branches and error
scenarios in the various components. Test for input validation and bounds
checking are also included in this suite.

### Integration Tests

Integration tests for each type of RPC is present in
`org.apache.beam.sdk.io.gcp.firestore.it.FirestoreV1IT`. All of these tests
leverage `TestPipeline` and verify the expected Documents/Collections are all
operated on during the test.

* fix failing nullability check for cursor comparator

* fix @Nullable imports

* fix typo

* throw exception upon failing to determine restart point for batch get

* add unit test for org.apache.beam.sdk.io.gcp.firestore.FirestoreV1.PartitionQuery.PartitionQueryResponseToRunQueryRequest.processElement

* javadoc typo fixes from review

* Explicitly set Client built in retry to max 1 attempt since we're taking care of all retry logic at a higher level

* Clean up names of DoFn base classes to make them more accurate

* rename FirestoreV1Fn -> FirestoreV1RpcAttemptContexts

* restructure javadocs a big to keep context close to code samples

* decouple partition query from run query

it can be advantageous to allow a customer to perform some post processing of a query before executing it. By decoupling PartitionQuery from directly outputting to RunQuery this is easily possible.

* Add todo to jira issues for query integration improvements

* spotless

* fix incorrect nullable annotation
21 files changed
tree: 54d1d5baf2005752098aa86356e9a21f2b0ecb87
  1. .github/
  2. .test-infra/
  3. buildSrc/
  4. dev-support/
  5. examples/
  6. gradle/
  7. learning/
  8. model/
  9. ownership/
  10. release/
  11. runners/
  12. scripts/
  13. sdks/
  14. vendor/
  15. website/
  16. .asf.yaml
  17. .gitattributes
  18. .gitignore
  19. .gitmodules
  20. .mailmap
  21. .pre-commit-config.yaml
  22. .yamllint.yml
  23. assembly.xml
  24. build.gradle.kts
  25. CHANGES.md
  26. CI.md
  27. gradle.properties
  28. gradlew
  29. gradlew.bat
  30. LICENSE
  31. local-env-setup.sh
  32. NOTICE
  33. OWNERS
  34. README.md
  35. settings.gradle.kts
  36. 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 Python coverage Compat Check PyPI Compat Check at master Build python source distribution and wheels Python tests Java tests

Post-commit tests status (on master branch)

LangSDKDataflowFlinkSamzaSparkTwister2
GoBuild Status---Build StatusBuild StatusBuild Status---
JavaBuild StatusBuild Status
Build Status
Build Status		Build Status
Build Status
Build Status
Build Status		Build Status
Build Status		Build Status
Build Status
Build Status		Build Status
PythonBuild Status
Build Status
Build Status		Build Status
Build Status
Build Status		Build Status
Build Status		---Build Status---
XLangBuild StatusBuild StatusBuild Status---Build StatusBuild Status

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 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.

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 JIRA.

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 code has been donated from cloudera/spark-dataflow and is now part of Beam.
  • 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 JIRA.

Getting Started

To learn how to write Beam pipelines, read the Quickstart for [Java, Python, or Go] available on our website.

Contact Us

To get involved in Apache Beam:

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

More Information