為什么談到大數(shù)據(jù)，傳統(tǒng)企業(yè)表現(xiàn)出更多的困惑?其原因是，企業(yè)決策者并不清楚大數(shù)據(jù)能給業(yè)務(wù)帶來(lái)哪些價(jià)值，也不知道如何學(xué)習(xí)、使用大數(shù)據(jù)分析工具。而這些大數(shù)據(jù)工具就擺在那里，誰(shuí)能先一步學(xué)習(xí)使用，誰(shuí)就占有先機(jī)。

算起來(lái)，接觸大數(shù)據(jù)、和互聯(lián)網(wǎng)之外的客戶談大數(shù)據(jù)也有快2年了。也該是時(shí)候整理下一些感受，和大家分享下我看到的國(guó)內(nèi)大數(shù)據(jù)應(yīng)用的一些困惑了。

云和大數(shù)據(jù)，應(yīng)該是近幾年IT炒的最熱的兩個(gè)話題了。在我看來(lái)，這兩者之間的不同就是：云是做新的瓶，裝舊的酒; 大數(shù)據(jù)是找合適的瓶，釀新的酒。

云說(shuō)到底是一種基礎(chǔ)架構(gòu)的革命。原先用物理服務(wù)器的應(yīng)用，在云中變成以各種虛擬服務(wù)器的形式交付出去，從而計(jì)算、存儲(chǔ)、網(wǎng)絡(luò)資源都能被更有效率的利用了。于是，酒量好無(wú)酒不歡的人就可以用個(gè)海碗牛飲二鍋頭;酒量小又想嘗嘗微醺小醉風(fēng)情的人也可以端個(gè)小杯咂巴咂巴女兒紅。

大數(shù)據(jù)的不同在于，它其實(shí)是把以前人們丟棄不理的數(shù)據(jù)都撿起來(lái)，加以重新分析利用，使之產(chǎn)生新價(jià)值的技術(shù)。換句話說(shuō)，原先20斤的糧食只能出2斤的酒糟，現(xiàn)在20斤的糧食都變成或者大部分變成酒糟。當(dāng)然這酒糟肯定會(huì)和原先的酒糟有不一樣，所以釀出來(lái)的酒肯定和以前不同，喝酒、裝酒、儲(chǔ)存酒的方法自然也不同。

所以，相對(duì)于云，人們對(duì)大數(shù)據(jù)使用的困惑更大。接下來(lái)談?wù)勎宜吹降膸最愖疃嗟睦Щ螅约拔覀兡壳按嬖谀男﹩?wèn)題。

困惑之一：大數(shù)據(jù)能干什么?

換用前面飲酒來(lái)作比方，這新釀出來(lái)的酒怎么喝才可以喝得痛快。這里不再想討論到底哪些數(shù)據(jù)是大數(shù)據(jù)了。 下面這張圖是Gartner 對(duì)各行業(yè)對(duì)于大數(shù)據(jù)需求的調(diào)查，該統(tǒng)計(jì)針對(duì)大數(shù)據(jù)通用的3個(gè)V ， 以及未被利用數(shù)據(jù)的需求情況做了分類。 可見(jiàn)幾乎所有行業(yè)都對(duì)大數(shù)據(jù)有著各種各樣的需求。

圖片來(lái)自Gartner

為什么有這些需求，是因?yàn)橐郧斑@些類型的數(shù)據(jù)都因?yàn)榧夹g(shù)和成本的原因，用戶沒(méi)有收集處理。現(xiàn)在有了性價(jià)比合理的手段可以讓你收集處理這些數(shù)據(jù)，怎么可能說(shuō)不要?還是以釀酒做比喻，以前釀兩斤酒糟要浪費(fèi)18斤的糧食，現(xiàn)在至少20斤糧食可以有10斤都變成酒糟了，雖然這些酒糟可能和以前不大一樣，但至少可以少浪費(fèi)8斤糧食呢。

