目錄
- 1. Spark 與 Hadoop 比較
- 1.1 Haoop 的缺點(diǎn)
- 1.2 相較于Hadoop MR的優(yōu)點(diǎn)
- 2. Spark 生態(tài)系統(tǒng)
- 2.1 大數(shù)據(jù)處理的三種類型
- 1. 復(fù)雜的批量數(shù)據(jù)處理
- 2. 基于歷史數(shù)據(jù)的交互式查詢
- 3. 基于實(shí)時(shí)數(shù)據(jù)流的數(shù)據(jù)處理
- 2.2 BDAS架構(gòu)
- 2.3 Spark 生態(tài)系統(tǒng)
- 3. 基本概念與架構(gòu)設(shè)計(jì)
- 3.1 基本概念
- 3.2 運(yùn)行架構(gòu)
- 3.3 各種概念之間的相互關(guān)系
- 4. Spark運(yùn)行基本流程
- 4.1 運(yùn)行流程
- 4.2 運(yùn)行架構(gòu)特點(diǎn)
- 5. Spark的部署和應(yīng)用方式
- 5.1 Spark的三種部署方式
- 5.1.1 Standalone
- 5.1.2 Spark on Mesos
- 5.1.3 Spark on YARN
- 5.2 從Hadoop+Storm架構(gòu)轉(zhuǎn)向Spark架構(gòu)
- Hadoop+Storm架構(gòu)
- 用Spark架構(gòu)滿足批處理和流處理需求
- Spark架構(gòu)的優(yōu)點(diǎn)：
- 5.3 Hadoop和Spark的統(tǒng)一部署
- 不同計(jì)算框架統(tǒng)一運(yùn)行在YARN中
1. Spark 與 Hadoop 比較
1.1 Haoop 的缺點(diǎn)
- 1. 表達(dá)能力有限；
- 2. 磁盤IO開銷大；
- 3. 延遲高；
- 4. 任務(wù)之間的銜接涉及IO開銷；
- 5. 在前一個(gè)任務(wù)執(zhí)行完之前，其他任務(wù)就無法開始，難以勝任復(fù)雜、多階段的計(jì)算任務(wù)。
1.2 相較于Hadoop MR的優(yōu)點(diǎn)
- 1. Spark的計(jì)算模式也屬于MR，但不局限于Map和Reduce操作，它還提供了多種數(shù)據(jù)集操作類型，編程模式也比Hadoop MR更靈活；
- 2. Spark提供了內(nèi)存計(jì)算，可將中間結(jié)果放到內(nèi)存中，對(duì)于迭代運(yùn)算效率更高；
- 3. Spark 基于DAG的任務(wù)調(diào)度執(zhí)行機(jī)制，要優(yōu)于Hadoop MR的迭代執(zhí)行機(jī)制。
|
Spark |
MapReduce |
| 數(shù)據(jù)存儲(chǔ)結(jié)構(gòu) |
使用內(nèi)存構(gòu)建彈性分布式數(shù)據(jù)集RDD，對(duì)數(shù)據(jù)進(jìn)行運(yùn)算和cache。 |
磁盤HDFS文件系統(tǒng)的split |
| 編程范式 |
DAG（Transformation+Action） |
Map+Reduce |
| 計(jì)算中間結(jié)果的存儲(chǔ) |
在內(nèi)存中維護(hù)，存取速度比磁盤高幾個(gè)數(shù)量級(jí) |
落到磁盤，IO及序列化、反序列化代價(jià)大 |
| Task維護(hù)方式 |
線程 |
進(jìn)程 |
| 時(shí)間 |
對(duì)于小數(shù)據(jù)集讀取能夠達(dá)到亞秒級(jí)的延遲 |
需要數(shù)秒時(shí)間才能啟動(dòng)任務(wù) |
2. Spark 生態(tài)系統(tǒng)
2.1 大數(shù)據(jù)處理的三種類型
1. 復(fù)雜的批量數(shù)據(jù)處理
時(shí)間跨度在數(shù)十分鐘到數(shù)小時(shí)
Haoop MapReduce
2. 基于歷史數(shù)據(jù)的交互式查詢
時(shí)間跨度在數(shù)十秒到數(shù)分鐘
Cloudera、Impala 這兩者實(shí)時(shí)性均優(yōu)于hive。
3. 基于實(shí)時(shí)數(shù)據(jù)流的數(shù)據(jù)處理
時(shí)間跨度在數(shù)百毫秒到數(shù)秒
Storm
2.2 BDAS架構(gòu)
2.3 Spark 生態(tài)系統(tǒng)
3. 基本概念與架構(gòu)設(shè)計(jì)
3.1 基本概念
3.2 運(yùn)行架構(gòu)
Spark采用Executor的優(yōu)點(diǎn)：（相比于Hadoop的MR）
- 1. 利用多線程來執(zhí)行具體的任務(wù)，減少任務(wù)的啟動(dòng)開銷；
- 2. Executor中有一個(gè)BlockManager存儲(chǔ)模塊，會(huì)將內(nèi)存和磁盤共同作為存儲(chǔ)設(shè)備，有效減少IO開銷。
3.3 各種概念之間的相互關(guān)系
- 一個(gè)Application由一個(gè)Driver和若干個(gè)Job構(gòu)成
- 一個(gè)Job由多個(gè)Stage構(gòu)成
- 一個(gè)Stage由多個(gè)沒有shuffle關(guān)系的Task組成
當(dāng)執(zhí)行一個(gè)Application時(shí)，Driver會(huì)向集群管理器申請(qǐng)資源，啟動(dòng)Executor，
并向Executor發(fā)送應(yīng)用程序代碼和文件，然后在Executor上執(zhí)行Task，運(yùn)行結(jié)束后，
執(zhí)行結(jié)果會(huì)返回給Driver，或者寫到HDFS或者其他數(shù)據(jù)庫中。
4. Spark運(yùn)行基本流程
4.1 運(yùn)行流程
1. 為應(yīng)用構(gòu)建起基本的運(yùn)行環(huán)境，即由Driver創(chuàng)建一個(gè)SparkContext進(jìn)行資源的申請(qǐng)、任務(wù)的分配和監(jiān)控。
2. 資源管理器為Executor分配資源，并啟動(dòng)Executor進(jìn)程。
- 3.1 SparkContext根據(jù)RDD的依賴關(guān)系構(gòu)建DAG圖，DAG圖提交給DAGScheduler解析成Stage，然后把一個(gè)個(gè)TaskSet提交給底層調(diào)度器TaskScheduler處理。
- 3.2 Executor向SparkContext申請(qǐng)Task，TaskScheduler將Task發(fā)送給Executor運(yùn)行并提供應(yīng)用程序代碼。
4. Task在Executor上運(yùn)行把執(zhí)行結(jié)果反饋給TaskScheduler，然后反饋給DAGScheduler，運(yùn)行完畢后寫入數(shù)據(jù)并釋放所有資源。
4.2 運(yùn)行架構(gòu)特點(diǎn)
1. 每個(gè)Application都有自己專屬的Executor進(jìn)程，并且該進(jìn)程在Application運(yùn)行期間一直駐留。Executor進(jìn)程以多線程的方式運(yùn)行Task。
2. Spark運(yùn)行過程與資源管理器無關(guān)，只要能夠獲取Executor進(jìn)程并保持通信即可。
3. Task采用了數(shù)據(jù)本地性和推測(cè)執(zhí)行等優(yōu)化機(jī)制。（計(jì)算向數(shù)據(jù)靠攏。）
5. Spark的部署和應(yīng)用方式
5.1 Spark的三種部署方式
5.1.1 Standalone
類似于MR1.0，slot為資源分配單位，但性能并不好。
5.1.2 Spark on Mesos
Mesos和Spark有一定的親緣關(guān)系。
5.1.3 Spark on YARN
mesos和yarn的聯(lián)系
5.2 從Hadoop+Storm架構(gòu)轉(zhuǎn)向Spark架構(gòu)
Hadoop+Storm架構(gòu)
這種部署方式較為繁瑣。
用Spark架構(gòu)滿足批處理和流處理需求
Spark用快速的小批量計(jì)算模擬流計(jì)算，并非真實(shí)的流計(jì)算。
無法實(shí)現(xiàn)毫秒級(jí)的流計(jì)算，對(duì)于需要毫秒級(jí)實(shí)時(shí)響應(yīng)的企業(yè)應(yīng)用而言，仍需采用流計(jì)算框架Storm等。
Spark架構(gòu)的優(yōu)點(diǎn)：
- 1. 實(shí)現(xiàn)一鍵式安裝和配置，線程級(jí)別的任務(wù)監(jiān)控和告警；
- 2. 降低硬件集群、軟件維護(hù)、任務(wù)監(jiān)控和應(yīng)用開發(fā)的難度；
- 3. 便于做成統(tǒng)一的硬件、計(jì)算平臺(tái)資源池。
5.3 Hadoop和Spark的統(tǒng)一部署
不同計(jì)算框架統(tǒng)一運(yùn)行在YARN中
好處如下：
- 1. 計(jì)算資源按需伸縮；
- 2. 不用負(fù)載應(yīng)用混搭，集群利用率高；
- 3. 共享底層存儲(chǔ)，避免數(shù)據(jù)跨集群遷移
現(xiàn)狀：
1. Spark目前還是無法取代Hadoop生態(tài)系統(tǒng)中的一些組件所實(shí)現(xiàn)的功能。
2. 現(xiàn)有的Hadoop組件開發(fā)的應(yīng)用，完全遷移到Spark上需要一定的成本。
到此這篇關(guān)于Spark簡介以及與Hadoop對(duì)比分析的文章就介紹到這了,更多相關(guān)Spark與Hadoop內(nèi)容請(qǐng)搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！
