揭祕「撩」大數據的正確姿式：生動示例解說大數據「三駕馬車」

我是我：「緣起於美麗，相識於邂逅，廝守到白頭！」

衆聽衆：「呃，難道今天是要分享如何做詩？！」

我是我：「你們不要誤會，今天主要的分享不是如何做詩，而是《揭祕：‘撩’大數據的正確姿式》，下面進入正題。」

話說當下技術圈的朋友，一塊兒聚個會聊個天，若是不會點大數據的知識，感受都融入不了圈子，爲了之後聚會時讓你有聊有料，接下來就跟隨個人講述，一塊兒與大數據混個臉熟吧，不過在「撩」大數據以前，仍是先揭祕一下研發這些年咱們都經歷了啥？

緣起：應用系統架構的從 0 到 1

揭祕：研發這些年咱們都經歷了啥？

大道至簡。生活在技術圈裏，你們靜下來想一想，不管一個應用系統多龐大、多複雜，無非也就是由一個漂亮的網站門面 + 一個醜陋的管理模塊 + 一個悶頭幹活的定時任務三大板塊組成。

咱們負責的應用系統固然也不例外，起初設計的時候三大模塊綁在一塊兒（All in one），線上跑一個 Tomcat 輕鬆就搞定，可謂是像極了一個大泥球。

衍化至繁。因爲網站模塊、管理平臺、定時任務三大模塊綁定在一塊兒，開發協做會比較麻煩，時不時會有代碼合併衝突出現；線上應用升級時，也會致使其它模塊暫時不能使用，例如若是修改了一個定時任務的配置，可能會致使網站、管理平臺的服務暫時不能用。面對諸多的不便，就不得不對 All in one 的大泥球系統進行拆解。

隨着產品需求的快速迭代，網站 WEB 功能逐漸增多，咱們起初設計時雄心勃勃（All in one 的單體架構），覺得直接按模塊設計疊加實現就行了，誰成想系統愈加顯得臃腫（想一想也是走彎路啦！）。因此不得不改變實現思路，讓模塊服務下沉，分佈式思想若現——讓原來網站 WEB 一個系統作的事，變成由子系統分擔去完成。

應用架構的演變，服務模塊化拆分，隨之而來的就是業務日誌、業務數據散落在各處。隨着業務的推廣，業務量逐日增多，沉澱的數據日益龐大，在業務層面、運維層面上的不少問題，逐漸開始暴露。

• 在業務層面上，面對監管機構的監管，整合提取散落在各地的海量數據稍顯困難；海量數據散落，想作個統計分析報表也很是不易。
• 在運維層面上，因爲缺乏統一的日誌歸檔，想基於日誌作快速分析也比較困難；若是想從散落在各模塊的日誌中，進行調用鏈路的分析也是至關費勁。

面對上述問題，此時一個碩大的紅色問號出如今咱們面前，到底該如何解決？

面對結構化的業務數據，不妨先考慮採用國內比較成熟的開源數據庫中間件 Sharding-JDBC、MyCat 看是否可以解決業務問題；面對日誌數據，能夠考慮採用 ELK 等開源組件。若是以上方案或者能嘗試的方式都沒法幫咱們解決，嘗試搬出大數據吧。

那到底何時須要用大數據呢？大數據到底能幫咱們解決什麼問題呢？注意，前方高能預警，門外漢「撩」大數據的正確姿式即將開啓。

邂逅：一塊兒撬開大數據之門

槽點：門外漢「撩」大數據的正確姿式

與大數據的邂逅，源於兩個頭痛的問題。第一個問題是海量數據的存儲，如何解決？第二個問題是海量數據的計算，如何解決？

面對這兩個頭痛的問題，不得不說起谷歌的「三駕馬車」（分佈式文件系統 GFS、MapReduce 和 BigTable），谷歌「三駕馬車」的出現，奠基了大數據發展的基石，絕不誇張地說，沒有谷歌的「三駕馬車」就沒有大數據，因此接下來頗有必要逐一認識。

你們都知道，谷歌搜索引擎天天要抓取數以億計的網頁，那麼抓取的海量數據該怎麼存儲？

谷歌痛則思變，重磅推出分佈式文件系統 GFS。面對谷歌推出的分佈式文件系統 GFS 架構，如 PPT 中示意，參與角色着實很簡單，主要分爲 GFS Master（主服務器）、GFS Chunkserver（塊存儲服務器）、GFS Client（客戶端）。

不過對於首次接觸這個的你，可能仍是一臉懵 ，你們心莫慌，接下來容我抽象一下。

GFS Master 咱們姑且認爲是古代的皇上，統籌全局，指揮若定。主要負責掌控管理全部文件系統的元數據，包括文件和塊的命名空間、從文件到塊的映射、每一個塊所在的節點位置。說白了，就是要維護哪一個文件存在哪些文件服務器上的元數據信息，而且按期經過心跳機制與每個 GFS Chunkserver 通訊，向其發送指令並收集其狀態。

GFS Chunkserver 能夠認爲是宰相，由於宰相肚子裏面能撐船，可以海納百川。主要提供數據塊的存儲服務，以文件的形式存儲於 Chunkserver 上。

