0lai0 opened a new pull request, #6038: URL: https://github.com/apache/datafusion-comet/pull/6038
## Which issue does this PR close? Closes #5647. ## Rationale for this change #5361 landed the native (iceberg-rust) writer with numbers measured by hand. Nothing in the tree exercises it repeatably, so a regression would go unnoticed, and enabling Comet turns the scan and the writer on at once, which makes their contributions easy to conflate. ## What changes are included in this PR? A new `CometIcebergWriteBenchmark`: four workloads (unpartitioned insert, partitioned insert clustered, partitioned insert fanout, copy-on-write `DELETE`) by three arms (stock Spark, Comet scan with the iceberg-java writer, Comet scan with the native writer). The first-to-second step is the scan speedup, the second-to-third the writer's own. Details worth knowing when reading the diff. The fanout case turns the distribution off as well as the fanout writer on, or rows arrive clustered and the writer never fans out. The copy-on-write case fills the table under stock Spark for every arm, since the two writers roll files at different points. Each iteration rebuilds the table before the timer starts, as neither an insert nor a delete is idempotent. Two base-class changes come along: `CometBenchmarkBase.warn` becomes `protected` with the duplicate in `CometCodegenDispatchBenchmark` removed, and `configureIcebergHadoopCatalog` is extracted there. The catalog settings were repeated in four benchmarks and had drifted. `CometOperatorSerdeBenchmark` registers `bench_cat` where the rest use `benchmark_cat`. The two copies in files this PR already touches are migrated, and the rest is a follow-up. `benchmarks/micro/run.py` needs no change: suites are discovered from the source directory and this one runs in 202 s. ## How are these changes tested? A benchmark has no assertions, so `verifyArm` runs each case once before any timing and throws if the case is not what its name claims: the resulting row count, a Comet operator in the Comet arms, **no** Comet operator in the baseline that divides every `Relative` figure, and an exchange present for the clustered case and absent for the fanout one. That last check is the only thing separating those two workloads. Run with `SPARK_GENERATE_BENCHMARK_FILES=1 make benchmark-org.apache.spark.sql.benchmark.CometIcebergWriteBenchmark`. On `-Pspark-4.1`, Apple M5 laptop, 4M rows over ten mixed-type columns, the recorded run puts `Comet scan + native write` at 2.8X unpartitioned, 1.8X clustered, 2.0X fanout and 1.3X on copy-on-write, with the `Comet scan` arm between 1.1X and 1.4X. A laptop is not a measurement machine, and this corpus is not the one #5361 measured, so these show the benchmark works rather than settling a number. The copy-on-write `Comet scan` row is the unstable one. It is 1.1X in the recorded run and 0.7X on a repeat of the same code, with a standard deviation many times the baseline's, while its best time stays within 8% of Spark's in both. The gap is in the tail rather than a systematically slower path. The plans explain the small margin there: in all three arms the main scan is `BatchScan ... IcebergCopyOnWriteScan` under a `ColumnarToRow`, with only the runtime group-filter subquery on Comet. The `Comet scan` arm therefore pays for a columnar shuffle with no scan speedup to offset it, while the native writer consumes that output directly. `spotless:check -Pspark-4.1` and `test-compile -Pspark-4.1` are clean, and `CometIcebergReadBenchmark` was re-run as the only other caller of the rewired `prepareIcebergTable`. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
