hadoop - 用于实时分析解决方案的 HBase 架构/ key

Question

我们正在考虑使用 HBase 进行实时分析。

在 HBase 之前，我们将在我们的日志文件上运行 Hadoop Map Reduce 作业并聚合数据，并将细粒度聚合结果存储在 HBase 中，以便对聚合数据进行实时分析和查询。因此 HBase 表将具有预先聚合的数据(按日​​期)。

我的问题是:如何最好地设计 HBase 数据库的架构和主键设计，以实现快速而灵活的查询。

例如，假设我们将以下行存储在数据库中:

timestamp, client_ip, url, referrer, useragent

假设我们的 map-reduce 作业产生三个不同的输出字段，我们希望将每个字段存储在一个单独的“表”(HBase 列族)中:

• 日期、操作系统、浏览器
• 日期、网址、推荐人
• 日期、网址、国家/地区

(我们的 map-reduce 作业从用户代理和 client_ip 数据中获取操作系统、浏览器和国家字段。)

我的问题是:我们如何构造 HBase 模式以允许对这些字段中的任何一个或组合进行快速、近乎实时和灵活的查找？例如，用户必须能够指定:

• operating_system by date(“这个日期范围内有多少 iPad 用户？”)
• url 按国家和日期(“上个月有多少用户从这个国家访问这个 url？”)

以及基本上任何其他自定义查询？

我们应该像这样使用键吗:

• date_os_browser
• date_url_referrer
• date_url_country

如果是这样，我们能否满足上面指定的那种查询？

Answer 1

是的，您已经掌握了要点。您的两个示例查询都按日期过滤，这是该域中的自然“主要”维度(事件报告)。

关于以日期开始 key 的常见注意事项是它会导致“热点”问题；该问题的本质是，时间上连续的日期范围也将是连续的服务器，因此如果您总是插入和查询“现在”(或“最近”)发生的数据，则一台服务器将承担所有负载而其他人则闲着。这听起来不像是插入时的大问题，因为您将专门批量加载，但它可能是读取时的问题；如果您的所有查询都转到您的 20 台服务器中的一台，则您的容量实际上只有 5%。

OpenTSDB 通过在日期前添加一个 3 字节的“指标 ID”来解决这个问题，并且可以很好地在整个集群中进行更新。如果您有类似的东西，并且您知道在大多数查询中总是(或通常)包含一个过滤器，那么您可以使用它。或者，您可以在日期的某些高阶部分(例如“月份”)的前面加上一个哈希值，这样至少您的读数会分散一些。