运行一百万次扫描的 hbase mapreduce 作业是不是有意义？

Posted 2023-04-17

【中文标题】运行一百万次扫描的 hbase mapreduce 作业是不是有意义？

【英文标题】：Does it make sense to run an hbase mapreduce job with a million Scans?运行一百万次扫描的 hbase mapreduce 作业是否有意义？

【发布时间】：2014-02-11 21:56:29

【问题描述】：

我在 hbase 中有一个数据集，它足够大，需要几个小时才能在整个数据集上运行 mapreduce 作业。我希望能够使用预先计算的索引来分解数据：每天一次映射整个数据集并将其分解为多个索引：

所有用户的 1% 样本 参与特定 A/B 实验的所有用户 每晚预发布频道的所有用户。 具有特定插件（或我们本周感兴趣的任何标准）的所有用户

我的想法是只存储相关记录的行 ID 列表，然后人们可以只对这些行执行少量 mapreduce 工作。但是 1% 的样本仍然是 100 万行数据，我不确定如何在一百万行的列表上构建 mapreduce 作业。

如果将有一百万个不同的 Scan 对象构成查询，那么使用 initTableMapperJob(List scans) 创建表映射器作业是否有意义？还有其他方法可以做到这一点，以便我仍然可以有效地将计算和 I/O 外包给 hbase 集群吗？

【参考方案1】：

不要进行一百万次扫描。如果您有一百万个不连续的 id，您可以使用自定义输入格式在 id 列表上运行 map/reduce 作业，以便将列表划分为合理数量的分区（我猜是您的数量的 4 倍） m/r 插槽，但该数字不是基于任何东西）。这会给你一百万次获取操作，这可能比一百万次扫描要好。

如果你有幸拥有更合理数量的连续范围，那么扫描会比直接获取更好

【讨论】：

David，这是个好建议，我有一个后续问题：我认为 hbase mapreduce 的好处之一是地图作业将在与数据存储在 hbase/ 中的数据相同的节点上运行Hadoop。这是真的？有没有办法对我的输入进行分区，这样它仍然是正确的并最小化跨节点 I/O？

当然。它比使用 TableInputFormat 的标准 M/R 作业更简单，因为您必须自己以自定义输入格式设置节点关联。好消息是 TableInputFormat 是开源的，你应该能够从那里窃取大部分逻辑