近年國內(nèi)大數(shù)據(jù)概念被炒得愈發(fā)火熱，相關(guān)的產(chǎn)品廠商也如雨后春筍般應運而生，大數(shù)據(jù)服務(wù)市場迎來爆發(fā)期。然而，很多大數(shù)據(jù)服務(wù)仍然處于“玩概念”的階段，大數(shù)據(jù)只被當做噱頭，并沒有發(fā)揮其實質(zhì)作用，還有許多用戶購買了產(chǎn)品才發(fā)現(xiàn)自己被忽悠了。這種現(xiàn)狀下，大數(shù)據(jù)不免被扣上“華而不實”、“炒作為生”的帽子，那么我們應該如何正確看待大數(shù)據(jù)?

大數(shù)據(jù)概念

大數(shù)據(jù)只是一個名詞，并不是數(shù)據(jù)量大就一定是大數(shù)據(jù)，假設(shè)單機器處理能力10G，那么大于10G就是大數(shù)據(jù)。網(wǎng)友heguangwu認為，大數(shù)據(jù)的核心是Value，哪怕用excel分析也可以。當前的趨勢是數(shù)據(jù)存儲和分析代價越來越小，所以能保存的數(shù)據(jù)的廣度和分析的深度都在擴大。以前出于成本考慮，不在保存分析范圍內(nèi)的數(shù)據(jù)，現(xiàn)在也開始作為一個參考的維度了。對企業(yè)而言，如何從更多的數(shù)據(jù)集分析出更有價值的東西才是他們所關(guān)心，即使是小企業(yè)有的也開始考慮(做大數(shù)據(jù)方面的投入)。

網(wǎng)友chenxing2從事SQL相關(guān)工作，其公司不久前做了一個ERP，增加功能包括貢獻度、銷售構(gòu)成、ABC分析、凍銷分析、商品趨勢、銷售速度、業(yè)績趨勢等等，而在客戶使用他們研發(fā)的這套軟件之前，一直使用excel做分析。那么他們現(xiàn)在做的這些是否也算是大數(shù)據(jù)處理?chenxing2表示：“個人認為，怎么得用個聚類、推薦、語言識別、特征識別、樸素貝葉斯算法與交叉驗證等之類的才夠檔次?，F(xiàn)在大數(shù)據(jù)的一些開發(fā)方式及開源框架，就目前很多公司的那點數(shù)據(jù)量根本用不上，現(xiàn)在單庫解決了，數(shù)據(jù)量再大，可以后期分表分庫、讀寫分離解決。當數(shù)據(jù)量再大時，才考慮大數(shù)據(jù)的框架。所以，現(xiàn)在用了也是大炮打蚊子，起不到作用，搞不好還不如傳統(tǒng)手段來的高效。目前能用上個nosql數(shù)據(jù)庫感覺都是超前一點的了。”

對于chenxing2的看法，網(wǎng)友heguangwu解釋道：“表面上看，企業(yè)所用的傳統(tǒng)方式已經(jīng)很好的解決問題，但公司數(shù)據(jù)終究會越來越多，而且要求分析結(jié)果會越來越快，到最后慢慢會應用到大數(shù)據(jù)的一些技術(shù)。現(xiàn)在即使很多大公司也不是馬上全盤采用當前的所有大數(shù)據(jù)技術(shù)，也是一個逐步替代和使用的過程。”

其實，數(shù)據(jù)一直存在且量未必小，只不過以前缺乏挖掘數(shù)據(jù)和將其產(chǎn)生聯(lián)系的思維，以及分析數(shù)據(jù)的能力。在信息爆炸時代中，隨著技術(shù)和硬件設(shè)備的增強，海量數(shù)據(jù)的價值被有意識的挖掘，大數(shù)據(jù)概念也慢慢被認可，明確“數(shù)據(jù)資源也是資產(chǎn)”這個觀點。

并不是所有的數(shù)據(jù)都具備挖掘價值，數(shù)據(jù)有足夠細的顆粒度、豐富的維度、活性以及相互關(guān)聯(lián)，只有這樣的大數(shù)據(jù)，才是可以對各種行為進行數(shù)字化描述，從而歸納出信息的。除了數(shù)據(jù)，技術(shù)也是大數(shù)據(jù)挖掘必不可少的一環(huán)，當數(shù)據(jù)規(guī)模達到甚至遠超PB級別，當數(shù)據(jù)開始位于不同數(shù)據(jù)庫，甚至不同平臺上，當數(shù)據(jù)以各種不同的形式出現(xiàn)，如何尋找有用的信息?這一切都引發(fā)了如今“面向大數(shù)據(jù)”的技術(shù)變革。而這以上的內(nèi)容均是為了最終的商用做準備。

