Add DBR 17.3 Delta CTAS/RTAS support and fix optimized writes [databricks] - #15320
Conversation
Signed-off-by: Niranjan Artal <nartal@nvidia.com>
Signed-off-by: Niranjan Artal <nartal@nvidia.com>
Signed-off-by: Niranjan Artal <nartal@nvidia.com>
Signed-off-by: Niranjan Artal <nartal@nvidia.com>
Signed-off-by: Niranjan Artal <nartal@nvidia.com>
Signed-off-by: Niranjan Artal <nartal@nvidia.com>
Signed-off-by: Niranjan Artal <nartal@nvidia.com>
Signed-off-by: Niranjan Artal <nartal@nvidia.com>
Signed-off-by: Niranjan Artal <nartal@nvidia.com>
Signed-off-by: Niranjan Artal <nartal@nvidia.com>
Signed-off-by: Niranjan Artal <nartal@nvidia.com>
Signed-off-by: Niranjan Artal <nartal@nvidia.com>
Greptile SummaryThis PR enables GPU acceleration for DBR 17.3
Confidence Score: 5/5Safe to merge; the DBR 17.3 atomicity, catalog-commit, and partitioning contracts are all preserved and guarded by purpose-built context sentinels. The CTAS/RTAS wrappers correctly delegate staging, commit, and abort to DBR's native catalog while enabling GPU execution only inside the GpuAtomicDeltaWriteContext scope. The optimized-write shuffle fix accurately replicates DBR's two-view partitioning contract (marker as target, physical hash as output) and resolves the dynamic partition count at the right point in the execution lifecycle. Shim splits, resource management, and context propagation all look correct. Files Needing Attention: No files require special attention. Important Files Changed
Reviews (11): Last reviewed commit: "address review comments" | Re-trigger Greptile |
|
build |
Signed-off-by: Niranjan Artal <nartal@nvidia.com>
Signed-off-by: Niranjan Artal <nartal@nvidia.com>
Signed-off-by: Niranjan Artal <nartal@nvidia.com>
Signed-off-by: Niranjan Artal <nartal@nvidia.com>
Signed-off-by: Niranjan Artal <nartal@nvidia.com>
|
build |
Signed-off-by: Niranjan Artal <nartal@nvidia.com>
|
build |
1 similar comment
|
build |
|
build |
Signed-off-by: Niranjan Artal <nartal@nvidia.com>
Signed-off-by: Niranjan Artal <nartal@nvidia.com>
|
build |
Signed-off-by: Niranjan Artal <nartal@nvidia.com>
|
build |
| assert effective_optimize_write.lower() == str(optimized_write).lower() | ||
| effective_aqe = spark.conf.get("spark.sql.adaptive.enabled") | ||
| assert effective_aqe.lower() == str(aqe_enabled).lower() | ||
| command = "CREATE OR REPLACE TABLE" if replace else "CREATE TABLE" |
There was a problem hiding this comment.
nit: Could we add coverage for the existing-table branches of the new atomic CTAS/RTAS wrappers? In particular, CREATE TABLE IF NOT EXISTS, the existing-table error for plain CREATE, and REPLACE TABLE without OR CREATE.
| source_table = spark_tmp_table_factory.get() + '_sql_source' | ||
|
|
||
| with_cpu_session( | ||
| lambda spark: spark.range(81920).selectExpr( |
There was a problem hiding this comment.
nit: Could we add a focused zero-row CTAS/RTAS case? The new tests only exercise non-empty inputs, so the schema-only/empty commit path is not covered.
| /** | ||
| * GPU wrapper for DBR 17.3 atomic RTAS. | ||
| * | ||
| * DBR's native catalog remains responsible for stage/commit/abort and therefore for Unity |
There was a problem hiding this comment.
nit: Could we clarify that only the native stage/commit/abort mechanics are retained here, while catalog-owned and coordinated-commit table creation remains blocked pending GPU qualification? The current wording can read as though those semantics are supported.
| override protected def run(): Seq[InternalRow] = { | ||
| if (catalog.tableExists(ident)) { | ||
| if (ifNotExists) { | ||
| return Nil |
There was a problem hiding this comment.
nit: Could this avoid explicit returns and use expression-style branching or matching instead? The repository’s Scala convention prefers the final expression as the result.
| private val activeKey = "spark.rapids.sql.delta.atomicWrite.active" | ||
|
|
||
| def isActive: Boolean = SparkContext.getActive | ||
| .exists(_.getLocalProperty(activeKey) == "true") |
There was a problem hiding this comment.
nit: Could this context use a private per-JVM token rather than the public literal "true"? Application code can set Spark local properties, so a fixed value makes the qualification gate externally reproducible.
|
NOTE: release/26.08 has been created from main. Please retarget your PR to release/26.08 if it should be included in the release. |
Signed-off-by: Niranjan Artal <nartal@nvidia.com>
|
build |
Closes #15059. ### Description This PR updates the download and archive documentation for the v26.08.0 release, adds the Databricks compatibility guidance requested in #15059 directly to the download page, and aligns the Code of Conduct contact with the cuDF Spark project name. Changes include: - Update `docs/download.md` to list v26.08.0 artifacts, Maven coordinates, signature verification commands, supported Spark versions, and concise release notes. - Add an inline Databricks compatibility section to `docs/download.md`, covering the current DBR 14.3/17.3 Spark, Scala, JDK, CUDA, driver, Delta feature, and fallback guidance without introducing a separate support page. - Update DBR 17.3 coverage for v26.08 liquid clustering and CTAS/RTAS support based on #15278 and #15320. - Move the previous current release, v26.06.1, into `docs/archive.md` as the newest archived release. - Replace `spark-rapids-conduct@nvidia.com` with `cudf-spark-conduct@nvidia.com` in `CODE_OF_CONDUCT.md`. - Verify the Spark support matrix against `pom.xml` on `release/26.08`. - Verify every PR referenced by the release notes is included in `release/26.08`. - Verify the archived v26.06.1 requirements and artifacts against the `v26.06.1` tag. Validation: - `git diff --check -- CODE_OF_CONDUCT.md docs/download.md docs/archive.md` - IDE lints for all three documentation files - Verified the inline Databricks matrix excludes the unsupported DBR 13.3 line ### Checklists Documentation - [x] Updated for new or modified user-facing features or behaviors - [ ] No user-facing change Testing - [ ] Added or modified tests to cover new code paths - [ ] Covered by existing tests (Please provide the names of the existing tests in the PR description.) - [x] Not required Performance - [ ] Tests ran and results are added in the PR description - [ ] Issue filed with a link in the PR description - [x] Not required --------- Signed-off-by: liyuan <yuali@nvidia.com>
Fixes #15263
Description
The initial Delta Lake write support for Databricks Runtime 17.3 kept atomic CTAS and RTAS operations on CPU. In addition, DBR 17.3 optimized writes could lose their target-partitioning marker during CPU-to-GPU shuffle conversion, preventing the optimized-write exchange from being reconstructed and resized correctly on GPU.
This PR enables the supported DBR 17.3 Delta CTAS/RTAS paths on GPU and fixes the optimized-write shuffle conversion.
In this PR:
AtomicCreateTableAsSelectExecandAtomicReplaceTableAsSelectExecplans to the corresponding GPU atomic wrappers.DeltaOptimizedWritePartitioningas the target partitioning while advertising the derived physical partitioning as the shuffle output.DELTA_OPTIMIZED_WRITEshuffle origin, preventing unrelated GPU exchanges from satisfying the optimized-write plan check.Expected fallback behavior
The implementation continues to fall back to CPU for table-creation features whose DBR metadata or catalog semantics have not been qualified for the GPU create path, including:
When Delta optimized writes are enabled with AQE, the
DELTA_OPTIMIZED_WRITEexchange can run on GPU. With optimized writes enabled and AQE disabled, DBR uses its non-AQEDeltaOptimizedWriterExec; that path remains an expected CPU fallback.Performance
The scaled workload used:
g4dn.4xlargeT4 workers and a matching driver.This is an SF100-class workload and is not an official TPC-DS SF100 benchmark.
GPU Delta writer benefit
Delta optimized writes were disabled in this comparison so that it isolates the Delta writer change.
Compared with the same-26.08 CPU-writer control, GPU Delta writing was:
Compared with the RAPIDS 26.06 released behavior, it was:
Physical-plan validation confirmed that the 26.06 run accelerated the query operators but crossed through
GpuColumnarToRowinto CPUWriteIntoDeltaCommand/WriteFiles. The 26.08 GPU result used the GPU atomic wrapper and GPU Delta writer.Delta optimized-write tradeoff
spark.databricks.delta.optimizeWrite.enabled=false/true using the build jar from this PR.
Enabling optimized writes increased write time by 22.5% for fresh creation and 21.7% for replacement. In exchange, it reduced the output from 2,004 files to 84 files, a 23.86x reduction.
This was not caused by CPU fallback: the optimize-on runs used GPU atomic wrappers, GPU Delta writing, and GPU
DELTA_OPTIMIZED_WRITEexchanges. The additional time represents the actual repartitioning and file-sizing work required to produce the more compact layout.Checklists
Documentation
Testing
(Please provide the names of the existing tests in the PR description.)
Performance