用户日志的收集传输存储架构设计讨论

上一篇我们分析了目前主流的用户日志采集方法：http://blog.csdn.net/tonylee0329/article/details/43705065，

本篇我们将要讨论是如何将这些日志传输到我们的存储系统以便于后续处理分析，会结合离线以及实时两条线来探讨。

目前我们采取的方案是这样的：

这样架构的考虑点：

1.先说离线，从日志传输和容错方面而言，rsync无疑是最好的方案，它基于日志的内容做增量传输，快速稳定而且高效

2.实时的这条路，前面的Flume和Kafka可替代的开源工具(如Scribe/RMQ)还是有的，但是考虑集成和性能，MQ还是用了Kafka，而传输则采用了Flume

3.离线和实时分开两条路

了解了其他公司的做法，有的是将日志都走实时，然后schedule transfer到HDFS，这样看起来好像是省了点事，但是细想想有诸多不便：

1.对于日志类数据量比较大的，在Flume这块一般都是使用memory channel，而不是FileChannel，这样就有可能因为应用本身或者网络而出现丢数据问题，如此设计的话，数据是无法补救的；

2.需要维护每次schedule consumer的offset，对于后面更为复杂的BI/ETL需求更为麻烦。

但是如果现有的架构要放到和RDBMS一起的整个Databus（离线和在线），觉得接入方面还是相对较难，期待看到更多的设计,也多多学习！