tlog数据存储

Tlog 采用了 hbase+ 云梯的存储方案，分别对应实时和离线的数据服务，它们在 tlog 中的场景描述为：

实时服务—如查看近2分钟某应用的服务调用情况；检索一笔彩票订单目前的流程状态。它们的特点是数据粒度细、实时性要求高、不能重复计算或重复计算结果不一致、稳定性差

离线服务—如统计昨天提供调用次数最多的前10个服务；分析前一个月里售出彩种ID=1的总额最高的代理商和最低代理商，金额分别是多少。与实时服务相反，它们的特点是数据粒度粗、时间跨度大、能重复计算、结果一致稳定

       可以看出，实时和离线可以互补长短，为接入方提供多层次个性化的数据服务。当然服务的前提是有数据，也就是如何存下来，且在大数据量下必须是高效的、稳定的。

（1）写HBase

需要考虑两种类型的存储数据：一种是需要快速检索的业务数据，另一种是实时展现的统计数据。对于前者具体又可分为带唯一业务标识和不带唯一业务标识的情况，带唯一标识的如彩票检索，订单号就是唯一的标识号，只需将订单号设计为rowkey，再将该订单不同状态的日志放入同一column family(cf)的不同qualifier中就可以通过订单号快速检索该笔彩票的状态信息了；而没有唯一标识的业务类型在存储时可能导致rowkey冲突老数据被覆盖，如操作日志即使以日志类型+时间戳也不能作为唯一的rowkey设计，这时对整条日志采用碰撞率低的定长编码算法是一个很好方法，如CRC32，通过将编码放在rowkey的最后即可解决冲突的问题。如果存储的是基于时序的统计数据，对于hbase存储模型的设计就需要更加注意了，因为这类数据不仅量大（如秒级统计）而且往往附带按某种维度的聚合操作，设计不好就会给存储和查询带来性能问题。关于这类数据的存储，业界基于hbase的开源产品Opentsdb给出了解决方案，这里介绍下其schemal设计和异步hbase模型

Ø  OpenTsdb之Schemal设计：

 

 

Figure 1.1 opentsdb之Schemal

众所周知，与通常RDMS相比，hbase是一个schema-less、面向列存储的nosql数据库，定位一个列元数据至多会经过rowkey->cf->qualifier->version四层索引，其中cf必须在表定义时就指定无法通过后期动态扩展，而version的定位是通过timestamp解决cell数据冲突的，所以大多数实际情况下只有rowkey和qualifier两级索引可以利用。对于time-serial性质的数据，如果每个时间细粒度(假设为秒