SPI Overview

When you implement a new openLooKeng plugin, you implement interfaces and override methods defined by the SPI. Plugins can provide additional Connectors, Types, Functions and System Access Control. In particular, connectors are the source of all data for queries in openLooKeng: they back each catalog available to openLooKeng.


The SPI source can be found in the presto-spi directory in the root of the openLooKeng source tree.

Plugin Metadata

Each plugin identifies an entry point: an implementation of the Plugininterface. This class name is provided to openLooKeng via the standard Java ServiceLoader interface: the classpath contains a resource file named io.prestosql.spi.Plugin in the META-INF/services directory. The content of this file is a single line listing the name of the plugin class:


For a built-in plugin that is included in the openLooKeng source code, this resource file is created whenever the pom.xml file of a plugin contains the following line:



The Plugin interface is a good starting place for developers looking to understand the openLooKeng SPI. It contains access methods to retrieve various classes that a Plugin can provide. For example, the getConnectorFactories() method is a top-level function that openLooKeng calls to retrieve a ConnectorFactory when openLooKeng is ready to create an instance of a connector to back a catalog. There are similar methods for Type, ParametricType, Function, SystemAccessControl, and EventListenerFactory objects.

Building Plugins via Maven

Plugins depend on the SPI from openLooKeng:


The plugin uses the Maven provided scope because openLooKeng provides the classes from the SPI at runtime and thus the plugin should not include them in the plugin assembly.

There are a few other dependencies that are provided by openLooKeng, including Slice and Jackson annotations. In particular, Jackson is used for serializing connector handles and thus plugins must use the annotations version provided by openLooKeng.

All other dependencies are based on what the plugin needs for its own implementation. Plugins are loaded in a separate class loader to provide isolation and to allow plugins to use a different version of a library that openLooKeng uses internally.

For an example pom.xml file, see the example HTTP connector in the presto-example-http directory in the root of the openLooKeng source tree.

Deploying a Custom Plugin

In order to add a custom plugin to a openLooKeng installation, create a directory for that plugin in the openLooKeng plugin directory and add all the necessary jars for the plugin to that directory. For example, for a plugin called my-functions, you would create a directory my-functions in the openLooKeng plugin directory and add the relevant jars to that directory.

By default, the plugin directory is the plugin directory relative to the directory in which openLooKeng is installed, but it is configurable using the configuration variable catalog.config-dir. In order for openLooKeng to pick up the new plugin, you must restart openLooKeng.

Plugins must be installed on all nodes in the openLooKeng cluster (coordinator and workers).






● 拼写,格式,无效链接等错误;

● 技术原理、功能、规格等描述和软件不一致,存在错误;

● 原理图、架构图等存在错误;

● 版本号不匹配:文档版本或内容描述和实际软件不一致;

● 对重要数据或系统存在风险的操作,缺少安全提示;

● 排版不美观,影响阅读;


● 描述存在歧义;

● 图形、表格、文字等晦涩难懂;

● 逻辑不清晰,该分类、分项、分步骤的没有给出;


● 很难通过搜索引擎,openLooKeng官网,相关博客找到所需内容;


● 命令、命令参数等错误;

● 命令无法执行或无法完成对应功能;


● 关键步骤错误或缺失,无法指导用户完成任务,比如安装、配置、部署等;

● 逻辑不清晰,该分类、分项、分步骤的没有给出

● 图形、表格、文字等晦涩难懂

● 缺少必要的前提条件、注意事项等;

● 描述存在歧义