817
顛覆大數據分析之結論
隨著Hadoop2.0到來——被稱作YARN的Hadoop新版本——超越Map-Reduce的思想已經穩固下來。就像本章要解釋的，Hadoop YARN將資源調度從
MR範式分離出來。需要注意的是在Hadoop1.0，Hadoop第一代，調度功能是與Map-Reduce範式綁定在一起的——這意味著在HDFS上惟一的處理方式就是Map-Reduce或它的業務流程。這一點已在YARN得到解決，它使得HDFS數據可以使用非Map-Reduce範式處理。其含義是，從事實上確認了Map-Reduce不是惟一的大數據分析範式，這也是本書的中心思想。 Hadoop YARN允許企業將數據存儲在HDFS，並使用專業框架以多種方式處理數據。比如，Spark可以借助HDFS上的數據迭代運行機器學習算法。（Spark已重構為工作在YARN之上，感謝Yahoo的創新精神），還有GraphLab/Giraph可以借助這些數據用來運行基於圖的算法。顯而易見的事實是，主要的Hadoop發行版已宣布支持Spark（Cloudera的），Storm（Hortonworks的），還有Giraph（Hortonworkds的）。所有的一切，本書一直主張的超越Hadoop Map-Reduce的思想已通過Hadoop YARN得到了驗證。本章概述了Hadoop YARN以及不同的框架（Spark/GraphLab/Storm）如何工作在它上麵工作。
Hadoop YARN概覽
Hadoop YARN的基本架構是從Map-Reduce框架中分離了資源調度，而這二者在Hadoop1.0中是捆綁在一起的。我們首先概述一下Hadoop YARN的動機，然後再討論一些YARN的有趣方麵。
Hadoop YARN的有趣方麵
Hadoop的普及導致它被應用於各種情況，即使最初它並不是為之設計的。一個例子就是開發者隻使用映射作業隨意產生工作進程，而沒有化簡階段，MapReduce範式沒有被恰當的使用。這些隨意的進程可以是web服務或迭代工作負載的成組調度計算，與消息傳遞接口（MPI）的成組調度作業類似（Bouteiller等2004）。這種情況引發了一係列討論Hadoop MapReduce局限性的論文。比如，MapScale或SciCloud談到Hadoop不適合做迭代計算。Hadoop1.0的限製主要在於以下方麵：
- 擴展性：沒有簡單的內建方法，為兩個不同的Hadoop集群交互/共享資源或作業。這個問題為一些部署帶來了困難，例如在Yahoo，運行著幾千個節點的Hadoop。大型Hadoop集群有其局限性，比如調度方案在擴展性上的局限和單點故障問題。
- 地方性意識：就近計算很重要，換句話說最好在擁有數據副本的節點上啟動映射/化簡。比方說，Yahoo為多租戶集群使用的平台，在JobTracker調用時，隻會返回相關數據的一個小子集。大多數讀取是遠程的，造成了性能損失。
- 集群效用：通過Pig/Hive構建的工作流可能會在集群中執行時導致無環有向圖（DAG）。缺乏動態調整集群規模的能力（當DAG出現時調整），也導致利用率不佳。
- Map-Reduce編程模型的局限性：這是Hadoop跨企業應用的主要障礙。Map-Reduce模型不適合做迭代式機器學習運算，而這類計算可能要求解決前文所述的三座大山(廣義N體問題)和五項優化。即使大型圖處理問題與MapReduce也不是天作之合。不同類型的處理過程對數據的要求是顯而易見的；這就是Hadoop YARN的主要推動因素。
作為資源調度器的YARN
YARN對範式的根本轉變是將資源管理從麵向具體應用的處理與執行中分離出來。這兩個功能的重要組件是資源管理（RM）和應用主機（Application Masteer(AM)）。RM是將集群資源視作統一的視圖，並與之一起的整體調度；它還負責全局調度。AM根據相關作業執行情況為RM負責具體作業資源征用。 AM向RM發送資源請求。RM用一個租約授權應答，並為AM申請一個容器（綁定到一個特定結點上的邏輯資源分組）。資源請求（ResourceRequest類）包含容器數量、每個容器的大小（4GB內存和兩核CPU）、位置參數，以及應用中的請求優先級。AM創建執行計劃，基於它從RM收到的容器集更新。AM通過節點管理器（NM）（駐留在集群的每個節點上）發送給RM的消息獲取節點中的容器狀態，RM又把消息傳播給各個AM。基於這些狀態，AM能夠重啟失敗任務。AM注冊到RM並定期向RM發送心跳。它在這些消息裏帶著它的資源請求。 RM負責客戶端應用的提交，擁有集群的完整視圖，為AM分配資源，通過NM監控集群。它通過NM的心跳獲取有效資源。借助這個集群的全局視圖，RM滿足公平性和活躍度等調度屬性，負責為更好的集群效用提供支持。RM向AM容器以及訪問這些容器的令牌。RM也可以從AM請求資源（在集群過載的情況下）——AM可以為這些請求生產一些容器。 NM注冊到RM，並持續發送心跳消息。它通過心跳消息向RMK發送節點上的有效資源，比如CPU、內存，諸如此類。NM還負責容器租約、監控、管理容器執行。容器由容器啟動上下文描述（CLC）——上下文包括執行啟動的命令、安全令牌、依賴（可執行文件、壓縮包）、環境變量，等等。NM可能會殺死容器，比如在容器租約結束時，即使調度器決定取消它也會如此。NM還監控節點健康狀況，並在發現節點有任何硬件或軟件問題時修改它的狀態為不健康。
YARN上的其它的框架
整體YARN架構如圖6.1。這張圖清晰的驗證了本書要闡釋的超越Hadoop MapReduce思想。存儲在HDFS的數據可以用多種方式，通過不同的框架處理，而不隻是Hadoop MapReduce（還有Pig和Hive）。舉個盒子，Hortonworks已宣布支持基於Storm的流式處理——這意味著當數據以流的方式到達時，它可以通過Storm處理並儲存在HDFS以備曆史分析。類似的，Tez這樣的開源平台可以用來做HDFS數據的交互式查詢處理。
圖6.1 Hadoop YARN架構：不同框架處理HDFS數據
Tez是新的Hadoop YARN生態係統平台之一——它擁有執行無環有向圖的能力，這樣的圖可以是一個數據流圖，以頂點表示數據的處理，以邊表示數據的流向。查詢計劃由Hive和Pig生成，比如，可以無環有向圖的形式瀏覽。無環有向圖通過Tez應用編程接口構建。（Tez API允許用戶指定無環有向圖、頂點計算，以及邊。它還支持無環有向圖的動態識別。） 另一種處理可能是迭代式機器學習——Spark是一個理想選擇，如同本書所展示的。它適合應用於YARN，因為Spark已有運行於Hadoop YARN之上的發布版。整個Spark生態係統——包含Spark流和Shark——都可以處理儲存在HDFS的數據。 圖處理框架也能夠處理HDFS的數據——Giraph（由Hortonworks支持）和GraphLab是不錯的選擇。（GraphLab團隊正在開發對Hadoop YARN的支持。）來自Spark生態係統的GraphX是這一領域的另一種選擇。
大數據分析的未來是怎樣的？
本節探討未來的大數據分析的技術前景。
要探討的一件有趣的事情是在Apache Tez之上實現機器學習算法。這裏要解決的問題在於是否存在幫助實現迭代式機器學習的無環有向圖執行器。主要的挑戰是停止/結束條件不可是靜態的，而隻能在運行時。這一點已在最近由Eurosys提出的Optimus係統（Ke等2013）探討過，該係統提供了一個在DryadLINQ上實現機器學習算法的途徑。
另一件需要引起注意的有趣工作是來自斯坦福大學的Forge係統（Sujeeth等2013）。Forge提供了一個領域特定元語言（DSL），該語言允許用戶為不同領域指定DSL。DSL概念的引入作為分布式係統的替代手段——後者從程序員以及高效實現的領悟中抽象出來的。Forge也有為機器學習提供的特定DSL，稱做OptiML。Forge即有單純的Scala實現（用於原型機）也有高效並行的分布式實現，後者可以部署在集群環境（用於生產環境）。Forge使用Delite框架（Brown等2011）實現了後者的一部分。性能測試顯示了由Forge在集群節點上自動生成的分布式實現相當於用Spark實現的等價功能的40倍性能。它也表達了Spark仍然有優化的可能性——這一點值得做更進一步的探討。
大數據方麵的深度學習仍然是神聖領域的聖杯。近期來自穀歌的論文顯示已取得一定進展（Dean等2012）。這篇論文展示了兩種訓練算法，多點同時隨機梯度下降算法（譯者注：原文為Downpour Stochastic Gradient Descent，譯文參考：https://blog.sina.com.cn/s/blog_81f72ca70101kuk9.html）和集群多節點L-BGFS（譯者注：原文為SandblasterL-BGFS，譯文參考前麵的鏈接），用於訓練深度神經網絡。核心思想是共享參數服務器用於多模型副本並行訓練。盡管參數服務器在訓練時是共享的，分片本身也會成為單點故障。一個可能的改進是在它們之間覆蓋網絡，作為通訊的對等集合查看參數服務器，就像OpenDHT或Pastry。這樣參數服務器就實現了容錯，甚至提升了性能。
使用七大任務（譯者注：此處應為前麵章節提到的以下七類任務：基礎分析、線性代數運算、廣義的多體問題、圖形計算、優化、積分、比對問題）的目的是需要描述為機器學習這類計算並識別在大數據世界裏當前實現的差距。就任務6、7的實現而言，它們之間在集成方麵就有差距（在處理數據方麵的整合工作上），可能要求馬爾科夫鏈的蒙特卡羅（MCMC）實現，正如在第一章解釋過的，“介紹：為什麼要超越Hadoop Map-Reduce？”。MCMC在Hadoop上是出名的難以實現。Spark可能是最理想的。類似的，任務7（比對問題）可能要求隱馬爾科夫（HMMs）實現。這一點就是另一個領域的討論了——實現了隱馬爾科夫模型的大數據。應用包括圖像的重複數據刪除（比如，在Aadhaar工程中——印度的身份項目，要求如何從存儲的數以億計的圖像中找出重複的照片）。
D-wave量子計算機已被安裝在量子人工智能（AI）實驗室（由NASA、穀歌，以及大學空間研究協會聯合運行）。這一舉措的根本目的是用量子方法探討難以解決的問題（任務5）。穀歌還聘請了一些人工智能研究人員，比如Ray Kurzweil。這一係列的舉措的聖杯是量子機器學習，可能會有人使用這一術語。而它已被麻省理工學院的Seth Lyod在量子計算國際會計中提出（ICQT 2013: https://icqt.org/conference/）。他的工作是使用量子比特檢索（譯者注：Qbit，量子比特）。在大數據集環境下它可以快速給出結果，同時又拋出了另外的有趣問題：隱私。量子比特不能在傳輸過程中窺探——窺探會影響量子比特狀態。當然這是一個值得深入探索的領域。
分析領域的另一項有趣進展是基於磁盤的單點分析——與雲/分布式的趨勢背道而馳。由GraphLab的創建者發表的GraphChi的論文（Kyrola等2012）提出了例證。GraphChi提供了一種處理磁盤上的大型圖的機製。對於Twitter-2010圖型的三角形計數，他們表現也單點低於90分鍾的性能，而相同功能的hadoop實現卻要在一個分布式環境下的1400個工作進程花費400分鍾。GraphChi采用一係列外存算法和並行滑動窗口的方式異步處理磁盤上的大型圖。2014年10月，在紐約的一次Strata會議中，Sisense，一家小的初創公司，展示了它單節點10秒鍾內處理10TB的能力，而全部花費不到10,000美元（www.marketwired.com/press-release/-1761584.htm ）。探索GraphChi在分布式環境的應用大概會很有趣——它可能會提供快速處理巨型圖的能力。
另一件有趣的趨勢是大數據、移動設備和雲端在物聯網（IoT）的支持下的整合。對於大數據架構/研究，這裏蘊藏著巨大的機遇，因為通過物聯網有更多來自用戶的有效數據，同時還提供了數據分析的溫床。通過雲端的大量大數據平台，雲端已與大數據做了很大程度上的整合。IoT與大數據雲的整合可能是一個可預見的趨勢。
最後更新：2017-05-22 17:01:22