現(xiàn)在問(wèn)題來(lái)了，酒糟多了，種類不一樣了,怎么根據(jù)新的酒糟釀酒呢?對(duì)不起，這個(gè)問(wèn)題酒作坊就要?jiǎng)e人來(lái)教了。但問(wèn)題是，所有酒坊現(xiàn)在可能都面臨這同一個(gè)問(wèn)題，于是就沒(méi)人可以教你了，只能自己慢慢摸索。這個(gè)就是現(xiàn)在各行業(yè)面對(duì)大數(shù)據(jù)的最大困惑 --- 海量的數(shù)據(jù)收集上來(lái)不知道怎么用。

這里不妨看看為什么傳統(tǒng)的數(shù)據(jù)倉(cāng)庫(kù)領(lǐng)域沒(méi)有這樣的困惑。如下這張圖很好的說(shuō)明了傳統(tǒng)和現(xiàn)在的區(qū)別：

圖片來(lái)自Sogeti

從上圖展示的流程可以看出產(chǎn)生困惑的根本原因是：苦逼的IT從業(yè)人員走在了業(yè)務(wù)決策者的前面 (流淚) 。傳統(tǒng)時(shí)代，都是業(yè)務(wù)人員希望得到某類型的統(tǒng)計(jì)報(bào)表或者分析預(yù)測(cè)，于是IT行業(yè)人員為了滿足他們的需求找方案、寫(xiě)算法，從而催生出了各種類型的數(shù)據(jù)倉(cāng)庫(kù)和解決方案。而現(xiàn)在，在互聯(lián)網(wǎng)的推動(dòng)下，IT人員發(fā)覺(jué)原來(lái)我們可以通過(guò)一些新的方式存儲(chǔ)海量的原先無(wú)法處理的數(shù)據(jù)，但業(yè)務(wù)人員卻沒(méi)有準(zhǔn)備好。所以，當(dāng)你告訴他們：“嘿，哥們兒，我這里現(xiàn)在又有了很多數(shù)據(jù)可以幫你了。”他們一頭霧水不知道這些數(shù)據(jù)對(duì)他們有什么用了。

怎么解決這個(gè)問(wèn)題?先來(lái)看傳統(tǒng)廠商O(píng)racle、IBM他們是怎么做的。方式細(xì)節(jié)略有不同，但他們的思路基本如下：

圖片來(lái)自HP首席技術(shù)專家 Greg Battas在ABDS2012大會(huì)上的 分享

簡(jiǎn)單來(lái)說(shuō)，這種處理方式是把Hadoop和其它各類NewSQL、NoSQL方案以ETL，或外部表的方式引入現(xiàn)有的數(shù)據(jù)分析解決方案架構(gòu)中。這種方案因?yàn)樯蠈拥臄?shù)據(jù)倉(cāng)庫(kù)沒(méi)有大的改變，客戶可以繼續(xù)使用原先的算法和報(bào)表結(jié)構(gòu)，即在新的數(shù)據(jù)平臺(tái)上繼續(xù)沿用舊的應(yīng)用場(chǎng)景和分析方法。好處是由于引入了大數(shù)據(jù)技術(shù)，可以處理多種數(shù)據(jù)源，同時(shí)降低原先海量數(shù)據(jù)ETL的成本。但這種方法依然存在不少問(wèn)題：

問(wèn)題一：性能瓶頸依然存在。縱觀現(xiàn)在各類NewSQL、NoSQL方案，分布式是一個(gè)最顯著的特色。之所以大家都采用分布式架構(gòu)，就是因?yàn)閭鹘y(tǒng)的縱向擴(kuò)展方案，在處理海量數(shù)據(jù)時(shí)候性能沒(méi)法隨著數(shù)據(jù)量的增長(zhǎng)而線性擴(kuò)展，或者成本代價(jià)太高。而上圖的方案，雖然通過(guò)Hadoop解決了ETL的性能瓶頸問(wèn)題，但BI還是傳統(tǒng)的數(shù)據(jù)倉(cāng)庫(kù)，海量的ETL使得原有數(shù)據(jù)倉(cāng)庫(kù)需要處理的數(shù)據(jù)量大增，所以必須花很大代價(jià)再次升級(jí)原有的數(shù)據(jù)倉(cāng)庫(kù)，否則分析就會(huì)跑的比原先還慢。因此，用戶依然需要升級(jí)價(jià)格不菲的上層數(shù)據(jù)倉(cāng)庫(kù)，向原先效率一般的算法妥協(xié)性能。

