Оптимизация Spark DataFrame / Dataset groupBy через bucketBy

Question

Я изучаю варианты для варианта использования, в котором мы сохраняем набор данных в виде файлов паркета и хотим выполнить эффективные запросы groupBy для определенного ключа позже, когда будем читать данные.

Я немного читал об оптимизациях для groupBy, но ничего особенного в этом не нашел (кроме RDD level reduByKey). Я имею в виду, что если набор данных записан с ключом, который также будет использоваться в groupBy. Теоретически groupBy может быть оптимизирован, поскольку все строки, содержащие ключ, будут совмещены (и даже последовательно, если он также хранится, отсортированный по одному и тому же ключу).

Одна идея, которую я имею в виду, состоит в том, чтобы применить преобразование через mapPartitions, а затем groupBy, однако это потребует разбиения моих функций на две части, что не очень желательно. Я полагаю, что для некоторого класса функций (скажем, сумма / число) спарк оптимизировал бы запрос аналогичным образом, но оптимизация была бы инициирована выбором функции и работала бы независимо от совместного расположения строк. , но не из-за совместного размещения.

Может ли spark использовать совместное расположение строк для оптимизации groupBy с помощью любой последующей функции?

Answer 1

Похоже, что основной сценарий использования bucketing - это выполнение JOIN для ключа с пакетами, что позволяет Spark избегать перемешивания по всей таблице. Если Spark знает, что строки уже распределены по сегментам, я не понимаю, почему он не знает, использовать предварительно разделенные сегменты в GROUP BY. Возможно, вам также потребуется отсортировать по группе по ключу.

Меня также интересует этот вариант использования, поэтому я попробую его и посмотрю, не произойдет ли случайное перемешивание.

Answer 2

Слишком сложное мышление.

Нет необходимости в mapPartitions.

bucketBy обычно для последующих JOIN, но сумма, считая с выражением where, выиграла бы от существенно меньшего количества необходимых перемешиваний. Также паркет столбчатый, что также быстро.

Ответ - ДА, слишком оптимизируйте, хотя последнее утверждение по вопросу не ясно.