海量數(shù)據(jù)的存儲(chǔ)問題很早就已經(jīng)出現(xiàn)了，一些行業(yè)或者部門因?yàn)闅v史的積累，數(shù)據(jù)量也達(dá)到了一定的級(jí)別。很早以前，當(dāng)一臺(tái)電腦無法存儲(chǔ)這么龐大的數(shù)據(jù)時(shí)，采用的解決方案是使用NFS(網(wǎng)絡(luò)文件系統(tǒng))將數(shù)據(jù)分開存儲(chǔ)。但是這種方法無法充分利用多臺(tái)計(jì)算機(jī)同時(shí)進(jìn)行分析數(shù)據(jù)。

一個(gè)實(shí)際的需求場(chǎng)景：日志分析

日志分析是對(duì)日志中的每一個(gè)用戶的流量進(jìn)行匯總求和。對(duì)于一個(gè)日志文件，如果只有這么幾行數(shù)據(jù)，我們一般會(huì)采用這樣的處理方式

• 讀取一行日志
• 抽取手機(jī)號(hào)和流量字段
• 累加到HashMap中
• 遍歷輸出結(jié)果

如果數(shù)據(jù)量變得很大呢，比如一個(gè)日志文件里面有幾個(gè)GB數(shù)據(jù)，仍然一行一行去讀，那么就會(huì)因?yàn)榇疟P的IO瓶頸導(dǎo)致效率太低，速度太慢。如果一次性加載到內(nèi)存，那么就會(huì)因?yàn)閱闻_(tái)計(jì)算機(jī)的內(nèi)存空間有限而導(dǎo)致內(nèi)存溢出。如果將中間結(jié)果全部緩存到HashMap中，那么也會(huì)因?yàn)閱闻_(tái)計(jì)算機(jī)的內(nèi)存空間有限而導(dǎo)致內(nèi)存溢出。可以選擇采用多線程處理，但是依然無法改變資源瓶頸的現(xiàn)實(shí)，因?yàn)橐慌_(tái)計(jì)算器的CPU資源，內(nèi)存資源，磁盤IO瓶頸是定，創(chuàng)建再多的線程也無法改變這個(gè)現(xiàn)實(shí)。

解決思路一：縱向擴(kuò)展

升級(jí)硬件，提高單機(jī)性能(增加內(nèi)存，增強(qiáng)CPU、用更高性能的磁盤(如固態(tài)硬盤)，比如可以購(gòu)買IBM的高端服務(wù)器。這種方法簡(jiǎn)單易行，但單臺(tái)計(jì)算機(jī)的擴(kuò)展空間有限，CPU、內(nèi)存、磁盤再怎么擴(kuò)展也是有限的，無法無限擴(kuò)展。除此之外，成本較高，高端服務(wù)器常常非常昂貴，幾百萬甚至上千萬一臺(tái)，一般的小公司承受不起這樣高昂的成本。

解決思路二：橫向擴(kuò)展:

用多臺(tái)節(jié)點(diǎn)分布式集群處理 ，通過增加節(jié)點(diǎn)數(shù)量提高處理能力，這里說的節(jié)點(diǎn)指的就是一臺(tái)計(jì)算機(jī)。其思想為任務(wù)分?jǐn)偅ㄟ^協(xié)作來實(shí)現(xiàn)單節(jié)點(diǎn)無法實(shí)現(xiàn)的任務(wù)，且成本相對(duì)低(可采用普通機(jī)器) 、易于線性擴(kuò)展。但是其系統(tǒng)復(fù)雜度增加，我們要將我們的web應(yīng)用部署到每一個(gè)節(jié)點(diǎn)上面，而多個(gè)節(jié)點(diǎn)協(xié)同工作時(shí)就要考慮：如何調(diào)度資源、任務(wù)如何監(jiān)控、中間結(jié)果如何調(diào)度、系統(tǒng)如何容錯(cuò)、如何實(shí)現(xiàn)眾多節(jié)點(diǎn)間的協(xié)調(diào)等問題。

