Hypertable是一个开源、高性能、可伸缩的数据库，采用与Google的BigTable相似的模型。BigTable让用户可以通过一些主键来组织海量数据，并实现高效的查询。Hypertable和HBase分别是BigTable的两个开源实现：HBase主要使用Java语言开发，而Hypertable使用Boost C++，另外在一些细节的设计理念上也有所不同。
Hypertable系统主要包括Hyperspace、Master和Range Server三大组件（如图1所示）。Hyperspace是一个锁服务，地位相当于Google的Chubby，主要用于同步、检测节点是否发生故障和存放顶层位置信息；Master主要用于完成任务分配，未来会有负载均衡以及灾后重建（Range Server失效后自动恢复服务）等其他作用；Range Server是Hypertable的实际工作者，主要负责对一个Range中的数据提供服务，此外它还肩负起灾后重建的责任，即重放本地日志恢复自身故障前状态；另外，还有访问Hypertable的客户端Client等组件。
图1 Hypertable原有架构示意图
业务应用
Facebook在SIGMOD 2011会议上介绍了基于Hadoop/HBase的三种应用系统：Titan（Facebook Messages）、Puma（Facebook Insights）和ODS（Facebook Internal Metrics）。Titan主要用于用户数据存储，Puma用于MapReduce分布式计算，ODS用于存储公司内部监控数据，Facebook基于HBase的应用方式与国内几大互联网公司类似。
和ODS类似，对于一些硬件或软件的运行数据，我们会保存监控数据到数据库中，供软件工程师或者运维工程师查询。这里的查询可能是大批量的，也可能是个别条目；可能是延迟查询，也可能是即时查询。将此类业务的需求总结如下。
- 要求存储容量非常大，往往达到10～100TB，10亿～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实际上覆盖了一个200MB的Range，所以任何一台包含METADATA的Range Server发生故障，都可能导致这部分METADATA所涵盖的一大批数据不可访问。将METADATA分布到多个不同的Range Server上，无异于给系统增加了很多单点，降低了系统可靠性。
解决：本着简单原则，我们认为将元数据与用户数据分离，放在专用的Meta Range Server上更具有可操作性。元数据集中化的唯一缺点是，由于受Meta Range Server内存限制，32GB物理内存所能存放的元数据理论上只能支持上PB的用户数据。但考虑一般机房所能容纳的机器规模，PB级的数据规模完全可以满足大多数公司的需要。