這篇文章將為大家詳細講解有關(guān)怎么分析spark rdd的另類解讀，文章內(nèi)容質(zhì)量較高，因此小編分享給大家做個參考，希望大家閱讀完這篇文章后對相關(guān)知識有一定的了解。

在成都網(wǎng)站設計、成都網(wǎng)站建設過程中，需要針對客戶的行業(yè)特點、產(chǎn)品特性、目標受眾和市場情況進行定位分析，以確定網(wǎng)站的風格、色彩、版式、交互等方面的設計方向。創(chuàng)新互聯(lián)還需要根據(jù)客戶的需求進行功能模塊的開發(fā)和設計，包括內(nèi)容管理、前臺展示、用戶權(quán)限管理、數(shù)據(jù)統(tǒng)計和安全保護等功能。

1 Spark的RDD

提到Spark必說RDD，RDD是Spark的核心，如果沒有對RDD的深入理解，是很難寫好spark程序的，但是網(wǎng)上對RDD的解釋一般都屬于人云亦云、鸚鵡學舌，基本都沒有加入自己的理解。下面基于Spark原創(chuàng)作者的論文，對Spark的核心概念RDD做一個初步的探討。

1.1 Resilient

中文解釋是“能復原的;彈回的，有彈性的;”，在我們的生活中，一個東西有彈性，就說明這個東西不易損壞，例如皮球、輪胎，而蘋果公司在給蘋果手機申請的一個專利，正是在手機的四個角加入了類似橡皮筋材質(zhì)的東西，來增加手機跌落時的抗摔性。Spark的核心數(shù)據(jù)結(jié)構(gòu)有彈性，能復原，說明spark在設計之初就考慮把spark應用在大規(guī)模的分布式集群中，因為這種大規(guī)模集群，任何一臺服務器是隨時都可能出故障的，如果正在進行計算的子任務(Task)所在的服務器出故障，那么這個子任務自然在這臺服務器無法繼續(xù)執(zhí)行，這時RDD所具有的“彈性”就派上了用場，它可以使這個失敗的子任務在集群內(nèi)進行遷移，從而保證整體任務(Job)對故障機器的平滑過渡?？赡苡行┩瑢W有疑問了，難道還有系統(tǒng)不具有彈性，是硬邦邦的？還真有，比如很多的即系查詢系統(tǒng)，例如presto或者impala，因為在其上運行的查詢，都是秒級的時延，所以如果子任務失敗，直接把查詢重跑一遍即可。而spark處理的任務，可能時常要運行分鐘級甚至小時級別，那么整個任務完全重跑的代價非常大，而某些task重跑的代價就比較小了，所以spark的數(shù)據(jù)結(jié)構(gòu)一定要有“彈性”，能自動容錯，保證任務只跑一遍。

1.2 Distributed

這個英文單詞的中文意思不用多解釋了，就是指的“分布式”。那么到底spark的數(shù)據(jù)結(jié)構(gòu)怎么個分布式法呢？這就涉及到了spark中分區(qū)(partition)的概念，也就是數(shù)據(jù)的切分規(guī)則，根據(jù)一些特定的規(guī)則切分后的數(shù)據(jù)子集，就可以在獨立的task中進行處理，而這些task又是分散在集群多個服務器上并行的同時的執(zhí)行，這就是spark中Distributed的含義。spark源碼中RDD是個表示數(shù)據(jù)的基類，在這個基類之上衍生了很多的子RDD，不同的子RDD具有不同的功能，但是他們都要具備的能力就是能夠被切分(partition)，比如從HDFS讀取數(shù)據(jù)，那么會有hadoopRDD，這個hadoopRDD的切分規(guī)則就是如果一個HDFS文件可按照block(64M或者128M)進行切分，例如txt格式，那么一個Block一個partition，spark會為這個Block生成一個task去處理這個Block的數(shù)據(jù)，而如果HDFS上的文件不可切分，比如壓縮的zip或者gzip格式，那么一個文件對應一個partition；如果數(shù)據(jù)在入庫時是隨機的，但是在處理時又需要根據(jù)數(shù)據(jù)的key進行分組(group)，那么就需要根據(jù)這個數(shù)據(jù)源的key對數(shù)據(jù)在集群中進行分發(fā)(shuffle)，把相同key的數(shù)據(jù)“歸類”到一起，如果把所有key放到同一個partition里，那么就只能有一個task來進行歸類處理，性能會很差，所以這個過程的并行化，就是靠把key進行切分，不同的key在不同的partition中被處理，來實現(xiàn)的歸類(group)過程并行化。

