Hypertable应用实践:比肩HBase

文 / 杨栋

Hypertable是一个开源、高性能、可伸缩的数据库,采用与GoogleBigTable相似的模型。BigTable让用户可以通过一些主键来组织海量数据,并实现高效的查询。HypertableHBase分别是BigTable的两个开源实现:HBase主要使用Java语言开发,而Hypertable使用Boost C++,另外在一些细节的设计理念上也有所不同。

Hypertable系统主要包括HyperspaceMasterRange Server三大组件(如图1所示)。Hyperspace是一个锁服务,地位相当于GoogleChubby,主要用于同步、检测节点是否发生故障和存放顶层位置信息;Master主要用于完成任务分配,未来会有负载均衡以及灾后重建(Range Server失效后自动恢复服务)等其他作用;Range ServerHypertable的实际工作者,主要负责对一个Range中的数据提供服务,此外它还肩负起灾后重建的责任,即重放本地日志恢复自身故障前状态;另外,还有访问Hypertable的客户端Client等组件。

 

图1 Hypertable原有架构示意图

 

业务应用

FacebookSIGMOD 2011会议上介绍了基于Hadoop/HBase的三种应用系统:TitanFacebook Messages)、PumaFacebook Insights)和ODSFacebook Internal Metrics)。Titan主要用于用户数据存储,Puma用于MapReduce分布式计算,ODS用于存储公司内部监控数据,Facebook基于HBase的应用方式与国内几大互联网公司类似。

ODS类似,对于一些硬件或软件的运行数据,我们会保存监控数据到数据库中,供软件工程师或者运维工程师查询。这里的查询可能是大批量的,也可能是个别条目;可能是延迟查询,也可能是即时查询。将此类业务的需求总结如下。

  •  要求存储容量非常大,往往达到10100TB10亿~100亿条记录。
  • 需要支持自动扩容,因为数据的增长模式不易估计,可能出现短时间的爆炸性增长。
  • 写吞吐的压力较大,每秒超过1万次的插入。
  •  近期导入数据能够快速检索。
  • 需要支持扫描早期的大量数据,例如支持周期性的检查或回滚。

这里可选的一个方案是使用传统的DBMS(如MySQL)。但它存在如下弊端:首先MySQL单机存储有上限,一般超过1.5GB性能就会有波动;不过即使MySQL支持拆表,也并非完全分布式的,由于表的大小限制,对于不规则的数据增长模式,分布式MySQL也并不能很好地应对,如果抖动频率较大,需要引入较多的人工操作来进行数据迁移;再者MySQL也不支持表的Schema动态改变。另一个可选方式是使用Hadoop。不过MapReduce并非实时计算,并且HDFS不支持随机写,随机读性能也很差。

综上分析,我们选择BigTable类型的系统来支持业务需求,即使用Hypertable+Hadoop的方式(如图2所示)。

 

图2 监控数据收集与查询示意图

 

高可用改进

元数据集中化

挑战:Hypertable或其他类似BigTable的系统中,元数据一般采用一种两级的类B+树结构,这主要是出于规模的考虑:采用这种结构理论上可以支持存放并索引2EB的用户数据。若要索引这么多用户数据,所需的元数据就高达16TB,一台机器是存不下的,因此在类BigTable系统中,元数据也是分布在不同节点上进行管理的,集群中任意一个节点既可能包含用户Range也可能包含元数据Range

虽然这种做法可以解决规模问题,但在管理上带来了一些困难,特别是进行故障恢复时,由于用户表的Range恢复过程中需要读取元数据,所以必须先恢复METADATA表中的Range,再恢复用户表中的Range。如果有多台Range Server同时故障,这种跨节点的依赖性处理起来非常困难,其他一些维护性操作同样具有类似问题。此外,由于一条METADATA实际上覆盖了一个200MBRange,所以任何一台包含METADATARange Server发生故障,都可能导致这部分METADATA所涵盖的一大批数据不可访问。将METADATA分布到多个不同的Range Server上,无异于给系统增加了很多单点,降低了系统可靠性。

解决:本着简单原则,我们认为将元数据与用户数据分离,放在专用的Meta Range Server上更具有可操作性。元数据集中化的唯一缺点是,由于受Meta Range Server内存限制,32GB物理内存所能存放的元数据理论上只能支持上PB的用户数据。但考虑一般机房所能容纳的机器规模,PB级的数据规模完全可以满足大多数公司的需要。

 

图3 Hypertable高可用改进架构示意图

 

3给出了Hypertable元数据集中管理的整体结构。目前的实现将Hypertable中的数据服务器(Range Server)分为两种:Meta Range ServerUser Range ServerMeta Range Server只管理Root表和METADATA表的RangeUser Range Server只管理用户表的Range。由于Master的负载较轻,因此一般将Meta Range ServerMaster放在同一个节点上。

系统启动时,每个Range Server从配置文件得知自己的类型,并在注册时汇报自己的类型。Master记录每台Range Server的信息。当Master需要将Range分配给Range Server时(例如表格创建和Range分裂),会根据Range所在表格的类型来选择合适的Range Server,元数据Range分配到Meta Range Server,用户Range则分配到User Range Server