Twitter 推出一個開源系統(tǒng)，旨在減低批處理和流式處理之間的交換，做法是把二者組合在一起成為一個混合系統(tǒng)。Twitter 用Hadoop做批處理，用Storm做流式處理，混合系統(tǒng)名為Summingbird。Summingbird沒法做每一件事，不過對完成其目標任務還是很方便的。

Twitter 博客發(fā)文公布了Summingbird，公布細節(jié)的技術成分很大。但是，如果你想想Twitter 如何運行的，本質(zhì)問題是很容易理解的。像Trending Topics(話題趨勢)和搜索一類的服務需要實時數(shù)據(jù)處理才會有用。但是最終還是需要準確性或許還要做一些深度分析。Storm有點像醫(yī)院里的治療類選科，而Hadoop則是長期患者護理。

以下是Summingbird項目Wiki的描述，在高層次上解釋了Summingbird如何運作，解釋得不錯，具體實現(xiàn)當然會稍微復雜一點：

Summingbird的混合模式可以讓 Hadoop處理大多數(shù)的數(shù)據(jù)，并且可以從Manhattan一類的只讀存儲得到服務。Storm 則只處理那些Hadoop沒有處理過的數(shù)據(jù)，那些限于延遲窗里的數(shù)據(jù)。這些實時數(shù)據(jù)來自數(shù)據(jù)存儲。實時層的誤差是有限度的，原因是Hadoop ***會對原來的同一數(shù)據(jù)進行處理，因而會理順引進的誤差。

此類混合系統(tǒng)實際上越來越常見，很多公司認識到他們沒辦法單靠Hadoop在實時世界生存。我們以前報道過不少公司——其中有Gravity，LinkedIn和Netflix——他們也做過類似的東西。Summingbird也許有點不太一樣，原因是Summingbird要處理的數(shù)據(jù)同時來自Hadoop和Storm，和管道式地處理幾個不同的系統(tǒng)不一樣。但是網(wǎng)絡公司卻需要方法保證不會用速度來換取準確度，或反之。

我們沒找到Twitter 的人來特別討論Summingbird，不過我們的數(shù)據(jù)陣容還是很引人注目的，也許可以深刻說明這東西為什么重要。他們來自PayPal、MailChimp和LinkedIn這些地方，也有的是來自像Yahoo和NSA這樣的地方的企業(yè)家。

再多講一點點Summingbird。Twitter 實際上將其描述為“Streaming MapReduce”，原因是Summingbird的重點是作業(yè)聚合。網(wǎng)上有Twitter 的Sam Ritchie六月做的一個演講稿，大家可以看看。Yahoo的開源項目 Storm-YARN其實是在Hadoop群里面運行Storm，可以讓Storm訪問基于Hadoop的數(shù)據(jù)存儲，也值得看看。