您好,登錄后才能下訂單哦!
分布式計(jì)算簡(jiǎn)單來說,是把一個(gè)大計(jì)算任務(wù)拆分成多個(gè)小計(jì)算任務(wù)分布到若干臺(tái)機(jī)器上去計(jì)算,然后再進(jìn)行結(jié)果匯總。 目的在于分析計(jì)算海量的數(shù)據(jù),從雷達(dá)監(jiān)測(cè)的海量歷史信號(hào)中分析異常信號(hào)(外星文明),淘寶雙十一實(shí)時(shí)計(jì)算各地區(qū)的消費(fèi)習(xí)慣等。
海量計(jì)算最開始的方案是提高單機(jī)計(jì)算性能,如大型機(jī),后來由于數(shù)據(jù)的爆發(fā)式增長、單機(jī)性能卻跟不上,才有分布式計(jì)算這種妥協(xié)方案。 因?yàn)橛?jì)算一旦拆分,問題會(huì)變得非常復(fù)雜,像一致性、數(shù)據(jù)完整、通信、容災(zāi)、任務(wù)調(diào)度等問題也都來了。
舉個(gè)例子,產(chǎn)品要求從數(shù)據(jù)庫中100G的用戶購買數(shù)據(jù),分析出各地域的消費(fèi)習(xí)慣金額等。 如果沒什么時(shí)間要求,程序員小明就寫個(gè)對(duì)應(yīng)的業(yè)務(wù)處理服務(wù)程序,部署到服務(wù)器上,讓它慢慢跑就是了,小明預(yù)計(jì)10個(gè)小時(shí)能處理完。 后面產(chǎn)品嫌太慢,讓小明想辦法加快到3個(gè)小時(shí)。
平常開發(fā)中類似的需求也很多,總結(jié)出來就是,數(shù)據(jù)量大、單機(jī)計(jì)算慢。 如果上Hadoop、storm之類成本較高、而且有點(diǎn)大才小用。 當(dāng)然讓老板買更好的服務(wù)器配置也是一種辦法。
小明作為一個(gè)有追求有理想的程序員,決定用介于單機(jī)計(jì)算和成熟計(jì)算框架的過度解決方案,這樣成本和需求都能滿足了。 分布式計(jì)算的核心在于計(jì)算任務(wù)拆分,如果數(shù)據(jù)能以水平拆分的方式,分布到5臺(tái)機(jī)器上,每臺(tái)機(jī)器只計(jì)算自身的1/5數(shù)據(jù),這樣即能在3小時(shí)內(nèi)完成產(chǎn)品需求了。
如上所述,小明需要把這些數(shù)據(jù)按照一定維度進(jìn)行劃分。 按需求來看以用戶ID劃分最好,由于用戶之間沒有狀態(tài)上的關(guān)聯(lián),所以也不需要事務(wù)性及二次迭代計(jì)算。 小明用簡(jiǎn)單的hash取模對(duì)id進(jìn)行劃分。
<pre style="margin:0px;
padding:0px;
white-space:pre-wrap;
overflow-wrap:break-word;
font-family:"
Courier New"
!important;
font-size:12px !important;
">f(memberid) % 5 = ServerN</pre>
這樣程序可以分別部署到5臺(tái)機(jī)器上,然后程序按照配置只取對(duì)應(yīng)余數(shù)的用戶id,計(jì)算出結(jié)果并入庫。 這種方式多機(jī)之間毫無關(guān)聯(lián),不需要進(jìn)行通信,可以避免很多問題。 機(jī)器上的程序本身也不具備分布式的特性,它和單機(jī)一樣,只計(jì)算自身獲取到的數(shù)據(jù)即可,所以如果某臺(tái)機(jī)器上程序崩潰的話,處理方式和單機(jī)一樣,比如記錄下處理進(jìn)度,下次從當(dāng)前進(jìn)度繼續(xù)進(jìn)行后續(xù)計(jì)算。
使用分片方式相對(duì)比較簡(jiǎn)單,但有如下不足之處。
小明這種方式引入了個(gè)第三方,消息隊(duì)列。 小明先用一個(gè)單獨(dú)的程序把用戶信息推送到消息隊(duì)列里去,然后各臺(tái)機(jī)器分別取消費(fèi)這個(gè)隊(duì)列。 于是就有了3個(gè)角色:
雖然僅僅引入了個(gè)第三方,但它已經(jīng)具備了分布式計(jì)算的很多特性。
Hadoop介紹已經(jīng)相當(dāng)多了,這里簡(jiǎn)述下比如:"Hadoop是一套海量數(shù)據(jù)計(jì)算存儲(chǔ)的基礎(chǔ)平臺(tái)架構(gòu)",分析下這句話。
下面找了介紹Hadoop的概覽圖,跟小明的設(shè)計(jì)做對(duì)比下:
PS:為了方便描述,把小明設(shè)計(jì)的分布式計(jì)算,叫做小和尚。
由于MapReduce計(jì)算輸入和輸出都是基于HDFS文件,所以大多數(shù)公司的做法是把mysql或sqlserver的數(shù)據(jù)導(dǎo)入到HDFS,計(jì)算完后再導(dǎo)出到常規(guī)的數(shù)據(jù)庫中,這是MapReduce不夠靈活的地方之一。 MapReduce優(yōu)勢(shì)在于提供了比較簡(jiǎn)單的分布式計(jì)算編程模型,使開發(fā)此類程序變得非常簡(jiǎn)單,像之前的MPI編程就相當(dāng)復(fù)雜。
狹隘的來講,MapReduce是把計(jì)算任務(wù)給規(guī)范化了,它可以等同于小和尚中Worker的業(yè)務(wù)邏輯部分。 MapReduce把業(yè)務(wù)邏輯給拆分成2個(gè)大部分,Map和Reduce,可以先在Map部分把任務(wù)計(jì)算一半后,扔給Reduce部分繼續(xù)后面的計(jì)算。 當(dāng)然在Map部分把計(jì)算任務(wù)全做完也是可以的。
如果把小明產(chǎn)品經(jīng)理的需求放到Hadoop來做,其處理流程大致如下:
這樣一看好像是把簡(jiǎn)單的計(jì)算任務(wù)給復(fù)雜化了,其實(shí)如果只有幾臺(tái)計(jì)算任務(wù)的話,使用Mapreduce確實(shí)是殺雞用牛刀了。 如果有TB、PB級(jí)別的數(shù)據(jù)、跑在成百上千臺(tái)計(jì)算節(jié)點(diǎn)上,Mapreduce的優(yōu)勢(shì)才會(huì)體現(xiàn)出來。 其計(jì)算框架圖架構(gòu)如下:?
通常稱Mapreduce及小和尚這種計(jì)算為離線計(jì)算,因?yàn)樗鼘?duì)已經(jīng)持久化的文件數(shù)據(jù)進(jìn)行計(jì)算,不能實(shí)時(shí)響應(yīng)。 還有個(gè)原因就是它的處理速度比較慢,它的輸入和輸出源都是基于HDFS設(shè)計(jì),如果數(shù)據(jù)不是一開始就寫入到HDFS上,就會(huì)涉及到數(shù)據(jù)導(dǎo)入導(dǎo)出,這部分相對(duì)耗費(fèi)時(shí)間。 而且它的數(shù)據(jù)流動(dòng)是基于文件系統(tǒng)的,Map部分輸出的數(shù)據(jù)不是直接傳送到Reduce部分,而是先寫入HDFS再進(jìn)行傳送。
處理速度慢也是Mapreduce的不足之處,促使了后面實(shí)時(shí)計(jì)算的誕生。
另外個(gè)缺點(diǎn)是Mapreduce的計(jì)算任務(wù)流比較單一,它只有Map、Reduce兩部分。 簡(jiǎn)單的可以只寫一部分邏輯來解決,如果想拆分成多個(gè)部分,如邏輯A、邏輯B、邏輯C等, 而且一部分計(jì)算邏輯依賴上一次計(jì)算結(jié)果的話,MapReduce處理起來就比較困難了。 像storm框架解決此類問題的方案,也稱為流式計(jì)算,下一章繼續(xù)補(bǔ)充。?
針對(duì)于上面所涉及到的知識(shí)點(diǎn)我總結(jié)出了有1到5年開發(fā)經(jīng)驗(yàn)的程序員在面試中涉及到的絕大部分架構(gòu)面試題及答案做成了文檔和架構(gòu)視頻資料免費(fèi)分享給大家(包括Dubbo、Redis、Netty、zookeeper、Spring cloud、分布式、高并發(fā)等架構(gòu)技術(shù)資料),希望能幫助到您面試前的復(fù)習(xí)且找到一個(gè)好的工作,也節(jié)省大家在網(wǎng)上搜索資料的時(shí)間來學(xué)習(xí),也可以關(guān)注我一下以后會(huì)有更多干貨分享。
免責(zé)聲明:本站發(fā)布的內(nèi)容(圖片、視頻和文字)以原創(chuàng)、轉(zhuǎn)載和分享為主,文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng),如果涉及侵權(quán)請(qǐng)聯(lián)系站長郵箱:is@yisu.com進(jìn)行舉報(bào),并提供相關(guān)證據(jù),一經(jīng)查實(shí),將立刻刪除涉嫌侵權(quán)內(nèi)容。