HBase 1.x 中的分配在操作中存在问题。不难看出原因。区域状态保存在 ZooKeeper 中 RPC 的另一端（终端状态 - 即 OPEN 或 CLOSED - 发布到 hbase：meta 表）。在 HBase-1.x.x 中，state 有多个编写器，Master 和 RegionServers 都能同时进行状态编辑（在 hbase：meta 表中并在 ZooKeeper 上输出）。如果时钟错误或观察者错过，则可以跳过或覆盖状态更改。锁定 HBase 实体 - 表，区域 - 并不全面，因此表操作 - 禁用/启用 - 可能与区域级操作发生冲突;拆分或合并。区域状态是分布式的，难以推理和测试。分配操作很慢，因为每个分配都涉及通过转换移动远程 znode。群集大小往往超过几十万个区域;除此之外，集群启动/停止需要数小时，并且容易出现损坏。
AMv2（AssignmentManager 版本 2）是 hbase-1.x AssignmentManager 的重构（ HBASE-14350 ），它基于 ProcedureV2（HBASE-12439）。 ProcedureV2（Pv2）， 是一个笨拙命名的系统，允许描述和运行多步状态机。它具有高效性并且可以将所有状态保存到可以在崩溃后恢复的商店。有关 ProcedureV2 系统的更多信息，请参见程序框架（Pv2）： HBASE-12439 的配套章节。
在 AMv2 中，所有赋值，崩溃处理，拆分和合并都重新编写为过程（v2）。 ZooKeeper 从混合中清除。和以前一样，最终的赋值状态被发布到 hbase：meta ，非主参与者读取（所有客户端）中间状态保存在本地 Pv2 基于 WAL 的“商店”但只有活跃的主人一个单一的作家，演变国家。 Master 的内存中集群映像是权限，如果不一致，RegionServers 将被强制遵守。 Pv2 添加了所有核心 HBase 实体的共享/独占锁定 - 名称空间，表和区域 - 以确保一个进程一次访问并防止操作争用资源（移动/拆分，禁用/分配等）。
在一个有目的的高性能状态机的 AM 上面的重做，所有操作都采用具有单个状态写入器的通用过程表单，仅将我们的 AM 移动到新的弹性和规模级别。