Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

Native blocks without a JVM input publish SQL metrics on every batch, ignoring spark.comet.metrics.updateInterval

オープン 初心者向け
  • 何か問題がありますか？
#6,313 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

まだ誰も着手していません。

評価

難易度
2/5
見積もり時間
1〜3時間
初心者へのやさしさ
78/100
issue の種類
バグ
明瞭さ
明確に書かれている
活発さ
活発
技術スタック
rust
領域
backend, performance

調査の方向性

native/core/src/execution/jni_api.rs の batch_receiver ブランチから始め、そのメトリクス公開パスを JVM 入力パスと比較してください。spark.comet.metrics.updateInterval=-1 と spark.comet.batchSize=1000 で再現し、pure-native ブロックが設定された間隔でのみメトリクスを公開すること、および releasePlan が最終値を公開することを確認してください。

索引モデルが issue の本文から書いたものです。

説明

bug performance priority:medium regression
Describe the bug

When a native block has no JVM input, meaning every leaf is a native scan, executePlan publishes the whole metric tree to the JVM after every output batch (the batch_receiver branch in native/core/src/execution/jni_api.rs). Blocks with a JVM input publish only after spark.comet.metrics.updateInterval has passed. So pure-native blocks ignore the setting, including a negative value, which the config doc says means "metrics will be updated upon task completion".

This came in with #3553 (0.14.0), which moved pure-native blocks onto a channel. Before that, both kinds of block checked the interval.

Each publish walks the plan, runs aggregate_by_name over every node's metrics, encodes a protobuf, and calls into the JVM, which decodes it and sets each SQLMetric. A native Parquet scan registers about 45 metrics for each file it opens, so the cost grows with the number of files a task has read.

I timed update_metrics in place on a release build (Apple M3 Max, local[1], 16M rows in 2,048 output batches from one task):

Plan Cost per publish Per task
Scan only, 1 file 19 µs 40 ms
Scan + filter + project 30 µs 62 ms
Scan only, 64 files in one task (2,905 raw metrics) 38 µs 78 ms
Scan + filter + project, noop write 26 µs 54 ms

Switching that branch to the interval check gave these medians of 7 runs:

Plan Wall time Process CPU time
Scan only, 1 file 174 → 143 ms 343 → 209 ms
Scan + filter + project 714 → 716 ms 882 → 834 ms
Scan only, 64 files in one task 210 → 167 ms 313 → 220 ms
Scan + filter + project, noop write 917 → 848 ms 1608 → 1505 ms

The scan + filter + project wall time doesn't move because the producer is the bottleneck there, and the publish runs on the consumer thread. It still spends CPU that other tasks on the executor could use.

This affects pure-native blocks whose output reaches the JVM batch by batch: a scan feeding a Spark write or a collect, a broadcast build side, JVM shuffle, or a fallback operator. A block that ends in a native shuffle write hands back only one batch, so it isn't affected.

Steps to reproduce

Set spark.comet.metrics.updateInterval=-1 and spark.comet.batchSize=1000, and read a 10,000-row Parquet file in one task. Inside the task, read the native scan's output_rows metric after the first batch. It is already non-zero, when it should stay 0 until the iterator closes.

Expected behavior

Pure-native blocks publish on the configured interval, as blocks with a JVM input do, and releasePlan publishes the final values.

Additional context

Found while looking at #1381.

主要言語
Scala
スター
1.3k
フォーク
377
平均マージ
2日 5時間
マージ済み PR（30日）
337

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

apache/datafusion-comet のほかの issue

apache/datafusion-comet の issue をすべて見る

似ている issue

Scala の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。