問(wèn)題二：大數(shù)據(jù)投資被浪費(fèi)。舊的分析應(yīng)用場(chǎng)景，算法是基于關(guān)系型數(shù)據(jù)庫(kù)的。和大數(shù)據(jù)方案的邏輯模式有很大的不同，這不同主要有兩類。

沙里淘金和打磨玉石的區(qū)別。我舉過(guò)辣子雞的例子來(lái)形容Hadoop，大致是說(shuō)一盤(pán)辣子雞就是大數(shù)據(jù)，Hadoop就是辣子雞里剔除尖椒，找出能吃的雞塊的方法。其實(shí)，大數(shù)據(jù)的處理就是幫你淘金的過(guò)程。以前沒(méi)有那么合適的“篩子”，所以只能放棄在沙子里淘金的夢(mèng)想，現(xiàn)在有了合適的“篩子”，就可以去從沙灘上比較高效快速的找出那些“閃光”的東西了。而傳統(tǒng)的數(shù)據(jù)處理方式，其實(shí)已經(jīng)通過(guò)人工、半人工的方式，把很多篩撿工作做了。所以雖然丟棄了大量的數(shù)據(jù)，但是保留下的數(shù)據(jù)已經(jīng)是塊“璞玉”了，要做的只是對(duì)這塊“璞玉”再精雕細(xì)啄，使其成為價(jià)值連成的“美玉”。 所以，用傳統(tǒng)的數(shù)據(jù)處理方法來(lái)處理大數(shù)據(jù)，就是拿美工刀去宰一頭牛，即使有人幫你端盤(pán)子分部位，還沒(méi)殺死牛人就累死。

動(dòng)車組和火車的區(qū)別。分布式的大數(shù)據(jù)架構(gòu)，其核心思想和三灣改編時(shí)的核心思想是一樣的：把支部建到連隊(duì)中去。把黨的有生力量分布到各個(gè)戰(zhàn)斗單元中，大大提高中央戰(zhàn)略的貫徹執(zhí)行，提高各個(gè)戰(zhàn)斗單位的機(jī)動(dòng)性和戰(zhàn)斗力。就是動(dòng)車為什么比火車開(kāi)得快的道理：每節(jié)車廂都有動(dòng)力，雖然每節(jié)都不比火車頭強(qiáng)勁，但車廂越多就跑的越快。而火車頭再?gòu)?qiáng)勁，也有拖不動(dòng)更多車廂的時(shí)候。現(xiàn)有的分析算法，很多時(shí)候都是針對(duì)“火車頭”類型的，很多時(shí)候沒(méi)辦法拆分成很多小的運(yùn)算分布到每個(gè)節(jié)點(diǎn)上。于是，如果沿用之前的算法，那么就必須增加額外的軟件方案把已經(jīng)分布出去了的數(shù)據(jù)再“集中”起來(lái)，額外增加的環(huán)節(jié)，肯定費(fèi)時(shí)費(fèi)力，效果不可能會(huì)好。

在我看來(lái)，前面提到的傳統(tǒng)廠商解決企業(yè)大數(shù)據(jù)應(yīng)用困惑的方案不是最好的方案。什么是最好的方案呢?其實(shí)很簡(jiǎn)單，就是針對(duì)新的數(shù)據(jù)集和數(shù)據(jù)庫(kù)結(jié)構(gòu)特點(diǎn)開(kāi)發(fā)新的應(yīng)用分析場(chǎng)景，并把這些分析應(yīng)用場(chǎng)景直接跑到大數(shù)據(jù)架構(gòu)上。而不是去削足適履，拿新的NewSQL、NoSQL嫁接傳統(tǒng)方案。

