fastparquet 和 pyarrow 的比较？

Posted 2023-02-15

【中文标题】fastparquet 和 pyarrow 的比较？

【英文标题】：A comparison between fastparquet and pyarrow?

【发布时间】：2018-12-23 23:22:03

【问题描述】：

经过一番搜索，我未能找到fastparquet 和pyarrow 的彻底比较。

我发现了这个博客post（速度的基本比较）。

还有一个 github discussion 声称使用 fastparquet 创建的文件不支持 AWS-athena（顺便说一句，现在还是这样吗？）

我何时/为什么要使用其中一种？主要优点和缺点是什么？

---

我的具体用例是使用 dask 处理数据并将其写入 s3，然后使用 AWS-athena 读取/分析它。

【问题讨论】：

可以被认为是一个“意见”问题，但可能有一些技术点可以做出一个体面的答案。

您是否尝试使用 Dask 而不是 AWS Glue 构建数据湖？我问因为我在同一条船上。

不，我正在从 s3 parquet 数据集读取数据，处理它并将其写入另一个 parquet 数据集。我没有数据多样性问题（湖泊试图解决）。

请注意，链接基准的范围非常有限，它呈现单一的数据大小和单一的数据类型。因此，您无法真正得出任何结论，这些工具是如何扩展的，或者它们如何处理其他数据类型。对于 python 字符串特别有趣，因为它们通常是许多进程中的瓶颈。

【参考方案1】：

我使用 fastparquet 和 pyarrow 将 protobuf 数据转换为 parquet，并使用 Athena 在 S3 中查询相同的数据。然而，在我的用例中，两者都有效，它是一个 lambda 函数，压缩包文件必须是轻量级的，所以继续使用 fastparquet。 （fastparquet 库只有 1.1mb 左右，而 pyarrow 库是 176mb，Lambda 包限制为 250mb）。

我使用以下内容将数据框存储为镶木地板文件：

from fastparquet import write

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

【讨论】：

我会指出，在安装fastparquet 时，我今天得到了Downloading fastparquet-0.4.1.tar.gz (28.6 MB)。

aws-data-wrangler 提供经过优化的预构建层。它们包括 PyArrow，绝对是当今在 Lambda 中使用 Parquet 最简单的方法：github.com/awslabs/aws-data-wrangler

【参考方案2】：

但是，由于这个问题缺乏具体的标准，而我来到这里是为了一个好的“默认选择”，我想声明 pandas 默认引擎 用于 DataFrame 对象是 pyarrow（见pandas docs）。

【参考方案3】：

我要指出的是速度比较的作者也是pyarrow的作者:)我可以谈谈fastparquet案例。

在您看来，最重要的是要了解兼容性。 Athena 不是 fastparquet（或 pyarrow）的测试目标之一，因此您应该在做出选择之前彻底测试。对于日期时间表示、空值、类型，您可能想要调用许多选项 (docs)，这些选项可能对您很重要。

使用 dask 写入 s3 肯定是 fastparquet 的一个测试用例，我相信 pyarrow 也应该没有问题。

【讨论】：

那么为什么以及何时我会使用其中一个而不是另一个？

我要指出，上述答案的作者也是 fastparquet 的贡献者:)

【参考方案4】：

我刚刚使用 fastparquet 从 Elasticsearch 中取出数据并将其存储在 S3 中并使用 Athena 进行查询，完全没有问题。

我使用以下内容将 S3 中的数据帧存储为 parquet 文件：

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)

我的表在 Athena 中看起来像这样：

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")

【参考方案5】：

这个问题可能有点老了，但我碰巧在处理同样的问题，我发现了这个基准https://wesmckinney.com/blog/python-parquet-update/。根据它的说法，pyarrow 比 fastparquet 更快，难怪它是 dask 中使用的默认引擎。

更新：

更新我之前的回复。我在谷歌云存储中使用 pyarrow 写作和使用 fastparquet 阅读更加幸运。

【讨论】：

（但是，同样，该博客的作者是箭头的作者）

我之前的回复的更新。我在谷歌云存储中使用 pyarrow 写作和使用 fastparquet 阅读更加幸运。

我的用例是从 hbase 读取数据并复制到 azure。我使用 pyarrow 将 pandas 数据框转换为镶木地板文件。但是，当我使用 pyarrow 从 blob 读取镶木地板文件时，即使在定义模式之后，我也面临很多与模式相关的问题。现在使用 fastparquet 进行读写，没有任何架构问题。

这不是我在问题中链接的相同基准吗？

pyarrow 在 pandas 中是默认的，在 dask 中是 fastparquet