Hadoop

Hadoop是一個(gè)開源的可運(yùn)行于大規(guī)模集群上的分布式文件系統(tǒng)和運(yùn)行處理基礎(chǔ)框架。其擅長(zhǎng)于在廉價(jià)機(jī)器搭建的集群上進(jìn)行海量數(shù)據(jù)(結(jié)構(gòu)化與非結(jié)構(gòu)化)的存儲(chǔ)與離線處理。Hadoop就是一門用來處理大數(shù)據(jù)的技術(shù)，就是用來解決上述提到的分布式計(jì)算里面的5個(gè)技術(shù)難題的。

Hadoop 由 Apache Software Foundation 公司于 2005 年秋天作為 Lucene 的子 項(xiàng)目 Nutch 的一部分正式引入。它受到最先由 Google Lab 開發(fā)的 MapReduce 和 Google File System 的啟發(fā)。2006 年 3 月份，MapReduce 和 Nutch Distributed File System (NDFS) 分別被納入稱為 Hadoop 的項(xiàng)目中?！　adoop 是最受歡迎的在 Internet 上對(duì)搜索關(guān)鍵字進(jìn)行內(nèi)容分類的工具，但它也可以解決許多要求極大伸縮性的問題。例如，如果您要 grep 一個(gè) 10TB 的巨型文件，會(huì)出現(xiàn)什么情況？在傳統(tǒng)的系統(tǒng)上，這將需要很長(zhǎng)的時(shí)間。但是 Hadoop 在設(shè)計(jì)時(shí)就考慮到這些問題，因此能大大提高效率。

Hadoop的生態(tài)壞境

Hadoop是一個(gè)能夠?qū)Υ罅繑?shù)據(jù)進(jìn)行分布式處理的軟件框架。具有可靠、高效、可伸縮的特點(diǎn)。Hadoop的核心是HDFS和Mapreduce，hadoop2.0還包括YARN。

HDFS（Hadoop分布式文件系統(tǒng)）

HDFS（Hadoop Distributed File System）源自于Google的GFS論文，發(fā)表于2003年10月，HDFS是GFS克隆版。是Hadoop體系中數(shù)據(jù)存儲(chǔ)管理的基礎(chǔ)。它是一個(gè)高度容錯(cuò)的系統(tǒng)，能檢測(cè)和應(yīng)對(duì)硬件故障，用于在低成本的通用硬件上運(yùn)行。HDFS簡(jiǎn)化了文件的一致性模型，通過流式數(shù)據(jù)訪問，提供高吞吐量應(yīng)用程序數(shù)據(jù)訪問功能，適合帶有大型數(shù)據(jù)集的應(yīng)用程序。

• Client：切分文件；訪問HDFS；與NameNode交互，獲取文件位置信息；與DataNode交互，讀取和寫入數(shù)據(jù)。
• NameNode：Master節(jié)點(diǎn)，在hadoop1.X中只有一個(gè)，管理HDFS的名稱空間和數(shù)據(jù)塊映射信息，配置副本策略，處理客戶端請(qǐng)求。
• DataNode：Slave節(jié)點(diǎn)，存儲(chǔ)實(shí)際的數(shù)據(jù)，匯報(bào)存儲(chǔ)信息給NameNode。
• Secondary NameNode：輔助NameNode，分擔(dān)其工作量；定期合并fsimage和fsedits，推送給NameNode；緊急情況下，可輔助恢復(fù)NameNode，但Secondary NameNode并非NameNode的熱備。

YARN是一種 Hadoop 資源管理器，它是一個(gè)通用資源管理系統(tǒng)，可為上層應(yīng)用提供統(tǒng)一的資源管理和調(diào)度，它的引入為集群在利用率、資源統(tǒng)一管理和數(shù)據(jù)共享等方面帶來了巨大好處。
#####Hadoop YARN產(chǎn)生背景
直接源于MRv1在幾個(gè)方面的缺陷：

