這樣“撩”大數(shù)據(jù)，小白都能看懂！

作者：許賽賽 2019-12-27 09:47:05

話說(shuō)當(dāng)下技術(shù)圈的朋友，一起聚個(gè)會(huì)聊個(gè)天，如果不會(huì)點(diǎn)大數(shù)據(jù)的知識(shí)，感覺(jué)都融入不了圈子。

圖片來(lái)自 Pexels

為了以后聚會(huì)時(shí)讓你有聊有料，接下來(lái)就跟隨我的講述，一起與大數(shù)據(jù)混個(gè)臉熟吧，不過(guò)在“撩”大數(shù)據(jù)之前，還是先揭秘一下研發(fā)這些年我們都經(jīng)歷了啥?

緣起：應(yīng)用系統(tǒng)架構(gòu)的從 0 到 1

揭秘：研發(fā)這些年我們都經(jīng)歷了啥?

①大道至簡(jiǎn)。生活在技術(shù)圈里，大家靜下來(lái)想想，無(wú)論一個(gè)應(yīng)用系統(tǒng)多龐大、多復(fù)雜，無(wú)非也就是由一個(gè)漂亮的網(wǎng)站門面+一個(gè)丑陋的管理模塊+一個(gè)悶頭干活的定時(shí)任務(wù)三大板塊組成。

我們負(fù)責(zé)的應(yīng)用系統(tǒng)當(dāng)然也不例外，起初設(shè)計(jì)的時(shí)候三大模塊綁在一起(All in One)，線上跑一個(gè) Tomcat 輕松就搞定，可謂是像極了一個(gè)大泥球。

②衍化至繁。由于網(wǎng)站模塊、管理平臺(tái)、定時(shí)任務(wù)三大模塊綁定在一起，開(kāi)發(fā)協(xié)作會(huì)比較麻煩，時(shí)不時(shí)會(huì)有代碼合并沖突出現(xiàn)。

線上應(yīng)用升級(jí)時(shí)，也會(huì)導(dǎo)致其他模塊暫時(shí)不能使用，例如如果修改了一個(gè)定時(shí)任務(wù)的配置，可能會(huì)導(dǎo)致網(wǎng)站、管理平臺(tái)的服務(wù)暫時(shí)不能用。

面對(duì)諸多的不便，就不得不對(duì) All in One 的大泥球系統(tǒng)進(jìn)行拆解。

隨著產(chǎn)品需求的快速迭代，網(wǎng)站 Web 功能逐漸增多，我們起初設(shè)計(jì)時(shí)雄心勃勃(All in One 的單體架構(gòu))，以為直接按模塊設(shè)計(jì)疊加實(shí)現(xiàn)就好了，誰(shuí)成想系統(tǒng)越發(fā)顯得臃腫(想想也是走彎路啦!)。

所以不得不改變實(shí)現(xiàn)思路，讓模塊服務(wù)下沉，分布式思想若現(xiàn)——讓原來(lái)網(wǎng)站 Web 一個(gè)系統(tǒng)做的事，變成由子系統(tǒng)分擔(dān)去完成。

應(yīng)用架構(gòu)的演變，服務(wù)模塊化拆分，隨之而來(lái)的就是業(yè)務(wù)日志、業(yè)務(wù)數(shù)據(jù)散落在各處。

隨著業(yè)務(wù)的推廣，業(yè)務(wù)量逐日增多，沉淀的數(shù)據(jù)日益龐大，在業(yè)務(wù)層面、運(yùn)維層面上的很多問(wèn)題，逐漸開(kāi)始暴露：

在業(yè)務(wù)層面上，面對(duì)監(jiān)管機(jī)構(gòu)的監(jiān)管，整合提取散落在各地的海量數(shù)據(jù)稍顯困難;海量數(shù)據(jù)散落，想做個(gè)統(tǒng)計(jì)分析報(bào)表也非常不易。
在運(yùn)維層面上，由于缺少統(tǒng)一的日志歸檔，想基于日志做快速分析也比較困難;如果想從散落在各模塊的日志中，進(jìn)行調(diào)用鏈路的分析也是相當(dāng)費(fèi)勁。

面對(duì)上述問(wèn)題，此時(shí)一個(gè)碩大的紅色問(wèn)號(hào)出現(xiàn)在我們面前，到底該如何解決?

面對(duì)結(jié)構(gòu)化的業(yè)務(wù)數(shù)據(jù)，不妨先考慮采用國(guó)內(nèi)比較成熟的開(kāi)源數(shù)據(jù)庫(kù)中間件 Sharding-JDBC、MyCat 看是否能夠解決業(yè)務(wù)問(wèn)題。

