一個電話 改變大數據命運的故事
凌晨 3 點時， Arun C. Murthy 被一個電話弄醒了，公司要求他緊急處理一個軟件 bug。當時他是雅虎一個的廣告定位 App 的工程師，App 運行很緩慢，因為 App 啟用開源數字平臺 Hadoop 時的一串軟件代碼寫得很糟糕。誰也不會想到，這個小 bug，數年后卻促成了官方 Hadoop 2.0 的誕生，改變了 Hadoop 的命運。
雖然是別人寫的，但 Murthy 的工作就是修復它。誰也不會想到，這個小 bug，數年后卻為 Hadoop 生成了一個全新的路徑；一個幾乎和大數據概念幾乎等同的軟件系統。
今天，Hadoop 應用在 非死book、推ter、eBay、Yahoo 等很多公司中，但 2007 年時，打那個電話之前，它不是這么有能耐的。
Doug Cutting 加入雅虎
受 Google 2004 年白皮書的影響，打電話的一年之前，Doug Cutting 和 Michael Cafarella 創建了 Hadoop 平臺， 后來 Doug Cutting 加入雅虎，Murthy 則被叫去繼續研究雅虎的 Hadoop 問題， 因為他對該系統軟件比較有經驗。
當時他看了看邀請表示“誰 TMD 要去用 Java 寫系統軟件呢？”但后來還是接受了，但是當天晚上，他又繼續詛咒“我 TMD 沒事干嘛去調試別人的 Hadoop 代碼呢？”但之后他發現自己陷入了更深的詛咒，因為他發現處理過后的應用程序（廣告定位 App）并沒有真正意義上地運行 Hadoop。
Hadoop 實際上是由兩部分組成的軟件平臺，一個叫做 Hadoop 分布式文件系統的存儲系統（HDFS），一個叫 MapReduce 的處理系統。你可以轉儲大量的數據在這個系統里面，然后被分布在數十、數百、數千臺服務器中，再用 MapReduce 在集群里把大問題拆分成小問題。這就是 Hadoop 的魅力：可以用大量廉價的商品服務器來省錢，而非購買少數昂貴的超級計算機。
不過有個小問題是，有時候開發者希望把數據從其中一個集群抽離出來，不用運行整個 MapReduce，這也是當時雅虎廣告定位 App 的問題，當時這個給 Murthy 的第一感覺是 Hadoop 需要另一個系統。
Murthy 的第一感覺是 Hadoop 需要另一個系統
當時用臨時手段解決了那個 bug 后，他開始籌謀這怎么徹底解決那個大 bug。 從 2008 到 2010 年，Hadoop 團隊一直在關注如何提高 Hadoop 的安全性和穩定性，使其更具企業特征。許多相關的系統，比如被內置在主要分布集群中的 Pig 和 Hive 就是希望打造不用運行 MapReduce 而查詢 Hadoop 的軟件，但其實還是沒抽離出 MapReduce，其查詢只是被譯成從 MapReduce 的方式罷了。
2010 年中的時候，Hadoop 團隊認為 Hadoop 是時候改革了，Murthy 和所有 Hadoop 社區的開發者集結起來準備解決這個老問題，最后成果就是后來加入 Hadoop 2.0 的 YARN 附件。
YARN 誕生
YARN 是一個坐落在 HDFS 上的系統，支持開發者創建和 HDFS 互動的應用，無需啟動整個 MapReduce，Murthy 表示：“2.0 其實不是一個任意數，是 Hadoop 第二體系”。
YARN 確定使用后，許多新的軟件也開始被創建出來進一步補充 Hadoop。比如 推ter 使用 Spark 用來實時處理數據；雅虎使用 Spark 用來處理存儲的數據。Cloudera 創建了 Impala 提高了查詢 Hadoop 的速度。
但 Murthy 表示，只要開發者愿意，他們就可以使用 YARN 來查詢 Hadoop，使得整個大數據的系統變得更為有效。
IT 檢測公司 Nodeable 就在自己的 Storm 和 Hadoop 之間建立了一個整合系統，稱為 StreamReduce，其副總裁（Appcelerato 副總裁，Nodeable 被 Appcelerator 收購了）表示 YARN 就是將來他們要進行批處理或者實時處理時需要的東西。
Hadoop 2.0
Spark 主要在 HDFS 上運行，雖然它丟棄了 MapReduce，遠離了官方的 Hadoop，但 YARN 足夠讓它們相互聯系，如果只想要一個簡單的部署，可以不用 YARN，但是有的用戶喜歡它，愿意安裝它。
目前 YARN 已經存在在不少 Hadoop 分布中，包括 Cloudera 分布等。官方 Hadoop 2.0 開源項目 beta 版本馬上要推出了，完全滲入市場可能還需要一段時間，但是它普及的時候將會帶來很大的變化，無論如何，我們要感謝那個凌晨 3 點的電話。
Via wired