轉自：http://www.aboutyun.com/thread-9216-1-1.html
使用Storm處理事務型實時計算需求時的幾處難點： http://blog.sina.com.cn/s/blog_6ff05a2c0101ficp.html
最近搞日志處理，注意是日志處理，如果用流計算處理一些金融數據比如交易所的行情數據，是不能這么“粗魯”的，后者必須還考慮數據的完整性和准確性。以下是在實踐過程中的一點點小總結，提供給日志分析的盆友參考，也歡迎大家來分享您遇到的一些情況：
（一）
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的消費實例進行開發。