很多团队开始用 ClickHouse 之后，第一阶段通常都很顺利。

  • 写分析 SQL 很快；
  • 聚合和扫描性能很猛；
  • 做日志、事件、指标或报表数据仓库都很顺手。

但只要真正进入日常维护阶段，问题就会开始出现。

  • 业务同学想看数据时，不一定愿意一直写裸 SQL；
  • 工程师排查查询性能时，要在系统表、命令行和监控面板之间来回跳；
  • 表结构、part、mutation、replication、磁盘和 Keeper 状态，散在不同入口；
  • 权限管理和查询历史如果没有一个统一界面，协作成本会越来越高。

今天想记下的 ntk148v/clicklens，就在补这个空缺。它不是要替代 ClickHouse 本身，而是想做一套更完整的 ClickHouse Web 工作台：把数据探索、SQL 控制台、监控、日志、Schema 浏览和访问控制都收进同一个浏览器界面里。

按 GitHub 仓库页面和提交历史页面在 2026-06-24 的公开信息，这个仓库当前约有 41 stars、7 forks，主要语言是 TypeScript，仓库创建于 2025-12-26，最近一次公开提交出现在 2026-06-04。项目采用 MIT 许可证，当前最新 release 是 v0.0.6，发布时间为 2026-04-17。

项目概览

属性详情
仓库ntk148v/clicklens
定位面向 ClickHouse 的浏览器端管理与分析工作台
Stars41
Forks7
主要语言TypeScript
创建时间2025-12-26
最近公开提交2026-06-04
LicenseMIT
最新版本v0.0.6
版本日期2026-04-17
文档ntk148v.github.io/clicklens

它想做的不是“再加一个查询框”，而是一整套 ClickHouse 日常操作台

README 里给出的定位很直接：ClickLens 是一个用于 管理和监控 ClickHouse 数据库 的现代 Web 界面。

它覆盖的核心能力并不窄：

  • Discover 式数据探索；
  • 多标签 SQL Console；
  • 实时监控；
  • Schema Explorer；
  • Query Analytics；
  • 日志查看；
  • 用户和角色管理；
  • 设置查看。

这点很关键。很多数据库工具要么偏“写 SQL”，要么偏“看监控”，要么只是非常基础的表浏览器。ClickLens 的路线更像是把多个分散的小入口整合成一个工作面。

如果团队日常已经在 ClickHouse 上做日志分析、事件分析、埋点查询或内部 BI，这种集中式界面会比单独准备几种工具更顺手。

Discover + SQL Console 的组合，让它比纯运维面板更实用

我觉得 ClickLens 最有价值的，不是“有个 UI”，而是它没有只停留在运维层。

README 里提到的 Discover 模式，强调的是一种更接近可视化探索的体验：

  • 可以按时间过滤；
  • 可以按字段筛选；
  • 可以做类似 Kibana 的数据浏览；
  • 可以在不先写完整 SQL 的情况下摸清表里到底有什么。

这很适合刚接手数据表、刚接入新日志源，或者需要先看样本再写查询的场景。

而 SQL Console 又补上了另一端：

  • 多标签编辑；
  • 自动补全；
  • EXPLAIN；
  • 查询结果流式返回；
  • 已保存查询和历史查询。

这两部分放在一起，意味着它既照顾“先探索再分析”的使用路径，也照顾“我就是要高效写 SQL”的路径。

很多内部工具最大的问题，是只支持其中一条。ClickLens 至少从产品设计上看，知道这两类用户经常是同一批人，而且会在一天里来回切换。

它真正对 ClickHouse 下功夫的地方，在于把表结构、parts、查询和集群状态放进了一套界面

ClickHouse 之所以好用，一部分在于它暴露了很多底层信息；但这也意味着，真正排查问题时你要面对很多不同层级的对象：

  • database / table / column；
  • parts、merges、mutations；
  • running queries、query history；
  • disk、replication、Keeper；
  • server settings、session settings。

