Я работаю с паркетными файлами, хранящимися в ведрах AWS S3. Они имеют размер несколько ТБ и разделены числовым столбцом, содержащим целочисленные значения от 1 до 200, назовем его my_partition
. Я читаю и выполняю вычислительные действия с этими данными в Databricks с отключенным автомасштабированием.
Я обнаружил, что чтение определенного пути раздела для моего паркетного объекта займет 2 секунды, тогда как чтение полного пути паркета и фильтрация по разделу займет 6 минут. В поисках ответов я узнал о InMemoryFileIndex в этом StackOverflow. Для меня это имеет смысл, почему чтение происходит намного быстрее, если я читаю s3://my_parquet/my_partition=1/
, гораздо меньше листинга / эвристики для работы с содержимым файла, чем если бы я прочитал s3://my_parquet/
и выполнил .filter(col("my_partition")==1)
.
Как ни странно, вычисление, которое следует сразу за чтением, всегда медленнее для конкретного объекта чтения раздела, хотя инструкции искры должны быть такими же. Например:
# Specific partition read + compute
specific_read = spark.read.parquet("s3://my_parquet/my_partition=1/") # Takes 2 seconds
specific_read.count() # Takes 10 minutes
# Full parquet/filter + compute
general_read = spark.read.parquet("s3://my_parquet/").filter(col("my_partition")==1) # Takes 5 minutes
general_read.count() # Takes 1 minute
Кажется, что чтение полного пути и фильтрация в целом происходит быстрее, но я не понимаю почему, особенно когда операция чтения выполняется намного быстрее для чтения определенных разделов. Почему один метод быстрее другого? Есть ли лучший способ извлечь данные, хранящиеся в определенном разделе, для вычислений?
какова будет производительность, если вы перезапустите кластер между этими запусками — я думаю, что Delta Cache может работать во втором случае. Кроме того, опубликуйте результаты specific_read.explain()
& general_read.explain()
как часть своего вопроса — person Zack Zofrea schedule 24.06.2021