dongjoon-hyun commented on code in PR #57355: URL: https://github.com/apache/spark/pull/57355#discussion_r3641126247
########## sql/core/src/main/scala/org/apache/spark/sql/execution/metric/CustomShuffleMetrics.scala: ########## @@ -0,0 +1,83 @@ +/* + * Licensed to the Apache Software Foundation (ASF) under one or more + * contributor license agreements. See the NOTICE file distributed with + * this work for additional information regarding copyright ownership. + * The ASF licenses this file to You under the Apache License, Version 2.0 + * (the "License"); you may not use this file except in compliance with + * the License. You may obtain a copy of the License at + * + * http://www.apache.org/licenses/LICENSE-2.0 + * + * Unless required by applicable law or agreed to in writing, software + * distributed under the License is distributed on an "AS IS" BASIS, + * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. + * See the License for the specific language governing permissions and + * limitations under the License. + */ + +package org.apache.spark.sql.execution.metric + +import org.apache.spark.SparkContext +import org.apache.spark.internal.Logging +import org.apache.spark.internal.LogKeys.METRIC_NAME +import org.apache.spark.shuffle.api.metric.{CustomShuffleMetric, CustomShuffleTaskMetric} +import org.apache.spark.util.MetricUtils + +object CustomShuffleMetrics extends Logging { + + /** + * Creates collision-filtered custom shuffle metric [[SQLMetric]]s for an operator that already + * exposes the given Spark-owned metric names. Plugin metrics whose names collide with a + * Spark-owned name are dropped so they can't shadow the real accumulators (e.g. + * `shuffleRecordsWritten`, which feeds AQE). Operators pass the reserved names they own; the + * declared metrics come from the shuffle driver components. + */ + def createFilteredMetrics( + sc: SparkContext, + reservedNames: Set[String]): Map[String, SQLMetric] = { + val (reserved, allowed) = sc.shuffleDriverComponents.supportedCustomMetrics() + .partition(metric => reservedNames.contains(metric.name())) + if (reserved.nonEmpty) { + logWarning(log"Ignoring custom shuffle metrics whose names collide with Spark-owned " + + log"Exchange metrics: " + + log"${MDC(METRIC_NAME, reserved.map(_.name()).sorted.mkString(", "))}.") + } + createMetrics(sc, allowed) + } + + /** + * Creates [[SQLMetric]]s for the given declared custom shuffle metrics, keyed by metric name. + */ + def createMetrics( + sc: SparkContext, + metrics: Array[CustomShuffleMetric]): Map[String, SQLMetric] = { + metrics.map { metric => + val label = metric.description() + // AVERAGE_METRIC is intentionally unsupported: its per-task values must be stored pre-scaled + // via SQLMetric.set(Double), whereas custom task metrics report a plain Long. + val acc = metric.metricType() match { + case MetricUtils.SUM_METRIC => SQLMetrics.createMetric(sc, label) + case MetricUtils.SIZE_METRIC => SQLMetrics.createSizeMetric(sc, label) + case MetricUtils.TIMING_METRIC => SQLMetrics.createTimingMetric(sc, label) + case MetricUtils.NS_TIMING_METRIC => SQLMetrics.createNanoTimingMetric(sc, label) + case other => throw new IllegalArgumentException( Review Comment: This looks like an inconsistent error handling between name collisions and invalid metric types. `createFilteredMetrics` handles the two failure modes differently: a plugin metric whose name collides with a Spark-owned metric is silently dropped with a warning, but an invalid `metricType()` throws an `IllegalArgumentException`. Since the exception is thrown while evaluating the operator's lazy `metrics` val (i.e. during planning / UI access), a single misconfigured plugin would fail **every query that contains a shuffle**, rather than just losing the bad metric. Could we make the two cases consistent? Two options: 1. Treat an invalid metric type the same as a collision: log a warning and drop the metric, so a buggy plugin degrades gracefully instead of breaking all queries. 2. If we do want to fail fast on an invalid type, use an error-class-based exception (e.g. `SparkIllegalArgumentException`) instead of a plain `IllegalArgumentException`, per the current error framework convention. I'd lean toward option 1, since custom metrics are purely observability and shouldn't be able to take down query execution. -- 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]