• 擴(kuò)展性受限
• 單點(diǎn)故障
• 難以支持MR之外的計(jì)算

除此之外，多計(jì)算框架各自為戰(zhàn)，數(shù)據(jù)共享困難。比如：MapReduce（離線計(jì)算框架）、Storm（實(shí)時(shí)計(jì)算框架）、Spark（內(nèi)存計(jì)算框架）。
#####Hadoop YARN基本架構(gòu)

ResourceManager

• 處理客戶端請(qǐng)求
• 啟動(dòng)/監(jiān)控ApplicationMaster
• 監(jiān)控NodeManager
• 資源分配與調(diào)度

NodeManager

• 單個(gè)節(jié)點(diǎn)上的資源管理
• 處理來自ResourceManager的命令
• 處理來自ApplicationMaster的命令

ApplicationMaster

• 數(shù)據(jù)切分
• 為應(yīng)用程序申請(qǐng)資源，并分配給內(nèi)部任務(wù)
• 任務(wù)監(jiān)控與容錯(cuò)

Hadoop YARN調(diào)度框架

Hadoop YARN采用雙層調(diào)度框架。首先，RM將資源分配給AM。其次，AM再將資源進(jìn)一步分配給各個(gè)Task。YARN與“all or nothing”策略不同（Apache Mesos），其遵循基于資源預(yù)留的調(diào)度策略，當(dāng)資源不夠時(shí)，會(huì)為Task預(yù)留，直到資源充足。

運(yùn)行在YARN上的計(jì)算框架

• 離線計(jì)算框架：MapReduce
• DAG計(jì)算框架：Tez
• 流式計(jì)算框架：Storm
• 內(nèi)存計(jì)算框架：Spark
• 圖計(jì)算框架：Giraph、GraphLib

Hadoop MapReduce是google MapReduce 克隆版。

MapReduce是一種計(jì)算模型，用以進(jìn)行大數(shù)據(jù)量的計(jì)算。其中Map對(duì)數(shù)據(jù)集上的獨(dú)立元素進(jìn)行指定的操作，生成鍵-值對(duì)形式中間結(jié)果。Reduce則對(duì)中間結(jié)果中相同“鍵”的所有“值”進(jìn)行規(guī)約，以得到最終結(jié)果。MapReduce這樣的功能劃分，非常適合在大量計(jì)算機(jī)組成的分布式并行環(huán)境里進(jìn)行數(shù)據(jù)處理。

• JobTracker：Master節(jié)點(diǎn)，只有一個(gè)，管理所有作業(yè)，作業(yè)/任務(wù)的監(jiān)控、錯(cuò)誤處理等；將任務(wù)分解成一系列任務(wù)，并分派給TaskTracker。
• TaskTracker：Slave節(jié)點(diǎn)，運(yùn)行Map Task和Reduce Task；并與JobTracker交互，匯報(bào)任務(wù)狀態(tài)。
• Map Task：解析每條數(shù)據(jù)記錄，傳遞給用戶編寫的map(),并執(zhí)行，將輸出結(jié)果寫入本地磁盤(如果為map-only作業(yè)，直接寫入HDFS)。
• Reducer Task：從Map Task的執(zhí)行結(jié)果中，遠(yuǎn)程讀取輸入數(shù)據(jù)，對(duì)數(shù)據(jù)進(jìn)行排序，將數(shù)據(jù)按照分組傳遞給用戶編寫的reduce函數(shù)執(zhí)行。

Hive（基于Hadoop的數(shù)據(jù)倉(cāng)庫）

Hive由facebook開源，最初用于解決海量結(jié)構(gòu)化的日志數(shù)據(jù)統(tǒng)計(jì)問題。Hive定義了一種類似SQL的查詢語言(HQL),將SQL轉(zhuǎn)化為MapReduce任務(wù)在Hadoop上執(zhí)行，通常用于離線分析。

