Laxcus大數據管理系統2.0版本推出有兩個多月了，最近做了一次使用情況調查，發現最受歡迎的竟是流式處理。這大大出乎我們推出新版本時的預料。因為當時新版本推出時，流式處理只是做為磁盤數據處理的一項輔助功能而附帶提供的，而且最初設計流式處理時，技術上也並沒有花太多心思，因為它很容易實現，只是改變一下數據處理流經的路線而已。不過現在想想，再看看當下SPARK火熱的情況，流式處理大熱也就不奇怪了，畢竟更多更快更強的大數據處理效果是大家共同追求的目標。舉一個例子，我們一個合作伙伴，原來做一次大數據計算，大概需要一兩個小時的時間，現在改用了流式處理，同樣的數據量，只用幾分鍾就搞掂了，計算效率一下子提升了幾十倍。這樣的數據處理，不招人喜歡才怪！
不過做為大數據技術開發者和運營管理者，對於流式處理，我們卻要冷靜對待，下面就從技術和運維的角度，來說一說我自己的看法。
流式處理的好處這里就不說了，大家都已經看得到：快！僅憑這一點，就足以讓沒有耐心的用戶心滿意足。
下面主要說一說“弊”的方面。
大家應該都知道，流式處理是以內存取代硬盤來達到快速處理效果的。不管現在任何流式處理產品，包括SPARK、STORM、SAMZA，它們怎么說自己的產品與別人有什么不同，這個根本的相同點是回避不了的，這是流式處理所以能夠快的根本原因。
在一台計算機里，以存儲容量比較，內存是少數，硬盤是多數，這樣的例子，我們看看自己用的PC就知道。一台PC，現在硬盤容量最少也是1TB了，但是內存呢，不過幾個GB的數量，兩者相差近千倍。這種情況在雲服務器上也一樣，每台服務器，可以分配給用戶的空間基本都是足夠的，即使偶爾不足，也可以通過負載均衡的辦法，分散到其它機器上來彌補。但是內存就不同了，內存在大多數的時候是不足的，而且在不足的情況下，還要滿足多個用戶的數據請求，每個用戶實際分到的內存就更少。而流式處理加入進來后，實際的結果是，把原來分配給多個用戶的內存資源，全部分配給一個用戶來使用，其他需要內存的用戶，因為沒有內存可用，將被迫進入等待狀態，直到這個用戶完成后，才能繼續使用。所以，從業務公平和數據公平角度來說，流式處理的這種做法是不合理的。這有點象社會上某些現象，為了滿足某些個體的私利，而犧牲掉公眾的利益。呵呵。當然，如果是自己搭建集群，只為自己業務服務的，那就另說。
還有一點是流式處理比較尷尬的，這在所有流式處理中都存在，但是我看過很多介紹流式處理的文章，不知他們是有意回避還是其它什么原因，被提及的並不多，也需要各位加以注意：回到根本，流式處理實質仍然是一個分布的計算過程，它的計算過程中，在集群中的作用節點肯定不會是一個，而是N個，這樣就要求所有節點都必須同時滿足操作流式處理所需要的內存，當任何一個節點不能滿足流式處理要求的內存時，這個節點的流式處理將被迫轉向磁盤，恢復成磁盤數據處理過程。雖然只是一個節點，但是根據木桶短板原理，這次流式處理的總處理時間將被這個節點拖累，實際的處理時間與磁盤處理無異，並不能達到流式處理的要求。這種現象，目前各種流式處理都無法完全避免，尤其當面臨多用戶多任務競用環境的時候。
可以解決這個問題的辦法是“預約”。就是在執行計算工作前，先評估一下這次流式計算所需要的內存總量，然后啟動一個“代理”工具，到每台計算機上去檢查剩余內存，如果符合要求，就鎖定這台計算機的內存，檢查全部達標后，批准此次流式處理。不過這樣又產生新的問題：就是如果內存不足的時候，流式處理任務將被迫轉入等待；或者實際內存不能滿足要求時，仍然要回到磁盤處理的老路。這樣的處理辦法，將造成與快速計算的目標相悖。但是目前看，也只能是這樣了。
再從運營商的角度來談談流式處理。
大家應該都知道，同樣單位容量情況下，內存比硬盤太貴多了。這個情況大家可以打開淘寶看看，1TB的硬盤和1TB的內存，它們的價差是多少。此前我們給一個雲服務商做預案時做一個測算，以一個中型集群（1000台服務器為單位）來計算，如果提供相對適中、讓用戶感覺比較順暢的流式處理，僅內存一項，就是增加一百萬元人民幣以上的成本。況且在實際部署時，雲服務商要部署的集群通常不只一個，那樣增加的內存成本就更高。所以，實際上除了阿里、騰訊這樣超級土豪級別的公司，沒有幾個雲服務商肯接受這樣的成本預案。
最后總結說一句：能不能在大數據集群中執行流式處理，使用戶獲得滿意的快速計算能力，更大的成分，並不是技術問題，而是錢的問題，它和集群所有者兜里的銀子成正比。這和金融、地產是一樣的，沒錢就別玩！
中國廣州超算中心的天河2號
美國能源部橡樹嶺國家實驗室的Titan
中國的天河2，美國的Titan，所以有這么強的性能，都是拿銀子堆出來的。這樣超一流硬件條件，做起超級計算、流式計算、超大規模數據存取工作來，自然是得心應手。