Hummer TimeSeries DB 技术架构介绍

浏览数：34 / 时间：2015年06月12日

Hummer Timeseries DB 系统架构主要特点有：

A. Hummer Timeseries DB 系统采用分层模块化设计，各层之间和各模块之间属松耦合关系。分层结构利于既各功能层独立演化，且容易代码维护；另外在使用部署时根据场景需要进行取舍。
B. 与优秀开源软件实现对接，既避免了再造轮子（比如使用改造impala作为并行查询层、使用zabbix 作为系统监控层）的麻烦，同时也帮助我们融入了技术主流环境。

Hummer Timeseries DB 系统主要含四个逻辑层次（子系统），分别是：

数据存储层 (HummerStore) : 数据存储系统是自主开发的一套基于key value的分布时存储系统，其负责分布式数据存储、查询和元数据管理等工作。它包含主要组件有 Zookeeper 、 Master 、 Node。
SQL并行查询层（Impala）：SQL查询系统负责执行SQL解析，执行计划制定执行等动作。这里借助的是开源SQL查询分析系统impala的演绎（fork）系统 —— 对其进行了特定目的改造（替换默认的hdfs为hummerdb作为数据存储、优化面向时序查询和分析）。它包含主要组件有 Statestored 、 catalogd 、 impalad
离线计算层(MR／MR2）：离线计算系统采用Hadoop的Map/Reduce计算框架，即实现了MR/MR2需要的数据操作接口（ InputFormat/OutFormat For HummerStore）。它包含JobTracker、TaskTracker ／ResourceManager 、NodeManger
监管层(Manager) ：监管层负责监控机器和各服务实例全生命周期活动，并汇报必要的性能计数 —— 机器和服务实例监控等使用zabbix监控系统 ; 同时提供了管理员操作Console UI 。它包含主要组件有 zabbix agent/server ，Console Manager

主要模块功能介绍和技术简介：

数据存储层：

Master

Master 负责工作有:

维护系统原数据：元数据有— 表信息［时序表/对象表，唯一Key/非唯一key , 列数据类型］、分片信息［机器位置、数据路径］等，原数据存储在mysql 中。
数据副本一致性维护： master 负责维护数据副本的伙伴关系（如选举主副本、加入和退出副本组）。具体操作需要和Node配合 —— 一致性算法类似zk使用的zab协议。
负载均衡、故障恢复： master 会负责数据迁移、扩容、缩容等调度工作
维护操作界面：管理命令统一由master 接收处理（如建表、删表、分片迁移、负载均衡等）

Master 体系架构:

Master HA ：多个Master之间是active - standby 关系（一个活跃，其余的待机）；由于Master实例属于无状态服务（所有信息存在mysql中），当active master发生故障时，可实时切换 —— 状态切换依靠zookeeper实现，即当zookeeper发现活跃master故障，则从 standby 的master实例中选择一个提升为active master，继续对外服务。
Mysql HA : 多个Mysql 之间采用环形binlog复制。当主Mysql 实例故障发生，则上述active Master 将负责将从mysql实例提升为主，并切换访问到新主上。

Node

Node 负责的工作有

写数据多副本同步： node 负责接收对分片的数据写入，并根据分片的伙伴关系，实施多副本间的数据同步。
负责数据读取和数据扫描：node 也要负责根据精确key的随机查询，或按范围的批量扫描。
负责数据持久化存储：持久化存储引擎我们使用特殊修改的Leveldb —— 去掉了WAL（node已经有WAL机制）、实现面向时序的排序算法、在merge中实现区间删除、引入LZ4压缩算法、分盘实现merge线程、修改SST 文件格式已优化统计功能等等。
分片选举：配合Master 实现分片主从选举
数据迁移：配合Master 调度指挥，实现数据分片在线迁移。

Node 体系架构

Zookeeper

Zookeeper 负责工作有

监听node实例是否在线：发现node实例故障则，master 会得到通知，并执行其对应的分片选主。
监听master实例是否在线：发现active master实例故障，则唤醒standby的master，并提升其为active master
负责记录少量的状态变量（如迁移执行计划和执行进度快照）
维护逻辑地址：master 的逻辑地址到物理地址映射关系记录在zookeeper中，master 切换时会更新映射关系。从而api等可根据逻辑地址找到实际物理地址

SQL查询层

我们主要的改造有：

catalogd ：表的原数据获取需要通过HummerDB的Master获取表分片位置信息，并告知impalad
impalad ：执行计划中将时间和key相关谓词下推到Node的扫描操作上（由于HummerDB针对时序的聚集排序，所以给定谓词下推到最下层的数据扫描处，无疑带来最高效率）
impalad ：根据分片数和分片位置实施物理执行计划（按分片数分配scan node、优先将scan node 下发到分片副本所在机器上“本地”执行）

离线计算层：

JobTracker、TaskTracker ／ResourceManager 、NodeManger

我们主要实现了对应的 HummerInputFormat 和 HummerOutputFormat 等接口

监管层：