如何重新创建现有的 HBASE 表以添加加盐键？答案

【问题标题】：How do you recreate an existing HBASE table to add salted keys?如何重新创建现有的 HBASE 表以添加加盐键？
【发布时间】：2021-12-30 02:21:07
【问题描述】：

我有一个包含 100 万行的 HBASE 表，我们遇到了热点问题。

我想用加盐的行键重新创建这个表。

我尝试将“org.apache.hadoop.hbase.mapreduce.Import/CopyTable”添加到一个新的加盐表中，但它没有为行键添加加盐前缀。

我在迁移带有前缀的行时遇到的唯一解决方案是 Phoenix 查询： UPSERT INTO TABLE_SALTED SELECT * FROM TABLE

但是，这非常低效且耗时太长。

如何在停机时间最短的情况下对现有 HBASE/Phoenix 表进行加盐？

【问题讨论】：

【解决方案1】：

通常 Hbase 使用拆分来处理“热点”。

也就是说您可以手动拆分表格：

split '[table_to_split]', '[split point]'

这更有效，因为您使用的是 HBASE 附带的工具，并且不需要整个重写。它只会帮助您稍微推动针头，但有时这足以让您跛行。

您可以使用很多设置来帮助解决问题。查看 RegionSplitPolicy，看看是否可以在那里找到帮助。

如果您想查看really good article on splitting，请阅读此 cloudera 帖子。

我不确定您选择拆分的意图有多大，但您确实无法获得比选择可靠的预拆分点来处理您的数据更好的优化。（如果您正在腌制，很可能您已经在数据中发现了偏斜，即使选择拆分的合理意图也无法处理偏斜。好吧，除非您已经知道偏斜。）

【讨论】：

你知道，如果我是你，我可能会专门纠正我自己的 RegionSplitPolicy 来处理倾斜的数据。它将允许更好的逻辑来处理偏差。（您可以对所有非偏斜数据使用现有类，并对偏斜数据执行特殊操作）
感谢您的回复。我们一直在拆分表和移动区域（基于读取请求）以更好地平衡负载。我们遇到的热点问题，不一定是我们所在区域的大小造成的，而是一个区域的读取请求数造成的。我们正在经历区域之间的读取请求不平衡，因此一些小型区域的负载很重。
这是一个创可贴的解决方案，但它不会完全解决我们的解决方案，因为它会加盐并投入更多的 CPU。是的，不幸的是，我们刚刚在我们的桌子设计后发现了 loooong 歪斜.我们的表现在有大约 60GB 的数据。

【解决方案2】：

如果这个热点问题是由重复读取引起的，为什么不尝试增加file.block.cache.size & hbase_regionserver_heapsize。

'file.block.cache.size' - 用于缓存的堆部分。 hbase_regionserver_heapsize - 区域服务器堆的大小。

您可以只增加file.block.cache.size，但最终可能会给堆施加更多压力。

下一个明显的问题是多少？所有性能优化的答案都是一样的。让专家尝试计算一下，或者继续添加一点点，直到空间用完/看不到改进为止。

【讨论】：