Llegó Hanzo Datastore: un motor OLAP listo para la era poscuántica

Hoy lanzamos Hanzo Datastore, la mitad OLAP de la plataforma de datos de Hanzo. Es un fork de ClickHouse 26.6, sin la marca de origen y rehecho alrededor de cómo corremos la analítica de verdad: almacenamiento separado del procesamiento en Hanzo S3, un binario optimizado más liviano, y la superficie RPC heredada quedó afuera. La imagen ya está en vivo en ghcr.io/hanzoai/datastore:26.6.1.1.

No escribimos una base de datos nueva. ClickHouse es el mejor motor columnar del mundo y lo tomamos como base. Lo que cambiamos son las piezas que importan para operar una flota: el sustrato de almacenamiento, el build, el transporte y la hoja de ruta de la coordinación.

Almacenamiento y procesamiento, separados

Las partes de una tabla MergeTree son objetos inmutables. Datastore las guarda como objetos en Hanzo S3 — nuestra capa de almacenamiento heredada de SeaweedFS — en vez de un disco local pegado a un solo servidor. Las réplicas de procesamiento sin estado comparten entonces una sola copia física de los datos con replicación de copia cero.

Está probado, no es un deseo. En la prueba de escalado horizontal, una tabla de 5 millones de filas cuya política de almacenamiento apunta a S3 reporta el disco seaweed en system.parts, y dos nodos de procesamiento escalan sobre esa única copia. Sumar un nodo de lectura no copia los datos; se acopla a ellos. Esa es la propiedad que quieren cuando una carga de analítica se dispara y necesitan sumar capacidad de consulta en segundos sin reacomodar terabytes.

-- 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   │
-- └───────────┴───────────┘

La mitad de la memoria, un binario más chico

El build de la versión corre optimización guiada por perfiles, optimización delgada en tiempo de enlace y una pasada BOLT después del enlace. El resultado es cerca de la mitad de la memoria residente del build estándar y un binario bastante más chico. Hacer que BOLT funcionara en aarch64 obligó a apagar la instrumentación XRay, que venía prendida por defecto y bloqueaba en silencio la reescritura de después del enlace: ese arreglo está en el árbol. El efecto práctico: el mismo plan de consulta, menos gigabytes y un binario que arranca más rápido.

gRPC ya no está

Un almacén de datos tiene que tener exactamente una ruta de consulta, no tres. Sacamos el servidor gRPC por completo — nada de contrib/grpc, nada de definiciones de servicio protobuf, nada de ruta de build ENABLE_GRPC — y en la misma pasada limpiamos el bloque <grpc> muerto de la configuración por defecto, para que el producto que sale coincida con el build. Datastore habla TCP nativo (9000), HTTP (8123) y replicación entre servidores (9009). Esa es toda la superficie.

El transporte que sigue es ZAP, nuestro RPC derivado de Cap'n Proto. El stub del servidor ya aterrizó; todavía no es la ruta de consulta en vivo. Preferimos decirles exactamente dónde está esa línea antes que dejar creer que ya está terminada.

Hacia dónde va la coordinación

Las tablas Replicated* hoy se coordinan con Raft embebido, el Keeper compatible con ZooKeeper que viene dentro del proceso del servidor: no hay un daemon aparte. Eso funciona, y es lo que corren en producción ahora.

La dirección es reemplazar ese backend de Raft por Quasar, el consenso sin líder y poscuántico de Lux, enlazado de forma nativa dentro del servidor C++. La costura es real: un programa C++ ya maneja el motor de consenso nativo a través de su C ABI — abrir una cadena, anexar una entrada del registro de replicación, empujar los votos de confianza, observar la finalidad — con cero Raft y cero maquinaria de conocimiento cero. Esa es la prueba de que el cambio es un problema de enlace, no una reescritura. Todavía no es la capa de coordinación de producción, y no vamos a fingir que sí.

La otra mitad

Datastore es OLAP. La mitad OLTP de la plataforma es un motor SQL descentralizado armado sobre SQLite/Base: diseñado, en construcción, todavía sin salir. Si hoy quieren la historia de datos local-first y de un solo archivo, ese linaje ya se ve en Hanzo Brain, y el sustrato de almacenamiento sobre el que viajan las dos mitades es el que lanzamos en Hanzo Storage.

Córranlo

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

• Fuente: github.com/hanzoai/datastore
• Producto: hanzo.ai/datastore
• Docs: docs.hanzo.ai

La imagen arm64 ya está publicada; el build amd64 viene después por CI. Este es el backend de analítica y perspectivas que corremos nosotros: apunten sus eventos hacia él y consúltenlos de vuelta a velocidad columnar.