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

当 ClickHouse 遇上工程化难题

ClickHouse 作为高性能列式分析数据库，在海量数据处理和实时聚合查询方面表现极为出色，早已成为数据分析、可观测性和 IoT 场景的首选引擎。它采用列式存储架构，数据按列而非按行组织在磁盘上，使得分析查询（如 SUM、AVG、COUNT 等聚合操作）只需读取涉及的列，大幅减少 I/O 开销。列式存储的优势不仅在于减少读取量——由于同一列的数据类型完全一致且值域分布相似，压缩算法（如 LZ4、ZSTD、Delta 编码、Double-Delta 等）可以获得极高的压缩比，通常在 10:1 到 100:1 之间，这进一步降低了磁盘 I/O 和内存占用。相比之下，传统行式数据库（如 MySQL、PostgreSQL）的一行数据可能包含字符串、整数、浮点数等多种类型混排，压缩效率远不及列式存储。此外，ClickHouse 的向量化查询执行引擎利用 SIMD（Single Instruction, Multiple Data）指令集对整列数据进行批量运算，使得 CPU 利用率极高。

其底层使用 MergeTree 引擎家族，数据写入时先落入内存缓冲区，再以 "part"（数据分区块）的形式刷盘，后台线程会持续将小 part 合并为大 part（类似 LSM-Tree 的 compaction），以优化查询性能。MergeTree 引擎的核心数据结构包括：分区键（Partition Key）决定数据如何按时间或其他维度分区存储，主键（Primary Key）用于构建稀疏索引——不同于传统 B-Tree 索引对每一行建立条目，ClickHouse 的主键索引每隔 8192 行（默认 index_granularity）才记录一个索引标记，这种稀疏设计使得索引体积极小，可以完全驻留在内存中，同时仍能快速定位到数据所在的颗粒（granule）范围。理解这一机制对于后续讨论写入问题至关重要：每个 part 都是一个自包含的目录，包含列数据文件、主键索引、分区信息等，part 数量过多会导致文件描述符膨胀、索引合并开销增大和查询时需要扫描的 part 数暴涨。然而，强大的查询能力背后，往往隐藏着不小的工程化门槛。

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

对于熟悉 Supabase 的开发者来说，这个类比几乎一目了然。Supabase 是一个开源的 Firebase 替代品，其核心理念是在 PostgreSQL 之上叠加一系列应用层服务。它的架构由多个松耦合组件组成：PostgREST 将数据库表自动映射为 RESTful API——这个用 Haskell 编写的组件之所以选择 Haskell，是因为其强类型系统能在编译期保证 SQL 到 HTTP 映射的类型安全性，同时 Warp 服务器的性能在 HTTP 框架基准测试中名列前茅；GoTrue 提供用户注册、登录、JWT 令牌管理等认证服务；Realtime 服务监听 PostgreSQL 的 WAL（Write-Ahead Log）变更并通过 WebSocket 推送给客户端——这一组件使用 Elixir 语言和 Phoenix 框架构建，因为底层的 BEAM 虚拟机（最初为 Erlang 电信系统设计）天然擅长管理数十万个并发 WebSocket 连接，每个连接作为轻量级进程运行，单个进程崩溃不会影响其他连接；Storage 模块则处理文件上传与访问控制。PostgreSQL 原生的 Row Level Security（RLS）策略被用于实现细粒度权限——RLS 的工作原理是在 SQL 执行计划生成阶段，由查询优化器自动将管理员定义的安全策略（本质上是 USING 子句中的布尔表达式）作为额外的过滤条件注入到每条查询中，这一过程对应用层完全透明。Supabase 通过在 PostgreSQL 之上叠加这些认证、行级安全、实时订阅等能力，把裸数据库变成了开箱即用的后端平台。WaveHouse 想为 ClickHouse 做的，正是同样的事情。

ClickHouse 落地的三大痛点

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

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

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

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

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

