hypertable架构与使用实践

uIMG的存储使用的是hypertable， 一个CPP版本的bigtable方案，它提供大数据存储，也提供了缓存，相对KV系统，它的功能和可管理性更强。

调用栈
Hypertable处于大数据生态系统调用栈的中间，在DFS的之上，它依赖DFS作为底层存储；在各种runtime-script之下，开放了灵活的高性能接口提供给业务策略使用。

这是官方提供的一个HBASE和Hypertable的性能测试比较图，写入都差不多，因为瓶颈都是在IO。读取的话，如果随机读Hypertable大概是HBASE的两倍，顺序读的话，目测速度差异大概在10%~20%。

如果随机读的话，大部分会在内存中命中。顺序读基本是读磁盘，所以开销不大。设计比较好的CPP操作CPU，内存和网络的整体性能比JAVA高出50%~100%。

系统进程

Hypertable的进程，一共有六种进程，四个是系统进城。下面按照其启动顺序来说。
核心组件： hyperspace->dfsbroker->master->rangeserver
可选组件：【thriftbroker, monitor】

1. hyperspace是一个类似HBASE中的zookeeper或者bigtable中的chubby，提供锁管理和元数据管理。在该系统中的功能有：
   1. master的leader选举
   2. key range在rangeserver的分布(location)
   部署时是一主多备，主是配置时候的第一个；从提供备份和加锁选举，没用到查询分流，当然流量也不大。
2. DFSBroker， 文件系统抽象层，支持Hadoop，KFS，或者本地文件系统-local等。需要运行在master和range server上。
3. Master，元数据管理，运行信息采集和range server Fail-Over管理。元数据管理就是涉及到表空间或者表操作，rangse server的管理涉及到ranger server状态探测和数据迁移。
   单机服务，支持HA。
4. Range-Server, 数据中心，负责具体实体数据的读取和写入。 这些数据都是放在内存和DFS上的，因此本身一定程度来说是无状态的。Master随时可以将其负责的数据职责转移到其它机器上。部署n个，每个负责不同的数据。
5. 可选组件，thriftbroker， 整个系统的一个对外的接入接口，应用可以通过thrift客户端来对系统进行操作，使用代理的方式，可以轻开发，轻客户端，另外其缓存重用也适合cgi这种用了即丢方式，否则启动时的读元数据信息都是秒级的。可以部署n台。
   
6. 可选组件monitor，展现master采集的各种状态信息，只在active的master上有意义

运行图

读取的过程，先检查内存中的Cell，如果不命中，穿透内存去查询DFS上的数据。
写入的过程，使用了同levelDB一样的LSM方案(The Log-structured Merge Tree) , 先将操作log写到DFS中，成功后更新内存中的cell 树中。然后在维护操作，将内存中的Cell批量更新到DFS中（cellcache->cellstore），同时trunk log文件。

数据存储, KV都是放在一起的。查询的过程是根据【range key】==>【range server】==>【CellCache】==>【CellStore】；Cell内部，[bloomfilter]==>[keyrange]==>[KV]

数据结构分析
hypertable是列存储，内部实现上是基于KV的。

我们先看一下KEY, Key一共有四个维度，第一个是ROW，包含了多层的表空间，表，业务中的主键，第二维度是列名，第三维是列名修饰符，第四维是数据版本，可以支持多个版本，这里用的是64位的时间。
（列名和列修饰符是，如果匹配到列名，相当前缀匹配，结果包含了咧修饰符。使用上，比如你爬到一群anchor，主键是anchor，值是被爬的数量，但是想针对几个大网站具体采集的次数分开处理，因此你可以将com.sina, com.uc作为列修饰符，使用的时候你可以全部的列也可以特定的网站的情况）。在平时应用中更方便，比如我们经常会因为业务的变化需要对表结构改变，但是这些比较重的操作影响很大，很不敏捷，一个使用技巧就是不断的动态增加qualified，而不需要改表的schema。

接下来看它的VALUE， 也就是列，列支持4个修饰符。
MAX_VERSIONS,规范了同一KEY前缀（前3个字段)下，允许有多少个不同的timestamp版本
TIME_ORDER, 多version数据的输出排序，默认是最新的优先获取。
TTL, 周期数据的存活时间
COUNTER, 是否是计数数据，计数数据每次插入相同的前三KEY定位到的数据都会累加。

