当智能机器人说”黑哥们语言是不通的“，作为开发者的你该如何应对？

作者：王运来，OceanBase 系统研发

有一个东南亚快递公司有大量的用户咨询与服务需求，为了降低人工成本，计划引入#智能机器人 以代替#人工客服。

随着近几年#AI大模型 技术突飞猛进的发展以及在各行各业的广泛应用，智能机器人产品也越来越成熟。只是目前市面上大部分智能机器人对中文和英文支持良好，能够较好地理解用户输入的信息，而对于#小语种 如泰语，支持效果并不理想。比如对于”欢迎参加北京城市交流会“，在中文语境中，智能机器人会将句子拆分为多个关键词进行分析（见图 1），而在泰语语境中，若没有合适的分词器功能，则很难有准确的语义表述效果。

图 1 中文语境中的关键词分析

比如我们要基于 #OceanBase 实现智能机器人，需要遵循图 2 的向量模型框架所示的流程。当 OceanBase 不支持泰语分词器时，我们需要联系 OceanBase 社区或在 GitHub 提需求，要求 OceanBase 尽快支持分词器功能。经过评估、研发、测试等开发流程，通常需要 1~3 个月才能实现，时间比较久。

图 2 向量模型框架

此时，作为开发者，你该怎么实现相关功能帮助业务解决客户需求呢？

使用插件来实现泰语的准确理解和表达就是一个不错的选择。目前已有企业基于 OceanBase 的分词插件实现了泰语智能机器人，可以大幅提升客服效率。本文为大家讲解：当需求比较急又要保证实现效果时，如何巧用插件快速响应功能需求。

如何开发自己的插件

基于 OceanBase 的灵活开发方式

#插件 是独立于 OBServer 的功能扩展模块，独立于 OceanBase 的动态库或者 Jar 包，或者其它语言的运行包，可单独发布、加载与升级，无需替换 OceanBase 核心二进制文件，其核心特征有三点。

1. 低耦合，开发周期短。

在传统模式下，任何新功能都必须合并进 OceanBase 内核源码，从需求评审到代码合入通常需要 1–3 个月。而插件与 OBServer 隔离，生命周期独立，可以独立发布、单独加载、独立升级，Bug 修复或功能增强仅需更新插件，不影响数据库内核。

2. 更开放，更低的开发门槛。

开发者遵循公开 API 即可实现任意功能，不受 OceanBase 内核编码规范的约束。而且开发者可以使用自己熟悉的#编程语言，比如 C/C++、Java、Python 等，自行决定运行环境。此外，开发者可自由选择 C++ 标准库、异常处理模型或其他第三方依赖，只需在插件边界做好异常捕获与资源管理，即可保证与 OceanBase 的稳定对接。

3. 自定义，代码自主可控。

个人开发者或企业开发者可按需定制私有功能，代码自己掌控，不受 OceanBase 木兰许可证的约束，可以商用，也可以贡献给 OceanBase 公共插件仓库。

总的来说，插件机制在功能、使用及维护层面均保持与 OceanBase 内核的最低耦合度，并具备灵活、安全且可持续演进的扩展方案。而其开放的特性，为个人开发者和企业提供了多样化选择。

插件的开发方式和使用方法

开发插件

为方便开发者上手，我们推出了开发套件，每种类型插件都有其开发样例代码。当大家安装开发套件后，可以直接复制样例代码到自己的开发目录中，在此基础上调整代码更加简便。插件动态库和内核代码在一起运行，没有沙箱机制，因此一定要经过充分的测试。如果插件运行不稳定，比如内存访问错误问题，运行时会导致整个 OceanBase 进程宕机，因此，建议大家根据自定义功能在生产发布前进行充分的测试。

欢迎大家把代码发布在 OceanBase 的 GitHub 仓库中（https://github.com/oceanbase/oceanbase），开放共享。目前已开放的插件 License 遵循 Apache 2.0 协议，可以进行商业的二次开发，也欢迎大家试用。

插件机制以高度开放的方式，支持在 OceanBase 内核之外独立扩展功能，提供 Plugins 和 OceanBase Kernel 接口（见图 3 ）。

图 3  插件接口

Plugins

• Plugin Interfaces：已知存在多种插件，包括外表插件、分词器插件，每种插件将对应一套已定义好的接口（Plugin Interfaces），插件实现这些接口即可完成与数据库的集成。

• Plugin API：同时插件也可能需要调用内核能力，例如使用内核的内存分配器等，为此 OceanBase 提供了内核接口即 Plugin API。

插件接口 Plugin Interfaces 和内核接口 Plugin API 都是插件和数据库内核之间的屏障，可以实现独立升级，并且在升级时尽量保持兼容。

OceanBase Kernel

• Plugin Interface Adaptor：插件适配器，用于适配不同类型的插件。以分词器为例，分词器接口 Plugin Interfaces 是以 C 语言实现的，OceanBase Kernel 内部其他的分词器如 IK 分词器或 N-gram 分词器是使用 OceanBase 的代码语言 C++ 实现的，如果需要把外部插件转换到内部进行调用，插件适配器可以屏蔽掉插件接口在升级以及兼容上的细节问题，使得内核和插件升级等的工作量尽量小。

