从sparkrdds，我想将json数据暂存并归档到awss3。压缩它才有意义，我有一个使用hadoop的进程 GzipCodec 但是有些事情让我很紧张。
当我看签名的时候 org.apache.spark.rdd.RDD.saveAsTextFile 在这里：
https://spark.apache.org/docs/2.3.0/api/scala/index.html#org.apache.spark.rdd.rdd
类型签名为：
def saveAsTextFile(path: String, codec: Class[_ <: CompressionCodec]): Unit但是当我在这里查看可用的压缩编解码器时：
https://spark.apache.org/docs/2.3.0/api/scala/index.html#org.apache.spark.io.compressioncodec
亲本特征 CompressionCodec 亚型都说：
编解码器的有线协议不能保证在spark的各个版本之间兼容。这是打算作为一个内部压缩实用程序内的单Spark应用
那不好。。。但这很好，因为gzip可能更容易跨生态系统处理。
类型签名表示编解码器必须是的子类型 CompressionCodec ... 但是我尝试了以下方法将其另存为.gz，尽管hadoop的gzip代码不是 <: CompressionCodec .
import org.apache.hadoop.io.compress.GzipCodec
rdd.saveAsTextFile(bucketName, classOf[GzipCodec])我的问题：
这是可行的，但是有什么理由不这样做。。。还是有更好的办法？
与内置的压缩编解码器不同，spark版本（以及其他版本）的性能会很好吗？
1条答案
按热度按时间uqdfh47h1#
首先，您是绑定到rdd还是可以使用数据集/Dataframe？
对于Dataframe，您可以使用
然而，有一些考虑。压缩是很好的，但是如果生成的文件非常大，那么必须记住gzip不是可拆分格式，也就是说，如果以后要处理该文件，则必须由一个工作进程读取。例如，如果您的文件是不可拆分的，并且是1g，则处理它需要t时间，如果它是可拆分的（如lzo、snappy或bzip2），则可以在t/n中处理，其中n是拆分的数目（假设128mb块，则大约为8）。这就是为什么hadoop使用sequencefiles（sequencefiles是可拆分的，并且在一个块中使用gzip），这也是为什么存储到s3时选择的压缩格式通常是parquet。Parquet文件比gzip文件小，并且是可拆分的，也就是说，它的内容可以由多个工人处理。您仍然可以使用gzip文本文件，但要将它们保持在~100/200字节的范围内。
归根结底，这实际上取决于您打算如何处理s3中的数据。
会被询问吗？在这种情况下，Parquet地板是一个更好的选择作为格式。
它是否会被读取/复制到其他不懂Parquet地板的系统？那么gzip压缩就可以了。而且它很稳定，你不必担心它的变化。您可以自己尝试，在s3上保存一些示例数据，您仍然可以使用任何gzip工具打开它。