如何让Presto可以连接Hbase？文中含Hbase-Connect开发详解

一、hbase-connector平台组件研发——要实现的接口简介

Presto是由facebook开源的一款大数据交互式查询框架，除了facebook之外，在国内像京东、美团等公司都有广泛的使用。前段时间基于HBase开发了presto的connector，由于开发时苦于在网上找不到详细可用的资料，踟蹰前进的走了很多弯路，因此这里把开发过程中遇到的问题和心得整理出来，希望能为其他研发者提供参考，有不准确的地方也请各路大佬多多指教。

开发时因为presto文档的不完善，所以我们需要参考presto提供的例子，但是当我们打开例子时，看到要实现的接口如此众多往往会感到一丝无力。

但是实际上这些接口中大部分只需要参考官方例子适当做些修改即可。真正需要由我们写代码实现的只有如下几个接口：

1. ConnectorMetadata

组件元数据相关的操作，例如查询DB中有哪些表、表中有哪些字段、删除表等。

2. ConnectorSplitManager

根据用户的查询条件以及数据的存储特点，将计算任务切分成若干split由coordinator进行并发调度。类似于spark RDD接口中的getSplit方法。

3. RecordCursor

定义应该如何根据拿到的一个split到库中查询数据。像我们在split中封装了StartRowkey和EndRowkey，那么在RecordCursor中就要根据起止rowkey定义Scan对象，对HBase做scan操作了。

如果需要实现写入，则还需要实现这个接口：

4. ConnectorPageSink

定义如何写入数据。

接下来将详细介绍各个接口的实现。

二、hbase-connector平台组件研发——ConnectorMetadata

ConnectorMetadata接口是用来定义与组件相关的元数据操作的。对应到presto控制台中的命令为show schemas; show tables; desc tablexxxxx; drop table;等等。该接口的实现相对比较简单，只需要了解接口含义调用组件API做出实现即可。下面就对各个接口的功能及实现做简要说明。

listSchemaNames

该方法对应show schemas命令，用来展示Connector下有哪些DB。接口的实现也很简单，只需要调用HBase的API对DB做查询即可，如下：

getTableMetadata

该方法是一个比较重要的接口，他是用来返回指定HBase表的表结构的。因为HBase中列族固定而字段不固定，所以我们需要有一个存储机制来定义表结构。我们这里是将其存储在MySQL中，至于字段所在列族是根据hashcode取模获得，也可以一并存储在MySQL中。

listTables

该方法用来获取指定schema（或不指定）下都有哪些表。最终的实现为：

getColumnHandles

该方法与getTableMetadata作用一致，只不过返回值稍有不同。

listTableColumns

获取指定schema下所有表的元数据信息。

dropTable

用来drop表。实现如下：

beginInsert

如果需要实现写入操作，则要实现该方法以及finishInsert方法。该方法主要需要将表的字段和数据类型封装到实现了ConnectorInsertTableHandle接口的对象中。实现如下：

finishInsert

三、hbase-connector平台组件研发——ConnectorSplitManager

ConnectorSplitManager接口用来解析SQL中的查询条件，根据数据存储的特点将计算任务切分成多个split，交由coordinator调度到各个节点执行。该接口的作用类似于Spark RDD中的getSplit方法。

以下是该接口中唯一的待实现方法：

该方法需要返回一个FixedSplitSource对象，该对象中用List封装了我们人工切分出的若干个Split，Split对象中封装了所读数据的元数据信息，例如namespace名、表名、（HBase相关的StartRowKey、EndRowKey）、字段名和字段类型等等。Coordinator会将该接口返回的这些Split逐一分发给不同Worker，由其构建一个RecordCursor对象，再进行读取操作。

以下是一个简单的例子：

使用盐值切分Split

经过我们的测试得知，从HBase读取同样数量的数据，如果采用多线程并发的方式进行，性能会比单线程查询提升10~20倍，因此我们这里采用了在RowKey前加00~29两位盐值的方式，将一份数据分割成30个Split，保证了数据的并发性。

谓词下推

不做任何谓词下推的情况下，我们会将数据整个扫描出来，然后在Presto的Worker中将符合筛选条件的数据过滤出来。这样会导致Presto Worker需要从数据存储层（即RegionServer）读取大量不需要的数据。造成不必要的系统开销。

谓词下推是指将数据的筛选下推到数据库的存储层，只返回查询所需的数据，这样可以极大的减少返回的数据量。

使用谓词下推优化查询在HBase Connector中又分为以下两种情况：

特定表的特定字段作为谓词

举例来说，在我们的业务场景中，大部分的查询会发生在事件表event中，其中90%以上的查询都会根据事件类型xwhat和日期date做筛选，因此我们将event表的RowKey设计成如下形式。

{盐值}01{xwhat}01{date}…

在拼接起始RowKey时，判断如果查询的表是event，并且有根据xwhat和date字段做筛选，会将这两个字段拼接到起始RowKey中做Scan的起止RowKey。

其余谓词

RowKey中能够拼接的查询条件是有限的，而且字段的顺序也是固定的，当出现查询条件无法通过RowKey做范围Scan时，就需要我们结合HBase的Filter API在RegionServer上做数据筛选。关于这一部分的描述，将在RecordCursor接口中详细描述。

如何获取谓词列表

获取谓词列表conditions的代码：

findConditionFromConstraint方法的实现：

ConditionInfo的构造函数包含四个字段，字段名、查询条件的操作类型、字段的值、字段类型：

如何指定Split要分配到哪个Worker执行

这里解释一下为什么要为Split指定Worker运行。

这是因为在一次查询Job中，不同的子查询由于表数据量和查询条件不同，其数据量大小也不一致，而同一个子查询切分出的若干Split，其数据量是大致相等的。如果采用随机分配的方式，有可能造成多个大Split分配到某一个Worker上执行，造成单点压力过高影响整体运行效率。因此我们需要将每一组Split均分到所有的Worker上。

以下代码节选自Presto的SimpleNodeSelector类的computeAssignments方法，由这段代码可以看到，Coordinator会根据Split的isRemotelyAccessible属性判断要分配到指定Worker上执行，还是随机分配到某个Worker上执行。