Question

我有一个月的日志文件（~60gb未压缩），我需要在这些日志文件上运行大约10万个查询。使用gzip压缩每个日志文件大约68MB。

出于测试目的，我已经在我们的测试服务器（8core，32gb ram）上以伪分布式模式安装了Hadoop和Hive，并且我已经在一个hive表中加载了日志文件，看起来有点像这样：

日期，时间，用户ID，频道

我有一个大约1000个时间帧的文件，如下所示：

日期，时间开始，时间结束

01_01_2015,08：05：31,08：09：54

01_01_2015,08：54：10,08：54：30

...

02_01_2015,08：15：14,18：20：48

...

[edit：]一天的时间范围不重叠，精确到秒。它们可以短至10秒，长达几分钟。

我想知道在这些确切的时间范围内，我的网站上有多少唯一身份用户。每个时间框架都是独一无二的。

我的问题是处理此类任务的最有效时间是什么？在Hive中运行一千个不同的查询似乎是一种可怕的方式。

替代方案是将50-100个查询捆绑成一个，以避免创建工作等过多的开销，这会更好吗？查询在Hive中的持续时间是否有限制？

虽然我对如何使用Hadoop感兴趣，但我也开放其他建议（特别是考虑到这是以伪分布式运行）。

Answer 1

时间框架是否重叠？如果是这样，1分钟的日志块是一种合理的方法来分块数据吗？那就是每分钟有几十行或几百行，所有时间帧都有一分钟的分辨率？如果不是一分钟，也许一个小时？

总结每个1分钟块中的数据;将结果放在另一个数据库表中。然后针对该表编写查询。

这可能是MySQL的方法，可能是在一台机器上。

编辑（根据OP的编辑显示范围不重叠且不方便划分）：

鉴于范围不重叠，您应该一次性完成工作。

我会在执行所有工作的Perl / PHP程序和使用

的1000 sql调用之间进行选择

INSERT INTO SummaryTable
SELECT MIN(ts), MAX(ts), SUM(...), COUNT(...)
    FROM ... 
    WHERE ts BETWEEN...

（这假定是一个关于ts的索引。）这足够简单且足够快 - 它的运行速度只比读取那么多磁盘的时间稍慢。

但是......为什么甚至将原始数据放入数据库表？这是很多工作，也许没有长期利益。所以，我回来写一个Perl脚本来读取日志文件，按照它去做。