HBase（分布式列存數(shù)據(jù)庫）

Hbae源自Google的Bigtable論文，發(fā)表于2006年11月，HBase是Google Bigtable克隆版。HBase是一個(gè)針對(duì)結(jié)構(gòu)化數(shù)據(jù)的可伸縮、高可靠、高性能、分布式和面向列的動(dòng)態(tài)模式數(shù)據(jù)庫。和傳統(tǒng)關(guān)系數(shù)據(jù)庫不同，HBase采用了BigTable的數(shù)據(jù)模型：增強(qiáng)的稀疏排序映射表（Key/Value），其中，鍵由行關(guān)鍵字、列關(guān)鍵字和時(shí)間戳構(gòu)成。HBase提供了對(duì)大規(guī)模數(shù)據(jù)的隨機(jī)、實(shí)時(shí)讀寫訪問，同時(shí)，HBase中保存的數(shù)據(jù)可以使用MapReduce來處理，它將數(shù)據(jù)存儲(chǔ)和并行計(jì)算完美地結(jié)合在一起。

HBase和Hive在大數(shù)據(jù)架構(gòu)中處在不同位置，HBase主要解決實(shí)時(shí)數(shù)據(jù)查詢問題，Hive主要解決數(shù)據(jù)處理和計(jì)算問題，一般是配合使用。

Zookeeper（分布式協(xié)作服務(wù)）

源自Google的Chubby論文，發(fā)表于2006年11月，Zookeeper是Chubby克隆版
解決分布式環(huán)境下的數(shù)據(jù)管理問題：統(tǒng)一命名，狀態(tài)同步，集群管理，配置同步等。

Sqoop（數(shù)據(jù)同步工具）

Sqoop是SQL-to-Hadoop的縮寫，主要用于傳統(tǒng)數(shù)據(jù)庫和Hadoop之前傳輸數(shù)據(jù)。數(shù)據(jù)的導(dǎo)入和導(dǎo)出本質(zhì)上是Mapreduce程序，充分利用了MR的并行化和容錯(cuò)性。

Pig（基于Hadoop的數(shù)據(jù)流系統(tǒng)）

由yahoo!開源，設(shè)計(jì)動(dòng)機(jī)是提供一種基于MapReduce的ad-hoc(計(jì)算在query時(shí)發(fā)生)數(shù)據(jù)分析工具。其定義了一種數(shù)據(jù)流語言—Pig Latin，將腳本轉(zhuǎn)換為MapReduce任務(wù)在Hadoop上執(zhí)行，通常用于進(jìn)行離線分析。

Spark

Spark是UC Berkeley AMPLab開發(fā)的是一種計(jì)算框架，分布式資源工作交由集群管理軟件（Mesos、YARN） 。

###Spark的特點(diǎn)

• 先進(jìn)架構(gòu)
• Spark采用Scala語言編寫，底層采用了actor model的akka作為通訊框架，代碼十分簡(jiǎn)潔高效。
• 基于DAG圖的執(zhí)行引擎，減少多次計(jì)算之間中間結(jié)果寫到Hdfs的開銷。
• 建立在統(tǒng)一抽象的RDD（分布式內(nèi)存抽象）之上,使得它可以以基本一致的方式應(yīng)對(duì)不同的大數(shù)據(jù)處理場(chǎng)景。
• 高效
• 提供Cache機(jī)制來支持需要反復(fù)迭代的計(jì)算或者多次數(shù)據(jù)共享，減少數(shù)據(jù)讀取的IO開銷。
• 與Hadoop的MapReduce相比，Spark基于內(nèi)存的運(yùn)算比MR要快100倍；而基于硬盤的運(yùn)算也要快10倍！
• 易用
• Spark提供廣泛的數(shù)據(jù)集操作類型（20+種），不像Hadoop只提供了Map和Reduce兩種操作。
• Spark支持Java，Python和Scala API，支持交互式的Python和Scala的shell。
• 提供整體解決方案
• 以其RDD模型的強(qiáng)大表現(xiàn)能力，逐漸形成了一套自己的生態(tài)圈，提供了full-stack的解決方案。
• 主要包括Spark內(nèi)存中批處理，Spark SQL交互式查詢，Spark Streaming流式計(jì)算， GraphX和MLlib提供的常用圖計(jì)算和機(jī)器學(xué)習(xí)算法。
• 與Hadoop無縫連接
• Spark可以使用YARN作為它的集群管理器
• 讀取HDFS,HBase等一切Hadoop的數(shù)據(jù)

