[Go SDK] Add pass through registration for the fixed and variable length string and bytes logical types (#40156) * [Go SDK] Encode INT16 row fields as big endian to match Java and Python The reflection based row coder used the varint encoding for int16 and uint16 fields. Java and Python encode the INT16 schema type as 2 big endian bytes, so rows with such fields could not be exchanged with the other SDKs. Fixes #40151. Part of #39684. * [Go SDK] Convert logical type arguments to and from schema protos Logical types registered with an argument now emit argument_type and argument in their FieldType, and schemas from other SDKs are matched on the URN and the argument value. A logical type registered without an argument still matches any argument, so pass through types keep working. Top level logical types carry the argument in a schema option. Part of #39684. * [Go SDK] Add portable logical type registration and standard date and micros_instant types schema.RegisterLogicalTypeConversion registers a logical type identified by a URN together with the conversions between its Go type and its storage type, and derives the row coder from the storage type. schema.RegisterLogicalTypeCoder does the same for logical types whose wire encoding differs from the row encoding of the storage type. The standard beam:logical_type:date:v1 and beam:logical_type:micros_instant:v1 logical types are registered by default as schema.Date and schema.MicrosInstant. The standard coder regression test now builds the expected row from the schema in the coder payload, decodes payload bytes above 0x7f, counts encoding mismatches as failures, and runs the micros_instant case. Part of #39684. * [Go SDK] Add the standard millis_instant and decimal logical types schema.MillisInstant encodes as the Java InstantCoder does: 8 big endian bytes of the milliseconds shifted by the minimum int64. schema.Decimal encodes as the Java BigDecimalCoder does: the scale as a varint followed by the length prefixed two's complement bytes of the unscaled value. Both cases of standard_coders.yaml now run in the Go regression test. Part of #39684. * [Go SDK] Add pass through registration for the fixed and variable length string and bytes logical types schema.RegisterPassThroughLogicalType maps a logical type URN to the Go type of its representation without mapping that Go type back, so a schema field with the URN decodes with the plain row encoding and the length argument is ignored. The standard fixed_char, var_char, fixed_bytes and var_bytes logical types are registered this way, and their standard_coders.yaml case now runs in the Go regression test. Part of #39684. * Put logical type release note in the active release section * Test public pass-through logical type registration and validation * Reject pointer types in pass-through logical type registration * [Go SDK] Address review nits in the pass-through logical type tests Separate the call and check sections with blank lines, say what a failing check wanted, and explain the repeated identical registration.
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.
If you're new to Apache Beam, start here:
Choose a language:
Run your first example:
Understand core concepts:
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 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.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.
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.PrismRunner runs the pipeline on your local machine using Beam Portability.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.JetRunner runs the pipeline on a Hazelcast Jet cluster. The code has been donated from hazelcast/hazelcast-jet 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.
Here are some resources actively maintained by the Beam community to help you get started:
To get involved with Apache Beam: