對流式計算技術的一些簡單理解

　　在大數據出現的早期，當時企業或者開發者所注重的都是批量計算，當時對於開發者來講，對於必定量數據的處理，利用普通的程序就能夠解決，然而當數據量或者計算量到達必定數量以後，應用程序的計算須要的時間也和數據量同樣飛速增加，這個時候僅僅依靠傳統的應用程序就遇到的很大的瓶頸，這個時候，一方面經過優化程序內部算法和一些機制等各類底層優化來提升系統性能和處理效率，另外一方面是提升硬件的質量，也就是提升服務器的配置，從而提高計算速度和I/O，可是這樣應對數據量的急速增加，顯然會出現問題，開發成本和部署成本也在不斷的提升，因此不少公司在具體的業務場景上都想到了一個共同的方法，那就是把一個複雜的任務放到多臺計算機上執行，這樣服務器配置不用過高，通常機器也能夠，而且效率大大提高，當數據量繼續增大時，那麼繼續增長服務器分擔任務便可，這樣就造成的初期的分佈式計算系統。

　　對於前面所說的分佈式計算系統，若是一個公司開發出來，另外公司想要拿過來用，根本是不可能的，由於這涉及到不一樣的硬件配置，通訊方式，處理的業務等等都不相同，因此根本不能通用，當時也有開發者試着抽象出來一種通用的大數據處理框架，可是效果不太理想，好比會有使用難度太大，應用到實際場景限制過多等問題，這樣的話也限制了大數據技術的發展，當時最流行的計算方式就是高性能分佈式計算和網格計算，，直到200三、200四、2006年Google分別發表了3篇論文，分別是Google File System(簡稱GFS)、BigTable、Google MapReduce；發表這三篇論文才使大數據技術有了第一次飛躍，開啓了真正的大數據時代，GFS使文件存儲系統，BigTable是數據存儲系統，MapReduce是計算模型，這樣將大數據技術進行了通常性抽象，開啓了後來大數據技術的大門，谷歌雖然沒有將他的成果開源，可是後來有人根據谷歌的計算模型開發出來，最後就造成了Apache開源基金會的一個項目，就是Hadoop，Hadoop的主要組成是HDFS和MapReduce，其中HDFS是GFS的開源實現，MapReduce是Google MapReduce的開源實現，Hadoop在處理大批量數據時表現很是好，後來圍繞這一中心造成了Hadoop生態系統，好比：

　　Hbase，至關於BigTable的分佈式NoSQL系列的數據庫

　　Hive數據倉庫工具，由Facebook貢獻，

　　Zookeeper 分佈式鎖，提供相似Google Chubby的功能，有Facebook貢獻

　　Avro 數據序列化與傳輸工具，將逐步取代Hadoop原有的IPC機制

　　Pig 大數據分析平臺，

　　Ambari Hadoop的管理工具，能夠快捷的監控、部署、管理集羣

　　Sqoop 支持Hadoop與傳統數據庫之間進行數據的傳遞

　　Mahout 用於數據挖掘和機器學習實現，實現文檔聚類、作出推薦和組織內容等，創始人是Grant Ingersoll

以上這些等等，造成了Hadoop的生態系統，一下是在網上找到的一張經典的Hadoop生態系統圖：

　　　　

　　HDFS存儲模型：

　　

　　MapReduce計算模型：

　　

 

　　以上這些Hadoop生態圈對批量處理TB、PB級的大數據是可靠的，不過在生產過程當中逐步出現一些不足之處，仔細想一想咱們也能夠發現，批量數據處理中，有如下的特色：

　　一、計算開始以前，數據必須提早準備好，而後才能夠開始計算

　　二、當大量數據計算完成以後，會輸出最後計算結果，完成計算

　　三、時效性比較低，不適用於實時的計算

　　針對以上這些問題，才慢慢造成了流式計算的這樣一種概念，流式計算主要應用場景就是在線海量數據處理，處理大量用戶的在線請求，能夠理解爲一臺服務器，這個服務是一直開着的，只要用戶有請求它都會去實時處理並輸出結果或者響應，能夠當作一個數據流源源不斷的流進計算系統，計算系統做爲後臺服務源源不斷的進行計算，最終將結果源源不斷的輸出，這就是對流式計算最基本一層的認識

