采集数据(通过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上的表数据会保留三天,以免业务上需要重新读取。