資料天生就是流式的

好久沒寫文章，發現寫長文太辛苦了，是以慢慢往短文開始靠。這次算是第一個實踐。

這個架構的核心概念是：

<b>你開發的任何一個應用，本質上都是将兩個或者多個節點連接配接起來，進而使得資料可以在不同節點之間流轉</b>

如果說在大資料領域，批量處理是第一次資料革命，那麼流式處理則必然是第二次資料革命。

從某種角度而言，批量是流式處理的一個特例，譬如隔天處理資料，本質就是時間視窗為一天的流式計算。當然我們也可以實作以數量為視窗的計算。

當你需要借助外力的時候，事情往往就變得并不美好了。你需要額外的維護譬如oozie等系統裡的工作流，并且你需要考慮各個系統能夠完成的時間，進而協調好元件。

資料流轉的理想狀态應該就如同河水一樣，當源頭水量變大後，水壓會自動迫使資料自動流轉速度加快。當我們需要灌溉新的農田時，我們隻要接上某個河道（比如kafka）,通過建立新的支流(由流式引擎比如spark streaming完成)，就可以很友善的将水引入。整個過程是水壓驅動水的流轉。

spark streaming的實作則讓流式和批量之間的關系愈加微妙。批量處理是spark streaming流式處理的一個視窗特别大的特例，但是如果細加觀察,spark streaming 的每個batch 又都是一個批處理，隻是因為這個批處理可以足夠小，看起來就像資料在真實流動一樣，是以我們也稱之為流式處理。

而storm這種流式引擎則能實作最細粒度的流轉，但是這種細粒度的流轉在很多場景并不足夠高效，因為在流轉的過程中，往往下遊無法接受來一條就處理一條的情況，需要通過小視窗的batch來完成更加高效的入庫操作。

是以從某種角度而言，spark streaming 這種将批處理和流處理巧妙融合的方式可以保證自己可以充分利用流式和批處理的優勢。

從另外一個角度而言，流式不過是一個具有無限資料的批處理過程。