顛覆大數據分析之結論

杜老師說 2022-01-07 08:27:10 阅读数:238

分析

顛覆大數據分析之結論

譯者:吳京潤    購書

隨著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,譯文參考:http://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: http://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與大數據雲的整合可能是一個可預見的趨勢。

 

原創文章,轉載請注明: 轉載自並發編程網 – ifeve.com本文鏈接地址: 顛覆大數據分析之結論

FavoriteLoading添加本文到我的收藏
版权声明:本文为[杜老師說]所创,转载请带上原文链接,感谢。 https://gsmany.com/2022/01/202201070827100888.html