README 列出的功能正好覆盖这些地方：

  • Table Explorer 可以浏览 schema、parts、mutation、DDL；
  • Monitoring 有 8 类 dashboard；
  • Query Analytics 可以看运行中查询、历史和性能；
  • Logging 能直接看 server log、session log、crash log；
  • Settings 页面可以查看 server 和 session 级配置。

这说明它不是一个“只对最终查询结果负责”的前端，而是试图把 从数据探索到集群诊断 的路径串起来。

对数据库平台团队来说，这比单独做一个漂亮的 query editor 更有意义。因为大部分麻烦都发生在“查询为什么慢”“这个表为什么行为不对”“这个节点到底出了什么事”这些问题上。

原生 RBAC 对齐，是很务实的一步

另一个我比较在意的点，是 README 明写了 Native RBAC。

它的意思不是再发明一套前端权限系统，而是让 UI 权限直接从 ClickHouse grants 推导出来。再加上用户和角色管理页面，这种设计就比较贴近真实环境了。

原因很简单：

  • 数据库权限如果和前端权限分裂，迟早会出现口径不一致；
  • 一套工具越多人用，越需要权限边界清楚；
  • 只要牵涉多租户、不同团队或生产数据，权限模型就不能太随意。

ClickLens 至少在定位上是理解这一点的。它不是只想让个人开发者本地连一个测试库，而是试图变成多人共享的操作界面。

文档和截图比较完整，说明它已经超过了“概念 demo”阶段

从公开仓库页面看，ClickLens 的信号还算不错。

  • README 很长，而且把功能、文档入口和截图都铺开了；
  • 有单独的文档站点；
  • 仓库里已经有接近 500 次提交；
  • 有多个 release；
  • e2e、scripts、docs、test 这些目录都已经成形。

这不代表它已经成熟到适合所有生产环境，但至少说明作者不是只做了一个首页 screenshot。

特别是数据库工作台这类项目，如果没有比较完整的截图和文档，通常很难判断它到底是“能展示几页 UI”，还是“真的可以拿来接实际集群”。ClickLens 在这方面给出的公开材料相对充分。

适合什么场景

从 README 的能力边界看，我觉得 ClickLens 比较适合下面这些情况：

  • 团队已经在用 ClickHouse，但还缺一个统一的浏览器入口；
  • 需要同时照顾数据探索、SQL 查询和集群监控；
  • 不想把日志、查询、表结构和权限管理拆在多个工具里；
  • 希望让分析、平台和后端同学共享同一套可视化工作界面。

尤其是内部分析平台、日志平台、事件仓库、运营查询后台，这类场景都很对路。

它的边界也很清楚

当然，ClickLens 不是万能数据库前端。

从公开信息看，它更像是：

  • ClickHouse 专用工作台；
  • 偏运维和分析协作的界面；
  • 建立在已有 ClickHouse 集群之上的管理层。

所以如果你的需求是：

  • 跨多种数据库统一管理；
  • 面向业务报表消费者的成品 BI 产品；
  • 完整的数据建模、血缘和治理平台；
  • 完全零门槛替代 SQL 认知；

那它都不是直接答案。

但如果你的目标是“让 ClickHouse 这套强大但略分散的能力，有一个更顺手的浏览器入口”，ClickLens 的方向是对的。

为什么值得关注

我觉得这个项目值得记住，不只是因为它给 ClickHouse 做了个好看的 UI。

真正有价值的是，它试图把 ClickHouse 日常使用里最容易分裂的几层重新收拢：

  • 数据探索；
  • SQL 执行；
  • 表结构理解；
  • 查询诊断；
  • 集群监控；
  • 日志排查；
  • 权限管理。

这类工具一旦做得顺，团队对 ClickHouse 的使用门槛会明显下降，因为大家不用再靠一堆零散脚本、系统表查询和各自收藏的命令去拼工作流。

小结

ntk148v/clicklens 不是想重新发明数据库，而是想把 ClickHouse 那些本来就很强、但平时分散在 CLI、系统表和不同页面里的能力，整理成一个更像现代开发工具的 Web 工作台。

如果你所在的团队已经把 ClickHouse 用成了核心分析底座，但还缺少一层好用的日常操作界面，这个项目很值得继续观察。