Комментарии 7
Обращу внимание, что любая оптимизация должна проводиться в первую очередь с контролем:
1) плана выполнения запроса
2) занимаемых ресурсов в процессе работы
3) конфигурации spark-приложения (в частности количества памяти на экзекьютор, драйвер, уровня auto-broadcast-treshold)
4) времени выполнения
5) размеров таблиц с исходными данными.
Использование Broadcast может привести вас к плавающему OutOfMemoryException когда "маленькая" таблица вдруг окажется слоном, который не влезает в экзекьютор.
Не-использование Broadcast в некоторых конфигурациях данных — тоже.
Я бы даже так сказал — я видел множество статей (в том числе как собственных, так и переводов тут на Хабре), где описывается например выбор конфигурации. И знаете что — практически везде этот выбор делается так, как будто наше приложение — единственное на кластере.
При этом у нас скажем в очереди Yarn иногда бывает по 4000 ждущих приложений, что сильно далеко от «мы одни на кластере». В одной очереди из многих, я имел в виду.
Ну и да, мы уже приходим к тому, что многие оптимизации (типа практического примера в конце поста) нужно проводить только после того, как ты померял, что же за таблицу тебе подсунули — т.е. посмотрел, сколько данных, сколько колонок, и т.п. — и только потом применять все эти хитрости типа блума.
Операция бакетирования по сравнению с ее отсутствием это, насколько я помню, дополнительный map(или reduce?)-этап и он вызывает shuffle данных чтобы данные по одинаковым ключам положить рядышком, т.е. нагрузку на сеть. Он не бесплатный. Поэтому если вы бакетируете какую-то таблицу, а потом ее читает всего один источник и тот — частично, то это может быть потерей времени.
Упомянутое партиционирование немного по-разному поддерживается в Hive и в spark и может быть источником граблей. Просто положить данные в папочку на hdfs (с помощью distcp или файловых операций) может быть недостаточно. Надо будет вызывать msck repair table, чтобы обновить партиции в metastore.
Если вы обновляете партиции у таблицы, которая читается каким-то еще стриминг-процессом, то в ходе стриминга тоже надо явно вызывать обновление партиций. Потому что он, зараза, их кэширует и потом может плеваться странными ошибками в духе "файл не найден".
Укажите источник фото
Отличная статья и аналогии понятные для людей не из ИТ!
Практические методы оптимизации запросов в Apache Spark