【4.分佈式計算】spark

spark和map-reduce(有時候hadoop會指這個，我仍是叫hadoop是個總體設計)，flink這三個都是並行計算的方式。map-reduce只支持批處理，另外兩個都支持，其中spark的流處理基於批處理，flink見：https://segmentfault.com/a/11...，更多數據存儲內容見：https://segmentfault.com/a/11...。
本文介紹spark的邏輯架構,分佈式部署架構，計算模式/流處理/容錯 等。
官方：batch是map-reduce的110倍，支持SQL and DataFrames, MLlib for machine learning, GraphX, and Spark Streaming.和map-reduce同樣可應用於多種隔離（Spark using its standalone cluster mode, on EC2, on Hadoop YARN, on Mesos, or on Kubernetes）和存儲（Access data in HDFS, Alluxio, Apache Cassandra, Apache HBase, Apache Hive, and hundreds of other data sources）之上

架構

邏輯架構

部署架構

部署在yarn中模式：
YARN-Cluster模式下，Driver運行在AM(Application Master)中，它負責向YARN申請資源，並監督做業的運行情況。當用戶提交了做業以後，就能夠關掉Client，做業會繼續在YARN上運行，於是YARN-Cluster模式不適合運行交互類型的做業，用於生產環境
YARN-Client模式下，Application Master僅僅向YARN請求Executor，Client會和請求的Container通訊來調度他們工做，也就是說Client不能離開。用於測試環境

一個能夠申請多個container，每一個coarseGrainedExecutorBackend中能夠多線程執行多個task

cluster啓動和執行流程：

啓動爲圖中黃色部分，執行黑色部分。

計算模式

RDD resilient distributed dataset (RDD), which is a collection of elements partitioned across the nodes of the cluster that can be operated on in parallel.（which is a fault-tolerant collection of elements that can be operated on in parallel）不可變，能夠分佈式存儲和緩存，利用Lineage（追蹤RDD依賴）能夠容錯恢復。(與傳統數據集對比https://databricks.com/blog/2...
基於內存迭代（對比與map-reduce輸出落盤再下一輪），超出也會溢出到磁盤，但儘可能不要，資源限制主要是內存和網絡，能夠序列化，評估內存，減小RDD的大小，（OutOfMemoryError，不是由於你的RDD不適合內存，而是由於你的一個任務的工做集，例如其中一個reduce任務groupByKey，太大了。最簡單的解決方法是 增長並行度，以便每一個任務的輸入集更小。Spark能夠有效地支持短至200毫秒的任務，由於它在許多任務中重用了一個執行程序JVM，而且它具備較低的任務啓動成本，所以您能夠安全地將並行度提升到超過羣集中的核心數。）
RDD的執行會被轉化爲DAG，RDD在Lineage依賴方面分爲兩種Narrow Dependencies（父只被一個子引用）與Wide Dependencies，寬依賴(即shuffle操做)是stage劃分的依據，窄依賴能夠執行流水線(pipeline)操做
job=>stage=>DAG。
Stage: 每一個Job會被拆分紅多組Task， 做爲一個TaskSet， 其名稱爲Stage，Stage的劃分和調度是有DAGScheduler來負責的，Stage有非最終的Stage（Shuffle Map Stage）和最終的Stage（Result Stage）兩種，Stage的邊界就是發生shuffle的地方，每一個stage每一個分區一個task並行執行
DAGScheduler: 根據Job構建基於Stage的DAG（Directed Acyclic Graph有向無環圖)，並提交Stage給TASkScheduler。 其劃分Stage的依據是RDD之間的依賴的關係找出開銷最小的調度方法，以下圖

https://jaceklaskowski.gitboo...

spark streaming

https://spark.apache.org/docs...
接收的數據必須存儲在內存中
Spark Streaming是將流式計算分解成一系列短小的批處理做業。這裏的批處理引擎是Spark Core，也就是把Spark Streaming的輸入數據按照batch size（如1秒）分紅一段一段的數據（Discretized Stream），每一段數據都轉換成Spark中的RDD（Resilient Distributed Dataset），而後將Spark Streaming中對DStream的Transformation操做變爲針對Spark中對RDD的Transformation操做，將RDD通過操做變成中間結果保存在內存中。整個流式計算根據業務的需求能夠對中間的結果進行疊加或者存儲到外部設備

窗口

但願經過每隔10秒生成最後30秒數據的字數來擴展
窗口長度 - 窗口的持續時間（圖中的3）。
滑動間隔 - 執行窗口操做的間隔（圖中的2）。
這兩個參數必須是源DStream的批處理間隔的倍數（圖中的1）。

背壓

估計處理速度。flink不須要，有空閒buffer才接受

簡單看下storm. zeromq發送消息，容錯是靠消息的ACK和重試。只保證至少一次完整處理，不保證只處理一次。
要用戶提交拓撲而非本身生成

容錯

1.數據庫（HDFS/S3）流：
checkpoint+從新讀，receiver失敗恢復重啓讀取，driver失敗恢復將從checkpoint恢復
checkpoint:元數據(配置，不完整的批次，操做)、數據Dstream(每次計算的RDD集合，是否提交標識),

2.網絡流：
checkpoint+wal(從諸如Kafka和Flume的數據源接收到的全部數據，在它們處理完成以前，一直都緩存在executor的內存中。縱然driver從新啓動，這些緩存的數據也不能被恢復)

接收數據（藍色箭頭）——接收器將數據流分紅一系列小塊，存儲到executor內存中。另外，在啓用之後，數據同時還寫入到容錯文件系統的預寫日誌。
通知driver（綠色箭頭）——接收塊中的元數據（metadata）被髮送到driver的StreamingContext。這個元數據包括：（i）定位其在executor內存中數據位置的塊reference id，（ii）塊數據在日誌中的偏移信息（若是啓用了）。
處理數據（紅色箭頭）——每批數據的間隔，流上下文使用塊信息產生彈性分佈數據集RDD和它們的做業（job）。StreamingContext經過運行任務處理executor內存中的塊來執行做業。
檢查點計算（橙色箭頭）——爲了恢復的須要，流計算（換句話說，即 StreamingContext提供的DStreams ）週期性地設置檢查點，並保存到同一個容錯文件系統中另外的一組文件中。
恢復：

恢復計算（橙色箭頭）——使用檢查點信息重啓driver，從新構造上下文並重啓接收器。
恢復元數據塊（綠色箭頭）——爲了保證可以繼續下去所必備的所有元數據塊都被恢復。
未完成做業的從新造成（紅色箭頭）——因爲失敗而沒有處理完成的批處理，將使用恢復的元數據再次產生RDD和對應的做業。
讀取保存在日誌中的塊數據（藍色箭頭）——在這些做業執行時，塊數據直接從預寫日誌中讀出。這將恢復在日誌中可靠地保存的全部必要數據。
重發還沒有確認的數據（紫色箭頭）——失敗時沒有保存到日誌中的緩存數據將由數據源再次發送。由於接收器還沒有對其確認。

總體：