　　在實際應用中，能夠處理用戶線上實時的請求，在線系統產生的日誌，記錄用戶行爲的數據庫，新聞熱點，電商促銷，微博熱詞推薦，實時用戶在線查詢等

　　目前流式計算最著名的框架就是：Spark、Twitter的Storm、Yahoo的S4

　　流式計算的共同特徵是：

　　一、和前面Hadoop生態系統做對比主要是：計算中數據持續到來、實時系統會做爲後臺服務持續運行、適用於時效性較高的場景

　　二、很是方便的編寫本身的計算邏輯，而不用關心底層的實現方式，好比Map和Reduce，咱們只須要編寫兩個方法，和單機的計算方式同樣，框架本身完成分佈式協調計算的功能，因此對於用戶使用很是方便

　　三、數據可靠性，系統須要保證數據不被丟失，也就是系統的高可用性

　　四、容錯性 用戶沒必要關心錯誤處理，系統應該提供高容錯性而且有效的調度和管理資源

　　五、超時設置 超時時間的大小必定要被重視，時間過短會誤殺正常運算，時間太長不能快速的檢測錯誤，系統應該有延時自動學習的功能，即根據多個計算任務找出出錯的任務，而後從新將任務調度到系統中的其餘節點，這樣保證整個系統的性能

 

　　Spark的設計思想是將流式計算分解成一系列短小的批處理做業，也就是把Spark Streaming的輸入數據按照時間分紅一段一段的數據，每一段數據都轉換成Spark中的RDD，而後在Spark內部對RDD進行處理操做，結果能夠放到內存中繼續處理或者存儲到外部設備

　　Storm將計算邏輯抽象爲拓撲Topology，Spout是Topology的數據源，數據源能夠是日誌或者消息隊列，也能夠是數據庫中的表等等數據，Bolt負責數據的整個傳遞方向，也叫消息處理者，Bolt可能由另外2個Bolt進行join獲得，在Storm中數據流的單位就是Tuple(元組)，這個Tuple多是由多個Fields字段構成，每一個字段都由Bolt定義，Storm中工做進程叫作worker，一個Topology實際上實在多個worker中運行的，在集羣中每一個Spout和Bolt都是由多個Tasks(任務)組成的，對於宏觀的節點，分爲Nimbus主節點和Supervisor從節點，Nimbus經過Zookeeper管理集羣全部的Supervisor，Storm提供不少配置來調整Nimbus、Supervisor進程和正在運行的Topology的行爲

　　因此，總結一下Storm的計算流程，首先是用戶使用Storm提供的API編寫Topology計算邏輯，而後使用Storm提供的Client將Topology提交給Nimbus，而後Nimbus將Task做業指派給Supervisor，Supervisor在獲得Task後，爲Task啓動Worker由Worker執行具體的Task，最後完成計算任務

　　Storm實際性能上比Spark還要高，整體上來講，Spark和Storm是流式計算中最著名使用也最普遍的2個框架

　　另外Google爲了應對併發數據流水線和以及實時數據，將MapReduce分佈式計算模型進行了全新嘗試，推出Cloud Dataflow，能夠構建、管理、優化複雜流水線，構建雲應用，而且提供了基於Java的統一API，開發者只須要使用簡單的API便可掌握Cloud Dataflow的使用，Google Cloud Platform還爲開發者提供了一系列工具：雲保存、雲調試、雲追蹤和雲監控，BigQuery爲Dataflow提供存儲，數據流通過Dataflow的清洗，能夠放到BigQuery中存儲；同時Dataflow還能夠鏈接BigQuery進行數據的讀取，所以若是想在Dataflow中使用一些開源資源是很是方便的，Dataflow的生態系統以下圖所示：

　　

　　以上就是簡單的說了大數據處理技術的發展歷程和流式計算框架的產生，從最初的網格計算到Hadoop生態系統是一次巨大的飛躍，從大數據批量計算到Spark、Storm、YahooS4和Google Cloud Dataflow這些大數據流式計算技術的產生又是一次巨大的飛躍，文中有不少地方也許理解的不夠到位，歡迎指正，相信在將來DT時代，大數據計算技術將爲各行各業注入新的生命力...