DBeaver 技术架构解析：OSGi 插件体系、100+ 数据库驱动与 AI 集成的实现方式

DBeaver 是一款免费、跨平台的通用数据库工具与 SQL 客户端，同时面向开发者、SQL 程序员、DBA 和数据分析人员。本篇基于仓库根目录的 README.md 并结合开源源码，系统讲解 DBeaver 的安装运行方式、OSGi + Eclipse RCP 插件架构、100+ 数据库驱动的插件化组织方式、AI 集成的上下文机制，以及从源码构建、运行测试的完整链路，读完后可建立对 DBeaver 整体技术栈与工程结构的完整认知。

一、DBeaver 是什么：功能定位与核心特性

README 将 DBeaver 定义为 "Free multi-platform database tool for developers, SQL programmers, database administrators and analysts"（免费多平台数据库工具）。其核心特性可归纳为四点：

• 功能面广：包含模式编辑器（schema editor）、SQL 编辑器、数据编辑器、AI 聊天、ER 图、数据导入/导出/迁移、SQL 执行计划、数据库管理工具、数据库仪表盘、空间数据查看器、代理与 SSH 隧道、自定义数据库驱动编辑器等；
• 开箱即用的驱动覆盖：内置 100 余个数据库驱动（见下文支持的数据库清单）；
• 通用 JDBC/ODBC 兼容：任何拥有 JDBC 或 ODBC 驱动的数据库均可接入，实际上覆盖几乎所有现存数据库；
• AI 工具集成：将 LLM 能力融入数据操作、SQL 编写与数据库结构分析的日常流程。

DBeaver 采用 Apache 2.0 协议开源（仓库根目录 LICENSE.md）。除社区版外，官方还有商业化版本（PRO），二者共享同一套模型层代码——这一点在 README 的 Architecture 一节被明确强调。

二、安装、运行与 JDK 要求

README 给出的运行方式非常直接：

• 图形安装：运行安装包后点击应用图标即可；
• 命令行运行：解压发行包后，直接执行目录下的 dbeaver 脚本；
• 获取渠道：从官方网站或 GitHub Releases 下载预构建二进制，另有每日发布的 Early Access 版本。

JDK 方面有两个关键事实，读者使用时需注意区分：

1. 发行版自带 JRE：README 说明 "DBeaver needs Java to run"，所有 DBeaver 发行包均内置 OpenJDK 25 JRE；若需更换 JDK 版本，只需替换安装目录中的 jre 目录即可；
2. 源码构建目标为 Java 21：从仓库 AGENTS.md 与核心插件清单 plugins/org.jkiss.dbeaver.core/META-INF/MANIFEST.MF（Bundle-RequiredExecutionEnvironment: JavaSE-21）可以确认，源码构建的目标平台是 JavaSE-21，且要求不使用 preview 特性。

也就是说，"发行包内置 JRE" 与 "源码编译要求 Java 21" 是两套独立的前提，部署时按发行包说明操作，构建时则需准备 Java 21 环境。

三、整体架构：OSGi + Eclipse RCP + JDBC

这是 README "Architecture" 一节的核心，也是理解整个代码库的钥匙。原文档给出五条架构描述，这里逐条展开并对照源码印证。

3.1 技术栈组合

README 明确指出：

• DBeaver 主体用 Java 编写，同时使用一组操作系统相关的原生组件负责桌面 UI、高性能数据库驱动和网络能力；
• OSGi 平台负责插件与依赖管理，社区版由 130+ 个插件组成；
• Eclipse RCP（富客户端平台）负责构建桌面 UI；
• JDBC 作为基础的数据库连接 API；
• JSQLParser 与 Antlr4 用于 SQL 语法与语义解析；
• 网络与扩展功能依赖一批开源库：SSHJ、Apache POI、JFreeChart、JTS、Apache JEXL 等。

在仓库中可以直接验证这些描述：

