hadoop需要什么技術(shù)支持

這篇文章給大家分享的是有關(guān)hadoop需要什么技術(shù)支持的內(nèi)容。小編覺(jué)得挺實(shí)用的，因此分享給大家做個(gè)參考，一起跟隨小編過(guò)來(lái)看看吧。

hadoop是一個(gè)開(kāi)源軟件框架，可安裝在一個(gè)商用機(jī)器集群中，使機(jī)器可彼此通信并協(xié)同工作，以高度分布式的方式共同存儲(chǔ)和處理大量數(shù)據(jù)。最初，Hadoop 包含以下兩個(gè)主要組件：Hadoop Distributed File System (HDFS) 和一個(gè)分布式計(jì)算引擎，該引擎支持以 MapReduce 作業(yè)的形式實(shí)現(xiàn)和運(yùn)行程序。

Hadoop 還提供了軟件基礎(chǔ)架構(gòu)，以一系列 map 和 reduce 任務(wù)的形式運(yùn)行 MapReduce 作業(yè)。Map 任務(wù)在輸入數(shù)據(jù)的子集上調(diào)用map函數(shù)。在完成這些調(diào)用后，reduce任務(wù)開(kāi)始在 map函數(shù)所生成的中間數(shù)據(jù)上調(diào)用reduce任務(wù)，生成最終的輸出。map和reduce任務(wù)彼此單獨(dú)運(yùn)行，這支持并行和容錯(cuò)的計(jì)算。

最重要的是，Hadoop 基礎(chǔ)架構(gòu)負(fù)責(zé)處理分布式處理的所有復(fù)雜方面：并行化、調(diào)度、資源管理、機(jī)器間通信、軟件和硬件故障處理，等等。得益于這種干凈的抽象，實(shí)現(xiàn)處理數(shù)百（或者甚至數(shù)千）個(gè)機(jī)器上的數(shù) TB 數(shù)據(jù)的分布式應(yīng)用程序從未像現(xiàn)在這么容易過(guò)，甚至對(duì)于之前沒(méi)有使用分布式系統(tǒng)的經(jīng)驗(yàn)的開(kāi)發(fā)人員也是如此。

map reduce 過(guò)程圖

shuffle combine

整體的Shuffle過(guò)程包含以下幾個(gè)部分：Map端Shuffle、Sort階段、Reduce端Shuffle。即是說(shuō)：Shuffle 過(guò)程橫跨 map 和 reduce 兩端，中間包含 sort 階段，就是數(shù)據(jù)從 map task 輸出到reduce task輸入的這段過(guò)程。

sort、combine 是在 map 端的，combine 是提前的 reduce ，需要自己設(shè)置。

Hadoop 集群中，大部分 map task 與 reduce task 的執(zhí)行是在不同的節(jié)點(diǎn)上。當(dāng)然很多情況下 Reduce 執(zhí)行時(shí)需要跨節(jié)點(diǎn)去拉取其它節(jié)點(diǎn)上的map task結(jié)果。如果集群正在運(yùn)行的 job 有很多，那么 task 的正常執(zhí)行對(duì)集群內(nèi)部的網(wǎng)絡(luò)資源消耗會(huì)很嚴(yán)重。而對(duì)于必要的網(wǎng)絡(luò)資源消耗，最終的目的就是最大化地減少不必要的消耗。還有在節(jié)點(diǎn)內(nèi)，相比于內(nèi)存，磁盤 IO 對(duì) job 完成時(shí)間的影響也是可觀的。從最基本的要求來(lái)說(shuō)，對(duì)于 MapReduce 的 job 性能調(diào)優(yōu)的 Shuffle 過(guò)程，目標(biāo)期望可以有：

完整地從map task端拉取數(shù)據(jù)到reduce 端。

在跨節(jié)點(diǎn)拉取數(shù)據(jù)時(shí)，盡可能地減少對(duì)帶寬的不必要消耗。

減少磁盤IO對(duì)task執(zhí)行的影響。

總體來(lái)講這段Shuffle過(guò)程，能優(yōu)化的地方主要在于減少拉取數(shù)據(jù)的量及盡量使用內(nèi)存而不是磁盤。

YARN

ResourceManager 代替集群管理器

ApplicationMaster 代替一個(gè)專用且短暫的 JobTracker

NodeManager 代替 TaskTracker

一個(gè)分布式應(yīng)用程序代替一個(gè) MapReduce 作業(yè)

一個(gè)全局 ResourceManager 以主要后臺(tái)進(jìn)程的形式運(yùn)行，它通常在專用機(jī)器上運(yùn)行，在各種競(jìng)爭(zhēng)的應(yīng)用程序之間仲裁可用的集群資源。

在用戶提交一個(gè)應(yīng)用程序時(shí)，一個(gè)稱為 ApplicationMaster 的輕量型進(jìn)程實(shí)例會(huì)啟動(dòng)來(lái)協(xié)調(diào)應(yīng)用程序內(nèi)的所有任務(wù)的執(zhí)行。這包括監(jiān)視任務(wù)，重新啟動(dòng)失敗的任務(wù)，推測(cè)性地運(yùn)行緩慢的任務(wù)，以及計(jì)算應(yīng)用程序計(jì)數(shù)器值的總和。有趣的是，ApplicationMaster 可在容器內(nèi)運(yùn)行任何類型的任務(wù)。

NodeManager 是 TaskTracker 的一種更加普通和高效的版本。沒(méi)有固定數(shù)量的 map 和 reduce slots，NodeManager 擁有許多動(dòng)態(tài)創(chuàng)建的資源容器。

大數(shù)據(jù)Hadoop開(kāi)發(fā)廠商有Amazon Web Services、Cloudera、Hortonworks、IBM、MapR科技、華為和大快搜索。這些廠商都是基于Apache開(kāi)源項(xiàng)目，然后增加打包、支持、集成等特性以及自己的創(chuàng)新等內(nèi)容。

大快的大數(shù)據(jù)通用計(jì)算平臺(tái) （DKH） ，已經(jīng)集成相同版本號(hào)的開(kāi)發(fā)框架的全部組件。如果在開(kāi)源大數(shù)據(jù)框架上部署大快的開(kāi)發(fā)框架，需要平臺(tái)的組件支持如下：

數(shù)據(jù)源與SQL引擎：DK.Hadoop、spark、hive、sqoop、flume、kafka

數(shù)據(jù)采集：DK.hadoop

數(shù)據(jù)處理模塊：DK.Hadoop、spark、storm、hive

機(jī)器學(xué)習(xí)和AI：DK.Hadoop、spark

NLP模塊：上傳服務(wù)器端JAR包，直接支持

搜索引擎模塊：不獨(dú)立發(fā)布

感謝各位的閱讀！關(guān)于“hadoop需要什么技術(shù)支持”這篇文章就分享到這里了，希望以上內(nèi)容可以對(duì)大家有一定的幫助，讓大家可以學(xué)到更多知識(shí)，如果覺(jué)得文章不錯(cuò)，可以把它分享出去讓更多的人看到吧！