S3 Select 会加快对 Parquet 文件的 Spark 分析吗？

Question

您可以在Amazon EMR上使用Spark和Databricks来使用S3选择，但只能用于CSV和JSON文件。我猜S3选择不提供纵栏文件格式，因为它不会有多大帮助。

假设我们有一个包含< code>first_name 、< code>last_name和< code>country列的人员数据湖。

如果数据存储为CSV文件，并且您运行类似于＜code＞peopleDF.select（“first_name”）.distinct（）的查询。count（），则S3将所有列的所有数据传输到ec2集群以运行计算。这非常低效，因为我们不需要所有last_name和country数据来运行此查询。

如果数据存储为 CSV 文件，并且您使用 S3 select 运行查询，则 S3 将仅传输first_name列中的数据以运行查询。

spark
  .read
  .format("s3select")
  .schema(...)
  .options(...)
  .load("s3://bucket/filename")
  .select("first_name")
  .distinct()
  .count()

如果数据存储在Parquet数据池中，并且＜code＞peopleDF.select（“first_name”）.distinct（）。如果运行count（），则S3将只将first_name列中的数据传输到ec2集群。拼花是一种柱状文件格式，这是其主要优点之一。

因此，根据我的理解，S3选择不会有助于加快对拼花数据湖的html" target="_blank">分析，因为列文件格式提供了开箱即用的S3选择优化。

我不确定，因为一位同事肯定我错了，还因为S3选择支持拼花文件格式。您能否确认分栏式文件格式提供了S3精选提供的主要优化功能？

Answer 1

在拼花地板上看到了s3 select的spark包[1]

[1]https://github.com/minio/spark-select

Answer 2

这是一个有趣的问题。我没有任何实数，尽管我已经在hadopop-aws模块中完成了S3选择绑定代码。Amazon EMR有一些值，数据库也有。

对于CSV IO是，S3选择将在积极过滤源数据的情况下加速，例如许多GB的数据但没有太多返回。为什么？尽管读取速度较慢，但您可以节省VM的有限带宽。

然而，对于拼花木地板，工作人员将一个大文件分成几个部分，并在它们之间安排工作（假设使用了像snappy这样的可拆分压缩格式），所以

如果集群中有足够的容量，并且您已经针对性能调整了S3客户端设置（对于s3a，这意味着：搜索策略、线程池大小、http池大小），我不相信S3集群中的Parquet读取可以击败spark集群。

就像我说的：我不确定。欢迎数字。