Spark整體架構(gòu)

Spark提供了多種高級(jí)工具，如： Shark SQL應(yīng)用于即席查詢（Ad-hoc query）、Spark Streaming應(yīng)用于流式計(jì)算、 MLlib應(yīng)用于機(jī)器學(xué)習(xí)、GraphX應(yīng)用于圖處理。Spark還可以基于自帶的standalone集群管理器獨(dú)立運(yùn)行，也可以部署在Apache Mesos 和 Hadoop YARN 等集群管理器上運(yùn)行。Spark可以訪問存儲(chǔ)在HDFS、 Hbase、Cassandra、Amazon S3、本地文件系統(tǒng)等等上的數(shù)據(jù)，Spark支持文本文件，序列文件，以及任何Hadoop的InputFormat。

Spark核心概念

Spark任務(wù)提供多層分解的概念，Spark組件將用戶的應(yīng)用程序分解為內(nèi)部執(zhí)行任務(wù)并提供執(zhí)行容器，資源管理為spark組件提供資源管理和調(diào)度。

Spark任務(wù)

• 應(yīng)用程序：由一個(gè)driver program和多個(gè)job構(gòu)成
• job：由多個(gè)stage組成
• stage：對(duì)應(yīng)一個(gè)taskset
• taskset：對(duì)應(yīng)一組關(guān)聯(lián)的相互之間沒有shuffle依賴關(guān)系的task組成。
• task：任務(wù)最小的工作單元

• Spark組件
• Driver Program (驅(qū)動(dòng)程序) ：Spark 的核心組件
• 構(gòu)建SparkContext(Spark應(yīng)用的入口,它負(fù)責(zé)和整個(gè)集群的交互，創(chuàng)建需要的變量，還包含集群的配置信息等)
• 將用戶提交的job轉(zhuǎn)換為DAG圖(類似數(shù)據(jù)處理的流程圖)
• 根據(jù)策略將DAG圖劃分為多個(gè)stage，根據(jù)分區(qū)從而生成一系列tasks
• 根據(jù)tasks要求向資源管理器申請(qǐng)資源
• 提交任務(wù)并檢測(cè)任務(wù)狀態(tài)
• Executor
• 真正執(zhí)行task的單元，一個(gè)Worker Node上可以有多個(gè)Executor
• 資資源管理組件
• YARN（通用）：Master/Slave結(jié)構(gòu)
• Resource Manager(RM)：全局的資源管理器，負(fù)責(zé)系統(tǒng)的資源管理和分配
• Node Manager(NM)：每個(gè)節(jié)點(diǎn)上的資源和任務(wù)管理器
• Application Master(AM)：每個(gè)應(yīng)用程序都有一個(gè)，負(fù)責(zé)任務(wù)的調(diào)度和監(jiān)視，并與RM調(diào)度器協(xié)商為任務(wù)獲取資源。
• Standalone（Spark自帶）：Master/Slave結(jié)構(gòu)
• Master：類似于YARN的RM
• Worker：類似于YARN的NM

Spark端到端流程

Spark的Driver Program (簡(jiǎn)稱Driver)包含用戶的應(yīng)用程序，Driver完成task的解析和生成。

