文章講的是大資料概念潮來勢凶猛 你被忽悠了嗎，
近年國內大資料概念被炒得愈發火熱，相關的產品廠商也如雨後春筍般應運而生，大資料服務市場迎來爆發期。然而，很多大資料服務仍然處於「玩概念」的階段，大資料只被當做噱頭，並沒有發揮其實質作用，還有許多使用者購買了產品才發現自己被忽悠了。這種現狀下，大資料不免被扣上「華而不實」、「炒作為生」的帽子，那麼我們應該如何正確看待大資料?
大資料概念
大資料只是乙個名詞，並不是資料量大就一定是大資料，假設單機器處理能力10g，那麼大於10g就是大資料。網友heguangwu認為，大資料的核心是value，哪怕用excel分析也可以。當前的趨勢是資料儲存和分析代價越來越小，所以能儲存的資料的廣度和分析的深度都在擴大。以前出於成本考慮，不在儲存分析範圍內的資料，現在也開始作為乙個參考的維度了。對企業而言，如何從更多的資料集分析出更有價值的東西才是他們所關心，即使是小企業有的也開始考慮(做大資料方面的投入)。
網友chenxing2從事sql相關工作，其公司不久前做了乙個erp，增加功能包括貢獻度、銷售構成、abc分析、凍銷分析、商品趨勢、銷售速度、業績趨勢等等，而在客戶使用他們研發的這套軟體之前，一直使用excel做分析。那麼他們現在做的這些是否也算是大資料處理?chenxing2表示：「個人認為，怎麼得用個聚類、推薦、語言識別、特徵識別、樸素貝葉斯演算法與交叉驗證等之類的才夠檔次。現在大資料的一些開發方式及開源框架，就目前很多公司的那點資料量根本用不上，現在單庫解決了，資料量再大，可以後期分表分庫、讀寫分離解決。當資料量再大時，才考慮大資料的框架。所以，現在用了也是大炮打蚊子，起不到作用，搞不好還不如傳統手段來的高效。目前能用上個nosql資料庫感覺都是超前一點的了。」
對於chenxing2的看法，網友heguangwu解釋道：「表面上看，企業所用的傳統方式已經很好的解決問題，但公司資料終究會越來越多，而且要求分析結果會越來越快，到最後慢慢會應用到大資料的一些技術。現在即使很多大公司也不是馬上全盤採用當前的所有大資料技術，也是乙個逐步替代和使用的過程。」
其實，資料一直存在且量未必小，只不過以前缺乏挖掘資料和將其產生聯絡的思維，以及分析資料的能力。在資訊**時代中，隨著技術和硬體裝置的增強，海量資料的價值被有意識的挖掘，大資料概念也慢慢被認可，明確「資料資源也是資產」這個觀點。
並不是所有的資料都具備挖掘價值，資料有足夠細的顆粒度、豐富的維度、活性以及相互關聯，只有這樣的大資料，才是可以對各種行為進行數位化描述，從而歸納出資訊的。除了資料，技術也是大資料探勘必不可少的一環，當資料規模達到甚至遠超pb級別，當資料開始位於不同資料庫，甚至不同平台上，當資料以各種不同的形式出現，如何尋找有用的資訊?這一切都引發了如今「面向大資料」的技術變革。而這以上的內容均是為了最終的商用做準備。
大資料處理相關技術
大資料技術種類繁多，近年誕生的新技術也有不少，sigmod、vldb、hadoop submit、spark submit等等，那麼，網友們是如何看待大資料技術的呢?
網友chenxing2說道：「關於大資料分析，從最開始的hadoop及hadoop的map reduce的問題發展到spark、samza、apache s4、storm等大行其道，而後storm的一些問題又衍生出了jstorm和twiter heron。es(elasticsearch是基於lucene的搜尋伺服器，提供乙個分布式多使用者能力的全文搜尋引擎)雖然能夠與hadoop結合使用，但一般推薦solr + haddop結合。」
網友laputa73從自身應用經驗中總結得到，voltdb的社群版只能玩玩，持久化，集群，ha特性都沒有。influxdb還不成熟，集群方案尚不可用。
網友heguangwu說：「時序資料庫方面開源方案不多，opentsdb也只是在hbase上套乙個schema來做的，效能只能說是一般了。這方面感覺開源的關注度不夠，無太多的產品。」
實際應用案例
網友laputa73講述了其在應對自身大資料處理的兩種需求時所遇到的困難：「我們的需求一類以插入為主，例如每天500g的日誌分析和查詢，目前使用es處理，把它當tsdb用。遇到關於es部署使用相關的問題，引數調整，索引規劃等，但感覺es的寫入效能沒有想象中高。es做乙個大集群，和分開幾個集群，寫入效能是否有不同?另一類需求以更新為主，每天1億次更新，但總記錄數在500w左右，這項工作以前用oracle，後來換成了redis，可感覺不太好用。redis的主要問題是它是乙個kv型的而非文件型，不能使用主鍵之外的查詢，這就需要自己維護多個表，這樣相當於降低了效能。」
網友heguangwu表示，對於第一類需求，es在這種資料量下應該是沒有問題的，es在記憶體中維護了乙個反轉索引表，所以能保證速度，相當於資料庫的記憶體索引。對於第二類需求，替代方案可以嘗試hbase(效能最低)/cassandra/巨杉(效能應該最高)之類的解決方案，插入速度應該可以，查詢就要取決於具體的查詢方式了。redis確實只支援主鍵查詢，這類可以試試voltdb，或許能滿足你的需求，其也是記憶體資料庫效能高，但好像只能用儲存過程。記憶體資料庫這塊大多是商用方案比較多，開源的大多是kv型儲存，而不是資料庫。
大資料概念
在網際網路技術發展到現今階段，大量日常 工作等事務產生的資料都已經資訊化，人類產生的資料量相比以前有了 式的增長，以前的傳統的資料處理技術已經無法勝任，需求催生技術，一套用來處理海量資料的軟體工具應運而生，這就是大資料！換個角度說，大資料是 1 有海量的資料 2 有對海量資料進行挖掘的需求 3 有對...
大資料概念
1.列舉hadoop生態的各個元件及其功能 以及各個元件之間的相互關係，以圖呈現並加以文字描述。hdfs hadoop distributed file system 基於google發布的gfs 設計開發，執行在通用硬體上的分布式檔案系統。除具備其它分布式檔案系統相同特性外，還有自己的特性 高容錯...
大資料 基礎概念
hadoop 分布式系統基礎架構 入門學習資料 spark 基於記憶體的計算框架 spark streaming sparksql spark的重要組成部分 hbase 可伸縮，面向列的分布式雲儲存系統 hive 建立在hadoop上的資料倉儲基礎架構。hive定義了簡單的類sql查詢語言，允許使用...