很明显，而且有很好的文档证明，拆分zip文件的能力对hadoop中作业的性能和并行化有很大的影响。然而，azure是建立在hadoop之上的，我在微软文档中没有提到这种影响。这不是adl的问题吗？例如，gzipping大文件现在是一种可以接受的方法，还是我会遇到同样的问题，由于选择了压缩编解码器而无法并行处理我的工作？谢谢
8dtrkrch1#
从随机位置开始读取gzip文件是不可能的。有必要从头开始阅读。然后，如果您有一个大的gzip（或其他不可拆分的压缩格式），您就不能并行地读取/处理它的块，只在一台机器上按顺序处理所有文件。hadoop（以及其他大数据替代品）的主要思想依赖于在不同机器上并行处理数据。一个大的gzip文件与这种方法不匹配。有一些数据格式允许使用gzip压缩数据页并保持文件可拆分（每个页可以在不同的机器上处理，但是每个gzip块仍然需要在一台机器上处理），比如parquet。
vlf7wbxs2#
请注意，azure data lake analytics不是基于hadoop的。rojosam认为gzip是一种不好的并行压缩格式，这是正确的。u-sql确实能够自动识别.gz文件并对其进行解压缩。但是，压缩文件的大小有4gb的限制（因为我们不能拆分和并行处理它），我们建议您使用几个100mb到1gb的文件。我们正在努力增加Parquet地板的支持。如果您需要其他压缩格式，如bzip:请在http://aka.ms/adlfeedback.
2条答案
按热度按时间8dtrkrch1#
从随机位置开始读取gzip文件是不可能的。有必要从头开始阅读。
然后，如果您有一个大的gzip（或其他不可拆分的压缩格式），您就不能并行地读取/处理它的块，只在一台机器上按顺序处理所有文件。
hadoop（以及其他大数据替代品）的主要思想依赖于在不同机器上并行处理数据。一个大的gzip文件与这种方法不匹配。
有一些数据格式允许使用gzip压缩数据页并保持文件可拆分（每个页可以在不同的机器上处理，但是每个gzip块仍然需要在一台机器上处理），比如parquet。
vlf7wbxs2#
请注意，azure data lake analytics不是基于hadoop的。
rojosam认为gzip是一种不好的并行压缩格式，这是正确的。
u-sql确实能够自动识别.gz文件并对其进行解压缩。但是，压缩文件的大小有4gb的限制（因为我们不能拆分和并行处理它），我们建议您使用几个100mb到1gb的文件。
我们正在努力增加Parquet地板的支持。如果您需要其他压缩格式，如bzip:请在http://aka.ms/adlfeedback.