1.3 Datasets

看到這個詞，很多人會錯誤的以為RDD是spark的數(shù)據(jù)存儲結(jié)構(gòu)，其實并非如此，RDD中的Datasets并非真正的“集合”，更不是java中的collection，而是表示spark中數(shù)據(jù)處理的邏輯。怎么理解呢？這需要結(jié)合兩個概念來理解，第一是spark中RDD 的transform操作，另一個是spark中得pipeline。首先看RDD的transform，來看論文中的一個transform圖：  

轉(zhuǎn)換

圖中每個長方形都是一個RDD，但是他們表示的數(shù)據(jù)結(jié)構(gòu)不同，注意，這里用的是”表示“，而不是”存儲“，例如lines這個RDD，就是最原始的文本行，而errors這個RDD，則只表示以”ERROR“開頭的文本行，而HDFSerrors這個RDD則表示包含了”HDFS“關(guān)鍵字的文本行。這就是一個RDD的”變形“過程。好了，我們回到上邊糾結(jié)的”表示“和”存儲“兩個字眼上，看看用不同的字眼表達會有什么不同的結(jié)果。如果我們用”存儲“，那么上一個RDD經(jīng)過transform后，需要存儲下來，等到全部處理完之后交給下一個處理邏輯(類似我們很久以前用迅雷下載電影，要先下載才能觀看，兩個過程是串行的)。那么問題來了，在一批數(shù)據(jù)達到之前，下一個處理邏輯必須要等待，這其實是沒有必要的。所以在上一個處理邏輯處理完一條數(shù)據(jù)后，如果立馬交給下一個處理邏輯，這樣就沒有等待的過程，整體系統(tǒng)性能會有極大的提升，而這正是用”表示“這個詞來表達的效果(類似后來的流媒體，不需要先下載電影，可以邊下載邊觀看)，這也就是是spark中的pipeline(流水線）處理方式。

2 spark的lineage

RDD的三個單詞分析完了，球友們可能也有一個疑問，那就是對于pipeline的處理方式，感覺各個處理邏輯的數(shù)據(jù)都是”懸在空中“，沒有落磁盤那么踏實。確實，如果是這種方式的話，spark怎么來保證這種”懸在空中“的流式數(shù)據(jù)在服務器故障后，能做到”可恢復“呢？這就引出了spark中另外一個重要的概念：lineage(血統(tǒng))。一個RDD的血統(tǒng)，就是如上圖那樣的一系列處理邏輯，spark會為每個RDD記錄其血統(tǒng)，借用范偉的經(jīng)典小品的橋段，spark知道每個RDD的子集是”怎么沒的“（變形變沒的）以及這個子集是 ”怎么來的“（變形變來的），那么當數(shù)據(jù)子集丟失后，spark就會根據(jù)lineage，復原出這個丟失的數(shù)據(jù)子集，從而保證Datasets的彈性。

3 注意

1) 當然如果RDD被cache和做了checkpoint就，可以理解為spark把一個RDD的數(shù)據(jù)“存儲了下來”，屬于后續(xù)優(yōu)化要講解的內(nèi)容。

2) RDD在transform時，并非每處理一條就交給下一個RDD，而是使用小批量的方式傳遞，也屬于優(yōu)化的內(nèi)容。

關(guān)于怎么分析spark rdd的另類解讀就分享到這里了，希望以上內(nèi)容可以對大家有一定的幫助，可以學到更多知識。如果覺得文章不錯，可以把它分享出去讓更多的人看到。

當前名稱：怎么分析sparkrdd的另類解讀
文章起源：http://chinadenli.net/article36/jggesg.html

成都網(wǎng)站建設公司_創(chuàng)新互聯(lián)，為您提供網(wǎng)站導航、用戶體驗、面包屑導航、App開發(fā)、網(wǎng)站內(nèi)鏈、ChatGPT

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)