我有一些关于Hive性能的问题。
我在网上的某个地方读到,压缩数据(orc,尤其是snappy)将在读取数据方面产生更好的性能。
另外,如果使用order by将数据加载到表中,则会产生一个大文件,从而降低读取可用性。
因此,实现与order by相同效果的另一种方法是使用cluster by,cluster by将创建多个小文件。
我做了一个压缩数据的实验,按数据聚类和按数据排序,以查看它们的性能。
目前,我有5个数据节点和1个名称节点。加载到每个表中的数据文件约为19gb+(200多万条记录)
我使用以下查询创建了orc snappy压缩表:
CREATE EXTERNAL TABLE orc_t (....)
STORED AS ORC
LOCATION '...'
TBLPROPERTIES(orc.compress="SNAPPY")
当我看到每一张table的表演时,我感到很迷茫。我运行的查询是:
SELECT * FROM orc_t WHERE date_format(st_time, 'yyyy-MM-dd') = '2017-05-20'
压缩数据需要2米45秒
按数据分类花了43秒
按数据排序43秒
似乎压缩数据花费的时间最长,而按数据分类的集群似乎比按数据排序的集群没有显著的性能。
我的5个数据节点是否有足够的读取能力,以至于解压实际上会降低性能?
还是我的样本数据不够大?
我错过什么了吗?
请任何Maven在上述问题上给我指点一下好吗?
1条答案
按热度按时间mzmfm0qo1#
为什么在执行示例查询时,多个小数据文件(大小约为256mb)与单个大数据文件(大小约为19gb+)相比没有显著的性能(select*from t where date_format(st_time,'yyyy-mm-dd')='2017-05-20';
您仍在扫描所有数据以查找数据中的单个值。因此,必须全部解压缩。您还选择了所有列,因此使用orc没有明显的好处。
多个小数据文件不应该比单个大数据文件有一些性能优势吗?
应该,但如果不是这样,则很可能初始输入文件能够适当地分块到mapreduce输入拆分中,并且磁盘io不是阻塞因素。
snappy或zlib压缩只是节省空间,而不是优化速度。
如果您想提高速度,可以根据您将经常使用的查询模式对数据进行分区