GFS Client 能夠認爲是使者，對外提供一套相似傳統文件系統的 API 接口，對內主要經過與皇帝通訊來獲取元數據，而後直接和宰相交互，來進行全部的數據操做。

爲了讓你們對 GFS 背後的讀寫流程有更多認識，獻上兩首歌謠。

到這裏，你們應該對分佈式文件系統 GFS 再也不陌生，之後在飯桌上討論該話題時，也能與朋友交涉兩嗓子啦。

不過這還只是瞭解了海量數據怎麼存儲，那如何從海量數據存儲中，快速計算出咱們想要的結果呢？

面對海量數據的計算，谷歌再次創新，推出了 MapReduce 編程模型及實現。

MapReduce 主要是採起分而治之的思想，通俗地講，主要是將一個大規模的問題，分紅多個小規模的問題，把多個小規模問題解決，而後再合併小規模問題的結果，就可以解決大規模的問題。

也有人說 MapReduce 就像光頭強的鋸子和錘子，世界上的萬事萬物均可以先鋸幾下，而後再錘幾下，就能輕鬆搞定，至於鋸子怎麼鋸，錘子怎麼錘，那就是我的的手藝了。

這麼解釋難免顯得枯燥乏味，咱們不妨換種方式，走進生活真實感覺 MapReduce。

鬥地主估計你們都玩過，每次開玩以前，都會統計一副牌的張數到底夠不夠，最快的步驟莫過於：分幾份給你們一塊兒數，最後你們把數累加，算總張數，接着就能夠愉快地玩耍啦... ...這不就是分而治之的思想嗎？！不得不說架構思想來源於人們的生活！

再舉個不太貼切的例子來感覺MapReduce 背後的運轉流程，估計不少人掰過玉米，每當玉米成熟的季節，地主家就開始忙碌起來。

首先地主將一畝地的玉米分給處於空閒狀態的長工來處理；專門負責掰玉米的長工領取任務，開始掰玉米操做（Map 操做），並把掰好的玉米放到在麻袋裏（緩衝區），麻袋裝不下時，會被裝到木桶中（溢寫），木桶被劃分爲藍色的生玉米木桶、紅色的熟玉米木桶（分區），地主通知二當家來「收」屬於本身的那部分玉米，二當家收到地主的通知後，就到相應的長工那兒「拿回」屬於本身的那部分玉米（Fetch 操做），二當家對收取的玉米進行處理（Reduce 操做），並把處理後的結果放入糧倉。

一個不太貼切的生活體驗 + 一張畫得不太對的醜圖 = 苦澀難懂的技術，也不知道這樣解釋，你瞭解了多少？不過若是之後再談大數據，知道 MapReduce 這個詞的存在，那此次的分享就算成功（哈哈）。

MapReduce 解決了海量數據的計算問題，可謂是力做，但谷歌新的業務需求一直在不斷出現。衆所周知，谷歌要存儲爬取的海量網頁，因爲網頁會不斷更新，因此要不斷地針對同一個 URL 進行爬取，那麼就須要可以存儲一個 URL 不一樣時期的多個版本的網頁內容。谷歌面臨不少諸如此類的業務場景，面對此類頭痛的需求，該怎麼辦？

谷歌重磅打造了一款相似以「URL + contents + time stamp」爲 key，以「html 網頁內容」爲值的存儲系統，因而就有了 BigTable 這個鍵值系統的存在（本文不展開詳述）。

至此，兩個頭痛的問題就算解決了。面對海量數據存儲難題，谷歌推出了分佈式文件系統 GFS、結構化存儲系統 BigTable；面對海量數據的計算難題，谷歌推出了 MapReduce。

不過靜下來想一想，GFS 也好、MapReduce 也罷，無非都是秉承了大道至簡、一人掌權、其它人辦事、人多力量大的設計理念。另外畫龍畫虎難畫骨，建議閒暇之餘也多些思考：爲何架構要這麼設計？架構設計的目標究竟是如何體現的？

基於谷歌的「三駕馬車」，出現了一大堆開源的輪子，不得不說谷歌的「三駕馬車」開啓了大數據時代。瞭解了谷歌的「三駕馬車」的設計理念後，再去看這些開源的輪子，應該會比較好上手。

好了，門外漢「撩」大數據就聊到這兒吧，但願經過上文的分享可以瞭解幾個關鍵詞：大道至簡、衍化至繁、谷歌三駕馬車（GFS、MapReduce、BigTable）、痛則思變、開源輪子。

白頭：番外篇

扯淡：不妨換一種態度

本文至此也即將接近尾聲，最後是番外篇~

首先，借用日本劍道學習心訣「守、破、離」，但願咱們一塊兒作一個精進的人。

最後，在有限的時間內要多學習，不要停下學習的腳步，在瞭解和使用已經有的成熟技術之時，更要多思考，開創適合本身工做場景的解決方案。

文章來源：宜信技術學院 & 宜信支付結算團隊技術分享第6期-宜信支付結算部支付研發團隊高級工程師許賽賽《揭祕：「撩」大數據的正確姿式》

分享者：宜信支付結算部支付研發團隊高級工程師許賽賽

原文首發於公號-野指針