[置顶] Hummer TimeSeries DB 技术架构介绍

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

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

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

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

 

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

数据存储层：

Master 

     Master 负责工作有:

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

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

    Node 体系架构

•  Node 采用Share Nothing 架构，各node 之间无共享状态。因此具有高可扩展和高性能。
  
•  HA： Node 管理多分片，而分片的HA和一致性由ZAB协议保证。
  

 

Zookeeper

    Zookeeper 负责工作有

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

SQL查询层 

• statestored 负责服务实例的状态监控（类似zk的作用）
  
• catalogd 负责原数据（表信息）同步
  
• impalad 负责SQL并行查询

我们主要的改造有：

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

离线计算层：

JobTracker、TaskTracker ／ ResourceManager 、NodeManger 

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

监管层：

• zabbix agent  ： 负责收集物理机器和各服务实例的运行状态
  
• zabbix server ： 收集和记录各指标 
  
• console manager    ：提供交互式运维操作的 Web Service 服务

Hummer TimeSeries DB Dock DEMO 介绍文章和下载见 http://blog.csdn.net/kanghua/article/details/44653149