大數(shù)據(jù)這個概念紅紅火火的也有兩三個年頭了，我在這個坑里的時間可能要更長一些，勉強可以從2008年開始算。所謂年頭待得久了，看得也多一些。對應(yīng)中國傳統(tǒng)文化的說法，什么東西老了都能成精。這個坑的主要目的還是以八卦為主，順便把我知道的道聽途說的有的沒的的大數(shù)據(jù)相關(guān)的東西給大家講一講，順便也把大數(shù)據(jù)來龍去脈理一理，權(quán)當(dāng)諸位茶余飯后的談資。倘若寫到精彩之處，還請多多打賞。錢多錢少其實不是問題，收起打賞就頗有成就感。感覺人生又完整了一些。
Google的后悔藥
大概說起大數(shù)據(jù)，我們就不可避免的要談起這個曾經(jīng)在國內(nèi)風(fēng)光無限，然后又從國內(nèi)退出去的公司，號稱Do not Evil而實際上相當(dāng)Evil的公司——Google。當(dāng)然，因為我本人的經(jīng)歷的關(guān)系，我在自己公眾號前面的文章里也提到過，我是Gou黑軟粉，不是和主流大眾的審美觀一致。
不可否認，大數(shù)據(jù)伊始，主要是因為Google這個公司。更加確切的說，不僅僅是因為Google的一系列的論文，更是因為Google以自己的一年又一年的財報告訴大家，免費的消費者們，結(jié)合大數(shù)據(jù)的技術(shù)，做成廣告平臺，就像開了印鈔機一樣。錢之所在，趨之若鶩，人性本來就是如此。
我們把時光倒流到2009年，經(jīng)濟危機的時候。那一年全世界發(fā)生了很多事。除了大家開始狂印鈔票以外，大數(shù)據(jù)作為一個概念也開始悄然登場了。這個時候我曾經(jīng)聽到一個特別著名的笑話。笑話大致上是說，有人采訪了Larry Page，問他有沒有什么后悔的事情，Larry Page說，他很后悔讓MapReduce和Google File System這樣的paper給發(fā)了出來。
這個采訪估計是子虛烏有的東西，然而其反應(yīng)的本質(zhì)問題，Google后悔了，卻是非常真實而有據(jù)可循的。在我看來，Google不僅僅是后悔了，而且是在不停的后悔又后悔之中。所以當(dāng)一個新的名詞人工智能，以及伴隨著的AR/VR出現(xiàn)的時候，Google采取了一種截然不同的做法。今天我們從Google的后悔藥說起。
Google的后悔藥的第一層意思其實非常的名曲，倘若Google早年沒有發(fā)表了Google File System， MapReduce，以及BigTable這三篇文章，那么Google依然擁有著這世界上最為先進而獨特的大規(guī)模數(shù)據(jù)存儲和計算的能力。而業(yè)界的其他公司如果要想平地起高樓的起起來，那可能會需要更多的時間。
這其實從Google發(fā)表的一系列文章里也能看出來。Google File System是論文里面的經(jīng)典，必須說每個做數(shù)據(jù)處理的人都值得一讀。MapReduce則寫得沒那么實誠了。等BigTable出來的時候，那就更需要讀者更多的想象空間了。至于此后若干年才誕生的Spanner，這個系統(tǒng)也許可以稱為是一個偉大的系統(tǒng)，這篇論文，寫得遮遮掩掩的那種樣子，能被OSDI接收也是奇跡，更何況是Best Paper Award呢。就事論事，Google從一個非常開放的方式到越來越保守，和它后悔自己泄露了自己的商業(yè)機密，而以后又不得不繼續(xù)以泄露商業(yè)機密的方式來半遮半掩的顯示它在大數(shù)據(jù)領(lǐng)域的存在，無疑說明Google其實很后悔一開始發(fā)了那幾篇論文，可惜這世界上并沒有后悔藥。
然而我覺得Google其實是一個商業(yè)上極其失敗的公司。倘若我做CEO的話，估計高marketing的應(yīng)該從上到下都清幾遍。為什么這么說呢。Google這個公司有著天生的優(yōu)越感：老子就是有Google File System，老子還有MapReduce，你們這些老朽的，還有新生的公司們，沒有我這樣牛逼的體系結(jié)構(gòu)，你們搞什么飛機都沒辦法趕得上我。
所以呢，Google這個作為奠定了整個BigData最開始的框架和基礎(chǔ)的公司，從來都沒有想過開源自己的系統(tǒng)，以便可以占領(lǐng)市場。于是活雷鋒Yahoo上場，硅谷大大小小的公司都湊上去，亂拳打死老師傅。Hadoop這樣的一個看起來很爛的系統(tǒng)就這樣在大家七拼八湊的節(jié)奏下搭出來了。然后就茁壯成長起來了。這是一件非常有意思的事情。作為大數(shù)據(jù)技術(shù)的奠基人，在大數(shù)據(jù)領(lǐng)域的影響力，基本上是等于零。那么大一塊餅，你Google只要自己open一點，本來很大的市場，現(xiàn)在是做了雷鋒卻沒撈到任何的好處，我想Larry Page回頭想起來，估計后悔藥吃的不止是一瓶。
除去商業(yè)上極其的傲慢以外，Google還是一個以自我為中心的公司。Jobs的偉大在于他說過用戶是愚蠢的我們要告訴用戶怎么用才是正確的，這話的前提是Jobs的確是非常的比用戶更知道他們需要的是什么。盡管蘋果有諸多弊端，對用戶的真實需要的理解是很深刻的。
Google不同，每次都是不切實際的指望用戶去按照他們的方式去用他們的產(chǎn)品。早年的Google玩的那個只需要瀏覽器就可以讓消費者訪問全世界以及完成日常所有應(yīng)用的Chrome應(yīng)該是一個很好的例子。然而在大數(shù)據(jù)這個背景下，和云計算相關(guān)的地方，Google做了一件事：Google App Engine。非要定義的話，這是個PAAS的東西。
Google2008年正式開始做這個App Engine，進入云計算市場，并且提供了包括BigTable在內(nèi)的API的支持。問題吧，Google大概忘記了它自己和它的用戶的不同。它的系統(tǒng)的Scalability對大部分用戶來說，都沒意義，沒有什么用戶要用幾萬臺電腦去解決問題的。而它的API的局限，對很多用戶來說其實無法接受。最簡單的，Google當(dāng)時并不支持join。并且Google告訴大家我自己這么大的公司就沒有用Join，你們也不需要用。
Google App Engine折騰幾年，并不成功。相反的微軟亞馬遜都開始做賣虛擬機的生意，而且越來越紅火，所以到了12年終于忍不住開始做Google Compute Engine，也就是終于承認自己以前的戰(zhàn)略錯誤，開始賣機器了。我相信4年時間可以做很多事情，我也相信4年時間足夠讓一個本來可以搶占一部分蛋糕的市場，變得無足輕重起來。所以說西雅圖才是云的中心，而彎曲，包括Google在內(nèi)，終究是慢了。我想Larry Page肯定是非常的感嘆他接二連三的做出的錯誤決定。這些錯誤決定的唯一結(jié)果就是BigData這塊大蛋糕，基于Google的論文，但是卻沒讓Google吃到一口。
所以當(dāng)人工智能這個新泡泡起來的時候，Google迅速采用了一個完全不同的策略，不僅僅用AlphaGo這個程序告訴大家，所謂圍棋，不管東亞人怎么吹是信仰是人生是哲理，其實無非就是個計算的問題。Google接下來很快的開放了Google內(nèi)部的人工智能平臺TensorFlow。我想這個戰(zhàn)略上的轉(zhuǎn)變，反映了Google不想在人工智能這個新的熱點上再一次吃上BigData上面顆粒無收的后悔藥。
三駕馬車之永垂不朽的GFS
但凡是要開始講大數(shù)據(jù)的，都繞不開最初的Google三駕馬車：Google File System（GFS）， MapReduce，BigTable。如果我們拉長時間軸到20年為一個周期來看呢，這三駕馬車到今天的影響力其實已然不同。
MapReduce作為一個有很多優(yōu)點又有很多缺點的東西來說，很大程度上影響力已經(jīng)釋微了。
BigTable以及以此為代表的各種KeyValue Store還有著它的市場，但是在Google內(nèi)部Spanner作為下一代的產(chǎn)品，也在很大程度上開始取代各種各樣的的BigTable的應(yīng)用。而作為這一切的基礎(chǔ)的Google File System，不但沒有任何倒臺的跡象，還在不斷的演化，事實上支撐著Google這個龐大的互聯(lián)網(wǎng)公司的一切計算。
作為開源最為成功的Hadoop Ecosystem來說，這么多年來風(fēng)起云涌，很多東西都在變。但是HDFS的地位卻始終很牢固。盡管各大云計算廠商都基于了自己的存儲系統(tǒng)實現(xiàn)了HDFS的接口，但是這個文件系統(tǒng)的基本理念至今并無太多改變。
那么GFS到底是什么呢？簡單一點來說它是一個文件系統(tǒng)，類似我們的NTFS或者EXT3，只是這個文件系統(tǒng)是建立在一堆的計算機的集群之上，用來存儲海量數(shù)據(jù)的。
一般來說，對文件系統(tǒng)的操作無非是讀或者寫，而寫通常又被細分成update和append。Update是對已有數(shù)據(jù)的更新，而append則是在文件的末尾增加新的數(shù)據(jù)。Google File System的論文發(fā)表于2003年，那個時候Google已經(jīng)可以讓這個文件系統(tǒng)穩(wěn)定的運行在幾千臺機器上，那么今天在我看來穩(wěn)定的運行在幾萬臺機器上并非是什么問題。這是非常了不起的成就，也是Hadoop的文件系統(tǒng)至今無非達到的高度。
GFS的設(shè)計理念上做了兩個非常重要的假設(shè)，其一是這個文件系統(tǒng)只處理大文件，一般來說要以TB或者PB作為級別去處理。其二是這個文件系統(tǒng)不支持update只支持append。在這兩個假設(shè)的基礎(chǔ)上，文件系統(tǒng)進一步假設(shè)可以把大文件切成若干個chunk，本文上面的圖大致上給了GFS的一個基本體系框架的解釋。
Chunk server是GFS的主體，它們存在的目的是為了保存各種各樣的chunk。這些chunk代表了不同文件的不同部分。為了保證文件的完整性不受到機器下崗的影響，通常來說這些chunk都有冗余，這個冗余標(biāo)準(zhǔn)的來說是3份。有過各種分析證明這個三份是多門的安全。
在我曾經(jīng)工作的微軟的文件系統(tǒng)實現(xiàn)里面也用過三份這樣的冗余。結(jié)果有一次data center的電源出問題，導(dǎo)致一個集裝箱的機器整個的失聯(lián)（微軟的數(shù)據(jù)中心采用了非常獨特的集裝箱設(shè)計）。有一些文件的兩個或者三個拷貝都在那個集裝箱對應(yīng)的機器上，可以想象，這也同樣導(dǎo)致了整個系統(tǒng)的不可用。所以對于這三個拷貝要放哪里怎么去放其實是GFS里比較有意思的一個問題。我相信Google一定是經(jīng)過了很多的研究。
除了保存實際數(shù)據(jù)的chunk server以外，我們還需要metadata manager，在GFS里面這個東西就是master了。按照最初的論文來說，master是一個GFS里面唯一的。當(dāng)然后續(xù)有些資料里有提到GFS V2的相關(guān)信息表明這個single point bottleneck 在Google的系統(tǒng)演進中得到了解決。Master說白了就是記錄了各個文件的不同chunk以及它們的各自拷貝在不同chunk server上的區(qū)別。
Master的重要性不言而喻。沒有了metadata的文件系統(tǒng)就是一團亂麻。Google的實現(xiàn)實際上用了一個Paxos協(xié)議，倘若我的理解是正確的話。Paxos是Lamport提出來的用來解決在不穩(wěn)定網(wǎng)絡(luò)里面的consensus的一個協(xié)議。協(xié)議本身并不難懂，但是論文的證明需要有些耐心。當(dāng)然最重要的，我自己從來沒有實現(xiàn)過這個協(xié)議。但是就我能看到的周圍實現(xiàn)過的人來說，這個東西很坑爹。
Paxos干的事情是在2N+1臺機器里保持N的冗余。簡單一點說，掛掉N臺機器這個metadata service依然可以使用。協(xié)議會選出一個master服務(wù)，而其他的則作為shadow server存在。一旦master掛了大家會重新投票。這個協(xié)議很好的解決了High Availability的問題。很不幸的是，抄襲的Hadoop 文件系統(tǒng)使用的是一個完全不同的方案。這個我們在講到Hadoop的時候再說。
對GFS的訪問通過client，讀的操作里，client會從master那邊拿回相應(yīng)的chunk server，數(shù)據(jù)的傳輸則通過chunk server和client之間進行。不會因此影響了master的性能。而寫的操作則需要確保所有的primary以及secondary都寫完以后才返回client。如果寫失敗，則會有一系列的retry，實在不行則這些chunk會被標(biāo)注成garbage，然后被garbage collection。
Master和chunk server之間會保持通信，master保持著每個chunk的三個copy的實際位置。當(dāng)有的機器掉線之后，master如果有必要也會在其他的機器上觸發(fā)額外的copy活動以確保冗余，保證文件系統(tǒng)的安全。
GFS的設(shè)計非常的值得學(xué)習(xí)。系統(tǒng)支持的目標(biāo)文件以及文件的操作非常的明確而簡單。對待大規(guī)模不穩(wěn)定的PC機構(gòu)成的data center上怎么樣建立一個穩(wěn)定的系統(tǒng)，對data使用了復(fù)制，而對metadata則用了Paxos這樣的算法的實現(xiàn)。這個文件系統(tǒng)體現(xiàn)了相當(dāng)高水準(zhǔn)的系統(tǒng)設(shè)計里對方方面面trade off的選擇。
有些東西只有自己做過或者就近看人做過才能真正感受到這系統(tǒng)設(shè)計的博大精深。故而對我個人而言，我對GFS的論文一直是非常的推崇，我覺得這篇論文值得每個做系統(tǒng)的人反復(fù)的讀。
三駕馬車之坑人的MapReduce
在Google的三駕馬車里面，Google File System是永垂不朽的，也是基本上沒有人去做什么進一步的研究的。BigTable是看不懂的，讀起來需要很多時間精力。唯獨MapReduce，是霓虹燈前面閃爍的星星，撕逼戰(zhàn)斗的主角，眾人追捧和喊打的對象。自從MapReduce這個詞出來以后，不知道有多少篇論文發(fā)表出來，又不知道有多少口誅筆伐的文章。我曾經(jīng)在HANA篇里寫過圍繞MapReduce，Google和Michael StoneBraker等等database的元老之間的論戰(zhàn)。歡迎大家先讀讀這篇八卦文。為了避免重復(fù)，這篇文章里，我就不再展開這部分的話題了。
作為論文來說MapReduce嚴格的來講不能算作一篇論文，因為它講述了兩件不同的事情。其一是一個叫做MapReduce的編程模型。其二是大規(guī)模數(shù)據(jù)處理的體系架構(gòu)的實現(xiàn)。這篇論文將兩者以某種方式混雜在一起來達到不可告人的目的，并且把這個體系吹得非常的牛，但是卻并沒有討論一些Google內(nèi)部造就知道的局限性，以我對某狗的某些表現(xiàn)來看，恐怕我的小人之心覺得有意為之的可能性比較大。
因此當(dāng)智商比較低的Yahoo活雷鋒抄襲MapReduce的時候弄出的Hadoop是不倫不類，這才有了后來Hadoop V2以及Yarn的引進。當(dāng)然這是后話。作為同樣抄襲對象的微軟就顯得老道很多。微軟內(nèi)部支撐大數(shù)據(jù)分析的平臺Cosmos是狠狠的抄襲了Google的File system卻很大程度上摒棄了MapReduce這個框架。當(dāng)然這些都是后話，只能留待以后的篇幅慢慢展開。
我們先看看作為編程模型的MapReduce。所謂MapReduce的意思是任何的事情只要都嚴格遵循Map Shuffle Reduce三個階段就好。其中Shuffle是系統(tǒng)自己提供的而Map和Reduce則用戶需要寫代碼。Map是一個per record的操作。任何兩個record之間都相互獨立。
Reduce是個per key的操作，相同key的所有record都在一起被同時操作，不同的key在不同的group下面，可以獨立運行。這就像是說我們有一把大砍刀，一個錘子。世界上的萬事萬物都可以先砍幾刀再錘幾下，就能搞定。至于刀怎么砍，錘子怎么錘，那就算個人的手藝了。
從計算模型的角度來看，這個模型極其的粗糙。所以現(xiàn)在連Google自己都不好意思繼續(xù)鼓吹MapReduce了。從做數(shù)據(jù)庫的人的角度來看這無非是一個select一個groupby，這些花樣197x的時候在SystemR里都被玩過了。數(shù)據(jù)庫領(lǐng)域玩這些花樣無數(shù)遍。真看不出有任何值得鼓吹的道理。
因此，在計算模型的角度上來說，我覺得Google在很大程度上誤導(dǎo)和夸大了MapReduce的實際適用范圍，也可能是自己把自己也給忽悠了。
在Google內(nèi)部MapReduce最大的應(yīng)用是作為inverted index的build的平臺。所謂inverted index是information retrieval里面一個重要的概念，簡單的講是從單詞到包含單詞的文本的一個索引。我們搜索internet，google需要爬蟲把網(wǎng)頁爬下來，然后建立出網(wǎng)頁里面的單詞到這個網(wǎng)頁的索引。這樣我們輸入關(guān)鍵字搜索的時候，對應(yīng)的頁面才能出來。也正因為是這樣，所以Google的論文里面用了word count這個例子。下圖是word count的MapReduce的一個示意圖。
然而我們需要知道的是，Google后來公布的信息顯示它的廣告系統(tǒng)是一直運行在MySQL的cluster的，該做join的時候也是做join的。MapReduce作為一個編程模型來說，顯然不是萬能的藥?？墒且驗榫幊棠Ｐ蜕婕暗氖鞘澜缬^方法論的問題。
于是，催生了無數(shù)篇論文，大致的套路都是我們怎么樣用MapReduce去解決這個那個問題。這些論文催生了無數(shù)PhD，幫助很多老師申請到了很多的錢。我覺得很大程度上都掉進了google的神話和這個編程模型的坑。
MapReduce這篇論文的另外一個方面是系統(tǒng)實現(xiàn)。我們可以把題目寫成：如何用一堆廉價PC去穩(wěn)定的實現(xiàn)超大規(guī)模的并行數(shù)據(jù)處理。我想這無疑可以體現(xiàn)出這篇論文真正有意義的地方。的確，數(shù)據(jù)庫的工業(yè)界和學(xué)術(shù)界都玩了幾十年了，有哪個不是用高端的機器。
在MapReduce論文出來的那個時候，誰能處理1個PB的數(shù)據(jù)我給誰跪了。但是Google就能啊。我得意的笑我得意的笑。所以Google以它十分牛逼的數(shù)據(jù)處理平臺，去吹噓那個沒有什么價值的編程模型。而數(shù)據(jù)庫的人以攻擊Google十分不行的編程模型，卻故意不去看Google那個十分強悍的數(shù)據(jù)處理平臺。這場馮京對馬涼的比賽，我覺得毫無意義。
那么我們來看看為什么Google可以做到那么大規(guī)模的數(shù)據(jù)處理。首先這個系統(tǒng)的第一條，很簡單，所有的中間結(jié)果可以寫入到一個穩(wěn)定的，不因為單機的失敗而不能工作的分布式海量文件系統(tǒng)。GFS的偉大可見一斑。沒有GFS，玩你妹的MapReduce。沒有一個database廠商做出過偉大的GFS，當(dāng)然也就沒辦法做出這么牛叉的MapReduce了。
這個系統(tǒng)的第二條也很簡單，能夠?qū)蝹€worker進行自動監(jiān)視和retry。這一點就使得單個節(jié)點的失敗不是問題，系統(tǒng)可以自動的進行管理。加上Google一直保持著絕不泄密的資源管理系統(tǒng)Borg。使得Google對于worker能夠進行有效的管理。
Borg這個系統(tǒng)存在有10多年了，但是Google故意什么都不告訴大家，論文里也假裝沒有。我第一次聽說是幾個從Google出來的人在Twitter想重新搞這樣一個東西。然而一直到以docker為代表的容器技術(shù)的出現(xiàn)，才使得大家知道google的Borg作為一個資源管理和虛擬化系統(tǒng)到底是怎么樣做的。而以docker為代表的容器技術(shù)的出現(xiàn)也使得Borg的優(yōu)勢不存在了。所以Google姍姍來遲的2015年終于發(fā)了篇論文。我想這也是Yahoo這個活雷鋒沒有抄好，而HadoopV2必須引入Yarn的很重要的原因。
解釋這么多，其實是想說明幾點，MapReduce作為編程模型，是一個很傻的模型。完全基于MapReduce的很多project都不太成功。而這個計算模型最重要的是做inverted index build，這就使得Google長久以來宣揚的Join沒意義的論調(diào)顯得很作。另外隨著F1的披露，大家知道Google的Ads系統(tǒng)實際上長期運行在MySQL上，這也從側(cè)面反應(yīng)了Google內(nèi)部的一些情況和當(dāng)初論文的高調(diào)宣揚之間的矛盾。
Google真正值得大家學(xué)習(xí)的是它怎么樣實現(xiàn)了大規(guī)模數(shù)據(jù)并發(fā)的處理。這個東西說穿了，一是依賴于一個很牛的文件系統(tǒng)，二是有著很好的自動監(jiān)控和重試機制。而MapReduce這個編程模型又使得這兩者的實現(xiàn)都簡化了。然而其中很重要的資源管理系統(tǒng)Borg又在當(dāng)初的論文里被徹底隱藏起來了。我想，隨著各種信息的披露，我只能說一句，你妹的。
MapReduce給學(xué)術(shù)界掀起了一片灌水高潮，學(xué)術(shù)界自娛自樂的精神實在很值得敬佩。然而這個東西火得快，死的也快。所謂人怕出名豬怕撞。但愿我的公眾號不會是MapReduce的下場。
以上內(nèi)容由飛總授權(quán)轉(zhuǎn)載，版權(quán)所有，侵權(quán)必究，轉(zhuǎn)載請授權(quán)。
聯(lián)系客服