1. Driver向Cluster Manager（集群資源管理器）申請(qǐng)運(yùn)行task需要的資源。
2. 集群資源管理器為task分配滿足要求的節(jié)點(diǎn)，并在節(jié)點(diǎn)按照要求創(chuàng)建Executor
3. 創(chuàng)建的Executor向Driver注冊(cè)。
4. Driver將Spark應(yīng)用程序的代碼和文件傳送給分配的Executor
5. Executor運(yùn)行task，運(yùn)行完之后將結(jié)果返回給Driver或者寫入HDFS或其他介質(zhì)。

Spark流程

Spark on Standalone

Master和Worker是Standalone的角色，Driver和Executor是Spark的角色。Master負(fù)責(zé)分配資源，分配Driver和Executor，讓W(xué)orker啟動(dòng)Driver和Executor，只管理到Executor層，不涉及任務(wù)。Driver負(fù)責(zé)生成task，并與Executor通信，進(jìn)行任務(wù)的調(diào)度和結(jié)果跟蹤，不涉及資源。

Driver運(yùn)行在Worker

1. 客戶端把作業(yè)發(fā)布到Master
2. Master讓一個(gè)Worker啟動(dòng)Driver，并將作業(yè)推送給Driver
3. Driver進(jìn)程生成一系列task
4. Driver向Master申請(qǐng)資源
5. Master讓調(diào)度的Worker啟動(dòng)Exeuctor
6. Exeuctor啟動(dòng)后向Driver注冊(cè)。
7. Driver將task調(diào)度到Exeuctor執(zhí)行。
8. Executor執(zhí)行結(jié)果寫入文件或返回Driver

1. 客戶端啟動(dòng)后直接運(yùn)行用戶程序，啟動(dòng)Driver
2. Driver進(jìn)程生成一系列task
3. Driver向Master申請(qǐng)資源
4. Master讓調(diào)度的Worker啟動(dòng)Exeuctor
5. Exeuctor啟動(dòng)后向Driver注冊(cè)。
6. Driver將task調(diào)度到Exeuctor執(zhí)行。
7. Executor執(zhí)行結(jié)果寫入文件或返回Driver

Spark的核心組件

Spark的核心組件包括RDD、Scheduler、Storage、Shuffle四部分：

• RDD是Spark最核心最精髓的部分，Spark將所有數(shù)據(jù)都抽象成RDD。
• Scheduler是Spark的調(diào)度機(jī)制，分為DAGScheduler和TaskScheduler。
• Storage模塊主要管理緩存后的RDD、shuffle中間結(jié)果數(shù)據(jù)和broadcast數(shù)據(jù)
• Shuffle分為Hash方式和Sort方式，兩種方式的shuffle中間數(shù)據(jù)都寫本地盤

RDD（Resilient Distributed Datasets）

RDD是彈性分布式數(shù)據(jù)集，是只讀的分區(qū)記錄集合。每個(gè)RDD有5個(gè)主要的屬性：

• 一組分片(Partition)：數(shù)據(jù)集的最基本組成單位
• 一個(gè)計(jì)算每個(gè)分片的函數(shù)：對(duì)于給定的數(shù)據(jù)集，需要做哪些計(jì)算
• 依賴（Dependencies）：RDD的依賴關(guān)系，描述了RDD之間的lineage
• preferredLocations（可選）：對(duì)于data partition的位置偏好
• partitioner（可選）：對(duì)于計(jì)算出來的數(shù)據(jù)結(jié)果如何分發(fā)

作用于RDD上的Operation分為轉(zhuǎn)換(transformantion)和動(dòng)作(action)。 Spark中的所有“轉(zhuǎn)換”都是惰性的，在執(zhí)行“轉(zhuǎn)換”操作，并不會(huì)提交Job，只有在執(zhí)行“動(dòng)作”操作，所有operation才會(huì)被提交到cluster中真正的被執(zhí)行。這樣可以大大提升系統(tǒng)的性能。

