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

深度解析为什么 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/9836ClickHouseapache/skywalking/issues/11924、apache/skywalking/discussions/9011Verticaapache/skywalking/discussions/8817说明以上链接为原文档引用的上游 GitHub Discussion/Issue 编号本文仅转述其存在不提供外部链接跳转。原文档明确指出这些提问的共性诉求是为 SkyWalking 增加一种新的存储而答案并非技术可行性问题而是一个社区治理与资源投入问题。二、为什么这些存储不存在志愿者驱动社区的治理逻辑2.1 为什么不是一个合适的问题原文档开宗明义地指出WHY 不是一个合适的问题。SkyWalking 是一个志愿者驱动的社区volunteer-driven community项目的全部工作——包括 bug 修复、日常维护和新功能开发——都来自于志愿者基于个人兴趣与雇主利益的投入而非强制性责任。因此社区中的任何一项现存能力本质上都是某个人/某群人感兴趣并贡献到上游的结果。反过来说一项能力不存在并不代表它不该存在或技术上不可行而仅仅代表目前没有人对它有足够的兴趣去实现和长期维护。2.2 当前维护者的兴趣焦点按照原文档的说明SkyWalking 活跃维护者目前的存储投入方向集中在三块存储方向定位JDBC 生态MySQL、PostgreSQL为现有用户服务适配中等规模部署Elasticsearch为现有用户服务适配大规模部署BanyanDB官方原生数据库native one向前推进的核心方向目前没有维护者对 ClickHouse 或其他数据库抱有足够兴趣这就是它们没有出现在官方存储列表中的直接原因。这一结论在原文档中有明确表述We for now dont 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或其他数据库存储原文档给出了明确路径走 SWIPSkyWalking Improvement Proposal流程并与维护团队进行充分讨论。3.1 什么是 SWIPSWIP 是 SkyWalking 的官方改进提案机制其说明文档位于 docs/en/swip/readme.md。根据该文档SWIP 用于提出与最终用户和开发者相关的新功能或功能改进且自 v9.x 以来项目进入稳定期所有重大变更都应经过 SWIP 严肃评估尽可能避免不兼容的破坏性变更。SWIP 明确定义了重大变更的目录其中与存储直接相关的一条是任何存储结构storage structure的变更这意味着新增一种存储后端几乎必然触碰存储结构定义属于必须走 SWIP 的变更范畴。3.2 SWIP 的发起流程按照 SWIP readme 的记录完整流程如下在 GitHub Discussion 的 SWIP 分类下以[DISCUSS] xxxx为标题发起讨论按 SWIP 模板填写内容模板要求覆盖Motivation 动机、Architecture Graph 架构图、Proposed Changes 提议变更、Imported Dependencies libs and their licenses 依赖及其许可证、Compatibility 兼容性、General usage docs 通用使用文档至少一名 SkyWalking committer 在讨论中表态有兴趣采纳该 committer 授予SWIP ID并将标题更新为[SWIP-ID NO.] [DISCUSS] xxxx后续讨论在讨论页持续进行获得足够 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 正是通过实现这些接口接入系统的例如BanyanDBStorageProviderStorageModuleElasticsearchProviderJDBC 系以 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 存储提案必须满足两个硬性前提你必须是该数据库的资深专家——只有深入了解 ClickHouse 的分片、副本、MergeTree 引擎、索引与物化视图机制才能写出与 SkyWalking 数据模型相匹配的高性能实现你必须拥有足够的规模与测试环境能够提供扎实的基准测试solid benchmark——用可复现的数据证明新实现确实达到或超过现有存储的表现。原文档特别点出社区常见的宣传口径人们谈论 ClickHouse 比 Elasticsearch 在大规模部署下更快、效率更高——但空口宣传不能替代基准数据任何性能主张都必须用 benchmark 和产品侧实践来支撑。五、合入之后维护责任与移除机制5.1 提案者必须承担长期维护责任原文档明确提出并合入新存储实现如 ClickHouse storage的人必须承担该实现的后续维护责任。维护意味着至少包括以下三项职责参与存储相关讨论——确保 SkyWalking 在内核级优化上持续推进时不会被这些特定存储选项阻塞即内核演进不能因为某个存储实现跟不上而被迫妥协响应存储相关问题——包括该存储相关的使用问题、bug、**CVE安全漏洞**与性能问题保持性能与提案预期一致——例如当初宣传ClickHouse 比 ES 在大规模下更快更高效那么后续就应该持续看到它有更优的 benchmark 与产品侧实践佐证。5.2 无主维护的后果PMC 有权移除实现原文档给出了一个非常关键的治理规则即使存储已被接受、合入并发布如果没有人能承担上述责任或社区收不到关于这些存储的反馈与问题SkyWalking PMC项目管理委员会将启动流程移除该实现。这不是一条停留在纸面上的规则——Apache IoTDB 与 InfluxDB 存储选项正是因此被移除的先例原文档附上了相关投票讨论apache/skywalking/discussions/9059。这一机制深刻体现了志愿者驱动 责任对等的社区哲学合入不等于一劳永逸一个无人维护的存储实现不仅不会成为项目资产反而会成为内核演进与技术债的负担。SkyWalking 宁可删除实现也不愿保留一个无法跟上内核变化的半成品存储。六、总结给社区提问者与潜在贡献者的行动建议综合全文可以从三个层面给出结论1. 对提问者为什么没有 ClickHouse这不是技术判断而是社区兴趣与投入的现实结果。当前维护者聚焦 JDBCMySQL/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.mdSWIP 提案机制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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考