值得一提的是，Kafka 并非写入缓冲的唯一选项。近年来出现了多种轻量替代方案：Redpanda 是一个兼容 Kafka API 但用 C++ 重写的流平台，消除了对 JVM 和 ZooKeeper 的依赖，单节点部署更加简洁；NATS JetStream 提供了轻量级的持久化消息流能力，部署复杂度远低于 Kafka；还有一些项目选择在应用层实现本地 WAL 缓冲，即数据先写入本地磁盘的追加日志文件，后台异步批量提交到 ClickHouse，崩溃后通过重放 WAL 恢复未提交数据。WaveHouse 选择将缓冲机制内建而非依赖外部消息队列，本质上就是走的这条本地 WAL 路线，用架构简洁性换取了对超大规模写入场景的一定妥协。

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

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

这意味着即便是一个简单的数据看板项目，也得从零搭建一套服务端逻辑：用户登录、权限校验、SQL 代理、结果返回。每换一个项目，这套脚手架就得重写一遍。虽然 ClickHouse 提供了原生的 HTTP 接口（监听 8123 端口，支持通过 URL 参数或 POST body 提交 SQL 查询），但这个接口的认证能力仅限于基础的用户名密码校验，缺乏 JWT/OAuth 等现代 Web 认证标准的支持，更无法实现基于用户上下文的动态权限过滤。将这个接口直接暴露到公网几乎等于向所有人开放了数据库的完整查询能力，安全隐患极大。

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

第三个问题是行级（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 机制（可以通过 GRANT SELECT(column_name) ON table TO user 语法实现列级授权），但缺乏原生的行级安全策略，实现多租户数据隔离通常需要在查询层手动拼接 WHERE 条件或依赖应用代码。一些团队尝试通过 ClickHouse 的查询级别设置（如 max_rows_to_read、自定义 SQL 字典查询）来间接模拟 RLS 行为，但这些方案既脆弱又难以审计。

在多租户或对数据敏感度有要求的场景中，控制谁能看到哪些行、哪些列是刚需。而将数据变化实时推送到前端，又是遥测、监控类应用的核心体验。实时流式传输在可观测性和遥测场景中至关重要：运维人员需要在监控大屏上看到指标的秒级变化，而非每隔数十秒手动刷新。常见的实现方式包括基于 WebSocket 的服务端推送、Server-Sent Events（SSE，一种基于 HTTP 的单向推送协议，相比 WebSocket 更轻量且天然支持自动重连）以及 gRPC 流。ClickHouse 本身不具备类似 PostgreSQL 逻辑复制那样的变更数据捕获（CDC）机制——它的 MergeTree 引擎在后台异步合并数据，并不产生标准的变更事件流。ClickHouse 曾在 2020 年引入了实验性的 LIVE VIEW 功能，其原理是缓存查询结果并在底层数据变化时重新计算差量——用户可以通过 WATCH 语句订阅一个 LIVE VIEW 的输出变化。然而这一功能至今仍处于实验阶段，存在内存开销大、不支持复杂 JOIN、无法在集群间同步等限制，官方文档明确标注不建议在生产环境使用。社区中还有人尝试通过监听 system.parts 系统表的变化来检测新数据写入，或通过定期对比 system.mutations 表来追踪数据变更，但这些都是 hack 性质的 workaround，远非可靠的 CDC 解决方案。这些能力 ClickHouse 本身并不直接提供完整的开箱方案，需要开发者自行拼装。

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

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

Go 语言的编译模型天然支持静态链接，能将所有依赖打包为一个无外部运行时依赖的可执行文件。这意味着部署时只需分发一个二进制，无需安装语言运行时、管理依赖版本或配置容器镜像层——在边缘节点、IoT 网关或资源受限的环境中尤为实用。Go 在云原生基础设施领域的统治地位已经充分验证了这一优势：Docker、Kubernetes、Prometheus、etcd、Terraform 等几乎所有核心云原生工具都是用 Go 编写的，其中一个重要原因就是单二进制分发带来的部署简洁性。Go 的 goroutine 调度器采用 M:N 线程模型（将 M 个 goroutine 复用到 N 个操作系统线程上），配合 netpoller 实现的非阻塞 I/O，使得单个进程可以轻松处理数万个并发网络连接，而每个 goroutine 的初始栈仅有 2-8 KB（相比之下 Java 线程默认栈大小为 1 MB），这使其特别适合构建网络代理和中间件类服务。

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

