大資料之惑

來源:互聯網
上載者:User
關鍵字 大資料 大資料 可以 大資料 可以 他們 大資料 可以 他們 傳統 大資料 可以 他們 傳統 現在
為什麼談到大資料,傳統企業表現出更多的困惑? 其原因是,企業決策者並不清楚大資料能給業務帶來哪些價值,也不知道如何學習、使用大資料分析工具。 而這些大資料工具就擺在那裡,誰能先一步學習使用,誰就佔有先機。

算起來,接觸大資料、和互聯網之外的客戶談大資料也有快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行業裡,處在金字塔頂的專業諮詢師、資料分析人員、資料科學家們,現在是時候走出原先的框架看看新技術新架構下有些新商機了。 不要總是桎梏于傳統的思路和方法,讓新的大資料思想來做「削足適履」的事情了。 真心希望你們可以利用專業知識和行業經驗,幫著那些」求大資料若渴「的行業使用者們好好定位下對他們真正有價值的新應用場景,設計更多的有意義的分散式演算法和機器學習模型,真正説明他們解決大資料應用之惑。

(責任編輯:fumingli)

相關文章

聯繫我們

該頁面正文內容均來源於網絡整理,並不代表阿里雲官方的觀點,該頁面所提到的產品和服務也與阿里云無關,如果該頁面內容對您造成了困擾,歡迎寫郵件給我們,收到郵件我們將在5個工作日內處理。

如果您發現本社區中有涉嫌抄襲的內容,歡迎發送郵件至: info-contact@alibabacloud.com 進行舉報並提供相關證據,工作人員會在 5 個工作天內聯絡您,一經查實,本站將立刻刪除涉嫌侵權內容。

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.