Сравнение между быстрым парком и пиарроу?

После некоторых поисков мне не удалось найти тщательного сравнения fastparquet и pyarrow.

Я нашел этот пост в блоге (базовое сравнение скоростей).

и обсуждение github, в котором утверждается, что файлы, созданные с помощью fastparquet, не поддерживают AWS-athena (кстати, это все еще так?)

когда/почему я использовал бы один поверх другого? Каковы основные преимущества и недостатки?


Мой конкретный пример использования - обработка данных с помощью dask запись их в s3, а затем чтение/анализ их с помощью AWS-athena.

Ответ 1

Я использовал и fastparquet, и pyarrow для преобразования данных protobuf в паркет и для запроса того же в S3 с использованием Athena. Оба сработали, однако, в моем сценарии использования, который является лямбда-функцией, пакетный zip файл должен быть легковесным, поэтому я выбрал fastparquet. (библиотека fastparquet составляла всего около 1,1 МБ, а библиотека Pyarrow была 176 МБ, а ограничение пакета Lambda - 250 МБ).

Я использовал следующее для хранения данных в виде файла паркета:

from fastparquet import write

parquet_file = path.join(filename + '.parq')
write(parquet_file, df_data)

Ответ 2

Я хотел бы указать, что автор сравнения скорости также является автором пиарроу :) Я могу говорить о случае fastparquet.

С вашей точки зрения, самое важное - это совместимость. Athena не является одной из контрольных целей для fastparquet (или pyarrow), поэтому вы должны тщательно протестировать, прежде чем делать свой выбор. Существует ряд опций, которые вы можете захотеть объявить (docs) для представления даты и времени, нулями, типами, которые могут быть важны для вас.

Запись на s3 с использованием dask - это, безусловно, тестовый пример для fastparquet, и я считаю, что у pyarrow тоже не должно быть проблем.

Ответ 3

Я просто использовал fastparquet для случая, чтобы получить данные из Elasticsearch и сохранить их в S3 и запросить у Athena, и у меня не было никаких проблем.

Я использовал следующее для хранения кадра данных в S3 в виде файла паркета:

import s3fs
import fastparquet as fp
import pandas as pd
import numpy as np

s3 = s3fs.S3FileSystem()
myopen = s3.open
s3bucket = 'mydata-aws-bucket/'

# random dataframe for demo
df = pd.DataFrame(np.random.randint(0,100,size=(100, 4)), columns=list('ABCD'))

parqKey = s3bucket + "datafile"  + ".parq.snappy"
fp.write(parqKey, df ,compression='SNAPPY', open_with=myopen)

Моя таблица выглядит примерно так в Афине:

CREATE EXTERNAL TABLE IF NOT EXISTS myanalytics_parquet (
  'column1' string,
  'column2' int,
  'column3' DOUBLE,
  'column4' int,
  'column5' string
 )
STORED AS PARQUET
LOCATION 's3://mydata-aws-bucket/'
tblproperties ("parquet.compress"="SNAPPY")

Ответ 4

Этот вопрос может быть немного старым, но я, похоже, работаю над той же проблемой, и нашел этот тест https://wesmckinney.com/blog/python-parquet-update/. Согласно ему, pyarrow быстрее, чем fastparquet, поэтому неудивительно, что он используется по умолчанию в dask.

Обновление:

Обновление к моему предыдущему ответу. Мне повезло больше писать с помощью pyarrow и читать с помощью fastparquet в облачном хранилище Google.