您可以使用S3 Select with Spark on Amazon EMR和with Databricks,但只能用于CSV和JSON文件。我猜S3精选不是为列文件格式提供的,因为它不会有太多帮助。
假设我们有一个包含first_name、last_name和country列的数据湖。
如果数据存储为CSV文件,并且您运行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数据湖中,并且正在运行peopleDF.select("first_name").distinct().count(),则S3将仅将first_name列中的数据传输到ec2集群。Parquet是一种柱状文件格式,这是它的主要优点之一。
因此,根据我的理解,镶嵌面板数据湖上的S3精选无助于加快分析速度,因为柱状文件格式提供了开箱即用的S3精选优化。
我不确定是因为一个同事确定我错了,也因为S3 Select supports the Parquet file format。您能否确认列式文件格式提供了S3精选提供的主要优化功能?
发布于 2019-04-30 07:14:51
这是一个有趣的问题。我没有任何实数,尽管我已经在hadoop-aws模块中完成了S3选择绑定代码。Amazon EMR和databricks都有一些价值。
对于CSV IO是的,S3精选将在对源数据进行积极筛选的情况下加快速度,例如许多GB的数据,但不会有太多回退。为什么?尽管读取速度较慢,但您可以节省到VM的有限带宽。
然而,对于Parquet,工作人员将一个大文件拆分成几个部分,并在它们之间调度工作(假设使用像snappy这样的可拆分压缩格式),因此>1个工作人员可以在同一文件上工作。它们只读取一小部分数据(==bandwidth获益较少),但它们确实会在该文件中查找(==need用于优化查找策略,否则会导致中止和重新打开HTTP连接的成本)
我不相信,如果集群中有足够的容量,并且你已经调优了你的S3客户端设置(对于s3a,这意味着:搜索策略,线程池大小,http池大小),那么s3集群中的Parquet read就可以胜过spark集群。
就像我说的:我不确定。欢迎使用数字。
发布于 2020-05-09 01:48:47
在Parquet1上偶然发现了这个s3 select的spark包
https://stackoverflow.com/questions/55911770
复制相似问题