這么做的好處不言而喻，關(guān)鍵是如何實(shí)現(xiàn)?這些事不能由搞IT的人來(lái)告訴業(yè)務(wù)人員，得讓業(yè)務(wù)人員來(lái)告訴我們!大數(shù)據(jù)應(yīng)用要真正在企業(yè)里生根開(kāi)花，真的需要一些數(shù)據(jù)科學(xué)家做需求生成(Demand Generation)的工作。我們要通過(guò)他們的幫助，使這張圖里的大數(shù)據(jù)路徑翻轉(zhuǎn)過(guò)來(lái)，像傳統(tǒng)數(shù)據(jù)處理一樣，由業(yè)務(wù)人員告訴我們，他們想做什么!

我接觸過(guò)很多客戶，去之前得到的需求都是：希望了解Hadoop或者內(nèi)存數(shù)據(jù)庫(kù)。但是去了之后都發(fā)覺(jué)，他們其實(shí)不知道Hadoop或者內(nèi)存數(shù)據(jù)庫(kù)可以幫他們達(dá)到哪些目的，希望我們可以告訴他們。但很坦率的說(shuō)，這個(gè)不是我們這些搞IT基礎(chǔ)架構(gòu)的人該做的事情。我們已經(jīng)“超前”的儲(chǔ)備好了這類技術(shù)手段了，怎么用這類技術(shù)真的是應(yīng)該懂業(yè)務(wù)的人去想，而不是我們了。

所以，在這里我想呼吁IT行業(yè)里，處在金字塔頂?shù)膶I(yè)咨詢師、數(shù)據(jù)分析人員、數(shù)據(jù)科學(xué)家們，現(xiàn)在是時(shí)候走出原先的框架看看新技術(shù)新架構(gòu)下有些新商機(jī)了。不要總是桎梏于傳統(tǒng)的思路和方法，讓新的大數(shù)據(jù)思想來(lái)做“削足適履”的事情了。真心希望你們可以利用專業(yè)知識(shí)和行業(yè)經(jīng)驗(yàn)，幫著那些”求大數(shù)據(jù)若渴“的行業(yè)用戶們好好定位下對(duì)他們真正有價(jià)值的新應(yīng)用場(chǎng)景，設(shè)計(jì)更多的有意義的分布式算法和機(jī)器學(xué)習(xí)模型，真正幫助他們解決大數(shù)據(jù)應(yīng)用之惑。 #p# 

困惑之二：不同的大數(shù)據(jù)方案之間有什么不一樣，我該用哪些?

首先，客戶必須把前一個(gè)問(wèn)題想清楚，明確自己要做什么事，實(shí)現(xiàn)什么功能。然后，我們就可以把這個(gè)需求分解成小的需求：

要處理幾種數(shù)據(jù)類型?

要處理多大的數(shù)據(jù)量?

要處理的多快?

這三個(gè)要求有比較明確答案之后。這張圖表以數(shù)據(jù)處理的時(shí)效性和數(shù)據(jù)量為兩個(gè)維度，把傳統(tǒng)的RDBMS和Hadoop、MPP、內(nèi)存數(shù)據(jù)庫(kù)等各類大數(shù)據(jù)方案做分類。這個(gè)分類針對(duì)的還是各種類別里比較典型的方案。現(xiàn)在實(shí)際情況，特別是MPP和Hadoop，各個(gè)發(fā)行版的特色功能都不盡相同，所以處理的場(chǎng)景也會(huì)各有不同方向的延伸。

大數(shù)據(jù)時(shí)代，一種架構(gòu)包打天下的局面是不大可能出現(xiàn)的。未來(lái)的企業(yè)大數(shù)據(jù)整體方案，肯定是多種數(shù)據(jù)庫(kù)方案結(jié)構(gòu)并存的。企業(yè)數(shù)據(jù)在各個(gè)不同方案架構(gòu)之間可以聯(lián)合互通，根據(jù)分析場(chǎng)景的不同分析工具運(yùn)作在不同的數(shù)據(jù)庫(kù)架構(gòu)上。

圖片來(lái)自 Nomura Research Institute