• 轉(zhuǎn)換：從現(xiàn)有的數(shù)據(jù)集創(chuàng)建一個(gè)新的數(shù)據(jù)集即數(shù)據(jù)集中的內(nèi)容會(huì)發(fā)生更改，由數(shù)據(jù)集A轉(zhuǎn)換成為數(shù)據(jù)集B
• 動(dòng)作：在數(shù)據(jù)集上運(yùn)行計(jì)算后，返回一個(gè)值給驅(qū)動(dòng)程序。 即數(shù)據(jù)集中的內(nèi)容會(huì)被歸約為一個(gè)具體的數(shù)值（Scala標(biāo)量、集合類型的數(shù)據(jù)或存儲(chǔ)）。

RDD擁有的操作比MR豐富的多，不僅僅包括Map、Reduce操作，還包括右圖的filter、sort、join、save、count等操作，所以Spark比MR更容易方便完成更復(fù)雜的任務(wù)。

RDD持久化

默認(rèn)情況下，每一個(gè)轉(zhuǎn)換過的RDD都會(huì)在它之上執(zhí)行一個(gè)動(dòng)作時(shí)被重新計(jì)算。如果RDD只被使用一次或者很少次，不需要持久化。如果RDD被重復(fù)使用或者計(jì)算其代價(jià)很高，才考慮持久化。另外，shuffle后生成的RDD盡量持久化，因?yàn)閟huffle代價(jià)太高。RDD被緩存后，Spark將會(huì)在集群中，保存相關(guān)元數(shù)據(jù)，下次查詢這個(gè)RDD時(shí)，它將能更快速訪問，不需要計(jì)算。如果持久化無謂的RDD，會(huì)浪費(fèi)內(nèi)存（或硬盤）空間，反而降低系統(tǒng)整體性能

RDD依賴關(guān)系

RDD只能基于在穩(wěn)定物理存儲(chǔ)中的數(shù)據(jù)集和其他已有的RDD上執(zhí)行確定性操作來創(chuàng)建。能從其他RDD通過確定操作創(chuàng)建新的RDD的原因是RDD含有從其他RDD衍生（即計(jì)算）出本RDD的相關(guān)信息（即Lineage）。Dependency代表了RDD之間的依賴關(guān)系，即血緣（Lineage），分為窄依賴和寬依賴：

• 窄依賴：一個(gè)父RDD最多被一個(gè)子RDD用在一個(gè)集群節(jié)點(diǎn)上管道式執(zhí)行。比如map、filter、union等
• 寬依賴：子RDD的分區(qū)依賴于父RDD的所有分區(qū)，這是因?yàn)閟huffle類操作要求所有父分區(qū)可用。比如groupByKey、reduceByKey、 sort、partitionBy等

根據(jù)RDD依賴關(guān)系的不同，Spark將每一個(gè)job分為不同的stage，stage之間的依賴關(guān)系形成了DAG圖。對(duì)于窄依賴，Spark將其盡量劃分在同一個(gè)stage中，因?yàn)樗鼈兛梢赃M(jìn)行流水線計(jì)算，而寬依賴往往意味著shuffle操作，這也是Spark劃分stage的主要邊界。

寬/窄依賴的概念不止用在stage劃分中，對(duì)容錯(cuò)也很有用。若Transformation操作中間發(fā)生計(jì)算失敗，如果運(yùn)算是窄依賴，只要把丟失的父RDD分區(qū)重算即可，跟其他節(jié)點(diǎn)沒有依賴，這樣可以大大加快場(chǎng)景恢復(fù)的開銷，但如果運(yùn)算是寬依賴，則需要父RDD的所有分區(qū)都存在， 重算代價(jià)就較高。當(dāng)Lineage特別長(zhǎng)時(shí)或者有寬依賴時(shí)，主動(dòng)調(diào)用 checkpoint把當(dāng)前數(shù)據(jù)寫入穩(wěn)定存儲(chǔ)，作為檢查點(diǎn)。

Scheduler

Scheduler模塊作為Spark最核心的模塊之一，充分體現(xiàn)了Spark與MapReduce的不同之處，體現(xiàn)了Spark DAG思想的精巧和設(shè)計(jì)的優(yōu)雅。Scheduler模塊分為兩大主要部分，DAGScheduler和TaskScheduler。

