WaveHouse：ClickHouse的开源全栈后端方案

当 ClickHouse 遇上工程化难题

ClickHouse 作为高性能列式分析数据库，在海量数据处理和实时聚合查询方面表现极为出色，早已成为数据分析、可观测性和 IoT 场景的首选引擎。它采用列式存储架构，数据按列而非按行组织在磁盘上，使得分析查询（如 SUM、AVG、COUNT 等聚合操作）只需读取涉及的列，大幅减少 I/O 开销。其底层使用 MergeTree 引擎家族，数据写入时先落入内存缓冲区，再以 "part"（数据分区块）的形式刷盘，后台线程会持续将小 part 合并为大 part（类似 LSM-Tree 的 compaction），以优化查询性能。然而，强大的查询能力背后，往往隐藏着不小的工程化门槛。

近日，一个名为 WaveHouse 的开源项目在 Reddit 上引发关注。它的定位相当直接——"ClickHouse 版的 Supabase"。项目作者在构建一套 IoT 遥测（telemetry）解决方案时，反复踩到了 ClickHouse 在实际落地中的几个坑，于是干脆把这些通用需求打包成了一个可以与 ClickHouse 一同部署的工具。

对于熟悉 Supabase 的开发者来说，这个类比几乎一目了然。Supabase 是一个开源的 Firebase 替代品，其核心理念是在 PostgreSQL 之上叠加一系列应用层服务。它的架构由多个松耦合组件组成：PostgREST 将数据库表自动映射为 RESTful API；GoTrue 提供用户注册、登录、JWT 令牌管理等认证服务；Realtime 服务监听 PostgreSQL 的 WAL（Write-Ahead Log）变更并通过 WebSocket 推送给客户端；Storage 模块则处理文件上传与访问控制。PostgreSQL 原生的 Row Level Security（RLS）策略被用于实现细粒度权限——每条 SQL 查询在执行前都会自动附加安全过滤条件。Supabase 通过在 PostgreSQL 之上叠加这些认证、行级安全、实时订阅等能力，把裸数据库变成了开箱即用的后端平台。WaveHouse 想为 ClickHouse 做的，正是同样的事情。

ClickHouse 落地的三大痛点

项目作者在原文中清晰地列举了自己遇到的困难，这些痛点也代表了许多团队使用 ClickHouse 时的普遍困境。

快速写入与持久化难以兼得

第一个问题是写入。如果想在 ClickHouse 中实现**既快速又持久（fast AND durable）**的数据插入，通常绑不开引入 Kafka 之类的消息队列作为缓冲层。

这背后是 ClickHouse 的设计哲学决定的：它偏好批量写入（batch insert），频繁的小批量插入会产生大量小分区（parts），触发合并压力，严重时甚至影响查询性能。如果应用层频繁发起小批量插入（例如每次只写几行），就会产生海量小 part，合并线程跟不上写入速度，最终导致 "Too many parts" 异常，查询延迟也会急剧上升。因此 ClickHouse 官方建议单次插入至少包含数千到数万行，写入频率控制在每秒一次左右。

为了兼顾写入吞吐和数据可靠性，工程上常见的做法是在前面架一套 Kafka 管道。Apache Kafka 是一种分布式事件流平台，以其高吞吐、持久化和精确一次语义（exactly-once semantics）著称。在 ClickHouse 数据管道中，Kafka 通常充当写入缓冲层：生产者将数据以消息形式写入 Kafka Topic，消费者（通常是 ClickHouse 的 Kafka 表引擎或外部 ETL 工具）按批次拉取并插入 ClickHouse，从而天然满足批量写入的要求。Kafka 自身通过多副本分区机制保证数据不丢失。然而部署 Kafka 集群意味着额外的 ZooKeeper/KRaft 管理、Topic 分区规划、消费者组协调以及监控告警，对于一个只想快速验证 ClickHouse 能力的项目而言，为此搭建并维护一整套 Kafka 基础设施，成本显然过高。

