Hadoop 什么'；从压缩文件将数据加载到配置单元的推荐方法是什么？

我在文档中发现了它，它让我有点困惑

根据页面，如果我的输入文件（在AWS s3上）是压缩的gzip文件，我应该首先使用存储为TextFile的选项

加载数据，然后使用存储为SEQUENCEFILE的选项
创建另一个表，并将数据插入其中。这真的是推荐的方法吗

或者我可以直接使用存储为SEQUENCEFILE的选项
将数据加载到表集中吗

如果前一种方法确实是推荐的方法，是否有任何进一步的解释来解释为什么会这样？
您必须以其格式加载数据。这意味着，如果你的文件是文本文件，那么你应该将它们作为文本文件加载，如果你的文件是序列文件，那么将它们作为序列文件加载

对于Hive来说，压缩格式并不重要，因为它将使用文件的扩展名作为参考（如果在Hadoop中正确配置了压缩编解码器），动态地对它们进行解压缩

您正在共享的页面中的建议是，使用序列文件比使用压缩文本文件更好。这是因为Gzip文件是不可拆分的，如果您有一个非常大的Gzip文件，则所有文件都必须仅使用一个映射器进行处理，不允许并行工作在集群节点之间分配工作

然后，配置单元的建议是将压缩文本文件转换为序列文件，以避免这种限制。这只关乎性能

如果您的文件很小，那么这并不重要（<1 Hadoop块大小-默认为128MB）
 必须以其格式加载数据。这意味着，如果你的文件是文本文件，那么你应该将它们作为文本文件加载，如果你的文件是序列文件，那么将它们作为序列文件加载

对于Hive来说，压缩格式并不重要，因为它将使用文件的扩展名作为参考（如果在Hadoop中正确配置了压缩编解码器），动态地对它们进行解压缩

您正在共享的页面中的建议是，使用序列文件比使用压缩文本文件更好。这是因为Gzip文件是不可拆分的，如果您有一个非常大的Gzip文件，则所有文件都必须仅使用一个映射器进行处理，不允许并行工作在集群节点之间分配工作

然后，配置单元的建议是将压缩文本文件转换为序列文件，以避免这种限制。这只关乎性能

如果您的文件很小，那么这并不重要（<1 Hadoop块大小-默认为128MB）
 顺便说一句，这适用于所有在hadoop中工作的框架，而不仅仅是HIVE。感谢您的解释。关于你的上一句话
，如果你的文件很小，那就没关系了
，你说的是任何类型的文件吗？所以如果我有一个100MB的
gzip
文件，如果我把它作为一个文本文件加载，它不会有任何区别，对吧？至少不会有太大的区别。文本文件和序列文件各有利弊。但是，即使GZip文件是不可拆分的，您也不希望拆分一个小文件，这意味着要创建更多的映射程序。每个块的“最佳”大小在默认hadoop块大小中定义，在当前版本中为128 MB（除非您有特定场景）。一个好的选择是将所有文件合并到一个大序列文件中，并在记录级别进行压缩（而不是像GZip那样的文件级别）。等等，您将有一个数GB的文件，但可拆分为128 MB的块。您需要确定在您的案例中，工作和预处理（创建大文件）是否合理。如果你想更深入的了解，你应该研究一下列格式，比如OCR或Parquet.BTW，这适用于所有在hadoop中工作的框架，而不仅仅是HIVE。谢谢你的解释。关于你的上一句话
，如果你的文件很小，那就没关系了
，你说的是任何类型的文件吗？所以如果我有一个100MB的
gzip
文件，如果我把它作为一个文本文件加载，它不会有任何区别，对吧？至少不会有太大的区别。文本文件和序列文件各有利弊。但是，即使GZip文件是不可拆分的，您也不希望拆分一个小文件，这意味着要创建更多的映射程序。每个块的“最佳”大小在默认hadoop块大小中定义，在当前版本中为128 MB（除非您有特定场景）。一个好的选择是将所有文件合并到一个大序列文件中，并在记录级别进行压缩（而不是像GZip那样的文件级别）。等等，您将有一个数GB的文件，但可拆分为128 MB的块。您需要确定在您的案例中，工作和预处理（创建大文件）是否合理。如果你想更深入的研究，你应该研究一下像OCR或拼花地板这样的柱状格式。