今日正式发布 Hanzo Datastore：面向后量子时代的列式 OLAP 分析引擎

今天我们发布 Hanzo Datastore，也就是 Hanzo 数据平台里负责 OLAP 的那一半。它是 ClickHouse 26.6 的分支，去掉了原有品牌，并按我们实际运行分析的方式重建：存储与计算分离，落在 Hanzo S3 上；二进制经过优化、更加精简；旧的 RPC 表面已经移除。镜像现已发布于 ghcr.io/hanzoai/datastore:26.6.1.1。

我们没有新写一个数据库。ClickHouse 是世界上最好的列式引擎，我们以它为基座。改动的是跑一整支机群时真正要紧的部分：存储基底、构建、传输，以及协调的路线图。

存储与计算分离

MergeTree 表的 part 是不可变对象。Datastore 把它们作为对象放在 Hanzo S3 上，也就是我们从 SeaweedFS 派生的存储层，而不是焊死在某一台服务器上的本地磁盘。无状态的计算副本随后通过零拷贝复制，共享同一份物理数据。

这是已经验证的，不是愿景。在我们的横向扩展测试里，一张存储策略指向 S3、有 500 万行的表，会在 system.parts 里报告磁盘 seaweed，两个计算节点就在这一份拷贝上扩出去。增加一个读取方不会复制数据，而是挂接到它上面。分析负载突然升高、需要在几秒内加上查询能力、又不能把数 TB 重新搬一遍时，要的就是这个性质。

-- parts live on S3, not on a node's local disk
SELECT name, disk_name FROM system.parts WHERE table = 'events' LIMIT 1;
-- ┌─name──────┬─disk_name─┐
-- │ all_1_1_0 │ seaweed   │
-- └───────────┴───────────┘

内存大约减半，二进制更小

发布构建会跑配置文件引导优化、瘦链接时优化，以及链接之后的 BOLT 过程。结果是常驻内存大约只有原版构建的一半，二进制也明显更小。要让 BOLT 在 aarch64 上跑通，必须关掉 XRay 插桩。它此前默认开启，并悄悄挡住了链接后的重写。这个修复已经在代码树里。实际效果是：同一套查询计划，更少的 GB，以及启动更快的二进制。

gRPC 已经移除

一个数据仓库应当恰好有一条查询路径，而不是三条。我们把 gRPC 服务端整个拿掉了：没有 contrib/grpc，没有 protobuf 服务定义，也没有 ENABLE_GRPC 构建路径。同一次改动里，默认配置中已经失效的 <grpc> 块也被清掉，让交付的产品和构建一致。Datastore 说的是原生 TCP（9000）、HTTP（8123）和服务器间复制（9009）。这就是全部表面。

往后打算用的传输是 ZAP，我们从 Cap'n Proto 派生的 RPC。服务端的桩已经落地，它还不是线上的查询路径。我们宁可把这条线现在停在哪里说清楚，也不暗示它已经完成。

协调将走向哪里

Replicated* 表今天通过内嵌的 Raft 来协调，也就是随服务器进程一起交付、兼容 ZooKeeper 的 Keeper，没有单独的守护进程。它能工作，也是你现在在生产里跑的东西。

方向是用 Quasar 换掉这层 Raft 后端。Quasar 是来自 Lux 的无主、后量子共识，以原生方式链进 C++ 服务器。这条接缝是真的：已有 C++ 程序通过 C ABI 驱动原生共识引擎——打开一条链、追加一条复制日志、推进置信投票、观察最终性——没有 Raft，也没有零知识那套机制。这证明替换是链接问题，不是重写。它还不是生产上的协调层，我们也不会装成它已经是。

另一半

Datastore 是 OLAP。平台的 OLTP 这一半，是建在 SQLite/Base 上的去中心化 SQL 引擎：已经设计，正在构建，尚未交付。如果你今天要的是本地优先、单文件的数据故事，这条脉络已经出现在 Hanzo Brain，而两半所依托的存储基底，就是我们在 Hanzo Storage 里发布的那一层。

跑起来

docker run -d --name datastore \
  -p 8123:8123 -p 9000:9000 \
  ghcr.io/hanzoai/datastore:26.6.1.1

• 源码：github.com/hanzoai/datastore
• 产品：hanzo.ai/datastore
• 文档：docs.hanzo.ai

arm64 镜像现已发布；amd64 构建经由 CI 随后跟上。这是我们自己在跑的分析与洞察后端。把事件打到它上面，再以列式的速度查回来。