既然未來(lái)企業(yè)里面肯定會(huì)有多種數(shù)據(jù)源，多種數(shù)據(jù)庫(kù)結(jié)構(gòu)，那么是否可以建立一個(gè)中間的數(shù)據(jù)服務(wù)層，把應(yīng)用和底層數(shù)據(jù)庫(kù)架構(gòu)隔離開(kāi)呢?就好像你趕著上班，沒(méi)時(shí)間買(mǎi)菜，于是就寫(xiě)個(gè)菜單交給鐘點(diǎn)工，給他錢(qián)讓他幫你買(mǎi)。你不用管她到底會(huì)去路邊菜市場(chǎng)買(mǎi)還是超市買(mǎi)。這個(gè)想法看起來(lái)很美好，但我覺(jué)得在企業(yè)里實(shí)行的難度比較大，不是很現(xiàn)實(shí)。為什么這么說(shuō)?這里只是說(shuō)說(shuō)我的一些看法。

看看對(duì)大數(shù)據(jù)應(yīng)用最純熟的互聯(lián)網(wǎng)，他們的方式就是：簡(jiǎn)潔，直接。什么樣的數(shù)據(jù)，用哪種方式存儲(chǔ)效率最高，處理起來(lái)最快就用哪種方式。能直接在文件系統(tǒng)上做的就不放到數(shù)據(jù)庫(kù)里。數(shù)據(jù)的分析也是如此，結(jié)構(gòu)層次越少越好，數(shù)據(jù)訪問(wèn)越直接越好，能用編程語(yǔ)言直接解決的問(wèn)題就堅(jiān)決不采用數(shù)據(jù)倉(cāng)庫(kù)用SQL。該用SQL解決的問(wèn)題也不去為了統(tǒng)一接口而再去跑一遍Java或Python。一切以高效直接為前提，充分貫徹“把支部建到連隊(duì)里”的核心思想，發(fā)揮小快靈的優(yōu)勢(shì)。以Hadoop舉例，很多互聯(lián)網(wǎng)或者發(fā)行版都開(kāi)始嘗試放棄Map/Reduce直接對(duì)HDFS進(jìn)行操作處理，其思想就是想更直接，更簡(jiǎn)潔。所以，前面所述的“建立一個(gè)數(shù)據(jù)服務(wù)層”還是傳統(tǒng)企業(yè)的舊思路老方法，希望通過(guò)建立中間層減少開(kāi)發(fā)移植難度，其實(shí)結(jié)果就是發(fā)揮不出大數(shù)據(jù)架構(gòu)本身的性能和規(guī)模優(yōu)勢(shì)，限制住了技術(shù)架構(gòu)本身的發(fā)展空間。之所以提這個(gè)話題，主要是想引出下一個(gè)行業(yè)對(duì)于大數(shù)據(jù)的困惑。 #p# 

困惑之三：我們應(yīng)該怎樣從傳統(tǒng)的關(guān)系型數(shù)據(jù)架構(gòu)向大數(shù)據(jù)架構(gòu)遷移。

這個(gè)問(wèn)題，我覺(jué)得沒(méi)有人可以給出完美的答案，因?yàn)楝F(xiàn)在的一些新企業(yè)，比如互聯(lián)網(wǎng)，面對(duì)的就是混合數(shù)據(jù)大數(shù)據(jù)的環(huán)境，不存在遷移的問(wèn)題。而且他們要處理的數(shù)據(jù)類型，應(yīng)用場(chǎng)景也和傳統(tǒng)企業(yè)不一樣，只有一定的借鑒意義，完全復(fù)制是不明智的。傳統(tǒng)的大型企業(yè)，現(xiàn)在國(guó)外大多數(shù)的企業(yè)自己在摸著石頭過(guò)河，國(guó)內(nèi)企業(yè)剛開(kāi)個(gè)頭。其實(shí)大家都在摸索過(guò)程中，前方基本沒(méi)有指路的明燈，只有一點(diǎn)點(diǎn)星星之火可供參考。

