如何通过 openLooKeng 更高效访问 HBase？

1. HBase Connector 介绍

数据虚拟化引擎 openLooKeng 中的 HBase Connector 支持访问 Apache HBase 集群并进行查询和创建表的操作。用户可以在 openLooKeng 中创建表，并映射到 HBase Cluster 中已有的表，支持 INSERT、SELECT 和 DELETE 操作。

—— 一个简单的全表扫描的 sql 的执行，会经历哪些阶段：

首先该 sql 将要访问的数据，一定是属于某一个数据源的，那么一个通用的 Connector 需要做哪些事情。Sql 的解析是由 openLooKeng 本身完成的；接下来是生成执行计划，在这个阶段需要验证用户所访问的表的合法性，那么 Connector 则需要提供该功能（即元数据管理）；然后就到了任务调度阶段，openLooKeng 会将一个大任务划分为多个小任务，由多个 worker 分工完成，那么 Connector 会提供 split 分割的接口，即 SplitManager；Worker 在收到任务之后，以分片为最小单元进行数据加载，此时需要用到 Connector 中的 PageSource/PageSink 来完成数据的读写操作。所以在 HBase Connector 中我们实现了这些关键模块（SplitManager，HBaseClient，HetuMetastore）。

HBase Cluster 的主要组件：ZooKeeper 用来记录一些元数据信息，Master 用来处理用户发过来的请求，RegionServer 用来执行用户请求并管理 Region 的分裂和合并。

——HBase Connector 数据流：

• 建表（HBase Connector 支持两种模式的建表）。 ① 直接关联远端 HBase 数据源上的表（即外表的形式） ② 在 openLooKeng 上创建一张 HBase 数据源不存在的新表

• 用户发送一条查询 HBase 数据的 sql 请求给 Coordinator

• Coordinator 收到请求后，从 hetuMetastore 中获取 table 信息，以验证用户 sql 所访问表和数据列的合法性

• Coordinator 通过 SplitManager 获取所有的分片信息，并生成执行计划和任务，将任务下发到各个 Worker 上

• 每个 Worker 会处理一部分的数据。Worker 通过 HBase Client 来实现对 HBase Cluster 的数据读写交互

——使用 openLooKeng 访问 HBase 集群

配置说明：使用 openLooKeng 来访问 HBase 集群，我们需要配置 HBase 的相关信息在 Catalog 中，主要是 ZooKeeper 的信息。创建并编辑 etc/catalog/hbase.properties： 具体操作可参考：https://openlookeng.io/zh-cn/docs/docs/connector/hbase.html

HBase Connector 所支持的语法： HBase Connector 基本上支持所有的 SQL 语句，包括创建、查询、删除模式，添加、删除、修改表，插入数据，删除行等。以下是一些示例：

算子下推支持：HBase 连接器支持下推大部分运算符，如基于 RowKey 的点查询、基于 RowKey 的范围查询等。此外，还支持这些谓词条件以进行下推：=、>=、>、<、<=、!=、in、not in、between and。

2.HBase Connector 性能分析

openLooKeng1.1.0 版本并未对 HBase Connector 做过全方面的性能优化。 我们先了解一下 HBase 读取数据的机制。实际上，HBase Client 首先会从 ZooKeeper 中获取 HBase 表元数据所在的 RegionServer，然后根据 RowKey，找到数据所在的 RegionServer，然后发送读数据请求给 RegionServer。

每个 RegionServer 由多个 Region 构成，Region 是存储数据的最小单元。每个 Region 里面会维护一定范围的 key 值。

那么先介绍一下我们之前切片的做法：HBase Client 调用 API 获取数据所在的 region 信息。每个 region 的 start key 和 end key 组成一个 split。Split 的个数即数据所分布在的 region 的个数。

这种情况下，我们没有利用到读取 Region 的并发能力。我们知道，分片数决定了任务的并发度，影响性能。所以从这个角度出发，需要提高数据读取的并发度。那么在 openLooKeng 1.2.0 版本中，我们引入了一种新的数据切片方式以及支持访问快照的模式。

3.HBase Connector 性能优化

——优化点 1（新的分片规则）

• 建表时指定分片切割规则，提升单表全表扫描性能 create table xxx() with(split_by_char='0~9,a~z,A~Z') split_by_char 表示 rowKey 的第一个字符的范围，为分片切割的依据。 若 RowKey 的第一个字符由数字构成，则可以根据不同的数字进行分片切割，提高查询并发度。不同类型的符号用逗号隔开。如果设置不当，会导致查询数据结果不完整，请根据 RowKey 的实际情况进行配置。无特殊要求时，无需修改。默认情况已包含所有的数字和字母。若 rowKey 为汉字，则 create table xxx() with(split_by_char='一~锯')；另外，建表时会根据 split_by_char 指定预分区的 splitKey，尽量将数据分散到各个 region，那样在进行 HBase 读写时，对性能会有很好的改善。

• HBase Server 支持使用 startRow 和 endRow 来获取 Scanner 比如，splitByChar 为 0~2，我们会生成一些键值对。键值对的个数将会小于一个常量（如 20），所以需要首先计算每个键值对的 gap 大小。 (startKey = 0, endKey = 0|),(startKey = 1, endKey = 1|),(startKey = 2, endKey = 2|) splitByChar 为 0~9, a~z (startKey = 0, endKey = 1|),(startKey = 2, endKey = 3|)……(startKey = y, endKey = z|)

——优化点 2（支持访问快照模式）

• 可配置 ClientSide 模式来读取数据,提升多并发查询性能 ClientSide 的工作机制是在 HDFS 上创建 HBase 表的 Snapshot，记录各个数据文件所在的 Region 地址，在读取数据时，不需要经过 HBase Region Server，而是直接访问 Region，这样可以在高并发下降低 Region Server 的压力。

• ——性能测试 HBase 3 节点，openLooKeng 3 节点，e_mp_day_read_52：10138492 行，64 列

HBase Shell 对于操作千万行的表做 count 操作时，性能会很差；HBase 也有提供计算行数的 jar 包，这里没有进行测试。因为 openLooKeng 1.2.0 优化了 count 操作，只会去加载第一列，所以 sql1 的情况下，Normal Scan 和 ClientSide 方式性能差异不大。Sql2 会获取多列数据，当 HBase Server 成为瓶颈时，ClientSide 的优势就凸显出来了。

当然，HBase 的应用场景并非是全表扫描，而应该是根据 RowKey 进行点查询的场景。该场景下，openLooKeng HBase Connector 会直接根据 RowKey 调用对应的 API，高效获取数据即可。openLooKeng 1.2.0 在具备访问 HBase 基本功能的前提下，优化了对于全表扫描的场景下的性能，openLooKeng 1.2.0 HBase Connector 的全表扫描相比 1.1.0 版本，性能提升多倍。

如果您还想了解更多，欢迎关注 4 月 29 日晚 8:00 B 站直播活动，与老师们互动探讨相关的技术问题。

本文作者 | 涂盛霞

授权转载 | 请联系 openLooKeng 小助手 （微信号：openLooKengoss）