• 快速且持久的数据摄入（fast, durable ingest）：无需为了写入可靠性而额外部署 Kafka。WaveHouse 可能采用本地 WAL 文件预写日志、内存缓冲 + 定时批量刷盘等机制，在单进程内实现等效的持久化保证。具体而言，写入请求到达时先被追加到本地磁盘的 WAL 文件（顺序写入，性能接近磁盘吞吐上限），同时在内存中累积数据，当缓冲区达到预设大小或时间阈值后，以一次批量 INSERT 提交到 ClickHouse。若进程在批量提交前崩溃，重启后可从 WAL 中重放未确认的写入，从而在单机范围内提供接近"不丢数据"的保证。
• 行级与列级安全及角色管理：在代理层拦截并改写查询以注入安全过滤条件，本质上是在 ClickHouse 外部模拟 RLS 的行为，直接在数据访问层实现细粒度权限控制。这种 SQL 改写代理的模式在业界并不罕见——例如 Apache ShardingSphere 和 ProxySQL 都采用类似的查询拦截与改写机制来实现分片路由或读写分离。WaveHouse 将其应用于安全场景，根据当前请求的用户身份和角色，在 SQL 发送到 ClickHouse 之前自动附加 WHERE 条件或移除未授权的列。
• 实时流式传输（realtime streaming）：支持将数据变化实时推送给消费端。可能的实现方案包括定期轮询差量查询、利用 ClickHouse 的 LIVE VIEW（实验性功能）监听查询结果变化，或在写入代理层同步推送事件。由于所有写入都经过 WaveHouse 代理，它天然掌握了数据变更的时机，可以在将数据批量提交给 ClickHouse 的同时，通过 WebSocket 或 SSE 将新数据推送给已订阅的客户端——这种"写入感知"的推送模式比轮询数据库更高效也更实时。

单二进制部署是这套方案的一大亮点。相比 Supabase 那种由多个服务（PostgREST、GoTrue、Realtime 等）组成的复杂架构——完整部署涉及 PostgreSQL、PostgREST（Haskell）、GoTrue（Go）、Realtime（Elixir）、Kong 网关等多个异构服务，需要 Docker Compose 或 Kubernetes 编排才能正常运行——一个 Go 编译产物意味着极低的部署和运维负担——下载、运行、连上 ClickHouse 即可开始使用。WaveHouse 将认证、安全策略、写入缓冲和实时推送全部编译进单个进程，虽然牺牲了微服务架构的独立扩展性（例如无法单独扩容认证模块或写入缓冲模块），但在运维简洁性上具有显著优势。这种"单体但模块化"的设计哲学在近年来有回归趋势——DHH（Ruby on Rails 创始人）提出的"Majestic Monolith"理念、以及 Basecamp 和 37signals 的实践都表明，对于大多数中小规模应用，精心设计的单体架构在开发效率和运维成本上往往优于过度拆分的微服务。这对小型团队和快速原型项目尤其友好。

这个方向为什么值得关注

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

Supabase 的成功已经证明，当一款强大但偏底层的数据库（PostgreSQL）被包裹上认证、权限、实时和 API 生成能力后，它能够触达远比原本更广的开发者群体。这一趋势并非 Supabase 独有——Neon 将 PostgreSQL 做成了 Serverless 架构，通过存算分离和按需扩缩容降低了使用门槛；PlanetScale 基于 Vitess 对 MySQL 进行平台化包装，提供了分支（branching）、在线 schema 变更等开发者友好特性；Turso 则围绕 libSQL（SQLite 的开源分支）构建了边缘数据库平台。ClickHouse 自身也在向这一方向探索——ClickHouse Cloud 作为官方托管服务，提供了自动扩缩容、存算分离和简化的集群管理，但其重心在于基础设施运维的简化，并未深入到认证、RLS、实时推送等应用层能力。WaveHouse 恰好补位于 ClickHouse Cloud 未覆盖的应用层平台化空间。ClickHouse 在分析和时序数据领域的地位，与 PostgreSQL 在 OLTP 领域的地位有几分相似——都是被广泛认可但存在使用门槛的核心引擎。