誰(shuí)能幫你呢?我覺(jué)得還是那些搞企業(yè)咨詢的人士。至少他們可以看到很多國(guó)外類似企業(yè)的成功或者失敗案例。但前提是他們真正站在中立的立場(chǎng)幫你從新的應(yīng)用場(chǎng)景著手分析規(guī)劃。

關(guān)于這個(gè)問(wèn)題，我也分享個(gè)人的觀點(diǎn)，僅供參考。

第一步：先把大數(shù)據(jù)存起來(lái)，用起來(lái)。現(xiàn)在看過(guò)很多傳統(tǒng)企業(yè)請(qǐng)各類咨詢?nèi)耸孔龅拇髷?shù)據(jù)戰(zhàn)略規(guī)劃，我沒(méi)資格評(píng)價(jià)這些規(guī)劃的可行性和問(wèn)題所在，但我覺(jué)得對(duì)于接受新生事物，首先要做的就是先嘗個(gè)鮮，而不是知道它的未來(lái)會(huì)怎樣。如果小試牛刀的結(jié)果不好，那么調(diào)整重頭再來(lái)的成本也比較小。所以我的建議，首先找個(gè)方案，把你準(zhǔn)備分析處理的數(shù)據(jù)用新的辦法存起來(lái)，然后再試著在上面做些簡(jiǎn)單的查詢，比較之類的應(yīng)用，看看效果好不好，領(lǐng)導(dǎo)買(mǎi)不買(mǎi)單。如果效果好了，那么再試著在這上面實(shí)現(xiàn)新的業(yè)務(wù)應(yīng)用場(chǎng)景，解決一部分業(yè)務(wù)人員的某些實(shí)際需求;效果好的話再試著做第二個(gè)應(yīng)用，第三個(gè)分析。。。。。。慢慢的讓越來(lái)越多人看到這些新數(shù)據(jù)新應(yīng)用的價(jià)值。

第二步：考慮新的大數(shù)據(jù)平臺(tái)和原有數(shù)據(jù)平臺(tái)的互通，聯(lián)合問(wèn)題。這里有兩個(gè)方面：

把舊的應(yīng)用分析運(yùn)行在新的大數(shù)據(jù)平臺(tái)上。把數(shù)據(jù)從原先的RDBMS數(shù)據(jù)源抽取到新的大數(shù)據(jù)平臺(tái)上，利用新的大數(shù)據(jù)分析方法實(shí)現(xiàn)傳統(tǒng)的業(yè)務(wù)分析邏輯。這么做有可能會(huì)分析更多的數(shù)據(jù)產(chǎn)生更好的分析結(jié)果，也有可能會(huì)發(fā)現(xiàn)效率還不如原先的RDBMS方案。

把大數(shù)據(jù)平臺(tái)上的數(shù)據(jù)抽取到舊有數(shù)據(jù)倉(cāng)庫(kù)中分析展現(xiàn)。這個(gè)方向主要還是為了保證舊有用戶的SQL使用習(xí)慣，區(qū)別是抽入舊數(shù)據(jù)倉(cāng)庫(kù)的不是外部表，而是經(jīng)過(guò)清洗整理的有價(jià)值的數(shù)據(jù)。

通過(guò)這兩個(gè)方面的嘗試，基本就可以把哪些應(yīng)用可以遷移，哪些不可以遷移搞清楚了。為下一步打下扎實(shí)的基礎(chǔ)。

第三步：數(shù)據(jù)源整合，分析應(yīng)用場(chǎng)景定制。 有了前兩步的基礎(chǔ)，基本你就可以很清楚你能夠處理哪些類型的數(shù)據(jù)，以及他們會(huì)為你帶來(lái)哪些業(yè)務(wù)價(jià)值了。接下來(lái)就可以發(fā)動(dòng)“總攻”了。

