Hadoop hbase跳过区域服务器直接从hfile读取行 我正试图将超过100亿条记录转储到hbase中，这将 平均每天增长1000万，然后尝试满桌 浏览记录。我知道对hdfs进行完全扫描将 要比hbase快 Hbase用于对不同的数据进行排序 在hdfs上。该应用程序正在使用spark构建 数据被批量加载到hbase上。由于各种2G限制，区域大小从3G的初始测试减少到1.2G（仍需要更详细的调查） 扫描缓存为1000，缓存块关闭 hbase的总大小在6TB范围内，可跨5个区域服务器（节点）生成数千个区域。（建议低至数百） spark作业基本上在每一行上运行，然后根据范围内的列计算某些内容 在hbase上使用spark，内部使用TableInputFormat，作业运行约7.5小时 为了绕过区域服务器，创建了一个快照，并改为使用TableSnapshotInputFormat。工作大约在5.5小时内完成

问题

当从hbase读入spark时，这些区域似乎决定了 火花分割，因此2G限制。这是否意味着区域规模需要较小

绕过区域服务器的TableSnapshotInputFormat和 直接从快照读取，还创建快照并按区域拆分 因此仍将陷入上述地区规模问题。它是 可以直接从hfiles读取键值，在这种情况下 分割大小由hdfs块大小决定。有没有 可以读取行的扫描仪或其他util的实现 直接从hfile（具体是从快照引用的hfile）

有没有其他的指标可以说明配置可能有助于提高性能？例如hdfs块大小等？主要用例是大部分的全表扫描

---

事实证明，这其实相当快。性能分析表明，问题在于ip地址的对象表示之一，即InetAddress解析ip地址花费了大量时间。我们决定使用原始字节提取我们需要的任何内容。这本身就使得这项工作在大约2.5小时内完成。 将该问题建模为Map Reduce问题，并在MR2上运行相同的上述更改，结果表明该问题可在1小时20分钟内完成。

---

迭代性质和较小的内存占用帮助MR2实现了更多的并行性，因此速度更快。

这里有很多信息，但这无助于解释为什么这项工作需要7.5小时。如果我理解正确，您的作业输入是超过5000个区域的10B记录，这将在5个节点上生成5000个映射器，因此每台机器约1000个映射器，每台映射器2M行。如果一切都是正确的，你的平均映射时间是多少？我使用spark。使用TableInputFormat的平均任务时间约为4.0分钟，使用TableSnapshotInputFormat的平均任务时间约为3.7分钟。