Spark Rapids: простой пример HashAggregate

Я не вижу указанного рисунка, но подозреваю, что то, что происходит в вашем конкретном запросе, сводится к одному из двух возможных случаев.

Если ваш запрос выполняет какой-то сбор данных обратно в драйвер (например: .show или .collect в Scala или иным образом напрямую отображает результаты запроса), то столбчатые данные графического процессора необходимо преобразовать обратно в строки, прежде чем они будут возвращены драйверу. . В конечном итоге драйвер работает с RDD[InternalRow], поэтому в этих случаях должен происходить переход с RDD[ColumnarBatch].

Если ваш запрос заканчивается записью вывода в файлы (например, в Parquet или ORC), то план часто показывает окончательный GpuColumnarToRow переход. Оптимизатор Catalyst от Spark автоматически вставляет ColumnarToRow переходов, когда видит операции, способные производить столбчатый вывод (например, RDD[ColumnarBatch]), а затем плагин обновляет эти переходы до GpuColumnarToRow, когда предыдущий узел будет работать с графическим процессором. Однако в этом случае узел запроса - это команда записи данных, и они не производят вывода в смысле плана запроса. Вывод напрямую записывается в файлы, когда узел выполняется, вместо того, чтобы отправлять вывод нижестоящему узлу для дальнейшей обработки. Следовательно, на практике это вырожденный переход, поскольку команда записи данных не отправляет данные при переходе от столбца к строке. Я подал жалобу на ускоритель RAPIDS, чтобы очистить этот вырожденный переход, но это не влияет на производительность запроса.