查询到 UI 之间隔着一整个后端

第二个痛点在于数据消费端。把 ClickHouse 里的数据查询出来并展示到前端界面时，不能让浏览器直连数据库——中间必须有一个后端 API，负责处理认证（auth）与权限控制。

这意味着即便是一个简单的数据看板项目，也得从零搭建一套服务端逻辑：用户登录、权限校验、SQL 代理、结果返回。每换一个项目，这套脚手架就得重写一遍。

缺少细粒度安全与实时能力

第三个问题是行级（row-level）和列级（column-level）安全、角色管理，以及实时流式传输（realtime streaming）。

行级安全（Row Level Security, RLS）是一种数据访问控制机制，允许数据库管理员定义策略，使不同用户在执行相同 SQL 查询时只能看到被授权的行。例如在多租户 SaaS 中，租户 A 的查询自动被过滤为只返回 tenant_id='A' 的记录。列级安全（Column Level Security, CLS）则进一步控制用户能访问哪些字段——例如普通分析师可以查看聚合指标列，但无法访问包含用户个人信息的列。PostgreSQL 从 9.5 版本起原生支持 RLS，Supabase 正是借此实现权限管理。ClickHouse 虽然提供了基于角色的访问控制（RBAC）和部分列级 GRANT 机制，但缺乏原生的行级安全策略，实现多租户数据隔离通常需要在查询层手动拼接 WHERE 条件或依赖应用代码。

在多租户或对数据敏感度有要求的场景中，控制谁能看到哪些行、哪些列是刚需。而将数据变化实时推送到前端，又是遥测、监控类应用的核心体验。实时流式传输在可观测性和遥测场景中至关重要：运维人员需要在监控大屏上看到指标的秒级变化，而非每隔数十秒手动刷新。常见的实现方式包括基于 WebSocket 的服务端推送、Server-Sent Events（SSE）以及 gRPC 流。ClickHouse 本身不具备类似 PostgreSQL 逻辑复制那样的变更数据捕获（CDC）机制——它的 MergeTree 引擎在后台异步合并数据，并不产生标准的变更事件流。这些能力 ClickHouse 本身并不直接提供完整的开箱方案，需要开发者自行拼装。

WaveHouse 的解法：一个 Go 二进制搞定一切

面对这些重复性的脚手架工作，WaveHouse 的做法是把它们统统内建到一个单独的 Go 二进制文件中，与 ClickHouse 并排部署。

Go 语言的编译模型天然支持静态链接，能将所有依赖打包为一个无外部运行时依赖的可执行文件。这意味着部署时只需分发一个二进制，无需安装语言运行时、管理依赖版本或配置容器镜像层——在边缘节点、IoT 网关或资源受限的环境中尤为实用。Go 的 goroutine 调度器和高效的网络 I/O 模型也使其特别适合构建网络代理和中间件类服务。

根据项目描述，WaveHouse 一次性提供了以下几类核心能力：

• 快速且持久的数据摄入（fast, durable ingest）：无需为了写入可靠性而额外部署 Kafka。WaveHouse 可能采用本地 WAL 文件预写日志、内存缓冲 + 定时批量刷盘等机制，在单进程内实现等效的持久化保证。
• 行级与列级安全及角色管理：在代理层拦截并改写查询以注入安全过滤条件，本质上是在 ClickHouse 外部模拟 RLS 的行为，直接在数据访问层实现细粒度权限控制。
• 实时流式传输（realtime streaming）：支持将数据变化实时推送给消费端。可能的实现方案包括定期轮询差量查询、利用 ClickHouse 的 LIVE VIEW（实验性功能）监听查询结果变化，或在写入代理层同步推送事件。

