企业官网建设流程全解析

深度解析：为什么 Apache SkyWalking 官方不提供 ClickHouse 存储方案及其社区治理逻辑

【免费下载链接】skywalkingAPM, Application Performance Monitoring System项目地址: https://gitcode.com/gh_mirrors/sk/skywalking

导读

Apache SkyWalking 社区用户长期存在一个高频疑问：为什么官方不支持 ClickHouse、Loki、Vertica 等数据库作为 OAP 后端的存储方案？本文基于官方 FAQ 文档 docs/en/FAQ/why-clickhouse-not-supported.md，系统梳理这一问题的背景、社区治理逻辑、新增存储的完整路径（SWIP 流程）、合入后的长期维护责任，以及 SkyWalking 存储架构（模块化 Provider 机制、数据模型注解体系）对"加一种存储"这件事的真实约束。读完本文，你将理解 SkyWalking 存储生态的演进逻辑，并掌握为上游贡献新存储插件的完整工作流与责任边界。

一、问题背景：一个被反复提问的存储诉求

在过去的数年里，SkyWalking 社区用户反复询问：为什么上游（upstream）不把 ClickHouse、Loki 或其他数据库作为受支持的存储选项？该问题在官方 FAQ 中被明确记录，原文档 指出"我们重复回答了多次，但提问仍在继续"，因此官方将答案正式成文，帮助更多人理解背后的逻辑。

这类提问的典型代表是 GitHub 上关于新增存储扩展的讨论，原文档列举了以下历史讨论：

• Loki 作为存储：apache/skywalking/discussions/9836
• ClickHouse：apache/skywalking/issues/11924、apache/skywalking/discussions/9011
• Vertica：apache/skywalking/discussions/8817

说明：以上链接为原文档引用的上游 GitHub Discussion/Issue 编号，本文仅转述其存在，不提供外部链接跳转。

原文档明确指出：这些提问的共性诉求是"为 SkyWalking 增加一种新的存储"，而答案并非技术可行性问题，而是一个社区治理与资源投入问题。

二、为什么这些存储不存在：志愿者驱动社区的治理逻辑

2.1 "为什么"不是一个合适的问题

原文档开宗明义地指出："WHY" 不是一个合适的问题。SkyWalking 是一个志愿者驱动的社区（volunteer-driven community），项目的全部工作——包括 bug 修复、日常维护和新功能开发——都来自于志愿者基于个人兴趣与雇主利益的投入，而非强制性责任。

因此，社区中的任何一项现存能力，本质上都是"某个人/某群人感兴趣并贡献到上游"的结果。反过来说，一项能力不存在，并不代表它"不该存在"或"技术上不可行"，而仅仅代表目前没有人对它有足够的兴趣去实现和长期维护。

2.2 当前维护者的兴趣焦点

按照原文档的说明，SkyWalking 活跃维护者目前的存储投入方向集中在三块：

目前没有维护者对 ClickHouse 或其他数据库抱有足够兴趣，这就是它们没有出现在官方存储列表中的直接原因。这一结论在原文档中有明确表述："We for now don't have people interested in ClickHouse or any other database."

从仓库实际配置也能印证这一点：OAP 默认配置文件 oap-server/server-starter/src/main/resources/application.yml 中，存储模块的 selector 默认值为${SW_STORAGE:banyandb}，且下方仅配置了banyandb与elasticsearch两个分支。而存储选型的官方总览文档 docs/en/setup/backend/backend-storage.md 中列出的受支持存储为：BanyanDB、MySQL（及兼容数据库）、PostgreSQL（及兼容数据库）、Elasticsearch/OpenSearch——同样没有 ClickHouse、Loki、Vertica。

三、如何新增一种存储：SWIP 提案流程

如果社区成员确实希望为 SkyWalking 增加 ClickHouse（或其他数据库）存储，原文档给出了明确路径：走 SWIP（SkyWalking Improvement Proposal）流程，并与维护团队进行充分讨论。

3.1 什么是 SWIP

SWIP 是 SkyWalking 的官方改进提案机制，其说明文档位于 docs/en/swip/readme.md。根据该文档，SWIP 用于提出与最终用户和开发者相关的新功能或功能改进，且自 v9.x 以来项目进入稳定期，所有重大变更都应经过 SWIP 严肃评估，尽可能避免不兼容的破坏性变更。

SWIP 明确定义了"重大变更"的目录，其中与存储直接相关的一条是：

• 任何存储结构（storage structure）的变更

这意味着，新增一种存储后端几乎必然触碰存储结构定义，属于必须走 SWIP 的变更范畴。

3.2 SWIP 的发起流程

按照 SWIP readme 的记录，完整流程如下：