面對(duì)日志數(shù)據(jù)，可以考慮采用 ELK 等開(kāi)源組件。如果以上方案或者能嘗試的方式都無(wú)法幫我們解決，嘗試搬出大數(shù)據(jù)吧。

那到底什么時(shí)候需要用大數(shù)據(jù)呢?大數(shù)據(jù)到底能幫我們解決什么問(wèn)題呢?注意，前方高能預(yù)警，門外漢“撩”大數(shù)據(jù)的正確姿勢(shì)即將開(kāi)啟。

邂逅：一起撬開(kāi)大數(shù)據(jù)之門

槽點(diǎn)：門外漢“撩”大數(shù)據(jù)的正確姿勢(shì)。

與大數(shù)據(jù)的邂逅，源于兩個(gè)頭痛的問(wèn)題。第一個(gè)問(wèn)題是海量數(shù)據(jù)的存儲(chǔ)，如何解決?第二個(gè)問(wèn)題是海量數(shù)據(jù)的計(jì)算，如何解決?

面對(duì)這兩個(gè)頭痛的問(wèn)題，不得不提及谷歌的“三駕馬車”(分布式文件系統(tǒng) GFS、MapReduce 和 BigTable)。

谷歌“三駕馬車”的出現(xiàn)，奠定了大數(shù)據(jù)發(fā)展的基石，毫不夸張地說(shuō)，沒(méi)有谷歌的“三駕馬車”就沒(méi)有大數(shù)據(jù)，所以接下來(lái)很有必要逐一認(rèn)識(shí)。

大家都知道，谷歌搜索引擎每天要抓取數(shù)以億計(jì)的網(wǎng)頁(yè)，那么抓取的海量數(shù)據(jù)該怎么存儲(chǔ)?

谷歌痛則思變，重磅推出分布式文件系統(tǒng) GFS。面對(duì)谷歌推出的分布式文件系統(tǒng) GFS 架構(gòu)，如 PPT 中示意，參與角色著實(shí)很簡(jiǎn)單。

主要分為：

GFS Master(主服務(wù)器)
GFS Chunkserver(塊存儲(chǔ)服務(wù)器)
GFS Client(客戶端)

不過(guò)對(duì)于首次接觸這個(gè)的你，可能還是一臉懵，大家心莫慌，接下來(lái)容我抽象一下。

GFS Master 我們姑且認(rèn)為是古代的皇上，統(tǒng)籌全局，運(yùn)籌帷幄。主要負(fù)責(zé)掌控管理所有文件系統(tǒng)的元數(shù)據(jù)，包括文件和塊的命名空間、從文件到塊的映射、每個(gè)塊所在的節(jié)點(diǎn)位置。

說(shuō)白了，就是要維護(hù)哪個(gè)文件存在哪些文件服務(wù)器上的元數(shù)據(jù)信息，并且定期通過(guò)心跳機(jī)制與每一個(gè) GFS Chunkserver 通信，向其發(fā)送指令并收集其狀態(tài)。

