AddFiles: SchemaDelta classifies what a file schema needs from the table (#40062) * AddFiles: SchemaDelta classifies what a file schema needs from the table The classifier behind the options. Iceberg's unionByNameWith has no knobs: it adds, relaxes and promotes in one go, or throws. To honour ALLOW_FIELD_ADDITION / ALLOW_FIELD_RELAXATION / ALLOW_TYPE_PROMOTION separately, SchemaDelta.classify(table, fileSchema) applies the union on a throwaway UpdateSchema (apply(), never commit()), diffs the result against the current table schema, and labels every change: - FIELD_ADDITION: a field id present only after the union. - FIELD_RELAXATION: required before, optional after; or a required table column with no counterpart in the file at all (see below). - TYPE_PROMOTION: same id, wider primitive type after. - CONFLICT: anything else. The union throwing (ValidationException or IllegalArgumentException, e.g. int column vs string file column, a dotted or empty file column name), a field removed by the union (cannot happen with unionByName but is refused rather than trusted), a struct where a primitive was, a doc string or default changing, a promotion Iceberg would not allow (TypeUtil.isPromotionAllowed guard, so a bad union result is never staged as a "promotion"). The diff is keyed by field id and walks fields attribute by attribute (name, optionality, type kind, doc, defaults), so an attribute the union silently changes is reported rather than committed unnoticed. Changes are listed in a deterministic order (unquoted path) with quoted names in messages so a reviewer can find them in the schema. Absence rule: a required table column that the file lacks is a FIELD_RELAXATION, not a pass. Registering such a file would put nulls in a required column for every reader; the fix is to relax the column explicitly (the commit side stages makeColumnOptional for exactly the paths absentRequiredPaths() reports). The walk descends through structs whose parent is present, through list elements and map values (paths use "element" and "value", which makeColumnOptional accepts); an absent struct is itself the relaxation, its children are not listed separately; map keys are required by definition and skipped. Pins: Change.allowedBy(config) refuses a relaxation of a pinned path even when ALLOW_FIELD_RELAXATION is set, and disallowedReason(config) names it, so "id is pinned" shows up as the reason rather than a generic "relaxation not allowed". * move pins to class * pins * docstring * Fix docstring * tests * split file * split * map keys * track test
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.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.
Here are some resources actively maintained by the Beam community to help you get started:
To get involved with Apache Beam: