Ускорение PyArrow Parquet до Pandas для фрейма данных с большим количеством строк - PullRequest
Новая
       47

Ускорение PyArrow Parquet до Pandas для фрейма данных с большим количеством строк

1 голос
/ 28 мая 2020

У меня есть pandas DataFrame, который я хочу часто запрашивать (в ray через API). Я пытаюсь ускорить его загрузку, но требуется значительное время (3+ с), чтобы поместить его в pandas. Для большинства моих наборов данных это быстро, а вот этот - нет. Я предполагаю, что это потому, что 90% из них - строки. 

[742461 rows x 248 columns]

Это примерно 137 МБ на диске. Чтобы исключить скорость диска как фактор, я поместил файл .parq в монтирование tmpfs.

Теперь я попробовал:

  • Чтение паркета с помощью pyArrow Parquet (read_table) а затем приведение его к pandas (чтение в таблицу происходит немедленно, но использование to_ pandas занимает 3 секунды)
  • Играет практически со всеми настройками to_ pandas, которые я могу придумать в pyarrow / parquet
  • Чтение с помощью pd.from_parquet
  • Чтение из хранилища памяти Plasma (https://arrow.apache.org/docs/python/plasma.html) и преобразование в pandas. Опять же, чтение происходит немедленно, но для_ pandas требуется время.
  • Преобразование всех строк в категории

У каждого есть хорошие советы, как ускорить преобразование pandas при работе с струны? У меня много ядер и оперативной памяти.

Мои конечные результаты хотят быть pandas DataFrame, поэтому я не привязан к формату файла parquet, хотя он обычно мой любимый.

С уважением, Никлас

1 Ответ

1 голос
/ 10 июня 2020

В конце концов, я сократил время за счет более тщательной обработки данных, в основном за счет удаления пустых значений, убедившись, что у нас есть как можно больше значений NA (вместо пустых строк и т. Д. c), и сделал категории для всех текстовых данных с менее чем 50% уникального содержания.

В итоге я создал схемы через PyArrow, чтобы я мог создавать категориальные значения с настраиваемым размером индекса (int64 вместо int16), чтобы мои категории могли содержать больше значений. В итоге размер данных был уменьшен на 50%.

...