Я работаю с паркетными файлами, хранящимися в ведрах 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
Источник: