针对 Web 分析的 Hadoop-Hive-HBase 建议

Question

我所在的团队很幸运，管理层认识到需要提高我们的技能和学习新技术。因此，每当我们在主要项目之间有一点停工时间时，我们都被鼓励利用这段时间来扩展我们的思维并学习新的东西。我们经常以团队的形式处理一个大型研究项目，以便每个人都从知识中受益。例如，我们构建了一个符合规范的 Kerberos 身份验证服务器来熟悉协议的来龙去脉。我们编写了自己的网络服务器来了解网络应用程序的有效设计策略。

最近，我们对 Map-Reduce 非常好奇，特别是 Hadoop 和各种支持组件（HBase、HDFS、Pig、Hive 等）。为了进一步了解它，我们想编写一个网络分析服务。它将使用 Javascript 页面标记来收集指标，并使用 Hadoop 和 something 通过 Web 界面提供分析和报告。

架构的非 Hadoop 方面很简单。 Java servlet 将解析来自 Javascript 标记的参数（很简单——我们是一家 Java 商店）。然后，servlet 将发送一条 JMS 消息进行异步处理（同样，很简单）。

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

就像我说的，我们是一支技术性很强的团队，并且喜欢学习新技术。不过，这与我们之前学到的任何东西都大不相同，所以我们想了解这里的“最佳实践”是什么。非常感谢您提供的任何建议或意见！

编辑：我想我会澄清一下我在寻找什么。我正在为这样的解决方案寻求有关架构和设计的建议。我们将在每月获得数百万页面浏览量的网站上收集 20-30 个不同的指标。这将是大量数据，我们希望能够尽可能接近实时地获取指标。我正在寻找关于这种解决方案架构的最佳实践和建议，因为我不希望我们自己想出一些非常糟糕的东西，这会让我们认为我们是“Hadoop 专家”，只是因为它有效。

Answer 1

正如您所提到的，Hive 的查询延迟很高。它可以指向 HBase（请参阅 https://cwiki.apache.org/Hive/hbaseintegration.html），但集成导致 HBase 的表被强制为大多数矩形、类似关系的模式，这对于 HBase 来说不是最佳的。另外，这样做的开销是非常昂贵的——在我的集群上，针对 hbase 的 hive 查询至少比针对普通 HDFS 文件慢一个数量级。

一个好的策略是将原始指标存储在 HBase 或普通 HDFS 中（如果这些指标来自日志文件，可能需要查看 Flume）并运行定期 MapReduce 作业（甚至每 5 分钟一次）以创建预聚合可以存储在可以通过 Hive 查询的普通矩形文件中的结果。当你只是读取一个文件并且 Hive 不需要做任何花哨的事情（例如排序、连接等）时，Hive 实际上是相当低的延迟——它不运行 MapReduce，它只是将文件的内容流式传输给你.

最后，另一种选择是使用类似Storm（在Hadoop上运行）之类的东西来实时收集和分析数据，并将结果存储在上面进行查询，或者将它们存储在HBase中通过自定义显示直接查询 HBase 的用户界面。