Spark Streaming筆記整理（一）：基本工做原理介紹

概述

大數據實時計算介紹

一、Spark Streaming，其實就是一種Spark提供的，對於大數據，進行實時計算的一種框架。它的底層，其實，也是基於咱們以前講解的Spark Core的。基本的計算模型，仍是基於內存的大數據實時計算模型。並且，它的底層的核心組件仍是咱們在Spark Core中常常用到的RDD。

二、針對實時計算的特色，在RDD之上，進行了一層封裝，叫作DStream。其實，學過了Spark SQL以後，你理解這種封裝就容易了。以前學習Spark SQL是否是也是發現，它針對數據查詢這種應用，提供了一種基於RDD之上的全新概念，DataFrame，可是，其底層仍是基於RDD的。因此，RDD是整個Spark技術生態中的核心。

正如市面上存在衆多可用的流處理引擎，人們常常詢問咱們Spark Streaming有何獨特的優點？那麼首先要說的就是Apache Spark在批處理以及流處理上提供了原生支持。這與別的系統不一樣之處在於其餘系統的處理引擎要麼只專一於流處理，要麼只負責批處理且僅提供須要外部實現的流處理API接口而已。Spark 憑藉其執行引擎以及統一的編程模型可實現批處理與流處理，這就是與傳統流處理系統相比Spark Streaming所具有獨一無二的優點。尤爲特別體如今如下四個重要部分：

1.能在故障報錯與straggler的狀況下迅速恢復狀態；
2.更好的負載均衡與資源使用；
3.靜態數據集與流數據的整合和可交互查詢；
4.內置豐富高級算法處理庫（SQL、機器學習、圖處理）

流處理架構——過去與如今1

當前分佈式流處理管道執行方式以下所述：

一、接收來自數據源的流數據（好比時日誌、系統遙測數據、物聯網設備數據等等），處理成爲數據攝取系統，好比Apache Kafka、Amazon Kinesis等等。

二、在集羣上並行處理數據。這也是設計流處理引擎的關鍵所在，咱們將在下文中作出更細節性的討論。

三、輸出結果存放至下游系統（例如HBase、Cassandra, Kafka等等）。

爲了處理這些數據，大部分傳統的流處理系統被設計爲連續算子 模型，其工做方式以下：

一、有一系列的工做節點，每組節點運行一至多個連續算子；

二、對於流數據，每一個連續算子一次處理一條記錄，而且將記錄傳輸給管道中別的算子；

三、源算子從攝入系統接收數據，接着輸出到下游系統。

流處理架構——過去與如今2

一、連續算子是一種較爲簡單、天然的模型。然而,隨着現在大數據時代下，數據規模的不斷擴大以及愈來愈複雜的實時分析，這個傳統的架構也面臨着嚴峻的挑戰。所以，咱們設計Spark Streaming就是爲了解決以下幾點需求：

二、故障迅速恢復–數據越龐大，出現節點故障與節點運行變慢（例如straggler）狀況的機率也愈來愈高。所以，系統要是可以實時給出結果,就必須可以自動修復故障。惋惜在傳統流處理系統中，在這些工做節點靜態分配的連續算子要迅速完成這項工做仍然是個挑戰；

三、負載均衡–在連續算子系統中工做節點間不平衡分配加載會形成部分節點性能的bottleneck（運行瓶頸）。這些問題更常見於大規模數據與動態變化的工做量面前。爲了解決這個問題，那麼要求系統必須可以根據工做量動態調整節點間的資源分配；

四、統一的流處理與批處理以及交互工做–在許多用例中，與流數據的交互是頗有必要的（畢竟全部流系統都將這置於內存中）或者與靜態數據集結合（例如pre-computed model）。這些都很難在連續算子系統中實現，當系統動態地添加新算子時，並無爲其設計臨時查詢功能，這樣大大的削弱了用戶與系統的交互能力。所以咱們須要一個引擎可以集成批處理、流處理與交互查詢；

五、高級分析（例如機器學習、SQL查詢等等）–一些更復雜的工做須要不斷學習和更新數據模型，或者利用SQL查詢流數據中最新的特徵信息。所以，這些分析任務中須要有一個共同的集成抽象組件，讓開發人員更容易地去完成他們的工做。

六、爲了解決這些要求，Spark Streaming使用了一個新的結構，咱們稱之爲discretized streams（離散化的流數據處理），它能夠直接使用Spark引擎中豐富的庫而且擁有優秀的故障容錯機制。

Spark Streaming簡單介紹

一、Spark的運行模式多種多樣，靈活多變，部署在單機上時，既能夠用本地模式運行，也能夠用僞分佈式模式運行；而當以分佈式集羣的方式部署時，也有衆多的運行模式可供選擇，這取決於集羣的實際狀況，底層的資源調度既能夠依賴於外部的資源調度框架，也可使用Spark內建的Standalone模式。對於外部資源調度框架的支持，目前的實現包括相對穩定的Mesos模式，以及還在持續開發更新中的Hadoop YARN模式。

二、Spark Streaming是Spark Core API的一種擴展，它能夠用於進行大規模、高吞吐量、容錯的實時數據流的處理。它支持從不少種數據源中讀取數據，好比Kafka、Flume、Twitter、ZeroMQ、Kinesis、ZMQ或者是TCP Socket。而且可以使用相似高階函數的複雜算法來進行數據處理，好比map、reduce、join和window。處理後的數據能夠被保存到文件系統、數據庫、Dashboard等存儲中。

Spark Streaming基本工做原理

