오늘 공개하는 Hanzo Datastore: 포스트양자 시대의 분석에 대비한 열 지향 OLAP 엔진

오늘 우리는 Hanzo Datastore를 내놓습니다. Hanzo 데이터 플랫폼의 OLAP 절반입니다. ClickHouse 26.6의 포크이며, 브랜드를 걷어 내고 우리가 실제로 분석을 운영하는 방식에 맞춰 다시 지었습니다. 저장은 계산과 분리되어 Hanzo S3에 두고, 최적화된 바이너리는 더 가벼우며, 낡은 RPC 표면은 제거했습니다. 이미지는 ghcr.io/hanzoai/datastore:26.6.1.1에서 받을 수 있습니다.

새 데이터베이스를 쓴 것이 아닙니다. ClickHouse는 세계에서 가장 뛰어난 열 지향 엔진이고, 우리는 그 위에 서 있습니다. 바꾼 부분은 머신 무리를 운영할 때 중요한 것들입니다. 저장 기반, 빌드, 전송, 그리고 조율의 로드맵입니다.

저장과 계산을 나누다

MergeTree 테이블의 파트는 불변 객체입니다. Datastore는 그것을 한 서버에 붙여 둔 로컬 디스크가 아니라 Hanzo S3 위의 객체로 둡니다. Hanzo S3는 SeaweedFS에서 갈라져 나온 우리의 저장 계층입니다. 상태가 없는 계산 복제본은 제로 카피 복제를 통해 데이터의 물리적 사본 하나를 함께 씁니다.

이것은 포부가 아니라 증명된 사실입니다. 확장 시험에서, 저장 정책이 S3를 가리키는 5백만 행 테이블은 system.parts에서 디스크 seaweed를 보고하고, 계산 노드 두 대가 그 단일 사본 위로 펼쳐집니다. 읽는 쪽을 더해도 데이터를 복사하지 않고 거기에 붙습니다. 분석 부하가 치솟아 테라바이트를 다시 배치하지 않고 몇 초 만에 질의 용량을 더해야 할 때 원하는 성질이 바로 이것입니다.

-- 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 패스를 돌립니다. 결과는 기본 빌드에 비해 상주 메모리가 대략 절반이고, 바이너리도 눈에 띄게 작아진 것입니다. aarch64에서 BOLT를 돌리려면 XRay 계측을 꺼야 했습니다. 그것은 기본으로 켜져 있었고, 링크 이후 다시 쓰기를 조용히 막고 있었습니다. 그 수정은 소스 트리에 들어 있습니다. 실제 효과는 같은 질의 계획, 더 적은 기가바이트, 그리고 더 빨리 뜨는 바이너리입니다.

gRPC는 사라졌습니다

데이터 저장소의 질의 경로는 정확히 하나여야 하고, 셋이어서는 안 됩니다. gRPC 서버를 통째로 걷어 냈습니다. contrib/grpc도 없고, protobuf 서비스 정의도 없고, ENABLE_GRPC 빌드 경로도 없습니다. 같은 과정에서 기본 설정에 남아 있던 죽은 <grpc> 블록도 지워, 나가는 제품이 빌드와 맞도록 했습니다. Datastore가 말하는 것은 네이티브 TCP (9000), HTTP (8123), 서버 간 복제 (9009)입니다. 표면은 이것이 전부입니다.

앞으로의 전송으로 둔 것은 Cap'n Proto에서 갈라져 나온 우리의 RPC인 ZAP입니다. 서버 스텁은 들어왔습니다. 아직 실제 질의 경로는 아닙니다. 끝났다고 비치기보다, 그 선이 지금 어디에 있는지를 그대로 말하겠습니다.

조율이 향하는 곳

Replicated* 테이블은 오늘 내장 Raft, 곧 서버 프로세스 안에 함께 실려 오는 ZooKeeper 호환 Keeper를 통해 조율합니다. 따로 도는 데몬은 없습니다. 이것은 동작하고, 프로덕션에서 지금 돌리는 것이 이것입니다.

방향은 그 Raft 백엔드를 Quasar로 바꾸는 것입니다. 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를 통해 뒤따릅니다. 이것은 우리 자신이 돌리는 분석과 인사이트 백엔드입니다. 이벤트를 여기로 보내고, 열 지향 속도로 다시 질의하십시오.