帶有 mapreduce 的 apache hadoop 是分布式資料處理的骨幹力量。借助其獨特的橫向擴充套件物理集群架構和由 google 最初開發的精細處理框架，hadoop 在大資料處理的全新領域迎來了**式增長。hadoop 還開發了乙個豐富多樣的應用程式生態系統，包括 apache pig（一種強大的指令碼語言）和 apache hive（乙個具有類似 sql 介面的資料倉儲解決方案）。
不幸的是，這個生態系統構建於一種程式設計模式之上，無法解決大資料中的所有問題。mapreduce 提供了一種特定的程式設計模型，儘管已通過 pig 和 hive 等工具得到了簡化，但它不是大資料的靈丹妙藥。我們首先介紹一下 mapreduce 2.0 (mrv2) — 或 yet another resource negotiator (yarn) — 並快速回顧一下 yarn 之前的 hadoop 架構。
hadoop 集群可從單一節點（其中所有 hadoop 實體都在同乙個節點上執行）擴充套件到數千個節點（其中的功能分散在各個節點之間，以增加並行處理活動）。圖 1 演示了乙個 hadoop 集群的高階元件。
圖 1. hadoop 集群架構的簡單演示
乙個 hadoop 集群可分解為兩個抽象實體：mapreduce 引擎和分布式檔案系統。mapreduce 引擎能夠在整個集群上執行 map 和 reduce 任務並報告結果，其中分布式檔案系統提供了一種儲存模式，可跨節點複製資料以進行處理。hadoop 分布式檔案系統 (hdfs) 通過定義來支援大型檔案（其中每個檔案通常為 64 mb 的倍數）。
當乙個客戶端向乙個 hadoop 集**出乙個請求時，此請求由 jobtracker 管理。jobtracker 與 namenode 聯合將工作分發到離它所處理的資料盡可能近的位置。namenode 是檔案系統的主系統，提供元資料服務來執行資料分發和複製。jobtracker 將 map 和 reduce 任務安排到乙個或多個 tasktracker 上的可用插槽中。tasktracker 與 datanode（分布式檔案系統）一起對來自 datanode 的資料執行 map 和 reduce 任務。當 map 和 reduce 任務完成時，tasktracker 會告知 jobtracker，後者確定所有任務何時完成並最終告知客戶作業已完成。
從 圖 1 中可以看到，mrv1 實現了乙個相對簡單的集群管理器來執行 mapreduce 處理。mrv1 提供了一種分層的集群管理模式，其中大資料作業以單個 map 和 reduce 任務的形式滲入乙個集群，並最後聚合成作業來報告給使用者。但這種簡單性有一些隱秘，不過也不是很隱秘的問題。
mapreduce 的第乙個版本既有優點也有缺點。mrv1 是目前使用的標準的大資料處理系統。但是，這種架構存在不足，主要表現在大型集群上。當集群包含的節點超過 4,000 個時（其中每個節點可能是多核的），就會表現出一定的不可**性。其中乙個最大的問題是級聯故障，由於要嘗試複製資料和過載活動的節點，所以乙個故障會通過網路泛洪形式導致整個集群嚴重惡化。
但 mrv1 的最大問題是多租戶。隨著集群規模的增加，一種可取的方式是為這些集群採用各種不同的模型。mrv1 的節點專用於 hadoop，所以可以改變它們的用途以用於其他應用程式和工作負載。當大資料和 hadoop 成為雲部署中乙個更重要的使用模型時，這種能力也會增強，因為它允許在伺服器上對 hadoop 進行物理化，而無需虛擬化且不會增加管理、計算和輸入/輸出開銷。
我們現在看看 yarn 的新架構，看看它如何支援 mrv2 和其他使用不同處理模型的應用程式。
為了實現乙個 hadoop 集群的集群共享、可伸縮性和可靠性。設計人員採用了一種分層的集群框架方法。具體來講，特定於 mapreduce 的功能已替換為一組新的守護程式，將該框架向新的處理模型開放。
回想一下，由於限制了擴充套件以及網路開銷所導致的某些故障模式，mrv1 jobtracker 和 tasktracker 方法曾是乙個重要的缺陷。這些守護程式也是 mapreduce 處理模型所獨有的。為了消除這一限制，jobtracker 和 tasktracker 已從 yarn 中刪除，取而代之的是一組對應用程式不可知的新守護程式。
圖 2. yarn 的新架構
nodemanager 管理乙個 yarn 集群中的每個節點。nodemanager 提供針對集群中每個節點的服務，從監督對乙個容器的終生管理到監視資源和跟蹤節點健康。mrv1 通過插槽管理 map 和 reduce 任務的執行，而 nodemanager 管理抽象容器，這些容器代表著可供乙個特定應用程式使用的針對每個節點的資源。yarn 繼續使用 hdfs 層。它的主要 namenode 用於元資料服務，而 datanode 用於分散在乙個集群中的複製儲存服務。
您需要知道的事
隨著 yarn 的出現，您不再受到更簡單的 mapreduce 開發模式約束，而是可以建立更複雜的分布式應用程式。實際上，您可以將 mapreduce 模型視為 yarn 架構可執行的一些應用程式中的其中乙個，只是為自定義開發公開了基礎框架的更多功能。這種能力非常強大，因為 yarn 的使用模型幾乎沒有限制，不再需要與乙個集群上可能存在的其他更複雜的分布式應用程式框架相隔離，就像 mrv1 一樣。甚至可以說，隨著 yarn 變得更加健全，它有能力取代其他一些分布式處理框架，從而完全消除了專用於其他框架的資源開銷，同時還簡化了整個系統。
歸結而言，mrv1 框架下的問題僅是需要乙個關聯陣列，而且這些問題有專門朝大資料操作方向演變的傾向。但是，問題一定不會永遠僅侷限於此正規化中，因為您現在可以更為簡單地將它們抽象化，編寫自定義客戶端、應用程式主程式，以及符合任何您想要的設計的應用程式。
儘管 hadoop 繼續在大資料市場中發展，但它已開始了一場演變，以解決有待定義的大規模資料工作負載。yarn 仍然在積極發展且可能不適合生產環境，但 yarn 相對傳統的 mapreduce 而言提供了重要優勢。它允許開發 mapreduce 之外的新分布式應用程式，允許它們彼此同時共存於同乙個集群中。yarn 構建於當前 hadoop 集群的現有元素之上，但也改進了 jobtracker 等元素，可以提高可伸縮性和增強許多不同應用程式共享集群的能力。yarn 很快會來到您近旁的 hadoop 集群中，帶來它的全新功能和新複雜性。
學習
Hadoop YARN的發展史與詳細解析
編者按 成熟 通用讓hadoop深得大資料玩家喜愛，即使是在yarn出現之前，在流處理框架林立下，hadoop仍然被眾多機構廣泛運用在離線處理之上。借鑑於mesos，mapreduce獲得新生，yarn提供了更加優秀的資源管理器，讓storm等流處理框架同樣可以執行在hadoop集群之上 但是別忘記...
IT薪水發展史
1k 兄弟別做it了，不論你是什麼公司，國營的做it就是配角，那位兄弟願意一輩子做配角，非國營的嗎，看看做什麼別的合適，it不好混，趁早離開 1k 3k 初級階段，一般是剛進公司的，肯定非常缺錢，這時候動力足，也有時間，沒有男 女朋友拖累,象公司內部5k 6k的高手學習。什麼，沒有，什麼爛公司，你也...
記憶體發展史
記憶體 容量 指標 時期出現原因 simm記憶體 30pin 256kb 1982年至今 軟體程式和新一代80286硬體平台的出現 simm記憶體 72pin 512kb 2mb 1988 1990 pc迎來386和486時代，cpu向16bit發展 edo dram 4 16mb 電壓 5v 頻寬...