Hbase 方案设计 - 最佳实践

Question

我最近从 rdbms 切换到 Hbase 来处理数百万条记录。但是作为一个新手，我不确定设计 Hbase 方案的有效方法是什么。实际上，场景是我有文本文件，其中包含我必须读取并存储到 Hbase 中的成百上千和数百万条记录。因此，有两组文本文件（RawData 文件、标签文件）彼此链接，因为它们属于同一个用户，对于这些文件，我制作了两个单独的表（RawData 和标签）并且我将它们的信息存储在那里.所以 RawData 文件和 RawData 表看起来像这样：

所以你可以在我的 RawData 表中看到我有行键，它实际上是文本文件 (01-01-All-Data.txt) 的文件名，其中包含文本文件每行的行号。列族只是随机的“r”，列限定符是文本文件的列，值是列的值。这就是我在表中插入记录的方式，并且我有第三个表（MapFile），其中我将文本文件的名称存储为行键用户 ID 作为列限定符，并将文本文件的记录总数存储为值，如下所示：

            01-01-All-Data.txt       column=m:1, timestamp=1375189274467, value=146209  

我将使用 Mapfile 表来逐行读取 RawData 表。

您对这种 Hbase Schema 有什么建议？这是正确的方法吗？还是在 Hbase 概念中没有意义？

此外，值得一提的是，在 Hbase 中插入 146207 行的 21 mbs 文件大约需要 3 分钟。

请指教。

谢谢

Answer 1

虽然我没有发现您当前的架构有什么问题，但只有在分析您的用例和频繁访问模式之后才能确定它是否合适。恕我直言，正确并不总是合适的。由于我对这一切一无所知，我的建议可能听起来不正确。请让我知道是否是这种情况。我会相应地更新答案。我们来了，

只有一个包含 3 个列族的表是否有意义（牢记您的数据和访问模式）：

• RD - 用于包含该文件所有列的 RawData 文件
• LF - 用于包含该文件所有列的标签文件，并且
• MF - 对于 MapFile，其中一列包含您的文本文件的记录数。

使用用户 ID 作为行键。它将是独一无二的，看起来不会很冗长。通过这种设计，您可以在获取数据时绕过从一个表分流到另一个表的开销。

还有一些建议：

• 如果用户 ID 单调增加，则散列您的行键，这样您就不会受到 RegionServer 热点的影响。
• 您还可以创建预拆分表以获得更好的分布。
• 尽可能缩短列名。
• 尽量减少版本数量。

此外，值得一提的是，在 Hbase 中插入 146207 行的 21 mbs 文件大约需要 3 分钟。

您是如何插入数据的？MapReduce 还是普通的 Java+HBAse API？您的集群大小是多少？配置和规格？

您可能会发现这些链接很有用：

• Beautiful vid by Lars.
• Official documentation on schema design.
• Schema design presentation form HBaseCon-2012

HTH