Test/spark geospatial - #33
Merged
Merged
Conversation
added 3 commits
July 30, 2026 12:54
EMR Serverless and Glue differ only in how a job is created and run. Everything around that -- the repo bundle, the S3 layout, the report download, the job summary -- is identical, so it now lives in tests/aws/platform_common.py instead of being copied. The report format is the part that matters most: the whole point is that every engine publishes the same shape, and two copies would drift. run_emr_serverless.py drops from 482 to about 300 lines with no behaviour change, verified by re-running both storage modes afterwards: 44/4/22 and 42/4/24, zero errors and zero discrepancies, the same as before. build_bundle is now engine-agnostic, carrying every engine's matrix JSON rather than just EMR's, so one bundle serves any driver and adding an engine does not mean remembering to extend it. emr_entrypoint.py becomes platform_entrypoint.py and takes --engine and --platform-id, since the only engine-specific things in it were the platform id and the matrix path. It now parses with parse_known_args because Glue injects job arguments of its own (--JOB_NAME, --TempDir), and detect_iceberg_version searches several roots so it finds the jar on Glue as well as EMR.
Adds tests/aws/run_glue.py and a glue-version input, so Glue is now a supported engine on the dispatch workflow rather than one that fails fast. Both storage modes pass with zero errors and zero discrepancies on Glue 5.1. The catalog wiring is identical to EMR -- GlueCatalog for s3buckets, and the federated s3tablescatalog through glue.id for s3tables -- which is the point: what differs between the two engines is the runtime, not the configuration. glue-version is a choice input rather than free text because it pins Iceberg rather than just bumping Spark. 5.1 ships Iceberg 1.10.0 and supports format version 3; 5.0 ships 1.7.1 and 4.0 ships 1.0.0, both of which predate most of V3. Running V3 below 5.1 mostly measures the absence of V3, so the input says so. Three Glue-specific behaviours cost a run each and are commented where they bite: An argument declared with an empty value reaches the script as a bare flag with no value, and argparse rejects it. Empty values are dropped instead, on both the job definition and the run. Glue treats any SystemExit as a failure, including SystemExit(0). A clean run was being reported FAILED with "SystemExit: 0", which hid the report behind it. The entrypoint now only raises SystemExit when there is something to report. MaxConcurrentRuns of 1 is too tight even though the modes run sequentially: Glue still counts a run as active for a moment after it reports SUCCEEDED, so starting the next mode failed with ConcurrentRunsExceededException. Teardown grows Glue job handling. A job definition is free to keep but an active run bills per DPU-hour, so runs are stopped before the definition is deleted, and it is prefix-scoped so it also sweeps up anything a crashed run left behind. The job role now trusts glue.amazonaws.com in addition to EMR Serverless, and can write CloudWatch Logs, which Glue uses instead of S3 and without which a job does not start. The Glue trust statement deliberately has no aws:SourceAccount condition, because Glue does not reliably populate it for job execution roles and a condition that never matches fails the job with a misleading AccessDenied; the control is the CI role, which may only pass this role to those two services.
Measured on Glue 5.1 (Spark 3.5.6-amzn-1, Iceberg 1.10.0-amzn-0). Both storage modes now run with zero discrepancies. VARIANT and shredded variant move to none. Glue 5.1 runs Spark 3.5.6, which has no VARIANT SQL type -- it arrived in Spark 4 -- so declaring the column is rejected with UNSUPPORTED_DATATYPE. Iceberg 1.10.0 supports variant at the format level, so this is an engine limitation rather than an Iceberg one, and the distinction is real rather than theoretical: the same test passes on EMR Serverless, which runs Spark 4.0.2 with the same Iceberg version. The s3buckets cell previously said full on the strength of a note that described EMR, not Glue. On S3 Tables, AWS Glue Catalog moves from none to full for the same reason it did on EMR: the old note, "S3 Tables uses its own built-in catalog, not AWS Glue", is wrong about how Glue actually reaches it -- the table bucket is mounted as the federated s3tablescatalog and addressed through GlueCatalog. Row lineage on S3 Tables moves from unknown to full, and multi-arg transforms, variant and shredded variant from unknown to none. These were unknown because AWS does not document them for S3 Tables; they are measured now. Also classifies a missing VARIANT type as a failure rather than an error in the shredded-variant test, matching what the variant-type test already did. An engine that cannot express the type is a measured "not supported", and reporting it as an error made a known gap look like a broken harness. Worth noting for later: Glue 5.1's release notes list column default values as supported, but the Spark SQL DDL path still rejects them (UNSUPPORTED_FEATURE.TABLE_OPERATION), exactly as on EMR. The cell stays none, which is what both engines measure.
PyIceberg Feature Test Report
Summary
Test Results
|
DuckDB Iceberg Feature Test Report
Summary
Test Results
|
ClickHouse Iceberg Feature Test Report
Summary
Test Results
|
Iceberg Feature Test Report (Spark, V2 + V3)
Summary
Matrix coverage: 35/35 features in Test Results
|
Flink Iceberg Feature Test Report
Summary
Test Results
UnverifiedThese could not be exercised here, so they neither confirm nor contradict the matrix:
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
No description provided.