DAGScheduler把一個(gè)spark作業(yè)轉(zhuǎn)換成成stage的DAG（Directed Acyclic Graph有向無環(huán)圖），根據(jù)RDD和stage之間的關(guān)系，找出開銷最小的調(diào)度方法，然后把stage以TaskSet的形式提交給TaskScheduler。TaskScheduler模塊用于與DAGScheduler交互，負(fù)責(zé)任務(wù)的具體調(diào)度和運(yùn)行。任務(wù)調(diào)度模塊基于兩個(gè)Trait：TaskScheduler和 SchedulerBackend。

Storage

Storage模塊主要分為兩層：

• 通信層：Storage模塊采用的是master-slave結(jié)構(gòu)來實(shí)現(xiàn)通信層，master和slave之間傳輸控制信息、狀態(tài)信息，這些都是通過通信層來實(shí)現(xiàn)的。
• 存儲(chǔ)層：Storage模塊需要把數(shù)據(jù)存儲(chǔ)到disk或是memory上面，有可能還需replicate到遠(yuǎn)端，這都是由存儲(chǔ)層來實(shí)現(xiàn)和提供相應(yīng)接口。

Storage模塊提供了統(tǒng)一的操作類BlockManager，外部類與storage模塊打交道都需要通過調(diào)用BlockManager相應(yīng)接口來實(shí)現(xiàn)。Storage模塊存取的最小單位是數(shù)據(jù)塊(Block)，Block與RDD中的Partition一一對(duì)應(yīng)，所以所有的轉(zhuǎn)換或動(dòng)作操作最終都是對(duì)Block進(jìn)行操作。

Shuffle

Shuffle 中Map任務(wù)產(chǎn)生的結(jié)果會(huì)根據(jù)所設(shè)置的partitioner算法填充到當(dāng)前執(zhí)行任務(wù)所在機(jī)器的每個(gè)桶中。Reduce任務(wù)啟動(dòng)時(shí)時(shí)，會(huì)根據(jù)任務(wù)的ID，所依賴的Map任務(wù)ID以及MapStatus從遠(yuǎn)端或本地的BlockManager獲取相應(yīng)的數(shù)據(jù)作為輸入進(jìn)行處理。Shuffle數(shù)據(jù)必須持久化磁盤，不能緩存在內(nèi)存。

Spark之上提供了四種應(yīng)用庫：

• Spark SQL 是為處理結(jié)構(gòu)化數(shù)據(jù)而設(shè)計(jì)的模塊
• Spark Streaming 可以很容易地創(chuàng)建可擴(kuò)展和容錯(cuò)性的流式應(yīng)用
• MLlib 是Spark的可擴(kuò)展機(jī)器學(xué)習(xí)庫
• GraphX 是Spark的并行圖計(jì)算API

以上便是對(duì)Hadoop、Spark的一些淺顯的介紹。事實(shí)上，解決大數(shù)據(jù)處理相關(guān)的問題，往往要經(jīng)過數(shù)據(jù)收集（Flume、Kafka、Sqoop）、數(shù)據(jù)存儲(chǔ)（HDFS、HBase）、資源管理（YARN）、計(jì)算（MapReduce、Spark）、數(shù)據(jù)分析（Pandas、NumPy、R）、數(shù)據(jù)可視化（Echart、Tableau）等環(huán)節(jié)。各個(gè)環(huán)節(jié)都有其相應(yīng)的工具，Hadoop和Spark就是大數(shù)據(jù)處理流程中非常常用的兩個(gè)框架。

到此這篇關(guān)于一文學(xué)會(huì)Hadoop與Spark等大數(shù)據(jù)框架知識(shí)的文章就介紹到這了,更多相關(guān)Hadoop與Spark大數(shù)據(jù)內(nèi)容請(qǐng)搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評(píng)論