Apache HoraeDB（孵化中）是一款高性能、分布式的云原生时序数据库，由蚂蚁集团捐赠并贡献至Apache软件基金会，核心技术源自蚂蚁自研的CeresDB。其设计目标是解决传统时序数据库在高基数标签场景（如物联网设备、金融交易监控）下的性能瓶颈，同时支持分析型负载与实时查询的混合工作流。其技术原理和架构设计深度贴合时序数据 “高写入、高基数、查询模式固定、冷热分化明显” 的核心特性，通过混合存储引擎、分布式架构、高基数优化三大技术支柱，实现了性能、成本与扩展性的平衡。
项目地址：https://github.com/apache/incubator-horaedb
一、技术原理
HoraeDB 的技术设计围绕时序数据的核心挑战（高写入吞吐、高基数标签处理、低成本存储、实时查询响应）展开，核心原理可归纳为四大方向：
1.混合存储模型：兼顾写入性能与查询效率
时序数据的 “写入密集” 与 “查询聚合” 特性存在天然矛盾：写入需要低延迟、高吞吐（适合行存），而查询多为列维度聚合（适合列存）。HoraeDB 采用内存行存 + 持久化列存的混合模型解决这一矛盾：
内存层（MemTable）：
采用行式存储结构，直接承接实时写入的数据（如智能手表的每秒心率、步数）。行存无需列维度重组，写入延迟可低至毫秒级，且支持原地更新（如设备状态标记）。同时，MemTable 内置 LRU 淘汰机制，避免内存溢出，当数据量达到阈值（默认 64MB）时，异步触发 “刷盘”（Flush）操作。
持久化层（SSTable）：
刷盘后的数据转为列存格式（基于 Parquet 优化），按时间线（Time Series）和时间范围分区存储。列存的优势在于：
高压缩比：相同数据量下，列存压缩后体积仅为行存的 1/10~1/5（Parquet 的字典编码 + LZ4 压缩），大幅降低存储成本；
聚合加速：查询 “某设备一周内平均穿戴时长” 时，仅需扫描 “时长” 列，避免无关列的 I/O 开销，比行存查询快 5~10 倍。
2.高基数标签优化：突破传统索引瓶颈
时序数据中，“标签（Tags）”（如设备 ID、用户 ID）的基数（不同值的数量）常达千万甚至亿级（如亿级用户的智能手表），传统时序数据库（如 InfluxDB）的 “全局倒排索引” 会导致内存爆炸和查询抖动。HoraeDB 采用去倒排索引 + 多级剪枝策略解决高基数问题：
去全局倒排索引：
摒弃对所有标签建立全局倒排索引的方案，转而通过 “时间范围 + 标签值域” 的二级过滤实现高效查询。例如，查询 “设备型号 = A 且 2025-08 月的穿戴时长” 时，先通过时间范围定位到 8 月的 SSTable 分片，再在分片内过滤 “设备型号 = A” 的标签，避免全表扫描。
动态索引策略：
针对低基数标签（如设备型号，可能仅 tens/hundreds 个值），自动构建内存倒排索引（标签值→数据地址），加速查询；针对高基数标签（如用户 ID，亿级值），则依赖 SSTable 的 “标签列排序 + 布隆过滤器”：标签列按值排序后，可通过二分查找快速定位范围，布隆过滤器则提前过滤不存在的标签值，避免无效 I/O。
通过该策略，HoraeDB 在高基数场景下的内存占用仅为传统方案的 1/3~1/5，查询成功率从 60% 提升至 90% 以上（蚂蚁集团内部数据）。
3.分布式查询引擎：向量化 + 分区感知优化
时序数据的查询常涉及 “跨分片聚合”（如统计全国所有设备的日均穿戴时长），HoraeDB 基于向量化执行 + 分区感知调度实现高效分布式查询：
向量化执行：
基于 Apache Arrow 内存格式，将数据按 “批次”（Batch）而非 “单行” 处理。例如，计算 100 万条穿戴时长的平均值时，向量化引擎一次性加载 64KB 数据块（约 1 万行），通过 CPU 指令级并行（SIMD）完成计算，比行式逐条处理快 3~5 倍，CPU 利用率提升 30% 以上。
分区感知查询计划：
数据按 “时间 + 哈希” 双维度分区（如按天分区，每天内按设备 ID 哈希分片），查询时 HoraeDB 的优化器会根据分区键自动过滤无关分片。例如，查询 “近 7 天数据” 时，仅调度近 7 天的分片参与计算，避免扫描历史冷数据。
4.云原生一致性与可靠性：WAL+Raft 协议
时序数据（如医疗设备监控）对 “不丢数据” 要求极高，HoraeDB 通过预写日志（WAL）+ Raft 元数据同步保证强一致性：
WAL 机制：
数据写入时，先写入独立的 WAL 服务（多副本持久化），再更新 MemTable。WAL 采用本地磁盘存储（最新版本替换 RocksDB，降低依赖复杂度），支持异步刷盘，确保 “写入确认” 前数据已持久化，RPO（恢复点目标）≈0。
元数据 Raft 同步：
集群元数据（分片分布、节点状态）由 HoraeMeta 集群管理，基于 Raft 协议实现多副本同步，确保元数据一致性。当节点故障时，HoraeMeta 自动触发分片迁移，RTO（恢复时间目标）< 30 秒。
二、技术架构
HoraeDB 采用 “计算与存储分离” 的云原生架构，支持水平扩展和弹性伸缩，核心组件包括 HoraeMeta 集群、HoraeDB 实例节点、WAL 服务、对象存储 四部分，架构图如下（简化版）：
plaintext
[客户端] → [负载均衡]
↓
[HoraeMeta 集群（Raft 同步元数据）]
↓（路由信息）
[HoraeDB 实例节点（无状态，水平扩展）]
↙ ↓ ↘
[WAL 服务] [MemTable] [SSTable]
↘ ↓
[对象存储（S3/HDFS）]
1.HoraeMeta 集群：元数据管理与调度中心
核心功能：
维护全局元数据：包括表结构、分片规则（时间 / 哈希分区）、节点健康状态、数据分片与节点的映射关系。
分片调度：当节点扩缩容或故障时，自动重新分配分片，确保负载均衡。
高可用：基于 Raft 协议部署 3~5 个副本，多数派存活即可提供服务，避免单点故障。
交互流程：
客户端首次连接时，先向 HoraeMeta 请求 “数据路由”（某条数据属于哪个分片、由哪个实例节点处理），之后直接与目标实例节点通信，减少中间层开销。
2.HoraeDB 实例节点：无状态计算节点
核心功能：
数据读写：接收客户端请求，完成 MemTable 写入、SSTable 读取 / 合并（Compaction）。
计算执行：基于向量化引擎处理查询（过滤、聚合、排序），跨分片查询时协调其他节点并行计算，最终汇总结果。
无状态设计：节点本身不存储数据（数据在 WAL 和对象存储），仅缓存热点数据，支持秒级扩缩容（新增节点直接加入集群，由 HoraeMeta 分配分片）。
数据生命周期：
写入：客户端 → 实例节点 → 写 WAL（确认持久化）→ 写入 MemTable。
持久化：MemTable 满后 → 异步刷盘为 SSTable → 定期将冷 SSTable 迁移至对象存储。
读取：合并 MemTable（最新数据）和 SSTable（历史数据），返回结果。
3.WAL 服务：独立日志存储
设计目标：确保数据写入的持久性，与计算节点解耦（避免实例故障导致日志丢失）。
实现：采用多副本部署（默认 3 副本），支持按时间范围切分日志文件，便于清理过期数据。最新版本（v2.1.0）改用本地磁盘存储（替代 RocksDB），降低编译复杂度，写入延迟降低 20%。
4.对象存储：冷热数据分层
作用：存储冷数据（如 3 个月前的历史穿戴数据），兼容 S3、HDFS、OSS 等主流对象存储，实现存储成本优化（对象存储单价仅为本地 SSD 的 1/10）。
访问优化：通过 Apache OpenDAL 统一接口抽象不同存储系统，实例节点读取冷数据时，先缓存至本地磁盘，避免重复远程 I/O。
三、性能对比与行业案例
| 维度 | HoraeDB | InfluxDB 1.8.x |
|------------------|-----------------------------------------------------------------------------|-----------------------------------------------------------------------------------|
| 写入性能 | 吞吐量稳定，长期平均为InfluxDB的1.5倍，高并发下延迟更低。 | 初始快但随数据量增加性能下降，高基数场景内存开销大。 |
| 查询性能（聚合） | 全库扫描查询比InfluxDB快26倍（如统计3个月内所有设备的日均穿戴时长）。 | 大范围扫描耗时长达6分43秒，I/O开销高。 |
| 内存占用 | 随时间线增长平缓，高基数场景内存占用仅为InfluxDB的1/3。 | 全局倒排索引导致内存线性增长，高基数场景可能占用数十GB。 |
| 扩展性 | 原生支持水平扩展，添加节点可线性提升吞吐，支持多数据中心双活。 | 开源版不支持横向扩展，企业版需付费且架构复杂。 |
行业落地案例：
蚂蚁集团金融监控：处理日均千万级时序数据点，查询成功率从60%提升至90%以上，支持实时交易异常预警。
智能设备场景：某可穿戴设备厂商通过HoraeDB存储用户行为数据，查询设备型号与穿戴时长的关联分析效率提升8倍，助力产品功能优化。
四、适用场景与选型建议
1.核心场景：
物联网（IoT）：设备状态监控、传感器数据存储（如智能手表的心率、步数数据）。
应用性能管理（APM）：服务调用链追踪、日志分析（如识别影响穿戴时长的系统瓶颈）。
金融交易：高频交易监控、市场波动分析（如实时股票交易数据的毫秒级写入与查询）。
2.选型优势：
成本敏感型企业：列存压缩与对象存储分层可降低长期存储成本70%，适合中小规模数据量。
技术驱动型团队：开源生态开放，支持二次开发（如自定义索引策略），适合深度整合至现有技术栈。
高可用需求场景：多数据中心双活、RPO≈0的容灾能力，适合金融、医疗等对数据可靠性要求极高的行业。
五、结言
Apache HoraeDB通过云原生架构、混合存储与高基数优化，重新定义了时序数据库的性能边界。其开源生态与蚂蚁集团的生产级实践背书，使其成为智能设备、金融、物联网等场景的理想选择。无论是快速构建实时监控系统，还是应对亿级数据点的分析挑战，HoraeDB均能以更低成本、更高效率满足需求。
