针对Amazon EMR/Hive处理S3中大量文件的性能调整

我正尝试将Amazon EMR与Hive配合使用来处理由广告跟踪服务器生成的大量日志文件。表现远比我预想的要差，我希望有人能给我提供改进的指针。针对Amazon EMR/Hive处理S3中大量文件的性能调整

跟踪服务器每隔几分钟就会将日志文件上传到按日分区的S3文件夹（例如，“2014-05-20”）。每天上传大约3000个文件，每个文件大约20K。

使用Hive，我成功创建了引用S3中数据的外部表，并为30天的日志文件设置了分区。我已经验证了分区工作正常，并且简单的查询（例如，“SELECT * FROM click WHERE dt ='2014-05-19'LIMIT 10）能正常工作并快速响应。

我正在将数据加载到。临时HDFS表的后续查询要做到这一点，我运行一个HQL作业基本上是这样（注意click是S3的外部表）：

CREATE TABLE tmp_click (
    clickId string, 
    -- ... 
    dt string 
) 
STORED AS SEQUENCEFILE; 

INSERT OVERWRITE TABLE tmp_click 
    SELECT 
     clickId, 
      -- ... 
      k.dt 
    FROM 
     click k 
    WHERE 
     k.dt >= '${START_DAY}' AND 
     k.dt <= '${END_DAY}' 
;

此操作需要一个小时的向上与25个XLARGE实例作为核心/任务节点，因为这里基本上没有进行任何处理 - 只是复制数据，对吧？ - 我觉得必须有一些我错过的东西。任何人都可以给我任何提示调查？

我认为也许大量的文件（〜3,000天），或日志文件的压缩（gz）可能是问题，但我没有能力控制输入。

来源

2014-05-20 Myk Willis

您的查询不得不处理S3N协议，列出S3中的文件并处理压缩。尝试使用s3distcp将文件从S3更快地复制到HDFS，然后使用复制的文件创建表。

来源

2014-05-21 08:37:37 SNeumann

针对Amazon EMR/Hive处理S3中大量文件的性能调整

回答

相关问题