GFS Chunkserver 可以認(rèn)為是宰相，因?yàn)樵紫喽亲永锩婺軗未軌蚝＜{百川。主要提供數(shù)據(jù)塊的存儲(chǔ)服務(wù)，以文件的形式存儲(chǔ)于 Chunkserver 上。

GFS Client 可以認(rèn)為是使者，對(duì)外提供一套類似傳統(tǒng)文件系統(tǒng)的 API 接口，對(duì)內(nèi)主要通過(guò)與皇帝通信來(lái)獲取元數(shù)據(jù)，然后直接和宰相交互，來(lái)進(jìn)行所有的數(shù)據(jù)操作。

為了讓大家對(duì) GFS 背后的讀寫流程有更多認(rèn)識(shí)，獻(xiàn)上兩首歌謠：

到這里，大家應(yīng)該對(duì)分布式文件系統(tǒng) GFS 不再陌生，以后在飯桌上討論該話題時(shí)，也能與朋友交涉兩嗓子啦。

不過(guò)這還只是了解了海量數(shù)據(jù)怎么存儲(chǔ)，那如何從海量數(shù)據(jù)存儲(chǔ)中，快速計(jì)算出我們想要的結(jié)果呢?

面對(duì)海量數(shù)據(jù)的計(jì)算，谷歌再次創(chuàng)新，推出了 MapReduce 編程模型及實(shí)現(xiàn)。

MapReduce 主要是采取分而治之的思想，通俗地講，主要是將一個(gè)大規(guī)模的問(wèn)題，分成多個(gè)小規(guī)模的問(wèn)題，把多個(gè)小規(guī)模問(wèn)題解決，然后再合并小規(guī)模問(wèn)題的結(jié)果，就能夠解決大規(guī)模的問(wèn)題。

也有人說(shuō) MapReduce 就像光頭強(qiáng)的鋸子和錘子，世界上的萬(wàn)事萬(wàn)物都可以先鋸幾下，然后再錘幾下，就能輕松搞定，至于鋸子怎么鋸，錘子怎么錘，那就是個(gè)人的手藝了。

這么解釋不免顯得枯燥乏味，我們不妨換種方式，走進(jìn)生活真實(shí)感受 MapReduce。

斗地主估計(jì)大家都玩過(guò)，每次開(kāi)玩之前，都會(huì)統(tǒng)計(jì)一副牌的張數(shù)到底夠不夠，最快的步驟莫過(guò)于：分幾份給大家一起數(shù)，最后大家把數(shù)累加，算總張數(shù)，接著就可以愉快地玩耍啦......

這不就是分而治之的思想嗎?!不得不說(shuō)架構(gòu)思想來(lái)源于人們的生活!

再舉個(gè)不太貼切的例子來(lái)感受 MapReduce 背后的運(yùn)轉(zhuǎn)流程，估計(jì)很多人掰過(guò)玉米，每當(dāng)玉米成熟的季節(jié)，地主家就開(kāi)始忙碌起來(lái)。

首先地主將一畝地的玉米分給處于空閑狀態(tài)的長(zhǎng)工來(lái)處理;專門負(fù)責(zé)掰玉米的長(zhǎng)工領(lǐng)取任務(wù)，開(kāi)始掰玉米操作(Map 操作)，并把掰好的玉米放到在麻袋里(緩沖區(qū))，麻袋裝不下時(shí)，會(huì)被裝到木桶中(溢寫)。

木桶被劃分為藍(lán)色的生玉米木桶、紅色的熟玉米木桶(分區(qū))，地主通知二當(dāng)家來(lái)“收”屬于自己的那部分玉米。

二當(dāng)家收到地主的通知后，就到相應(yīng)的長(zhǎng)工那兒“拿回”屬于自己的那部分玉米(Fetch 操作)，二當(dāng)家對(duì)收取的玉米進(jìn)行處理(Reduce 操作)，并把處理后的結(jié)果放入糧倉(cāng)。

一個(gè)不太貼切的生活體驗(yàn)+一張畫得不太對(duì)的丑圖=苦澀難懂的技術(shù)，也不知道這樣解釋，你了解了多少?

不過(guò)如果以后再談大數(shù)據(jù)，知道 MapReduce 這個(gè)詞的存在，那這次的分享就算成功(哈哈)。

MapReduce 解決了海量數(shù)據(jù)的計(jì)算問(wèn)題，可謂是力作，但谷歌新的業(yè)務(wù)需求一直在不斷出現(xiàn)。

眾所周知，谷歌要存儲(chǔ)爬取的海量網(wǎng)頁(yè)，由于網(wǎng)頁(yè)會(huì)不斷更新，所以要不斷地針對(duì)同一個(gè) URL 進(jìn)行爬取，那么就需要能夠存儲(chǔ)一個(gè) URL 不同時(shí)期的多個(gè)版本的網(wǎng)頁(yè)內(nèi)容。

谷歌面臨很多諸如此類的業(yè)務(wù)場(chǎng)景，面對(duì)此類頭痛的需求，該怎么辦?

谷歌重磅打造了一款類似以“URL+contents+time stamp”為 key，以“html 網(wǎng)頁(yè)內(nèi)容”為值的存儲(chǔ)系統(tǒng)，于是就有了 BigTable 這個(gè)鍵值系統(tǒng)的存在(本文不展開(kāi)詳述)。

至此，兩個(gè)頭痛的問(wèn)題就算解決了。面對(duì)海量數(shù)據(jù)存儲(chǔ)難題，谷歌推出了分布式文件系統(tǒng) GFS、結(jié)構(gòu)化存儲(chǔ)系統(tǒng) BigTable;面對(duì)海量數(shù)據(jù)的計(jì)算難題，谷歌推出了 MapReduce。

不過(guò)靜下來(lái)想想，GFS 也好、MapReduce 也罷，無(wú)非都是秉承了大道至簡(jiǎn)、一人掌權(quán)、其他人辦事、人多力量大的設(shè)計(jì)理念。

另外畫龍畫虎難畫骨，建議閑暇之余也多些思考：為什么架構(gòu)要這么設(shè)計(jì)?架構(gòu)設(shè)計(jì)的目標(biāo)到底是如何體現(xiàn)的?