總攻第一步，就是整合數(shù)據(jù)源，把將會(huì)涉及到的各類型數(shù)據(jù)分類，用各自最合適的方法儲(chǔ)存起來(lái)整理好。然后，把應(yīng)用、展現(xiàn)工具根據(jù)所涉及數(shù)據(jù)源的不同，應(yīng)用場(chǎng)景的差異，和不同的數(shù)據(jù)存儲(chǔ)架構(gòu)做耦合，定制化應(yīng)用場(chǎng)景，使每個(gè)應(yīng)用都可以充分利用到底層架構(gòu)的性能和擴(kuò)展能力。對(duì)于需要跨數(shù)據(jù)源的應(yīng)用場(chǎng)景，選定中間處理層方案，保證中間處理層方案的定制化，不會(huì)因其存在影響底層架構(gòu)的性能和上層分析應(yīng)用的實(shí)現(xiàn)。

這樣的步驟，沒(méi)辦法一下子讓企業(yè)領(lǐng)導(dǎo)看到“未來(lái)10年以后的IT架構(gòu)宏偉藍(lán)圖”，但可操作性比較強(qiáng)，而且一步不對(duì)修改調(diào)整的機(jī)會(huì)也比較大。這種思路屬于互聯(lián)網(wǎng)和新興行業(yè)那種“小步快跑”的思維模式，先走幾步看看，如果不行也有了寶貴的經(jīng)驗(yàn)教訓(xùn)，花的代價(jià)也不算很大。

大致上來(lái)說(shuō)，我所能感受到的，行業(yè)用戶對(duì)于大數(shù)據(jù)的困惑就是以上所說(shuō)的三個(gè)方面。之所以會(huì)有這些困惑，歸根結(jié)底還是因?yàn)榇髷?shù)據(jù)的處理方式和以前的傳統(tǒng)方式太不同了。

以Hadoop為代表的大數(shù)據(jù)處理體系，其實(shí)是采取了一種粗放的方式處理海量的數(shù)據(jù)，機(jī)器學(xué)習(xí)的原理很多時(shí)候也是依靠大量的樣本而不是精確的邏輯。舉個(gè)例子，我們常說(shuō)的“清明時(shí)節(jié)雨紛紛”，根本沒(méi)有邏輯和科學(xué)公式去推導(dǎo)出這個(gè)結(jié)論。之所以會(huì)有這個(gè)結(jié)論，是無(wú)數(shù)勞動(dòng)人民通過(guò)多年觀察，從“海量的”清明氣候樣本中發(fā)現(xiàn)，每到這幾天總是下雨比較多。而為什么清明這幾天會(huì)下雨，卻沒(méi)有人去仔細(xì)分析。大數(shù)據(jù)的處理方式類似，它依托前人留下的經(jīng)驗(yàn)，歷史數(shù)據(jù)，歸納總結(jié)，而不是去依賴一些復(fù)雜的公式演算。其所依仗的，就是“樣本”多，而且能夠通過(guò)技術(shù)手段快速高效的分析整理海量的樣本。而之前因?yàn)闆](méi)辦法處理這么多樣本，只能靠先進(jìn)高精尖的數(shù)學(xué)模型。所以，想用好大數(shù)據(jù)，一是要調(diào)整思路，盡量用簡(jiǎn)單的方式去處理大量的數(shù)據(jù);二是在某些情況下可能需要考慮通過(guò)多采樣等方式把數(shù)據(jù)“變大”。

所以，企業(yè)要想用好大數(shù)據(jù)，在沙海里淘金，就應(yīng)該大膽的拋棄掉原有的一套成熟的架構(gòu)和方案。從零開(kāi)始，真正的去思考這么多數(shù)據(jù)，這些個(gè)新方法對(duì)于企業(yè)能夠有什么意義，產(chǎn)生什么價(jià)值。然后，就是把想法一個(gè)個(gè)在Hadoop，MPP等等架構(gòu)上實(shí)現(xiàn)，落地，一旦發(fā)覺(jué)有問(wèn)題了就馬上調(diào)整，從頭再來(lái)。而不是先像以前那樣看看別的人都怎么做，然后做幾十頁(yè)“看上去很美“的PPT，畫(huà)一個(gè)”未來(lái)十年“的美麗的大餅了事。要多向互聯(lián)網(wǎng)和新興行業(yè)學(xué)習(xí)，改變思路，掛鉤業(yè)務(wù)，活在當(dāng)下，小步快跑。