单二进制部署是这套方案的一大亮点。相比 Supabase 那种由多个服务（PostgREST、GoTrue、Realtime 等）组成的复杂架构——完整部署涉及 PostgreSQL、PostgREST（Haskell）、GoTrue（Go）、Realtime（Elixir）、Kong 网关等多个异构服务，需要 Docker Compose 或 Kubernetes 编排才能正常运行——一个 Go 编译产物意味着极低的部署和运维负担——下载、运行、连上 ClickHouse 即可开始使用。WaveHouse 将认证、安全策略、写入缓冲和实时推送全部编译进单个进程，虽然牺牲了微服务架构的独立扩展性，但在运维简洁性上具有显著优势。这对小型团队和快速原型项目尤其友好。

这个方向为什么值得关注

WaveHouse 的出现，反映了一个更大的行业趋势：围绕高性能数据引擎构建"应用层平台"的需求正在增长。

Supabase 的成功已经证明，当一款强大但偏底层的数据库（PostgreSQL）被包裹上认证、权限、实时和 API 生成能力后，它能够触达远比原本更广的开发者群体。ClickHouse 在分析和时序数据领域的地位，与 PostgreSQL 在 OLTP 领域的地位有几分相似——都是被广泛认可但存在使用门槛的核心引擎。

从 IoT 遥测这个切入点也能看出定位的精准。IoT 遥测数据在工程层面具有鲜明特征：首先是写入频率极高，数万甚至数百万设备可能同时以亚秒级间隔上报传感器读数，写入峰值可达每秒百万条以上；其次是数据天然具有时序性，每条记录都带有时间戳，查询模式以时间范围扫描和降采样聚合为主；第三是多租户隔离需求——不同客户的设备数据必须严格隔离，既涉及安全合规也关乎查询性能；第四是实时性要求——设备异常告警、地理围栏触发等场景要求数据从采集到可视化的端到端延迟在秒级以内。

遥测数据具有高频写入、时序性强、需要实时可视化、往往涉及多设备/多租户权限的特征，这恰恰把 ClickHouse 的写入难题、实时需求和安全需求全部集中暴露了出来。ClickHouse 凭借列式压缩和向量化执行引擎，在时序聚合查询上性能卓越，但上述写入模式和实时推送需求恰恰落在其架构短板上。以此为原点打磨出的工具，反而具备更强的通用性。

使用前需要留意的问题

作为一个早期开源项目，WaveHouse 目前更多是在"降低 ClickHouse 工程化门槛"这一价值主张上做文章，具体的技术实现细节、性能表现和生产可用性还有待更多验证。以下几个方面值得潜在使用者重点关注：

• 持久化摄入的实现机制：在不依赖 Kafka 的情况下，WaveHouse 如何保证写入既快又不丢数据？是通过本地 WAL（Write-Ahead Log，即预写日志，一种在数据正式写入目标存储前先将变更记录到持久化日志中的技术，用于崩溃恢复时重放未完成的写入操作）、缓冲刷盘还是其他机制，直接决定了它能否替代成熟的消息队列方案。
• 安全模型的成熟度：行级、列级安全在复杂多租户场景下的表现，往往是魔鬼藏在细节里的地方。需要验证策略在高并发查询下的性能开销、策略规则的表达能力是否足够覆盖复杂业务逻辑，以及安全过滤是否存在绕过风险。
• 社区与生态发展：作为开源项目，作者明确表示希望获得反馈并持续增加功能，这意味着现阶段更适合尝鲜和参与共建，而非直接用于关键生产系统。

总结

WaveHouse 用"ClickHouse 的 Supabase"这个简洁的类比，精准击中了许多开发者的痛点——强大的数据库不该被繁重的周边脚手架挡在门外。将持久化摄入、细粒度安全和实时流式能力打包进单个 Go 二进制，是一种务实且友好的工程选择。

对于正在或计划使用 ClickHouse 的团队，尤其是 IoT 遥测、监控告警、实时看板类项目，WaveHouse 值得关注和试用。作为一个仍在快速迭代的开源项目，它更适合作为原型验证工具和社区贡献对象，其在生产环境的稳健性还需要时间和社区的共同打磨。