為什麼談到大資料，傳統企業表現出更多的困惑?其原因是，企業決策者并不清楚大資料能給業務帶來哪些價值，也不知道如何學習、使用大資料分析工具。而這些大資料工具就擺在那裡，誰能先一步學習使用，誰就占有先機。
算起來，接觸大資料、和網際網路之外的客戶談大資料也有快2年了。也該是時候整理下一些感受，和大家分享下我看到的國内大資料應用的一些困惑了。
雲和大資料，應該是近幾年it炒的最熱的兩個話題了。在我看來，這兩者之間的不同就是：雲是做新的瓶，裝舊的酒; 大資料是找合适的瓶，釀新的酒。
雲說到底是一種基礎架構的革命。原先用實體伺服器的應用，在雲中變成以各種虛拟伺服器的形式傳遞出去，進而計算、存儲、網絡資源都能被更有效率的利用了。于是，酒量好無酒不歡的人就可以用個海碗牛飲二鍋頭;酒量小又想嘗嘗微醺小醉風情的人也可以端個小杯咂巴咂巴女兒紅。
大資料的不同在于，它其實是把以前人們丢棄不理的資料都撿起來，加以重新分析利用，使之産生新價值的技術。換句話說，原先20斤的糧食隻能出2斤的 酒糟，現在20斤的糧食都變成或者大部分變成酒糟。當然這酒糟肯定會和原先的酒糟有不一樣，是以釀出來的酒肯定和以前不同，喝酒、裝酒、儲存酒的方法自然 也不同。
是以，相對于雲，人們對大資料使用的困惑更大。接下來談談我所看到的幾類最多的困惑，以及我們目前存在哪些問題。
困惑之一：大資料能幹什麼?
換用前面飲酒來作比方，這新釀出來的酒怎麼喝才可以喝得痛快。這裡不再想讨論到底哪些資料是大資料了。 下面這張圖是gartner 對各行業對于大資料需求的調查，該統計針對大資料通用的3個v ， 以及未被利用資料的需求情況做了分類。 可見幾乎所有行業都對大資料有着各種各樣的需求。
圖檔來自gartner
為什麼有這些需求，是因為以前這些類型的資料都因為技術和成本的原因，使用者沒有收集處理。現在有了成本效益合理的手段可以讓你收集處理這些資料，怎麼 可能說不要?還是以釀酒做比喻，以前釀兩斤酒糟要浪費18斤的糧食，現在至少20斤糧食可以有10斤都變成酒糟了，雖然這些酒糟可能和以前不大一樣，但至 少可以少浪費8斤糧食呢。
現在問題來了，酒糟多了，種類不一樣了,怎麼根據新的酒糟釀酒呢?對不起，這個問題酒作坊就要别人來教了。但問題是，所有酒坊現在可能都面臨這同一 個問題，于是就沒人可以教你了，隻能自己慢慢摸索。這個就是現在各行業面對大資料的最大困惑 — 海量的資料收集上來不知道怎麼用。
這裡不妨看看為什麼傳統的資料倉庫領域沒有這樣的困惑。如下這張圖很好的說明了傳統和現在的差別：
圖檔來自sogeti
從上圖展示的流程可以看出産生困惑的根本原因是：苦逼的it從業人員走在了業務決策者的前面 (流淚) 。傳統時代，都是業務人員希望得到某類型的統計報表或者分析預測，于是it行業人員為了滿足他們的需求找方案、寫算法，進而催生出了各種類型的資料倉庫和 解決方案。而現在，在網際網路的推動下，it人員發覺原來我們可以通過一些新的方式存儲海量的原先無法處理的資料，但業務人員卻沒有準備好。是以，當你告訴 他們：“嘿，哥們兒，我這裡現在又有了很多資料可以幫你了。”他們一頭霧水不知道這些資料對他們有什麼用了。
怎麼解決這個問題?先來看傳統廠商oracle、ibm他們是怎麼做的。方式細節略有不同，但他們的思路基本如下：
圖檔來自hp首席技術專家 greg battas在abds2012大會上的 分享
簡單來說，這種處理方式是把hadoop和其它各類newsql、nosql方案以etl，或外部表的方式引入現有的資料分析解決方案架構中。這種 方案因為上層的資料倉庫沒有大的改變，客戶可以繼續使用原先的算法和報表結構，即在新的資料平台上繼續沿用舊的應用場景和分析方法。好處是由于引入了大數 據技術，可以處理多種資料源，同時降低原先海量資料etl的成本。但這種方法依然存在不少問題：
問題一：性能瓶頸依然存在。
縱觀現在各類newsql、nosql方案，分布式是一個最顯著的特色。之是以大家 都采用分布式架構，就是因為傳統的縱向擴充方案，在處理海量資料時候性能沒法随着資料量的增長而線性擴充，或者成本代價太高。而上圖的方案，雖然通過 hadoop解決了etl的性能瓶頸問題，但bi還是傳統的資料倉庫，海量的etl使得原有資料倉庫需要處理的資料量大增，是以必須花很大代價再次更新原 有的資料倉庫，否則分析就會跑的比原先還慢。是以，使用者依然需要更新價格不菲的上層資料倉庫，向原先效率一般的算法妥協性能。
問題二：大資料投資被浪費。
舊的分析應用場景，算法是基于關系型資料庫的。和大資料方案的邏輯模式有很大的不同，這不同主要有兩類。
沙裡淘金和打磨玉石的差別。我舉過辣子雞的例子來形容hadoop，大緻是說一盤辣子雞就是大資料，hadoop就是辣子雞裡剔除尖椒，找出能吃的 雞塊的方法。其實，大資料的處理就是幫你淘金的過程。以前沒有那麼合适的“篩子”，是以隻能放棄在沙子裡淘金的夢想，現在有了合适的“篩子”，就可以去從 沙灘上比較高效快速的找出那些“閃光”的東西了。而傳統的資料處理方式，其實已經通過人工、半人工的方式，把很多篩撿工作做了。是以雖然丢棄了大量的數 據，但是保留下的資料已經是塊“璞玉”了，要做的隻是對這塊“璞玉”再精雕細啄，使其成為價值連成的“美玉”。 是以，用傳統的資料處理方法來處理大資料，就是拿美工刀去宰一頭牛，即使有人幫你端盤子分部位，還沒殺死牛人就累死。
動車組和火車的差別。分布式的大資料架構，其核心思想和三灣改編時的核心思想是一樣的：把支部建到連隊中去。把黨的有生力量分布到各個戰鬥單元中， 大大提高中央戰略的貫徹執行，提高各個戰鬥機關的機動性和戰鬥力。就是動車為什麼比火車開得快的道理：每節車廂都有動力，雖然每節都不比火車頭強勁，但車 廂越多就跑的越快。而火車頭再強勁，也有拖不動更多車廂的時候。現有的分析算法，很多時候都是針對“火車頭”類型的，很多時候沒辦法拆分成很多小的運算分 布到每個節點上。于是，如果沿用之前的算法，那麼就必須增加額外的軟體方案把已經分布出去了的資料再“集中”起來，額外增加的環節，肯定費時費力，效果不 可能會好。
在我看來，前面提到的傳統廠商解決企業大資料應用困惑的方案不是最好的方案。什麼是最好的方案呢?其實很簡單，就是針對新的資料集和資料庫結構特點 開發新的應用分析場景，并把這些分析應用場景直接跑到大資料架構上。而不是去削足适履，拿新的newsql、nosql嫁接傳統方案。
這麼做的好處不言而喻，關鍵是如何實作?這些事不能由搞it的人來告訴業務人員，得讓業務人員來告訴我們!大資料應用要真正在企業裡生根開花，真的 需要一些資料科學家做需求生成(demand generation)的工作。我們要通過他們的幫助，使這張圖裡的大資料路徑翻轉過來，像傳統資料處理一樣，由業務人員告訴我們，他們想做什麼!
我接觸過很多客戶，去之前得到的需求都是：希望了解hadoop或者記憶體資料庫。但是去了之後都發覺，他們其實不知道hadoop或者記憶體資料庫可 以幫他們達到哪些目的，希望我們可以告訴他們。但很坦率的說，這個不是我們這些搞it基礎架構的人該做的事情。我們已經“超前”的儲備好了這類技術手段 了，怎麼用這類技術真的是應該懂業務的人去想，而不是我們了。
是以，在這裡我想呼籲it行業裡，處在金字塔頂的專業咨詢師、資料分析人員、資料科學家們，現在是時候走出原先的架構看看新技術新架構下有些新商機 了。不要總是桎梏于傳統的思路和方法，讓新的大資料思想來做“削足适履”的事情了。真心希望你們可以利用專業知識和行業經驗，幫着那些”求大資料若渴“的 行業使用者們好好定位下對他們真正有價值的新應用場景，設計更多的有意義的分布式算法和機器學習模型，真正幫助他們解決大資料應用之惑。
困惑之二：不同的大資料方案之間有什麼不一樣，我該用哪些?
首先，客戶必須把前一個問題想清楚，明确自己要做什麼事，實作什麼功能。然後，我們就可以把這個需求分解成小的需求：
要處理幾種資料類型?
要處理多大的資料量?
要處理的多快?
這三個要求有比較明确答案之後。這張圖表以資料處理的時效性和資料量為兩個次元，把傳統的rdbms和hadoop、mpp、記憶體資料庫等各類大數 據方案做分類。這個分類針對的還是各種類别裡比較典型的方案。現在實際情況，特别是mpp和hadoop，各個發行版的特色功能都不盡相同，是以處理的場 景也會各有不同方向的延伸。
大資料時代，一種架構包打天下的局面是不大可能出現的。未來的企業大資料整體方案，肯定是多種資料庫方案結構并存的。企業資料在各個不同方案架構之間可以聯合互通，根據分析場景的不同分析工具運作在不同的資料庫架構上。
圖檔來自 nomura research institute
既然未來企業裡面肯定會有多種資料源，多種資料庫結構，那麼是否可以建立一個中間的資料服務層，把應用和底層資料庫架構隔離開呢?就好像你趕着上 班，沒時間買菜，于是就寫個菜單交給鐘點工，給他錢讓他幫你買。你不用管她到底會去路邊菜市場買還是超市買。這個想法看起來很美好，但我覺得在企業裡實行 的難度比較大，不是很現實。為什麼這麼說?這裡隻是說說我的一些看法。
看看對大資料應用最純熟的網際網路，他們的方式就是：簡潔，直接。什麼樣的資料，用哪種方式存儲效率最高，處理起來最快就用哪種方式。能直接在檔案系 統上做的就不放到資料庫裡。資料的分析也是如此，結構層次越少越好，資料通路越直接越好，能用程式設計語言直接解決的問題就堅決不采用資料倉庫用sql。該用 sql解決的問題也不去為了統一接口而再去跑一遍java或python。一切以高效直接為前提，充分貫徹“把支部建到連隊裡”的核心思想，發揮小快靈的 優勢。以hadoop舉例，很多網際網路或者發行版都開始嘗試放棄map/reduce直接對hdfs進行操作處理，其思想就是想更直接，更簡潔。是以，前 面所述的“建立一個資料服務層”還是傳統企業的舊思路老方法，希望通過建立中間層減少開發移植難度，其實結果就是發揮不出大資料架構本身的性能和規模優 勢，限制住了技術架構本身的發展空間。之是以提這個話題，主要是想引出下一個行業對于大資料的困惑。
困惑之三：我們應該怎樣從傳統的關系型資料架構向大資料架構遷移。
這個問題，我覺得沒有人可以給出完美的答案，因為現在的一些新企業，比如網際網路，面對的就是混合資料大資料的環境，不存在遷移的問題。而且他們要處 理的資料類型，應用場景也和傳統企業不一樣，隻有一定的借鑒意義，完全複制是不明智的。傳統的大型企業，現在國外大多數的企業自己在摸着石頭過河，國内企 業剛開個頭。其實大家都在摸索過程中，前方基本沒有指路的明燈，隻有一點點星星之火可供參考。
誰能幫你呢?我覺得還是那些搞企業咨詢的人士。至少他們可以看到很多國外類似企業的成功或者失敗案例。但前提是他們真正站在中立的立場幫你從新的應用場景着手分析規劃。
關于這個問題，我也分享個人的觀點，僅供參考。
第一步：先把大資料存起來，用起來。
現在看過很多傳統企業請各類咨詢人士做的大資料戰略規劃，我沒資格評價這些 規劃的可行性和問題所在，但我覺得對于接受新生事物，首先要做的就是先嘗個鮮，而不是知道它的未來會怎樣。如果小試牛刀的結果不好，那麼調整重頭再來的成 本也比較小。是以我的建議，首先找個方案，把你準備分析處理的資料用新的辦法存起來，然後再試着在上面做些簡單的查詢，比較之類的應用，看看效果好不好， 上司買不買單。如果效果好了，那麼再試着在這上面實作新的業務應用場景，解決一部分業務人員的某些實際需求;效果好的話再試着做第二個應用，第三個分 析。。。。。。慢慢的讓越來越多人看到這些新資料新應用的價值。
第二步：考慮新的大資料平台和原有資料平台的互通，聯合問題。
這裡有兩個方面：把舊的應用分析運作在新的大資料平台上。把資料從原先的rdbms資料源抽取到新的大資料平台上，利用新的大資料分析方法實作傳統的業務分析邏輯。這麼做有可能會分析更多的資料産生更好的分析結果，也有可能會發現效率還不如原先的rdbms方案。
把大資料平台上的資料抽取到舊有資料倉庫中分析展現。這個方向主要還是為了保證舊有使用者的sql使用習慣，差別是抽入舊資料倉庫的不是外部表，而是經過清洗整理的有價值的資料。
通過這兩個方面的嘗試，基本就可以把哪些應用可以遷移，哪些不可以遷移搞清楚了。為下一步打下紮實的基礎。
第三步：資料源整合，分析應用場景定制。
有了前兩步的基礎，基本你就可以很清楚你能夠處理哪些類型的資料，以及他們會為你帶來哪些業務價值了。接下來就可以發動“總攻”了。
總攻第一步，就是整合資料源，把将會涉及到的各類型資料分類，用各自最合适的方法儲存起來整理好。然後，把應用、展現工具根據所涉及資料源的不同， 應用場景的差異，和不同的資料存儲架構做耦合，定制化應用場景，使每個應用都可以充分利用到底層架構的性能和擴充能力。對于需要跨資料源的應用場景，標明 中間處理層方案，保證中間處理層方案的定制化，不會因其存在影響底層架構的性能和上層分析應用的實作。
這樣的步驟，沒辦法一下子讓企業上司看到“未來10年以後的it架構宏偉藍圖”，但可操作性比較強，而且一步不對修改調整的機會也比較大。這種思路屬于網際網路和新興行業那種“小步快跑”的思維模式，先走幾步看看，如果不行也有了寶貴的經驗教訓，花的代價也不算很大。
大緻上來說，我所能感受到的，行業使用者對于大資料的困惑就是以上所說的三個方面。之是以會有這些困惑，歸根結底還是因為大資料的處理方式和以前的傳統方式太不同了。
以hadoop為代表的大資料處理體系，其實是采取了一種粗放的方式處理海量的資料，機器學習的原理很多時候也是依靠大量的樣本而不是精确的邏輯。 舉個例子，我們常說的“清明時節雨紛紛”，根本沒有邏輯和科學公式去推導出這個結論。之是以會有這個結論，是無數勞動人民通過多年觀察，從“海量的”清明 氣候樣本中發現，每到這幾天總是下雨比較多。而為什麼清明這幾天會下雨，卻沒有人去仔細分析。大資料的處理方式類似，它依托前人留下的經驗，曆史資料，歸 納總結，而不是去依賴一些複雜的公式演算。其所依仗的，就是“樣本”多，而且能夠通過技術手段快速高效的分析整理海量的樣本。而之前因為沒辦法處理這麼多 樣本，隻能靠先進高精尖的數學模型。是以，想用好大資料，一是要調整思路，盡量用簡單的方式去處理大量的資料;二是在某些情況下可能需要考慮通過多采樣等 方式把資料“變大”。
是以，企業要想用好大資料，在沙海裡淘金，就應該大膽的抛棄掉原有的一套成熟的架構和方案。從零開始，真正的去思考這麼多資料，這些個新方法對于企 業能夠有什麼意義，産生什麼價值。然後，就是把想法一個個在hadoop，mpp等等架構上實作，落地，一旦發覺有問題了就馬上調整，從頭再來。而不是先 像以前那樣看看别的人都怎麼做，然後做幾十頁“看上去很美“的ppt，畫一個”未來十年“的美麗的大餅了事。要多向網際網路和新興行業學習，改變思路，挂鈎 業務，活在當下，小步快跑。
<b>原文釋出時間為：2013-09-22</b>
<b></b>
<b>本文來自雲栖社群合作夥伴“大資料文摘”，了解相關資訊可以關注“bigdatadigest”微信公衆号</b>