Буквально только что сидел и «крутил» данные на работе. Данные у нас хранятся в Hadoop, а обрабатываем их мы с помощью Spark (в частности, используем pyspark).

И естественно, все таблицы у нас партиционированы. Грубо говоря - данные в Hadoop благодаря партиционированию хранятся в директориях. Если партиционировать, например, по report_date, то данные за январь хранятся в одной папке, данные за февраль в другой и так далее.

Так вот, я написал запрос

SELECT * FROM NAME_TABLE LIMIT 5,

чтобы просто посмотреть на рандомные пять строк из таблицы. И … такой запрос работал минут 15.

Это произошло потому, что Spark сначала просканировал всю таблицу (а там она весит под 1 Tb и строк несколько сотен миллионов) и только потом вывел результат.

Причем же здесь партиционирование? А притом, что нужно было дописать всего одно условие:

WHERE report_date = “2023-01-01”.

Такой скрипт отработал за 10 секунд! Так произошло потому, что Spark уже не заходил во все директории, а знал конкретно куда идти и что сканировать. В итоге, просканировал немного данных и быстро вывел результат.

Посмотреть партиции в таблице можно командой SHOW PARTITIONS NAME_TABLE.

А дальше уже можно для тестирования писать более сложные запросы и накручивать более сложный код.

Вообще оптимизация запросов в БД (или конкретно в Spark) довольно обширная тема, но об этом в другой раз.