最近搞日志处理，注意是日志处理，如果用流计算处理一些金融数据比如交易所的行情数据，是不能这么“粗鲁”的，后者必须还考虑数据的完整性和准确性。以下是在实践过程中的一点点小总结，提供给日志分析的盆友参考，也欢迎大家来分享您遇到的一些情况：
（一）
flume到kafka的实时数据优于单条过快，造成storm spout消费kafka速率跟不上，这个延时主要是数据发射到stream中后进行hbase的计算操作引起的（这部分已经用内存计算进行优化处理）。分析tuple的特点，tuple每条log都很小，数量大，如果用现在的spout，会照成tuple在stream中的大量堆积，造成超时自动回调fail()的函数（但是其实这里不影响结果）。
storm的几个特点参考http://www.aboutyun.com/thread-8527-1-1.html
（1）storm单条流水线的处理能力大约为20000 tupe/s, (每个tuple大小为1000字节)
（2）storm系统本省的处理延迟为毫秒级，Jvm GC一般情况下对系统性能影响有限，但是内存紧张时，GC会成为系统性能的瓶颈。
实践中我们发现，tuple过多，由于kafka的message需要new String()进行获取，会报gc的异常。
以上的一些情况和现象，我觉得可以进行多tuple结构的优化，对多个log打包成一个tuple进行发射处理。
不过，就一般情况而言，单条发射已经足够速度很效率
（二）
kafkaspout获取的数据，就我的业务而言，不需太注重数据的完整性，所以，在整个stream中，避免使用ack和fail的，即spout获取到数据后，发射出去就不再关心这条数据是否被正确处理或者超时等情况
（三）
有一个误区，曾经又一次控制了spout获取的速率，发现fail的数量基本很少，但是在一次补数据的时候，spout获取了千万条基本的数据，而bolt有一个业务是频繁交互hbase，造成了stream中的数据大量堆积和延时，ui显示fail的数量巨大，开始以为是处理失败造成的，后来对比数据发现，计算结果并没有多少失误，猜想可能就是因为超时回调了fail函数。
（四）
落地为hbase的，虽然hbase的效率已经不错，但是发现，对于某些业务，仅仅采用hbase，还是有较大的延时，因此，可以将一些经常使用的数据表同步到内存中，可以设计成map等结构进行计算，关键点是要同步hbase，不然storm或者work挂了后启动就会有计算失误了。
（五）
一些可能的BUG
（1）zk集群宕机，这个错误是很不应该的，但是，我出现了，造成了storm宕机，而且我的数据后端是hbase，所以所有计算都失败了，所以最好有一个监控系统可以检测zk、hbase、storm等基础平台工具，免得查错浪费时间；
（2）kafkaspout中有一个线程如果不断的从kafka中获取数据并new String()解析后发射，有可能报异常： java.lang.StringIndexOutOfBoundsException: String index out of range: 2，这个BUG不是必然，但是我偶然出现了，计划直接将Byte[]作为tuple进行发射到bolt中处理。
（3）可恶的INFO日志
由于开着INFO级别的日志配置，storm emit和ack的info日志太多，我这边1个小时差不多1g左右的日志，加上kafka消费端的请求日志，好几次都把磁盘刷爆了，导致服务器宕机，这个要严重注意，我目前的处理方法是吧info改成warn级别。不知道有没有更好的方法~
（4）开源kafkaspout
开源kafkaspout有好几个，git上有，但是有些对环境要求有约束，需要注意，如果是简单的，像我这样要求不高的应用，完全可以自己用kafka的消费实例进行开发。