• Plugin Manager：用于插件管理，管理某一类插件中具体包含哪些插件，例如分词器插件包括哪些插件，外表插件有哪些插件等。

使用插件

插件的用法比较简单，C/C++编写的插件编译后是一个动态库，Java 是一个 Jar 包。将动态库或 Jar 包放在指定目录或用户配置的目录，修改配置项后再重启（如果使用 OBD 部署，可以直接使用 OBD 重启集群命令 obd cluster restart + 集群名重启）即可使用插件。

现有插件：分词器和外表

OceanBase 目前有分词器插件和外表插件两种插件，都提供了对应的接口和样例代码，同时 OceanBase 也实现了对中文支持比较友好的结巴分词器插件。

分词器插件

OceanBase 的分词器插件具有三个主要特性：多语言、行业定制、系统兼容（见图 4）。

图 4 OceanBase 分词器插件的主要特性

多语言。OceanBase 分词器的功能接口都比较简单易用，可用场景丰富。例如前文提到的泰语分词器，对于在东南亚有业务的用户，使用泰语分词器可以更好地服务东南亚业务，同时用户也可以根据业务需求个性化扩展多语言分词器如韩语分词器。

行业定制。除了支持多语言分词器，基于不同行业的应用场景，例如医疗、法律、金融等包含特定词语的特定行业，也可以定制自己的分词器以及词库从而更精确地识别特定场景。

兼容多个系统。如果需要在一个系统中同时运行多种系统，如 Elasticsearch、Amazon OpenSearch Service 等，可以通过插件让它们表现得尽可能接近，例如在 Elasticsearch 中使用其他分词器，可以按照 Elasticsearch 分词器写一个插件在 OceanBase 中使用，在集成大系统时各产品组件之间会更加融洽。

结巴分词插件

图 5 是#结巴分词器 的使用示例，可以看到结巴分词器对中文的支持很友好，可以良好实现对中文和中英文结合的需求。结巴分词器代码请参考：https://github.com/oceanbase/oceanbase-plugins/tree/main/jieba_ftparser。

图 5 结巴分词器的使用示例

外表插件

在介绍外表插件前，先简单介绍下外表的概念，以便大家更好地理解。以 OceanBase 外表为例，可以通过 OceanBase 客户端直接连接 OceanBase 并创建一个外表，访问 #MySQL 或 ODPS 甚至是一些本地目录中的 CSV 文件。同时，外表也可以和 OceanBase 中的表进行关联查询，更便于数据分析。外表插件代码请参考：https://github.com/oceanbase/oceanbase-plugins/tree/main/external_table。

外表意味着用户无需将 CSV 或 MySQL 数据导入 OceanBase，就可以直接和 OceanBase 内部的表进行关联查询，实现了多源合一（见图 6 ）。当前支持主流的数据源如 HDFS、Kafka、MySQL 等，以及 CSV、ORC、Excel 等数据文件，大家可以根据需求灵活定制。对于数据文件类型，OceanBase 已经实现了 CSV、Parquet、ORC 等，如果有 Excel、Doc 等其他需求，可以通过接口定制，将插件装到 OceanBase 后即可使用。

图 6 外表的价值

此外，企业内部可能有一些和标准格式不同的数据格式，如果不使用插件方式，需要先转化数据格式，效率较低。在这种情况下，企业便可以直接开发插件并应用于内部，提高效率。

图 7 是 OceanBase 的外表产品图，支持通过 OceanBase 引擎直接访问不同格式、不同存储方式（如云上 S3 、OSS）的外部数据。当然这些数据格式不仅包含使用外表插件实现的功能，也包含了一些内嵌在 OceanBase 中的功能、数据湖功能等，都可以直接通过 OceanBase 进行查询。

图 7 OceanBase 外表产品图

如果大家有兴趣深入理解插件的实现过程，可以先了解外表 TableScan 的实现。如图 8 所示，TableScan 是表扫描的接口，针对不同类型的表需要实现不同的 AccessServce，其中： ObAccessServce 对应 OceanBase 内部表；ObVirtualDataAccessService 对应 OceanBase 内部的虚拟表；ObExternalTableAccessService 对应外部表。外部表的查询类 ExternalTableScan 可以根据不同数据类型创建出不同的行迭代器，如 MySQL 是基于 JdbcRowIterator 实现的，加载了 JDBC 驱动，同时对于 PG 以及支持 JDBC 驱动的数据库也可以轻松扩展。

图 8  TableScan 的实现

来吧，实现你的插件

基于上述插件体系的解读，相信已有功能需求的开发者已经了解到自己接下来该如何做。对于暂无功能需求的开发者，当前 OceanBase 已提供两类插件框架，但可选类型仍较为有限。我们欢迎并接纳大家的创意和需求，以丰富插件类型：无论是审计接口、认证接口，还是其他任何类型的插件设想，均可提出。

在插件开发过程中，如需调用内核功能、访问 OceanBase 的系统变量或实现可配置化支持，我们可以协同解决。除了目前 OceanBase 已支持的 C++ 及外表的 Java 语言外，如果对 Python、Rust 或其他语言有需求，也可以和社区联系，我们将共同评估并拓展多语言支持。

对  OceanBase 插件开发感兴趣的小伙伴欢迎扫码加入 OceanBase 插件开发者交流群，群内会不定时同步插件产品相关资讯。