架构声明	仓库中的印证
OSGi 插件 + 依赖管理	plugins 目录下共 152 个插件（bundle），features 目录下 19 个 feature 描述符
Eclipse RCP（e4）UI	plugins/org.jkiss.dbeaver.core/META-INF/MANIFEST.MF 中 Require-Bundle 依赖 org.eclipse.e4.ui.workbench、org.eclipse.e4.ui.css.swt 等一系列 e4 包
SQL 解析（ANTLR4 语法）	plugins/org.jkiss.dbeaver.model.lsm 包含 .g4 语法文件；grammar/*.g4 也散见于 ClickHouse、Databricks 等驱动插件
SSH 隧道	plugins/org.jkiss.dbeaver.net.ssh 为抽象层，org.jkiss.dbeaver.net.ssh.jsch 与 org.jkiss.dbeaver.net.ssh.sshj 分别提供两种 SSH 实现
GIS / 空间数据	plugins/org.jkiss.dbeaver.data.gis 与 plugins/org.jkiss.dbeaver.data.gis.view
数据导入/导出/迁移	plugins/org.jkiss.dbeaver.data.transfer 及其 UI 模块
图表（JFreeChart 能力）	plugins/org.jkiss.dbeaver.ui.charts

3.2 模型层与 UI 层分离

README 强调了一条重要的设计决策：

"We separate model plugins from desktop UI plugins. This allows us to use the same set of 'back-end' plugins in both DBeaver and CloudBeaver."

即模型插件（"后端"）与桌面 UI 插件严格分离，同一套模型层插件被 DBeaver 桌面版和 Web 版 CloudBeaver 共同复用。仓库结构是这条原则最直观的证据：几乎每个功能都有成对出现的 xxx 与 xxx.ui 两个 bundle，例如：

• 驱动侧：org.jkiss.dbeaver.ext.mysql / org.jkiss.dbeaver.ext.mysql.ui
• 功能侧：org.jkiss.dbeaver.data.transfer / org.jkiss.dbeaver.data.transfer.ui、org.jkiss.dbeaver.debug.core / org.jkiss.dbeaver.debug.ui
• AI 侧：plugins/org.jkiss.dbeaver.model.ai（约 200 个 Java 文件的模型层）/ plugins/org.jkiss.dbeaver.ui.ai（聊天视图 UI）

AGENTS-Architecture.md 进一步规定了这条边界：模型插件禁止依赖 SWT、JFace 等任何 UI 包；也不允许在 UI 模块中直接执行 SQL 等模型层操作，必须通过模型层的抽象接口调用。同一文件还给出了 DBeaver 类命名的前缀约定，帮助读者快速定位源码：

• DBP*：平台级能力（如 DBPDataSource）；
• DBS*：数据库结构/元数据对象（如 DBSTable、DBSSchema）；
• DBC*：连接与会话（如 DBCSession）；
• DBD*：数据值与格式化（如 DBDValueHandler）；
• DBR*：运行时基础设施（如 DBRProgressMonitor）。

核心抽象接口集中在 plugins/org.jkiss.dbeaver.model（1100+ 文件的模型插件）与 plugins/org.jkiss.dbeaver.model.jdbc（JDBC 实现层），SQL 处理框架则在 plugins/org.jkiss.dbeaver.model.sql 与 plugins/org.jkiss.dbeaver.model.sql.jdbc。

3.3 依赖管理：P2 仓库而非 Maven Central

README 说明：作为 OSGi 应用，DBeaver 使用 P2 仓库管理第三方依赖；对于 Maven 侧的额外依赖，则通过官方维护的 DBeaver P2 仓库（dbeaver-deps-ce）解决。仓库内的 AGENTS.md 补充了这条机制的细节：

• 所有 OSGi 依赖均来自 P2 仓库，而不是 Maven 中央仓库，相关配置在各根 POM（layout=p2）中；
• 捆绑包之间的依赖不写在 pom.xml，而是写在 MANIFEST.MF 的 Require-Bundle 头中；
• dbeaver-deps-ce 的作用是把经典 Maven 依赖转换成 P2 bundle。

跨仓库依赖则通过根目录的 project.deps 文件声明（当前仓库声明依赖 dbeaver-common），要求所有 DBeaver 系列仓库克隆在同一父目录下。

3.4 构建体系：Maven + Eclipse Tycho

根目录 pom.xml 表明构建由 Apache Maven 与 Eclipse Tycho 驱动：

• 聚合模块为 plugins、features、product 三部分；
• target-platform-configuration 声明了 6 个目标环境（win32/gtk/cocoa × x86_64/aarch64），即 Windows、Linux、macOS 的双架构发行；
• 每个插件以 eclipse-plugin 打包，测试插件以 eclipse-test-plugin 打包，测试代码集中在 test 目录，与生产插件一一对应（如 test/org.jkiss.dbeaver.ext.postgresql.test 对应 plugins/org.jkiss.dbeaver.ext.postgresql）。

AGENTS.md 给出了可复制的构建与测试命令（注意：单独构建/测试单个 bundle 通常因 OSGi 需要完整 bundle 集而失败，应以聚合 POM 为入口）：

# 完整产品构建（桌面版 CE + Eclipse 插件版 CE）
mvn package -f product/aggregate/pom.xml -T1C -Pproduct-dbeaver-ce,product-dbeaver-eclipse-ce

# 全仓库测试（Tycho 在标准构建过程中执行 JUnit 5 / Mockito 测试）
mvn verify -f product/aggregate/pom.xml -T1C -Pproduct-dbeaver-ce,product-dbeaver-eclipse-ce

其他产品形态的构建可使用 product/pom.xml 中声明的 Maven profile。开发工作流方面，devel 是主开发分支，所有 PR 必须指向该分支；分支与 PR 命名需遵循 dbeaver/repo#issueNumber 规范。

四、支持的数据库：100+ 驱动如何组织

4.1 社区版驱动清单

README "Supported databases / Community version" 一节列出了开箱即用的完整驱动清单，按原文完整保留如下：

MySQL, MariaDB, Oracle, DB2, PostgreSQL, SQL Server, Sybase, Apache Hive, Drill, Presto, Trino, Phoenix, Exasol, Informix, Teradata, Vertica, Netezza, Firebird, Derby, H2, H2GIS, WMI, Snowflake, Greenplum, Redshift, Athena, SAP HANA, MaxDB, NuoDB, MS Access, SQLite, CSV, DBF, TimescaleDB, Yellowbrick, CockroachDB, OrientDB, MonetDB, Google BigQuery, Google Spanner, Apache Hive/Impala/Spark, Apache Ignite, MapD, Azure SQL, CrateDB, Elasticsearch, Ocient, Ingres, OmniSci, Yugabyte, IRIS, Data Virtuality, Denodo, Virtuoso, Machbase, DuckDB, Babelfish, OceanBase, Salesforce, EnterpriseDB, Apache Druid, Apache Kylin, Databricks, OpenSearch, TiDB, TDEngine, Materialize, JDBCX, Dameng, Altibase, StarRocks, CUBRID, GaussDB, DolphinDB, LibSQL, GBase 8s, Databend, Cloudberry, Teiid, Kingbase, GreptimeDB。

4.2 驱动插件的仓库组织

从源码结构看，每个"重点支持的数据库"对应一个 org.jkiss.dbeaver.ext.<db> 核心 bundle（负责连接、元数据、方言）及可选的 .ui 变体（负责连接设置页等 UI）。plugins/ 目录下的 ext.* 驱动插件约有 48 个，例如：

• plugins/org.jkiss.dbeaver.ext.postgresql（240 个文件的最大驱动之一，另有独立 debug core/ui 模块支持调试器）；
• plugins/org.jkiss.dbeaver.ext.mysql、org.jkiss.dbeaver.ext.oracle、org.jkiss.dbeaver.ext.mssql、org.jkiss.dbeaver.ext.db2（含 db2.i / db2.zos 变体）、org.jkiss.dbeaver.ext.clickhouse 等；
• org.jkiss.dbeaver.ext.generic 则是通用 JDBC 驱动，配合 README "支持任何有 JDBC 驱动的数据库" 的承诺，作为长尾数据库的兜底方案。

新增驱动的完整流程（驱动模型类、连接提供者注册、方言与元数据扩展点）在 AGENTS-New-Database-Driver.md 中有专门说明，扩展新数据库时可作为操作手册参考。

4.3 PRO 版本扩展

README 同时说明，商业版（PRO）扩展了更多驱动的完整能力，并支持非 JDBC 数据源：ODBC、MongoDB、Cassandra、Couchbase、CouchDB、Redis、InfluxDB、Firestore、BigTable、DynamoDB、Kafka KSQL、Neo4j、AWS Neptune、AWS Timestream、Azure CosmosDB、Yugabyte、Salesforce 等，以及把 CSV、XLSX、JSON、XML、Parquet 等平面文件当数据库使用。这些非 JDBC 数据源属于商业版范围，不在当前社区版仓库内。

五、AI 集成：上下文感知与动态工具

README "AI integration" 一节描述的机制可以概括为四条：

1. 所有 DBeaver 产品都内置类似经典 LLM 聊天的 AI Chat 视图；
2. 可生成/分析/优化 SQL 查询、操作数据库结构，甚至让 SQL 知识很少的用户直接操作数据库；
3. 使用智能聊天上下文（smart chat context），向 LLM 提供数据库结构、SQL 方言等细节；
4. LLM 集成采用上下文依赖的动态工具（context-dependent dynamic tools），在 token 消耗上非常高效。

提供商方面：社区版内置 OpenAI（可通过自定义 endpoint 配置大多数现存 LLM）与 Copilot；PRO 版额外原生支持 Anthropic、Grok、Azure、Bedrock、Gemini、Ollama。

仓库中该能力的代码落点清晰体现了前文所述的模型/UI 分层：

• 模型层 plugins/org.jkiss.dbeaver.model.ai：约 200 个 Java 文件，承载 AI 会话、上下文构建、工具调用等后端逻辑，按架构约定不依赖任何 UI 包——这正是"同一套后端插件复用于 CloudBeaver" 的又一实例；
• UI 层 plugins/org.jkiss.dbeaver.ui.ai：聊天视图、配置界面及前端资源（含 JS/CSS）。

"动态工具 + 上下文注入" 的设计意味着 LLM 按需获取 schema、方言等结构化信息，而非一次性塞入全部元数据，这也是 README 强调其 token 效率高企的原因。

六、文档入口与社区协作

README 指出的官方资料入口包括：完整产品文档、项目 WIKI、Issue 跟踪器、以及从源码构建的指南（外部站点链接此处从略，可按名称在官方站点检索）。社区协作约定在仓库内有明确记载：

• Bug 报告与功能请求通过 Issue 提交，对 "wait for votes" 类工单点 👍 可提升优先级；
• 欢迎 Pull Request，AGENTS.md 是面向开发者（含 AI Agent）的完整指引，涵盖代码风格、日志（统一使用 org.jkiss.dbeaver.Log）、异常处理（DBException 体系）、NLS 本地化、注解约定（@NotNull/@Nullable、@Property 只可放在 getter 上）、许可证头（每个 Java 文件须带 Apache 2.0 头，见 docs/license_header.txt）等；
• 测试框架为 JUnit 5 + Mockito + 自定义 OSGi 测试运行器 test/org.jkiss.dbeaver.osgi.test.runner，通用测试基类在 test/org.jkiss.dbeaver.test.platform。

七、总结：从 README 到源码的一条主线

把 README 的架构声明与仓库结构对齐后，DBeaver 的技术主线可以浓缩为：

1. 分层：OSGi 插件承载一切能力，模型层与 UI 层严格分离，使同一后端支撑桌面版与 Web 版（CloudBeaver）；
2. 扩展：100+ 数据库 = 48 个左右的 ext.* 专用驱动插件 + ext.generic 通用 JDBC 兜底 + 商业版非 JDBC 扩展；
3. 构建：Maven + Tycho + P2 仓库，依赖关系写在 MANIFEST 而非 pom.xml，聚合 POM 是构建与测试的统一入口；
4. AI：模型层 model.ai + UI 层 ui.ai，以智能上下文和动态工具控制 token 开销。

以上每个结论都能在对应路径的源码与构建文件中得到验证，这也是阅读本仓库时的建议路径：从 README.md 建立全局认知，按 AGENTS.md 与 AGENTS-Architecture.md 掌握工程约定，再深入 plugins 中具体 bundle 的 plugin.xml（扩展点声明）、MANIFEST.MF（依赖声明）与 src（实现）三层文件。