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包，直接支持
搜索引擎模塊：不獨立發佈