许多最佳实践建议数据应该以压缩格式存储在hdfs中。在一个由压缩文本文件（每个大约250 mb的分块gzip文件）和未压缩文本文件组成的表上运行配置单元查询时，存在明显的性能差异。有人能解释一下幕后发生了什么吗？根据我的理解，当查询输入被分配给Map器任务时，有一个解压阶段，然后有一个查询。如果是这样的话，它怎么能提供比未压缩文本文件更好的性能，因为它会有解压缩的开销？
yptwkmov1#
众所周知，在磁盘使用率和查询性能方面，配置单元表中的数据压缩比未压缩存储提供更好的性能。您可以将用gzip压缩的文本文件直接导入存储为textfile的表中。压缩将被自动检测，并且在查询执行期间文件将被动态解压缩。在执行压缩之前，record会单独压缩每个值，而block会缓冲1mb（默认值）。
muk1a3rh2#
这里涉及两个方面：网络开销：map-reduce范式因洗牌和排序的开销而备受批评。如果您以非常自私的方式看待处理步骤，那么这些步骤对您想要的处理没有任何贡献。另外，当更大的数据在物理层通过网络时，即使您使用千兆频率开关，也会（如果不是非常复杂的操作），然后无序排序成为瓶颈。因此更容易压缩数据，它可以通过无序排序瓶颈。稀疏数据：较大的数据集大多是稀疏的（存在例外，但将其视为经验法则）。所以压缩会降低数据的大小，然后再次进行无序排序的步骤非常小。
2条答案
按热度按时间yptwkmov1#
众所周知，在磁盘使用率和查询性能方面，配置单元表中的数据压缩比未压缩存储提供更好的性能。
您可以将用gzip压缩的文本文件直接导入存储为textfile的表中。压缩将被自动检测，并且在查询执行期间文件将被动态解压缩。
在执行压缩之前，record会单独压缩每个值，而block会缓冲1mb（默认值）。
muk1a3rh2#
这里涉及两个方面：
网络开销：map-reduce范式因洗牌和排序的开销而备受批评。如果您以非常自私的方式看待处理步骤，那么这些步骤对您想要的处理没有任何贡献。另外，当更大的数据在物理层通过网络时，即使您使用千兆频率开关，也会（如果不是非常复杂的操作），然后无序排序成为瓶颈。因此更容易压缩数据，它可以通过无序排序瓶颈。
稀疏数据：较大的数据集大多是稀疏的（存在例外，但将其视为经验法则）。所以压缩会降低数据的大小，然后再次进行无序排序的步骤非常小。