天天看點

大資料架構思考(三)

越十年生聚,而十年教訓,二十年之外,吳其為沼乎。——《左傳·哀公元年》

越人為了報仇,準備了二十年,其中10年用來生育,十年用來教育訓練,——懷胎十月,成長十年,教育十年方能成為一個合格的戰士。

大資料架構思考(三)

OK,突然有一天,一個叫做大資料神突然來造訪越王勾踐來了……神告訴我們,大資料可以并行計算……也就是把很多機器合并起來,提高性能和速度。

那麼:

大資料架構思考(三)

以上場景,是不是特别像現在很多大資料的需求場景?

你們不是說并行計算,可以加快麼?我的資料量就這麼多,1台機器十分鐘,那給你10台機器,你一分鐘給我算出來……

嗯……北京到上海,一趟高鐵需要5個小時,現在我給你5趟高鐵,麻煩你在1小時之内把我從北京送到上海,謝謝啊,親愛的達瓦裡希.大(товарищ,毛子語“同”志的意思)。

雖然說,理論上并行計算的原理如下:

大資料架構思考(三)

但是實際上,有如下幾個關鍵點需要明确:

第一:切分任務和結果合并的開銷。

這個兩個步驟是屬于串行的,是以無論如何是硬性的時間開銷。

因為叢集之間的通信,都是利用網絡進行的,那麼我們可以自己在腦子裡面腦補一下把一份資料從存儲節點發送到運算節點需要的時間:

大資料架構思考(三)

而對于大資料(量)來說,動辄TB,設定PB,那小小的網絡小水管,需要多少時間才能給把需要計算的資料和計算的模型比對起來?

但是hadoop/spark這樣的架構,給了一個比較好的解決方法,把計算模型,發送到資料節點上去,這樣可以有效的減少叢集之間的網絡開銷,但是減少不代表沒有,隻要有傳輸,就要有時間開銷。

第二,在Hadoop和Spark架構中,任務切分的粒度也是有規則的。

原始情況下,hadoop的預設任務分片大小是64M,後來擴大為128M。表示你要分析的任務,将被切分為最小128M一個的任務塊,分析這一個任務塊的時間,就是最小的時間片段。

不說,給你1000台機器,就能把資料配置設定到這1000台機器上運算的。

是以,并行計算或者說大資料并行計算,解決的是龐大資料計算效率的問題,而非簡單的速度問題。

回到前面給出的高鐵假設:

一趟高鐵,5小時能從北京跑到上海,那麼給五趟高鐵,肯定也沒辦法在一小時之内做到。但是如果是1趟高鐵隻能運載500人,那麼5趟高鐵可以在同樣的時間内,把2500人,從北京運送到上海去。

傳統企業,最大的痛點是龐大的資料,無法快速分析,但是傳統企業的特點也是這龐大的資料幾乎是靜态的,今天是100GB,明天還是100GB,起碼在一個時間段内,不會以幾何級數的增長。

是以傳統企業的腦海裡面,就出現了1台機器2小時分析完成,給你1000台機器,那麼7秒你就給算完這種思想——資料量不變的情況下,增加機器,就能加快速度,這就是傳統企業裡面很多使用者對“性能”這個詞的了解。

實際上這種了解,差不多就等于給5趟高鐵,就能1小時把人從北京送到上海是一樣。

大資料思想下的“性能”,實際上給出的第二種思想:1台機器處理100G資料,要2小時,那麼你的資料正在到1000GB的時候,給我10台機器,也能在2小時處理完成。就等于5趟高鐵,可以在同樣的時間内完成2500人的運輸任務。

回歸最原始的阿裡巴巴對hadoop架構的應用場景:

大資料架構思考(三)

如果hadoop/spark真的為了(傳統意義上的)速度存在的,那麼為什麼阿裡最後還是要将資料寫入到mysql裡面呢?因為hadoop/spark他們的存在,并不是用來和傳統資料庫比實時響應效率的。

那這樣說來,大資料的并行計算還有價值麼?能不能夠提升我的計算效率呢?

答案是肯定的。

回到前面那個假設,1小時之内,利用高鐵,把貨物送到上海。怎麼做?答案是利用中轉倉儲。在北京到上海之間設立5個中轉站,然後把貨物存放在中轉站裡面,每個高鐵隻需要在這1小時區間内運作,那麼隻要建立好了中轉站(預先開銷),那麼之後就可以在一小時内收到貨物了。也就是流水線作業。

這裡帶來的問題就變成了哪些貨物放到哪些中轉站裡面?如果這個中轉站裡面沒有我需要,而在其他中轉站裡面怎麼辦?這就是spark提出的一個排程算法,決定你哪些資料需要重複使用(中轉站記憶體儲的貨物的選擇),然後利用排程算法,來減少這種“我需要,但是最近的一個中轉站木有”的問題。

那麼回歸到資料分析中,如何來利用這種思想呢?

答案就是中間資料。

将原始資料按照需要,組織成中間資料,然後前端的分析,實際上調用的是這些中間的資料。

比如要在1秒之内,計算整個京九沿線九個省一共有多少耕地?

大資料架構思考(三)

如果從原始資料裡面去計算,起碼超過100個小時(國土的資料是分庫存儲的,一個縣一個庫,103個縣,就要跨越103庫去進行查詢。

但是利用大資料的模式麼?

先把所有的地塊,聚合計算到10平方公裡的網格裡面,那麼這個中間資料,全國也就90多萬個網格。每個網格裡面記錄了每種地塊類型的count、sum等統計聚合值。

現在隻需要利用京九線對90多萬個網格做個相交計算即可。

那麼得到的資料,可能不是完全正确的,因為每個網格裡面僅有統計值。那麼最後的的出來的資料,到底是1億3千623萬1456.4447畝,還得出1億3千600多萬畝,在這種資料量的統計下,有多少大的差别?

根據目前最新的試驗,使用1平方公裡網格,對千萬級地塊覆寫面積超過10萬平方公裡的區域的資料進行聚合,原始資料和網格資料查詢出來的結果,誤差率僅為百分之0.7,也就是說精确度高達99.3%。

繼續閱讀