从 IoT 遥测这个切入点也能看出定位的精准。IoT 遥测数据在工程层面具有鲜明特征：首先是写入频率极高，数万甚至数百万设备可能同时以亚秒级间隔上报传感器读数，写入峰值可达每秒百万条以上；其次是数据天然具有时序性，每条记录都带有时间戳，查询模式以时间范围扫描和降采样聚合为主——例如"过去 1 小时每分钟的平均温度"这类查询，ClickHouse 的 toStartOfMinute() 等时间函数和物化视图（Materialized View）的预聚合能力可以将此类查询的响应时间从秒级优化到毫秒级；第三是多租户隔离需求——不同客户的设备数据必须严格隔离，既涉及安全合规（如 GDPR 要求的数据主权）也关乎查询性能（避免一个租户的海量数据影响其他租户的查询速度）；第四是实时性要求——设备异常告警、地理围栏触发等场景要求数据从采集到可视化的端到端延迟在秒级以内。

遥测数据具有高频写入、时序性强、需要实时可视化、往往涉及多设备/多租户权限的特征，这恰恰把 ClickHouse 的写入难题、实时需求和安全需求全部集中暴露了出来。ClickHouse 凭借列式压缩和向量化执行引擎，在时序聚合查询上性能卓越——在 ClickBench 等公开基准测试中，ClickHouse 在分析查询延迟上通常比 Elasticsearch 快 10-100 倍，比传统 OLAP 数据库（如 Apache Druid）快数倍——但上述写入模式和实时推送需求恰恰落在其架构短板上。以此为原点打磨出的工具，反而具备更强的通用性。

使用前需要留意的问题

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

• 持久化摄入的实现机制：在不依赖 Kafka 的情况下，WaveHouse 如何保证写入既快又不丢数据？是通过本地 WAL（Write-Ahead Log，即预写日志，一种在数据正式写入目标存储前先将变更记录到持久化日志中的技术，用于崩溃恢复时重放未完成的写入操作）、缓冲刷盘还是其他机制，直接决定了它能否替代成熟的消息队列方案。需要特别关注的边界场景包括：进程崩溃时 WAL 文件的完整性保证（是否使用 fsync 确保数据落盘）、WAL 重放的幂等性（重启后重复插入是否导致数据重复）、以及当 ClickHouse 不可用时 WAL 文件的增长控制策略。
• 安全模型的成熟度：行级、列级安全在复杂多租户场景下的表现，往往是魔鬼藏在细节里的地方。需要验证策略在高并发查询下的性能开销（SQL 改写和条件注入是否引入显著延迟）、策略规则的表达能力是否足够覆盖复杂业务逻辑（例如基于时间窗口的动态权限、跨表关联的权限继承等），以及安全过滤是否存在绕过风险——例如精心构造的子查询、UNION 语句或系统函数调用是否能突破代理层的 SQL 改写逻辑。成熟的 SQL 防火墙和代理（如 AWS 的 Babelfish、Google 的 AlloyDB Auth Proxy）通常需要经过大量的安全审计和渗透测试才能达到生产级别的安全保证。
• 社区与生态发展：作为开源项目，作者明确表示希望获得反馈并持续增加功能，这意味着现阶段更适合尝鲜和参与共建，而非直接用于关键生产系统。可以参照的发展路径是 Supabase 本身——它在 2020 年初期也是一个功能有限的开源项目，经过活跃社区的持续贡献和 Y Combinator 孵化，如今已成长为估值超过 20 亿美元的公司，管理着超过 100 万个数据库实例。WaveHouse 是否能走出类似的成长曲线，取决于其核心架构决策的合理性、社区参与度以及 ClickHouse 生态对此类平台化工具的需求强度。

总结

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

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