我已经阅读了一些关于镶木地板格式以及 spark 如何与之集成的信息。
作为列式存储，parquet really shines 只要 spark 可以与底层存储协作以执行投影，而无需加载所有数据以及指示存储根据各种统计信息加载特定的列块（当过滤器涉及）。
我看到lecture on youtube (21:54) 警告说对象存储不支持下推过滤器（特别是以 Amazon S3 为例）。
Azure Blob 存储在这方面的表现如何（当我们阅读会话拼花时）？
【问题讨论】：
标签： apache-spark parquet azure-blob-storage
她错了。更具体地说，即使在 2017 年 2 月的演讲中，她对 Hadoop 2.8 中的 S3 的看法也是错误的 HADOOP-13203；多年来一直向后移植到 CDH 和 HDP。
Azure 自 2017 年 8 月就拥有它，HADOOP-14535，它被反向移植到发布 Azure HD/Insights 和 HDP（请与 Cloudera 联系以了解 CDH）。
她提到的问题是 seek() 在 HTTP 连接上的开销很大，因为如果要 D/L 的数据很多 GB，您需要中止连接并建立一个新连接。上面的 Hadoop 补丁更改了商店的 IO 模式，通过执行内容长度有限的 GET 来优化随机访问，让您重用相同的 HTTP1.1 连接。这对于完整的文件读取来说是病态的； S3A 让您自问自答 (fs.s3a.experimental.fadvise=random)； Azure 在第一次向后搜索时切换到随机 IO。
这与谓词下推根本无关：这一切都在 ParquetFileFormat 中完成，只是如果您需要建立新的 HTTP 连接，则查找，尤其是向后查找非常昂贵。由于 ORC 和 Parquet 格式将列摘要放在列块之后，因此有很多这样的内容 更多详情，请查看同一会议的this other talk。
【讨论】：