接收實時輸入數據流，而後將數據拆分紅多個batch，好比每收集1秒的數據封裝爲一個batch，而後將每一個batch交給Spark的計算引擎進行處理，最後會生產出一個結果數據流，其中的數據，也是由一個一個的batch所組成的。

Spark Streaming DStream

一、Spark Streaming提供了一種高級的抽象，叫作DStream，英文全稱爲Discretized Stream，中文翻譯爲「離散流」，它表明了一個持續不斷的數據流。DStream能夠經過輸入數據源來建立，好比Kafka、Flume、ZMQ和Kinesis；也能夠經過對其餘DStream應用高階函數來建立，好比map、reduce、join、window。

二、DStream的內部，其實一系列持續不斷產生的RDD。RDD是Spark Core的核心抽象，即，不可變的，分佈式的數據集。DStream中的每一個RDD都包含了一個時間段內的數據。

一、對DStream應用的算子，好比map，其實在底層會被翻譯爲對DStream中每一個RDD的操做。好比對一個DStream執行一個map操做，會產生一個新的DStream。可是，在底層，其實其原理爲，對輸入DStream中每一個時間段的RDD，都應用一遍map操做，而後生成的新的RDD，即做爲新的DStream中的那個時間段的一個RDD。底層的RDD的transformation操做。

二、仍是由Spark Core的計算引擎來實現的。Spark Streaming對Spark Core進行了一層封裝，隱藏了細節，而後對開發人員提供了方便易用的高層次的API。

與其它流式框架對比分析

Spark Streaming、Flink和Storm對比

對比點	Storm	Spark Streaming	Flink
實時計算模型	純實時，來一條數據處理一條	一、準實時，對一個時間段的RDD數據收集起來，一塊兒處理	流式計算和批處理分別採用DataStream和DataSet
實時計算延遲度	毫秒級	秒級	秒級
吞吐量	低	高	高
事務機制	支持完善	支持，但不夠完善	支持，但不夠完善
健壯性/容錯性	ZK、Acker,很好	CheckPoint，WAL通常	CheckPoint通常
動態調整並行度	支持	不支持	支持
運行時同時支持流失和離線處理	不支持	支持	支持
成熟度	高	高	低
模型	native	Micro-batching	native
API	組合式	聲明式	組合式

• 組合式：操做更加基礎的API操做，一步步精細控制，各組件組合定義成拓撲；
• 聲明式：提供封裝後的高階函數。封裝後可提供初步的優化；可提供窗口管理、狀態管理等高級操做；

Spark Streaming、Flink和Storm的優點分析

一、Spark Streaming絕對談不上比Storm、Flink優秀。這兩個框架在實時計算領域中，都很優秀，只是擅長的細分場景並不相同。

二、Spark Streaming在吞吐量上要比Storm優秀。

三、Storm在實時延遲度上，比Spark Streaming就好多了，前者是純實時，後者是準實時。並且，Storm的事務機制、健壯性/容錯性、動態調整並行度等特性，都要比Spark Streaming更加優秀。

四、Spark Streaming，有一點是Storm絕對比不上的，就是：它位於Spark整個生態技術棧中，所以Spark Streaming能夠和Spark Core、Spark SQL、Spark　Ｇraphx無縫整合，換句話說，咱們能夠對實時處理出來的中間數據，當即在程序中無縫進行延遲批處理、交互式查詢等操做。這個特色大大加強了Spark Streaming的優點和功能。

Spark Streaming、Flink和Storm的應用場景

Storm

一、建議在須要純實時，不能忍受1秒以上延遲的場景下使用，好比實時計算系統，要求純實時進行交易和分析時。

二、在實時計算的功能中，要求可靠的事務機制和可靠性機制，即數據的處理徹底精準，一條也不能多，一條也不能少，也能夠考慮使用Storm，可是Spark Streaming也能夠保證數據的不丟失。

三、若是咱們須要考慮針對高峯低峯時間段，動態調整實時計算程序的並行度，以最大限度利用集羣資源（一般是在小型公司，集羣資源緊張的狀況），咱們也能夠考慮用Storm

Spark Streaming

一、不知足上述3點要求的話，咱們能夠考慮使用Spark Streaming來進行實時計算。

二、考慮使用Spark Streaming最主要的一個因素，應該是針對整個項目進行宏觀的考慮，即，若是一個項目除了實時計算以外，還包括了離線批處理、交互式查詢、圖計算和MLIB機器學習等業務功能，並且實時計算中，可能還會牽扯到高延遲批處理、交互式查詢等功能，那麼就應該首選Spark生態，用Spark Core開發離線批處理，用Spark SQL開發交互式查詢，用Spark Streaming開發實時計算，三者能夠無縫整合，給系統提供很是高的可擴展性。

Flink

1.支持高吞吐、低延遲、高性能的流處理 2.支持帶有事件時間的窗口（Window）操做 3.支持有狀態計算的Exactly-once語義 4.支持高度靈活的窗口（Window）操做，支持基於time、count、session，以及data-driven的窗口操做 5.支持具備Backpressure功能的持續流模型 6.支持基於輕量級分佈式快照（Snapshot）實現的容錯 7.一個運行時同時支持Batch on Streaming處理和Streaming處理 8.Flink在JVM內部實現了本身的內存管理 9.支持迭代計算 10.支持程序自動優化：避免特定狀況下Shuffle、排序等昂貴操做，中間結果有必要進行緩存


原文連接：http://blog.51cto.com/xpleaf/2114744