hadoop需要哪些技術支援

hadoop是一個開源軟體框架，可安裝在一個商用機器叢集中，使機器可彼此通訊並協同工作，以高度分散式的方式共同儲存和處理大量資料。最初，Hadoop 包含以下兩個主要元件：Hadoop Distributed File System (HDFS) 和一個分散式計算引擎，該引擎支援以 MapReduce 作業的形式實現和執行程式。
Hadoop 還提供了軟體基礎架構，以一系列 map 和 reduce 任務的形式執行 MapReduce 作業。Map 任務在輸入資料的子集上呼叫map函式。在完成這些呼叫後，reduce任務開始在 map函式所生成的中間資料上呼叫reduce任務，生成最終的輸出。map和reduce任務彼此單獨執行，這支援並行和容錯的計算。
最重要的是，Hadoop 基礎架構負責處理分散式處理的所有複雜方面：並行化、排程、資源管理、機器間通訊、軟體和硬體故障處理，等等。得益於這種乾淨的抽象，實現處理數百（或者甚至數千）個機器上的數 TB 資料的分散式應用程式從未像現在這麼容易過，甚至對於之前沒有使用分散式系統的經驗的開發人員也是如此。

map reduce 過程圖
shuffle combine
整體的Shuffle過程包含以下幾個部分：Map端Shuffle、Sort階段、Reduce端Shuffle。即是說：Shuffle 過程橫跨 map 和 reduce 兩端，中間包含 sort 階段，就是資料從 map task 輸出到reduce task輸入的這段過程。
sort、combine 是在 map 端的，combine 是提前的 reduce ，需要自己設定。
Hadoop 叢集中，大部分 map task 與 reduce task 的執行是在不同的節點上。當然很多情況下 Reduce 執行時需要跨節點去拉取其它節點上的map task結果。如果叢集正在執行的 job 有很多，那麼 task 的正常執行對叢集內部的網路資源消耗會很嚴重。而對於必要的網路資源消耗，最終的目的就是最大化地減少不必要的消耗。還有在節點內，相比於記憶體，磁碟 IO 對 job 完成時間的影響也是可觀的。從最基本的要求來說，對於 MapReduce 的 job 效能調優的 Shuffle 過程，目標期望可以有：
完整地從map task端拉取資料到reduce 端。
在跨節點拉取資料時，儘可能地減少對頻寬的不必要消耗。
減少磁碟IO對task執行的影響。
總體來講這段Shuffle過程，能優化的地方主要在於減少拉取資料的量及儘量使用記憶體而不是磁碟。
YARN
ResourceManager 代替叢集管理器
ApplicationMaster 代替一個專用且短暫的 JobTracker
NodeManager 代替 TaskTracker
一個分散式應用程式代替一個 MapReduce 作業
一個全域性 ResourceManager 以主要後臺程式的形式執行，它通常在專用機器上執行，在各種競爭的應用程式之間仲裁可用的叢集資源。
在使用者提交一個應用程式時，一個稱為 ApplicationMaster 的輕量型程式例項會啟動來協調應用程式內的所有任務的執行。這包括監視任務，重新啟動失敗的任務，推測性地執行緩慢的任務，以及計算應用程式計數器值的總和。有趣的是，ApplicationMaster 可在容器內執行任何型別的任務。
NodeManager 是 TaskTracker 的一種更加普通和高效的版本。沒有固定數量的 map 和 reduce slots，NodeManager 擁有許多動態建立的資源容器。

大資料Hadoop開發廠商有Amazon Web Services、Cloudera、Hortonworks、IBM、MapR科技、華為和大快搜尋。這些廠商都是基於Apache開源專案，然後增加打包、支援、整合等特性以及自己的創新等內容。
大快的大資料通用計算平臺（DKH），已經整合相同版本號的開發框架的全部元件。如果在開源大資料框架上部署大快的開發框架，需要平臺的元件支援如下：
資料來源與SQL引擎：DK.Hadoop、spark、hive、sqoop、flume、kafka
資料採集：DK.hadoop
資料處理模組：DK.Hadoop、spark、storm、hive
機器學習和AI：DK.Hadoop、spark
NLP模組：上傳伺服器端JAR包，直接支援
搜尋引擎模組：不獨立釋出