大數據分析:找合適的瓶,釀新的酒

為什么談到大數據，傳統企業表現出更多的困惑?其原因是，企業決策者并不清楚大數據能給業務帶來哪些價值，也不知道如何學習、使用大數據分析工具。而這些大數據工具就擺在那里，誰能先一步學習使用，誰就占有先機。

算起來，接觸大數據、和互聯網之外的客戶談大數據也有快2年了。也該是時候整理下一些感受，和大家分享下我看到的國內大數據應用的一些困惑了。

云和大數據，應該是近幾年IT炒的最熱的兩個話題了。在我看來，這兩者之間的不同就是：云是做新的瓶，裝舊的酒; 大數據是找合適的瓶，釀新的酒。

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

大數據的不同在于，它其實是把以前人們丟棄不理的數據都撿起來，加以重新分析利用，使之產生新價值的技術。換句話說，原先20斤的糧食只能出2斤的 酒糟，現在20斤的糧食都變成或者大部分變成酒糟。當然這酒糟肯定會和原先的酒糟有不一樣，所以釀出來的酒肯定和以前不同，喝酒、裝酒、儲存酒的方法自然 也不同。

所以，相對于云，人們對大數據使用的困惑更大。接下來談談我所看到的幾類最多的困惑，以及我們目前存在哪些問題。

困惑之一：大數據能干什么?

換用前面飲酒來作比方，這新釀出來的酒怎么喝才可以喝得痛快。這里不再想討論到底哪些數據是大數據了。 下面這張圖是Gartner 對各行業對于大數據需求的調查，該統計針對大數據通用的3個V ， 以及未被利用數據的需求情況做了分類。 可見幾乎所有行業都對大數據有著各種各樣的需求。

圖片來自Gartner

為什么有這些需求，是因為以前這些類型的數據都因為技術和成本的原因，用戶沒有收集處理?，F在有了性價比合理的手段可以讓你收集處理這些數據，怎么 可能說不要?還是以釀酒做比喻，以前釀兩斤酒糟要浪費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就是辣子雞里剔除尖椒，找出能吃的 雞塊的方法。其實，大數據的處理就是幫你淘金的過程。以前沒有那么合適的“篩子”，所以只能放棄在沙子里淘金的夢想，現在有了合適的“篩子”，就可以去從 沙灘上比較高效快速的找出那些“閃光”的東西了。而傳統的數據處理方式，其實已經通過人工、半人工的方式，把很多篩撿工作做了。所以雖然丟棄了大量的數 據，但是保留下的數據已經是塊“璞玉”了，要做的只是對這塊“璞玉”再精雕細啄，使其成為價值連成的“美玉”。 所以，用傳統的數據處理方法來處理大數據，就是拿美工刀去宰一頭牛，即使有人幫你端盤子分部位，還沒殺死牛人就累死。

動車組和火車的區別。分布式的大數據架構，其核心思想和三灣改編時的核心思想是一樣的：把支部建到連隊中去。把黨的有生力量分布到各個戰斗單元中， 大大提高中央戰略的貫徹執行，提高各個戰斗單位的機動性和戰斗力。就是動車為什么比火車開得快的道理：每節車廂都有動力，雖然每節都不比火車頭強勁，但車 廂越多就跑的越快。而火車頭再強勁，也有拖不動更多車廂的時候?，F有的分析算法，很多時候都是針對“火車頭”類型的，很多時候沒辦法拆分成很多小的運算分 布到每個節點上。于是，如果沿用之前的算法，那么就必須增加額外的軟件方案把已經分布出去了的數據再“集中”起來，額外增加的環節，肯定費時費力，效果不 可能會好。

在我看來，前面提到的傳統廠商解決企業大數據應用困惑的方案不是最好的方案。什么是最好的方案呢?其實很簡單，就是針對新的數據集和數據庫結構特點 開發新的應用分析場景，并把這些分析應用場景直接跑到大數據架構上。而不是去削足適履，拿新的NewSQL、NoSQL嫁接傳統方案。

這么做的好處不言而喻，關鍵是如何實現?這些事不能由搞IT的人來告訴業務人員，得讓業務人員來告訴我們!大數據應用要真正在企業里生根開花，真的 需要一些數據科學家做需求生成(Demand Generation)的工作。我們要通過他們的幫助，使這張圖里的大數據路徑翻轉過來，像傳統數據處理一樣，由業務人員告訴我們，他們想做什么!

我接觸過很多客戶，去之前得到的需求都是：希望了解Hadoop或者內存數據庫。但是去了之后都發覺，他們其實不知道Hadoop或者內存數據庫可 以幫他們達到哪些目的，希望我們可以告訴他們。但很坦率的說，這個不是我們這些搞IT基礎架構的人該做的事情。我們已經“超前”的儲備好了這類技術手段 了，怎么用這類技術真的是應該懂業務的人去想，而不是我們了。

所以，在這里我想呼吁IT行業里，處在金字塔頂的專業咨詢師、數據分析人員、數據科學家們，現在是時候走出原先的框架看看新技術新架構下有些新商機 了。不要總是桎梏于傳統的思路和方法，讓新的大數據思想來做“削足適履”的事情了。真心希望你們可以利用專業知識和行業經驗，幫著那些”求大數據若渴“的 行業用戶們好好定位下對他們真正有價值的新應用場景，設計更多的有意義的分布式算法和機器學習模型，真正幫助他們解決大數據應用之惑。