timeTunnel的学习

采集数据(通过TT的client API)：

APP直接写

tailfile

dbsync

dfswriter向HDFS写数据--向云梯写数据格式固定，sequence file，基于key-value

storm从TT读数据，进行实时计算。

TT可以认为是“持久化的队列”，持续的流处理。

TT与datax的比较：

如果把datax做持续的导数据，效果可以与TT等同。

两者各有侧重点，一般可以让datax做一次全量，然后由TT进行增量，最后进行merge。

TT比较关注吞吐量，TPS不高，受限于带宽。

发送给TT的数据，在client端进行进行了压缩，目前用的压缩算法为gzip(大概4倍的压缩比)

TT的接入：

1，需要在日志服务器上安装TT的agent(agent是TT的监控程序)，与TT服务器有心跳检测。

2，在TT的配置中心配置日志路径等配置

3，agent启动时，会与中心进行连接读取配置信息。如果本机没有采集进程，则会去下载安装。启动采集程序，读取配置，通过client api与TT进行数据传输，保持长连接。

4，client从router获取broker后，进行直接通信，协议为thrift。broker充当proxy的作用，向hbase写数据，以后存储可以改换成其他的。

5，broker从多个partition读数据，然后merge，返回给client。当然了，client也可以在API中指定访问的具体partition，参数上有控制。

topic对应一张表，多个queue，可以并发写，提高吞吐量。

一张表中可以存储多个应用的数据，通过属性来区分属于哪个应用，可以通过hbase的filter进行查询。

队列对应到分区。

考虑到性能，可以针对表预先建region，减少split提高写的性能。

Rowkey的设计：

sequence:一秒内的计数，后续会将rowkey用字符串的方式来表示，目前是bytes不太可读和维护

目前TT上的表数据会保留三天，以免业务上需要重新读取。