1. 在 GitHub Discussion 的 SWIP 分类下以[DISCUSS] xxxx为标题发起讨论；
2. 按 SWIP 模板填写内容（模板要求覆盖：Motivation 动机、Architecture Graph 架构图、Proposed Changes 提议变更、Imported Dependencies libs and their licenses 依赖及其许可证、Compatibility 兼容性、General usage docs 通用使用文档）；
3. 至少一名 SkyWalking committer 在讨论中表态有兴趣采纳；
4. 该 committer 授予SWIP ID并将标题更新为[SWIP-ID NO.] [DISCUSS] xxxx；
5. 后续讨论在讨论页持续进行；
6. 获得足够 committer 支持达成共识（或通过邮件列表投票）后，提案被收录为正式 SWIP 文档。

仓库中已收录的 SWIP 实例（如 SWIP-1 至 SWIP-16）均可参考，其中SWIP-5 即为 "Support ClickHouse Monitoring"（支持对 ClickHouse 的监控）——注意这指的是将 ClickHouse 作为被监控对象（类似 MySQL、Redis 等中间件的监控），而不是将 ClickHouse 作为 OAP 的存储后端，二者是完全不同的两个方向，这也是社区中常见的混淆点。

3.3 存储插件化的技术现实：接口可行，但绝非"换个驱动"这么简单

原文档同时指出，SkyWalking 拥有可插拔的存储系统（pluggable storage system），从理想角度看，新增存储可以抽象为"为存储模块实现一个新的 Provider"。

这一点在源码层面可以得到充分印证：

• 核心存储模块 StorageModule 定义于oap-server/server-core，声明了数十个存储服务接口，包括IBatchDAO、IMetricsDAO、ITraceQueryDAO、ILogQueryDAO、IAlarmQueryDAO、IProfileTaskQueryDAO、IEBPFProfilingDataDAO、ModelInstaller等；
• 其中 StorageDAO 是一个典型的DAO 工厂接口，要求 Provider 为指标、记录、无流数据、管理数据四类模型分别提供newMetricsDao、newRecordDao、newNoneStreamDao、newManagementDao实现；
• 现有 Provider 正是通过实现这些接口接入系统的，例如：
  • BanyanDBStorageProvider；
  • StorageModuleElasticsearchProvider；
  • JDBC 系以 JDBCStorageProvider 为抽象基类，MySQLStorageProvider 与 PostgreSQLStorageProvider 分别继承并注册各自的 DAO 实现。

但原文档特别强调了一个关键现实：在实践层面，存储实现必须做到高性能与深度优化。基于维护团队在 JDBC 与 Elasticsearch 实现上的经验，可能需要在内核层面（kernel level）和数据模型声明层面（data model declarations）追加一些 flag 与 annotation，才能让新存储发挥出应有的性能。

这一点同样在源码中得到印证：server-core的存储注解体系为不同数据库准备了独立的声明式注解：

• annotation/SQLDatabase.java：包含CompositeIndex、AdditionalEntity、ExtraColumn4AdditionalEntity等 JDBC 专属注解；
• annotation/ElasticSearch.java：包含MatchQuery、Keyword、Routing、EnableDocValues等 ES 专属注解；
• annotation/BanyanDB.java：包含SeriesID、ShardingKey、IndexRule、MeasureField、MatchQuery、IndexMode等 BanyanDB 专属注解。

可以推断：如果新增 ClickHouse 存储，同样需要在数据模型上增加 ClickHouse 专属的注解（如分区键、排序键、物化视图、TTL 等声明），并让内核层感知这些声明——这是一个涉及数据模型、DAO 层、TTL 机制、索引/分区策略的系统性工程，远超"改一行连接串"的范畴。

此外，存储模块的接入还依赖模块化配置系统：新增 Provider 后，需要在 application.yml 中为storage模块注册 selector 分支（现有 selector 通过${SW_STORAGE:banyandb}这类环境变量占位符切换），并配套ModelInstaller完成建表/建索引等初始化工作（ModelInstaller已被纳入 StorageModule 对外暴露的服务，见 StorageModule.java 的注释说明）。

四、提案者的硬性要求：精通数据库 + 足够规模与环境的基准测试

原文档进一步给出了一条非常务实的建议：由于当前维护者对 ClickHouse 等数据库并不热衷（否则你早就看到相关实现了），他们不会参与新存储的具体代码实现，也难以从通用视角判断"在该特定数据库中哪种实现方式会有更好的行为与性能"。

因此，如果你希望向上游提交 ClickHouse 存储提案，必须满足两个硬性前提：

1. 你必须是该数据库的资深专家——只有深入了解 ClickHouse 的分片、副本、MergeTree 引擎、索引与物化视图机制，才能写出与 SkyWalking 数据模型相匹配的高性能实现；
2. 你必须拥有足够的规模与测试环境，能够提供扎实的基准测试（solid benchmark）——用可复现的数据证明新实现确实达到或超过现有存储的表现。

