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 - 对于原始数据文件，它将包含此文件的所有列
• LF - 对于带有此文件所有列的标签文件，以及
• MF - 对于具有一列保存文本文件记录数的 MapFile。

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

还有一些建议：

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

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

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

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

• 拉斯的美丽视频。
• 关于模式设计的官方文档。
• HBaseCon-2012 架构设计演示表格

HTH