大數(shù)據(jù)處理相關(guān)技術(shù)

大數(shù)據(jù)技術(shù)種類繁多，近年誕生的新技術(shù)也有不少，SIGMOD、VLDB、Hadoop submit、spark submit等等，那么，網(wǎng)友們是如何看待大數(shù)據(jù)技術(shù)的呢?

網(wǎng)友chenxing2說道：“關(guān)于大數(shù)據(jù)分析，從最開始的Hadoop及Hadoop的map reduce的問題發(fā)展到Spark、Samza、Apache S4、storm等大行其道，而后storm的一些問題又衍生出了JStorm和Twiter Heron。ES(ElasticSearch是基于Lucene的搜索服務(wù)器，提供一個分布式多用戶能力的全文搜索引擎)雖然能夠與Hadoop結(jié)合使用，但一般推薦solr + haddop結(jié)合。”

網(wǎng)友laputa73從自身應用經(jīng)驗中總結(jié)得到，voltdb的社區(qū)版只能玩玩，持久化，集群，HA特性都沒有。influxdb還不成熟，集群方案尚不可用。

網(wǎng)友heguangwu說：“時序數(shù)據(jù)庫方面開源方案不多，OpenTSDB也只是在HBase上套一個schema來做的，性能只能說是一般了。這方面感覺開源的關(guān)注度不夠，無太多的產(chǎn)品。”

實際應用案例

網(wǎng)友laputa73講述了其在應對自身大數(shù)據(jù)處理的兩種需求時所遇到的困難：“我們的需求一類以插入為主，例如每天500G的日志分析和查詢，目前使用ES處理，把它當TSDB用。遇到關(guān)于ES部署使用相關(guān)的問題，參數(shù)調(diào)整，索引規(guī)劃等，但感覺ES的寫入性能沒有想象中高。ES做一個大集群，和分開幾個集群，寫入性能是否有不同?另一類需求以更新為主，每天1億次更新，但總記錄數(shù)在500w左右，這項工作以前用Oracle，后來換成了Redis，可感覺不太好用。Redis的主要問題是它是一個KV型的而非文檔型，不能使用主鍵之外的查詢，這就需要自己維護多個表，這樣相當于降低了性能。”

網(wǎng)友heguangwu表示，對于第一類需求，ES在這種數(shù)據(jù)量下應該是沒有問題的，ES在內(nèi)存中維護了一個反轉(zhuǎn)索引表，所以能保證速度，相當于數(shù)據(jù)庫的內(nèi)存索引。對于第二類需求，替代方案可以嘗試HBase(性能最低)/Cassandra/巨杉(性能應該最高)之類的解決方案，插入速度應該可以，查詢就要取決于具體的查詢方式了。Redis確實只支持主鍵查詢，這類可以試試voltdb，或許能滿足你的需求，其也是內(nèi)存數(shù)據(jù)庫性能高，但好像只能用存儲過程。內(nèi)存數(shù)據(jù)庫這塊大多是商用方案比較多，開源的大多是KV型存儲，而不是數(shù)據(jù)庫。

目前大數(shù)據(jù)處理廠商基本能夠分為三類。首先是具有收集大量數(shù)據(jù)的能力的公司，其次是具備數(shù)據(jù)分析技能的公司，最后是基于思維的，對數(shù)據(jù)挖掘新價值有想法的公司。我們現(xiàn)在處于一個數(shù)據(jù)過量而技能稀缺的時代，資訊的價值就是資訊本身而不是資訊的來源，而大數(shù)據(jù)最值錢的部分就是它自身。即便我們處理數(shù)據(jù)量不是很大，也并不妨礙我們?nèi)ジ嗟娜リP(guān)注數(shù)據(jù)本身的價值。以上觀點均出自IT168旗下chinaunix論壇的一則討論帖中，網(wǎng)友們分享了自己對大數(shù)據(jù)方面的認知及處理經(jīng)驗。小編將話題內(nèi)容篩選整理成文。還對大數(shù)據(jù)概念和技術(shù)等云里霧里的小伙伴們，不妨一看。

原帖地址：http://bbs.chinaunix.net/thread-4185247-1-1.html