原文档特别点出社区常见的宣传口径："人们谈论 ClickHouse 比 Elasticsearch 在大规模部署下更快、效率更高"——但空口宣传不能替代基准数据，任何性能主张都必须用 benchmark 和产品侧实践来支撑。

五、合入之后：维护责任与移除机制

5.1 提案者必须承担长期维护责任

原文档明确：提出并合入新存储实现（如 ClickHouse storage）的人，必须承担该实现的后续维护责任。维护意味着至少包括以下三项职责：

1. 参与存储相关讨论——确保 SkyWalking 在内核级优化上持续推进时，不会被这些特定存储选项阻塞（即：内核演进不能因为某个存储实现跟不上而被迫妥协）；
2. 响应存储相关问题——包括该存储相关的使用问题、bug、**CVE（安全漏洞）**与性能问题；
3. 保持性能与提案预期一致——例如当初宣传"ClickHouse 比 ES 在大规模下更快更高效"，那么后续就应该持续看到它有更优的 benchmark 与产品侧实践佐证。

5.2 无主维护的后果：PMC 有权移除实现

原文档给出了一个非常关键的治理规则：即使存储已被接受、合入并发布，如果"没有人能承担上述责任"，或"社区收不到关于这些存储的反馈与问题"，SkyWalking PMC（项目管理委员会）将启动流程移除该实现。

这不是一条停留在纸面上的规则——Apache IoTDB 与 InfluxDB 存储选项正是因此被移除的先例，原文档附上了相关投票讨论（apache/skywalking/discussions/9059）。

这一机制深刻体现了"志愿者驱动 + 责任对等"的社区哲学：合入不等于一劳永逸，一个无人维护的存储实现不仅不会成为项目资产，反而会成为内核演进与技术债的负担。SkyWalking 宁可删除实现，也不愿保留一个无法跟上内核变化的"半成品"存储。

六、总结：给社区提问者与潜在贡献者的行动建议

综合全文，可以从三个层面给出结论：

1. 对提问者（为什么没有 ClickHouse？）：这不是技术判断，而是社区兴趣与投入的现实结果。当前维护者聚焦 JDBC（MySQL/PostgreSQL）、Elasticsearch 与原生 BanyanDB，暂时没有人有意愿长期维护 ClickHouse 等存储。如果你只是需要"一种类列式存储"，应优先评估 BanyanDB（官方原生数据库）或按官方文档评估 Elasticsearch、MySQL、PostgreSQL 的适用场景（例如 backend-storage.md 中提到 MySQL/PostgreSQL 适合中等规模、低 Trace 量场景，而日志与 Trace 性能显著低于 BanyanDB 和 Elasticsearch，且性能无法线性提升）。

2. 对潜在贡献者（我想加 ClickHouse 存储）：请按 SWIP 流程 发起提案，先与维护团队充分讨论。技术上要意识到"可插拔存储"背后的真实成本：不仅要实现StorageDAO工厂与全部 DAO 接口，还要在内核与数据模型注解层补齐针对该数据库的优化声明，并通过模块化配置接入 selector。同时请自问：你是否是该数据库的资深专家？能否提供足够规模环境下的扎实 benchmark？是否愿意长期承担 bug、CVE、性能与讨论的维护责任？

3. 对旁观者（判断一个存储选项是否靠谱）：关注的不应只是"有没有这个实现"，而是有没有人持续维护它、有没有持续的性能佐证、社区能否收到关于它的反馈。SkyWalking 对 Apache IoTDB 与 InfluxDB 存储的移除先例表明：一个没有维护者的存储，迟早会被 PMC 移除——这恰恰是项目保持内核健康与长期可演进性的治理保障。

参考资源（仓库内）

• 官方 FAQ 原文：docs/en/FAQ/why-clickhouse-not-supported.md
• SWIP 提案机制：docs/en/swip/readme.md
• 存储选型总览：docs/en/setup/backend/backend-storage.md
• 各存储详细指南：storages/banyandb.md、storages/elasticsearch.md、storages/mysql.md、storages/postgresql.md
• 存储模块核心接口：StorageModule.java、StorageDAO.java
• 存储 Provider 示例：JDBCStorageProvider.java、BanyanDBStorageProvider.java、StorageModuleElasticsearchProvider.java
• 数据模型注解体系：annotation/SQLDatabase.java、annotation/ElasticSearch.java、annotation/BanyanDB.java
• 默认存储配置：application.yml

【免费下载链接】skywalkingAPM, Application Performance Monitoring System项目地址: https://gitcode.com/gh_mirrors/sk/skywalking