优化开关。
列索引，如果引用有需要经常对某列查询，建立索引加速查询。否则全表扫描后果很严重。
AccessGroup， 某几个字段需要经常查询或修改的话，可以让其物理上放在一起，分城不同的存储组，这样会加速访问速度。 每张表有一个默认AccessGroup存放所有字段。
AccessGroup有几个修饰词。是否仅存放在内存；是否支持压缩，用什么算法；是否打开Bloomfilter开关（row / row+col / none)，bloomfilter简单的解释就是多个健公用bitmap中的一位，可以快速的知道如果某健不存在的话。

使用
我们看一下它的检索，根据key的结构，这几个维度可以成为检索的过滤条件。ROW，也就是内容，他支持前缀匹配，正则匹配，或者全匹配；列名；列名修饰；Timestamp，这个是可以指定特例或者范围。
对列的查询也支持，跟ROW的内容查询是一样的。

这三个圆圈代表的是操作，不同的操作对检索的支持程度不一样。颜色越深权限越大，Select 最大，Insert最小。Insert只能操作指定主键的指定版本。

接入方式

shell， 跟mysql的客户端程序一样， 可以进去控制台增删改等交互操作，也可以用命令行方式批处理。

Hadoop stream mapreduce， stream是基于管道，支持脚本或应用对标准输入处理输出到标准输出中。hbase提供扩展支持输入和输出数据源都是Hypertable的表。（输入源支持数据过滤，过滤规则同前面的select相同）

ThriftClient,官方推荐使用，为什么说官方推荐，因为RAW API是没有文档的。

RAW API， 直接使用hypertable的lib编译，运行时会直连hypertable各个组件。

这个是RAW API和Thrift的性能测试比较，对于读取操作来说，使用RAW API远快于通过thrift中转。这并不是说thrift烂，这种已经用到烂的代码一般优化空间已经很小了，这跟使用场景还有具体情况跟测试方式，还有基于thrift实现的代码有关。中转一次性能会损耗40%这个正常了（解码，转发等操作），除此之外，当时测试只用到了10个线程，对于thrift这种采用了同步IO方式的哥们来说是不公平的。（thriftbroker使用的是TThreadedServer，每个链接一个线程，thrift使用的都是同步IO，相对来高并发来说网络性能会差点)。

uImg实战
space的repica数目，要不就1个，要不就3个，如果两个的话，系统会一直死锁，估计跟其加锁方式有关。
dfsbroker，我们系统用的不是程序指定的版本hadoop版本，系统捆绑的是cdh4管理hadoop版本，需要yum安装，这个不符合我们运维策略，所以我们安装的是hadoop官方2.1版本。这个导致了jar包不一致，因此也需要升级对应的JAR包，另外，里边有些函数发生了改变，会引起运行时错误，也需要对dfsbroker的代码做少量修改。
ssh port，线上环境都是9922，默认是22端口，无法改变端口，可以改变环境变量，让ssh-client的port改成22

开发接口
在图片处理核心我们使用的RAW API，原因就是基于上图。
管理端用的是thrift api，因为我们的管理端用的是RUBY，另外cgi这种方式肯定是用broker性能最好的。

数据的使用
首先看一下我们的图片数据。
我们针对每个账号创建一个命名空间，自定义路径的前两级自动进行分表，其余路径作为表中的主键。分表的意义主要是为了统计方便。系统可以对每张表生成统计数据包括容量，平均键值和图片大小，插入和查询各项统计数据。
对于数据，我们使用了max_versions=1限制，无压缩，因为对图片这种数据无损压缩，压缩率很低，因此干脆不压缩。

周期图片，和短链
键值设计跟图片一样，对数值我们增加了TTL限制，可以让它自动过期，想续约也简单，重新设置一下相同的KEY和相同的VALUE可以。

Metric数据，像那些访问量这种累加的数据，我们对相应列增加COUNTER限制，不同机器可以原子的增加其统计计数；另外，，对不同时间粒度的数据过期时间不同。

系统事件，和配置我们也放到hypertable中；事件去掉MAX_VERSIONS限制，因此发生事件时，我们重复INSERT就可以了，系统可以自动记住事件发生的时间。在系统中，我们以事件类别建表，发生事件服务器作为主键。
对于配置，我们限制MAX_VERSIONS为1000，保存1000份。

它的数据类型不丰富但是却很适用，面向的就是海量存储，大表性能有保证。


Q&A:
社区不活跃，发展堪忧？
不是活跃的东西就是一定发展比其它好，这么说现在一直是hadoop或者mysql,memcache等的天下了，怎么还会有其它的不同产品。而且设计这种东西不是人多力量大。
另外有bug，很多东西都是可以规避而不是必须要硬挑的，我们用东西都是用适合的，正常的流程，无需去挑战极端。成熟架构的代码，仅仅代码级的优化是没啥意义。