目標
閱讀完本文撼泛，你講對 Hadoop昙楚，Spark 有個簡單認識琅束，并學習到 Spark 中的一些基礎概念招盲。
背景
因為業(yè)務需求低缩，工程方需要將大量的 hive 數(shù)據(jù)導入緩存集群中，由于數(shù)據(jù)量比較大曹货，MapReduce 計算模型已經不能滿足我們的需求咆繁，于是決定使用 Spark 代替 MapReduce對數(shù)據(jù)進行處理。
但是在使用的過程中發(fā)現(xiàn)顶籽，功能是實現(xiàn)了玩般，但是1億的數(shù)據(jù)量要導2~3個小時，那還搞個線啊礼饱。根本原因還是對 Spark 的運行原理理解不深入坏为，只停留在了表層使用，要對 Spark 進行?性能優(yōu)化那是必須的镊绪，于是就有了今天的這篇入門文章匀伏。
講一下，Hadoop
在早期的 Hadoop 中采用的是 MRv1版本的 MapReduce 編程模型镰吆。MRv1包括三個部分內容：
1. 運行時環(huán)境（JobTracker 和 TaskTracker）
2. 編程模型（MapReduce）
3. 數(shù)據(jù)處理引擎（Map 任務和 Reduce 任務）
MRv1的簡單示意圖如下：
具體一點就是（畫圖不易）:
從上圖中可以看出 MRv1的流程與設計思路：
1. 首先用戶程序 (JobClient) 提交了一個 job帘撰，job 的信息會發(fā)送到 Job Tracker 中，Job Tracker 是 Map-reduce 框架的中心万皿，他需要與集群中的機器定時通信 (heartbeat), 需要管理哪些程序應該跑在哪些機器上摧找，需要管理所有 job 失敗核行、重啟等操作。
2. TaskTracker 是 Map-reduce 集群中每臺機器都有的一個部分蹬耘，他做的事情主要是監(jiān)視自己所在機器的資源情況芝雪。
3. TaskTracker 同時監(jiān)視當前機器的 tasks 運行狀況。TaskTracker 需要把這些信息通過 heartbeat 發(fā)送給 JobTracker综苔，JobTracker 會搜集這些信息以給新提交的 job 分配運行在哪些機器上惩系。上圖虛線箭頭就是表示消息的發(fā)送 - 接收的過程。
MRv1 存在一些不足：
1.?可擴展性差如筛，JobTracker 職責過重堡牡，它即負責資源管理有負責任務調度，當集群繁忙時杨刨，JobTracker 可能成為系統(tǒng)瓶頸晤柄，也增加了 JobTracker fail 的風險，業(yè)界普遍總結出 MRv1只能支持4000節(jié)點主機的上線妖胀。
2.?可用性差芥颈，JobTracker 是 Map-reduce 的集中處理點，存在單點故障赚抡。
3.?在 TaskTracker 端爬坑，以 map/reduce task 的數(shù)目作為資源的表示過于簡單，沒有考慮到 cpu/ 內存的占用情況涂臣，如果兩個大內存消耗的 task 被調度到了一塊盾计，很容易出現(xiàn) OOM。
4.?資源利用率低肉康，TaskTracker 使用 slot 等量劃分節(jié)點上的資源量闯估。啥意思灼舍，假設資源量總數(shù)的 slot 數(shù)為 n吼和，task 必須獲取到 slot 后才能有機會運行，如果某些 task 沒有充分利用 slot骑素，然而其他需要大量計算資源的 task 也無法獲取這些空閑的資源炫乓。同時 slot 還分為 Map Slot 和 Reduce Slot 兩種，作業(yè)剛啟動的時候大部分的應該是 MapTask献丑，此時 Reduce Task 都還沒有調度末捣，Reduce Slot 的資源就閑置了。
5.?不能支持多種 MapReduce 框架创橄，無法通過可插拔方式將自身的 MapReduce 框架替換為其他實現(xiàn)箩做，比如 Spark、Strom等妥畏。
技術在進步邦邦，分布式系統(tǒng)也在不斷的變化安吁，MRv1的框架已經不符合當前的要求了，從 0.23.0 版本開始燃辖，Hadoop 的 MapReduce 框架完全重構鬼店，發(fā)生了根本的變化。新的 Hadoop MapReduce 框架命名為 MRv2 或者叫 Yarn黔龟，Yarn 的架構圖如下：
MRv2重用了 MRv1中的編程模型和數(shù)據(jù)處理引擎妇智。但是運行時環(huán)境被重構了，JobTracker 被拆分成通用的資源調度平臺ResourceManager(簡稱 RM)氏身，節(jié)點管理器NodeManager 和負責各個計算框架的任務調度模型 ApplicationMaster(簡稱 AM)巍棱。
ResourceManager 負責對整個集群的資源管理，但是在任務資源的調度方面只負責將資源封裝成 Container 分配給 ApplicationMaster 的一級調度蛋欣，二級調度的細節(jié)將交給 ApplicationMaster 去完成拉盾，這大大減輕了 ResourceManager 的壓力。
NodeManager 負責對單個節(jié)點的資源管理豁状，并將資源信息捉偏、Container 運行狀態(tài)、健康狀況等信息上報給 ResourceManager泻红。ResourceManager 為了保證 Container 的利用率夭禽，會監(jiān)控 Container，如果 Container 未在有限的時間內使用谊路，ResourceManager 將命令 NodeManager “殺死”Container讹躯，以便將資源分配給其他任務。
Spark
前面說了這么多 hadoop缠劝，終于到 Spark 了潮梯。
Spark 特點
Spark 看到了 MRv1的問題，對 MapReduce 做了大量優(yōu)化惨恭，總結如下：
1. 減少磁盤 I/O: MapReduce?會將計算中間結果存儲到 HDFS 上秉馏，后續(xù)計算再從 HDFS 上讀取數(shù)據(jù)計算，這樣勢必造成磁盤 I/O 成為瓶頸脱羡。Spark 將內容存儲在內存中萝究，減少了磁盤I/O，但是確增加了對內存的大量需求锉罐。
2. 增加并行度: Spark 任務劃分為不同的 stage帆竹，允許多個 stage 即可以串行執(zhí)行，又可以并行執(zhí)行脓规。
3. 避免重新計算: 當 stage 中某個分區(qū)的 Task 執(zhí)行失敗后栽连，會重新對此 stage調度，但在重新杜調度的時候回過濾已經執(zhí)行成功的分區(qū)任務侨舆，避免重復計算和資源浪費秒紧。
4. 可選的 Shuffle 排序: Hadoop MapReduce 在 Shuffle 之前有著固定的排序操作舷暮，而 Spark 則可以根據(jù)不同場景選擇在 map 端排序還是 reduce 端排序。
5.?靈活的內存管理策略: Spark 將內存分為堆上的存儲內存噩茄、堆外的存儲內存下面、堆上的執(zhí)行內存、堆外的執(zhí)行內存4個部分绩聘。執(zhí)行內存與存儲內存并不是有明顯的邊界沥割，而是"軟"邊界，執(zhí)行內存和存儲內存的任意一方在資源不足時都可以借用另一方的內存凿菩。
6. 其他特點: 檢查點支持机杜、易于使用、支持交互衅谷、支持 SQL椒拗、支持流式計算、可用性高获黔、豐富的數(shù)據(jù)源支持和豐富的文件格式支持蚀苛。
Spark 基礎概念
1. RDD(resillient distributed dataset): 彈性分布式數(shù)據(jù)集。通過 Spark 的 轉換 API?可以將 RDD 封裝成一系列具有血緣關系的 RDD玷氏，也就是 DAG堵未。只有通過 Spark 的 動作 API 才會將 RDD 及其 DAG 提交到 DAGScheduler。RDD 的祖先一定是一個跟數(shù)據(jù)源相關的 RDD盏触，負責從數(shù)據(jù)源迭代讀取數(shù)據(jù)渗蟹。
2. DAG(Directed Acycle Graph): 有向無環(huán)圖。Spark 使用 DAG 來反映各 RDD 之間的依賴或血緣關系赞辩。
3. Partition: 數(shù)據(jù)分區(qū)雌芽，即一個 RDD 的數(shù)據(jù)可以劃分為多少個分區(qū)。Spark 根據(jù) Partition 的數(shù)量來確定 Task 的數(shù)量辨嗽。
4. NarrowDependency: 窄依賴世落，即子 RDD 依賴于父 RDD 中固定的 Partition。NarrowDependency分為 OneToOneDependency 和 RangeDependency 兩種召庞。
5. ShuffleDependency: Shuffle 依賴岛心，也稱為寬依賴，即子 RDD 對父 RDD 中的所有 Patition 都可能產生依賴篮灼。子 RDD 對父 RDD 各個 Partition 的依賴將取決于分區(qū)計算器(Partitioner)的算法。
6. Job: 用戶提交的作業(yè)徘禁。當 RDD 及其 DAG 被提交給 DAGScheduler 調度后诅诱，DAGScheduler 會將所有 RDD 中的轉換及動作視為一個 Job。一個 Job 有一個到多個 Task 組成送朱。
7. Stage: Job 的執(zhí)行階段娘荡。DAGScheduler 按照ShuffleDependency 作為 Stage 的劃分節(jié)點對 RDD的 DAG 進行 Stage 劃分(上游的 Stage 將為 ShuffleMapStage)干旁。因此一個 Job 可能被劃分為一到多個 Stage。Stage 分為 ShuffleMapStage 和 ResultStage 兩種炮沐。
8. Task: 具體執(zhí)行任務争群。一個 Job 在每個 Stage 內都會按照 RDD 的 Partition 數(shù)量，創(chuàng)建多個 Task大年。Task 分為 ShuffleMapTask 和 ResultTask 兩種换薄。ShuffleMapStage中的 Task 為 ShuffleMapTask，而 ResultStage 中的 Task 為 ResultTask翔试。ShuffleMapTask 和 ReduceTask 類似于 Hadoop 中的 Map 任務和 Reduce 任務轻要。
9. Shuffle: Shuffle 是所有MapReduce 計算框架的核心執(zhí)行階段，Shuffle 用于打通 Map 任務(在 Spark 中就是 ShuffleMapTask)的輸出與 reduce 任務(在 Spark 中就是 ResultTask)的輸入垦缅，map 任務的中間結果按照指定的分區(qū)策略(例如：按照 key 哈希)分配給處理某個分區(qū)的 reduce 任務冲泥。
這么多概念，搞不懂壁涎，沒圖你說個 JB 啊凡恍，大家結合一下
