论 ES 如何为 HBase 赋能

题图：By LOFTER

在正式进行讲述实现之前，我觉得有必要说一下出发点。团队期初数据都是基于 HBase+Phoenix 这样架构进行持久化。随着业务的复杂性增加，对部分表的查询效率和查询条件多样性，提出了更高的要求。 HBase+Phoenix 就会出现索引滥用。变更索引变的特别的频繁，同时一些数据客观的表，变更索引的代价是非常大的。

在海量数据的查询方面，Elasticsearch 具有出色的性能。如果 HBase+ES 是不是会是更好的解决方法呢？其实，这个时候会有一个思考点，Phoenix 是如何实现二级索引的？ HBase 协处理器（Coprocessor） 。

我的实现过程比较曲折，后文中也会提到，以帮助大家避免这些坑。在过程中，还尝试了另一种实现方案。存放两份数据，一份 HBase，一份 ES。该方案需要解决的一个问题—— 数据一致性问题 ，但这个问题协处理器可以解决。在此过程中，由于不当操作，把 HBase 服务宕机了，现象是  REGION SERVERS 无法启动，只有通过硬删的方式解决。

出于不死心，在经历重装 HBase 之后。内心又开始蠢蠢欲动。首先要声明一下，我们团队的环境是 HDP 3.0、HBase 2.0 ，网上很多教程都是基于  1.X ， 2.X 与 1.X 区别还是挺大的。 RegionObserver 从继承方式改为了面向接口编程。

协处理器

没有选择协处理情况下，HBase 实现 RDBMS SQL 方式查询数据，大量的 Filter 需要在客户端进行编码完成，代码的臃肿，可维护性大大降低。如果这部分操作在服务器端完成，是否是更好的选择呢。协处理就能帮助实现该设想，由于在服务端完成，可以集中式优化查询，降低请求的带宽和提高查询效率。当然，对 HBase 性能产生了一定影响。

类型

• Observer

• Endpoint

Observer

Observer 协处理器类似于 RDBMS 中的触发器，当事件触发的时候该类协处理器会被 Server 端调用。

Endpoint

Endpoint 协处理器类似传统数据库中的存储过程，完成一些聚合操作。

全文 阅读 ，欢迎点击 「阅读原文」