概述
Presto里面有个类似普通数据库存储过程的东西叫做 Procedure(https://prestosql.io/docs/current/sql/call.html), 它的主要作用是用来提供一下DDL或者管理性的工作，它的用法跟MySQL里面的存储过程类似，比如:
-- 调用一个两个参数的存储过程
CALL test(123, 'apple');
-- 支持named arguments
CALL test(
name => 'apple',
id => 123
);虽然名字叫Procedure，但是你无法通过Presto的CALL语法来调用底层RDBMS里面的存储过程，概念类似，但是不是一个层面的东西，Presto里面能CALL的Procedure是需要Connector注册的。
开发一个Procedure
我们来看一下一个Procedure包含哪些部分:
/** 属于哪个schema */
private final String schema;
/** 名字叫什么 */
private final String name;
/** 有哪些参数？每个参数的名称、类型是什么? */
private final List<Argument> arguments;
/** 由哪个方法实现? */
private final MethodHandle methodHandle;
...从上面Procedure的结构可以看出，真正要做的实现一个方法(MethodHandle)就好了，比如我们要drop一个hive partition，它大概的逻辑是这样的:
public void dropPartition(
ConnectorSession session,
String schema, String table,
List<Object> partitionColNames,
List<Object> partitionValues)
{
metastore.dropPartition(
schema, table,
partitionValues, false
);
}正式声明这个drop_partitionProcedure的代码是这样的:
new Procedure(
"system",
"drop_partition",
ImmutableList.of(
new Argument("schema", VARCHAR),
new Argument("table", VARCHAR),
new Argument(
"partitionColumnNames",
"array(varchar)"
),
new Argument(
"partitionValues",
"array(varchar)"
)
),
methodHandle(
DemoProcedure.class,
"dropPartition",
ConnectorSession.class,
String.class,
String.class,
List.class,
List.class
).bindTo(this)
);从上面两段代码我们可以很清楚的看出:
- 它的名字叫
drop_partition。 - 它有4个参数，前两个参数名字分别叫
schema和table，类型都是VARCHAR。 - 它的具体的逻辑是由
DemoProcedure里面的dropPartition来实现的(也就是上面第一段代码)。
细心的同学可能注意到了，这个 dropPartition 还有一个 ConnectorSession 类型的参数呀，怎么没有声明出来？没错，不过这个参数不用显式声明给Procedure的使用者，ConnectorSession里面包含调用这个Procedure时候的一些上下文信息，Presto在调用对应MethodHandle的时候发现这种类型的参数会自动传过来。
开发完成之后通过 com.facebook.presto.spi.connector.Connector#getProcedures 暴露出去就可以调用了。
Procedure的实际使用场景
前面也说过Procedure的使用场景是一些DDL以及管理性的工作，一个典型的例子就是处理Hive Connector里面 drop table/drop partition的工作，我们知道Hive是有自己的Hive Meta Store的，要实现drop partition，一个不经意的想法是直接利用HiveCli去Hive Meta Store上面去drop，但是这样会有问题, 原因在于 Presto 里面对于Hive Meta Store里面的元数据是有缓存的，直接操作Hive Meta Store会使得Presto里面的元数据缓存没有及时失效掉，导致用户通过Presto查询Hive数据得到错误的结果, 如下图:
这时候Procedure就可以派上用场了，利用我们前面介绍的drop_partition, 我们可以通过如下的命令去“彻底地”删除一个partition了:
CALL system.hive.drop_partition(
'db001', 'table001',
ARRAY['dt'], ARRAY['bar']
);让用户直接用这种语句去删除partition当然很傻，你可以稍微包装一下，用户写SQL: alter table db001.table001 drop partition(dt = 'bar'), 你背后自动调用 drop_partition 即可。
当然，通过Procedure来解决Presto Connector内部的缓存问题也不是理想的方案，但是是目前Presto框架下比较现实的方案。理想的方案应该让Presto通过SPI层面暴露出接口来做这种事情。
总结
今天介绍了Presto里面的Procedure, 可以用它来做一些DDL以及管理的事情，因为是Presto内置提供的机制，做起事情来比较“合规”，有需要的场景不妨试试。
