我工作的团队很幸运,能够拥有能够认识到需要增强我们的技能和学习新技术的管理层。因此,每当在主要项目之间有短暂的停机时间时,我们都被鼓励利用这段时间来拓宽思路,学习新知识。我们通常以团队的形式进行大型研究项目,以便每个人都从知识中受益。例如,我们构建了一个符合规范的Kerberos身份验证服务器,以熟悉协议(protocol)的来龙去脉。我们编写了自己的Web服务器,以了解网络应用程序的有效设计策略。

最近,我们对Map-Reduce非常好奇,特别是Hadoop和各种支持组件(HBase,HDFS,Pig,Hive等)。要了解更多信息,我们想编写一个网络分析服务。它将使用Javascript页面标记来收集指标,并使用Hadoop以及通过网络界面提供分析和报告的内容。

该架构的非Hadoop方面很容易。 Java servlet将解析Javascript标记中的参数(很容易-我们是一家Java商店)。然后,该servlet将发出JMS消息以进行异步处理(再次,很容易)。

我的问题是...接下来呢?我们已经对Hive之类的东西进行了研究,这听起来非常适合查询数据存储中正在寻找的各种指标。但是,这是高延迟。我们很幸运能够将其投放到一个每月获得数百万点击的网站上。我们真的很想使用我们的分析工具的网络界面来获得相对快速的指标。延迟不是我们的 friend 。那么,实现此目标的最佳方法是什么?是将查询作为计划的作业运行,然后将结果存储在较低延迟的地方(PostgreSQL等),然后从那里检索它们吗?如果是这样,侦听JMS消息的组件应该在哪里存储数据? Hive可以直接从HBase获取其数据吗?我们是否应该将其存储在HDFS中并在Hive中读取?

就像我说的,我们是一支技术含量很高的团队,热爱学习新技术。但是,这与我们以前学到的方法大不相同,因此我们希望对这里的“最佳实践”有所了解。您可以给出的任何建议或意见,我们将不胜感激!

编辑:我以为我要寻找的内容会有所说明。我正在寻求有关此类解决方案的体系结构和设计方面的建议。我们将在一个每月获得数百万次页面浏览的网站上收集20-30种不同的指标。这将是大量数据,我们希望能够尽可能接近实时地获取指标。我正在寻找有关这种解决方案的架构的最佳实践和建议,因为我不希望我们自己提出非常糟糕的事情,而使我们以为我们是“Hadoop专家”,因为有用。

最佳答案

正如您提到的,Hive对查询的延迟很高。可以指向HBase(请参阅https://cwiki.apache.org/Hive/hbaseintegration.html),但是集成会导致HBase的表被强制转换为对HBase而言并非最佳的,大多数为矩形​​,类似关系的模式。另外,在我的集群上,对hbase的查询比对普通HDFS文件的查询要慢至少一个数量级。

一种好的策略是将原始指标存储在HBase或纯HDFS中(如果这些指标来自日志文件,则可能要查看Flume)并运行定期的MapReduce作业(甚至每5分钟一次)以创建预先汇总的结果,可以存储在简单的矩形文件中,您可以通过Hive查询。当您仅读取文件而Hive不必做任何花哨的事情(例如排序,联接等)时,Hive实际上的延迟就相当低-它不运行MapReduce,它只是将文件内容流式传输给您。

最后,另一种选择是使用诸如Storm(在Hadoop上运行)之类的工具实时收集和分析数据,并存储结果以进行上述查询,或将其存储在HBase中以通过查询HBase的自定义用户界面显示直。

09-11 02:15
查看更多