達到多大規模的資料，才值得用大資料的方式來處理？

1樓：Intoae

這個問題我認真思考過。

資料本來作用不大，無論多少。但有了應用場景和目標，資料不管多少都有了很大作用。

這些原因就是人為干擾太大和自然資料質量方便完全不一樣，應用結果也是很大差別。

再如極小級別的線下門店客流資料統計，這個資料雖然不多，但作用不小。可以知道老客戶，新客戶，知道區域興趣度，知道最終轉化率，也能用於再召回營銷。如58數雲WIFI探針對線下客流統計就是如此。

2樓：圓胖腫

大資料的本質並不是大，而是亂

真正大資料的各種技術，區別於現有亂七八糟技術的主要點在於其資料結構的不規則上

如果都是規則資料，多大都沒有太大問題，o(lgn)複雜度的威力足夠應付

但是一旦資料結構變得不規則，那麼複雜度瞬間就會變成o(n)甚至o(n^2)，如果不做任何處理的話

你想想傳統資料庫中like的有多慢吧，但是傳統資料庫中的資料量並不小

map reduce只是將操作並行了而已，真正核心是演算法的改變，從o(n)又恢復到了n(lgn)

所以你用hadoop這些本質上是在改變演算法和結構，而不是資料量有多大

其實小資料一樣可以用這些大資料技術的，vert.x乙個最基本的file system就可以用上不是？

另外我很不贊同傳統動不動就上資料庫的搞法，實際工作中，大部分資料都是辣雞資料

尤其是web應用，大部分都是辣雞資料，精度要求哪有那麼高

完全可以犧牲一定精度以提公升客戶體驗

這個時候用db徒增io，嚴重影響客戶體驗

完全可以用big data技術予以處理，上sql engine，顯然是牛刀剁小雞

3樓：Lida Li

當使用大資料系統所帶來的好處大於那些為並行處理所付出的各種成本，例如取資料儲存，分片，通訊，集群管理。通常至少要幾十，上百TB

4樓：周陽

單機跑不動的時候，比如每天需要產出新的資料，單機產出一次要8小時，那麼意味著乙個意外中斷，就可能導致今天的資料明天才產出。

5樓：

看規模，看資料內容，看需求。單純的日誌，上PB不算大資料，只能說大量的資料。

通常說的大資料，大量的資料是前提，分析挖掘才是根本。

6樓：嘉慧Lincoln

建議在處理非結構化資料，or硬體裝置無法支援當前資料量時再上。

那些上分布式系統的公司，很少是因為資料量過於龐大，有些是因為沒錢買小型機和資料庫，有些是因為資料安全響應國家號召，有些純粹就是跟風騙投資人。不管怎樣，Hadoop確實沒有SQL查詢指令碼好用，需要耗費大量的人力資源進行維護。

7樓：

我工作中使用的資料表，達到TB很常見。

計算方面，資料量要達到多少才應該上分布式，沒法答，這不可能有一致的標準。這個要從業務上看，比如乙個T+1的推薦資料，半夜開始跑，最起碼第二天中午之前要產出吧，不然你這個資料打算T+2用？哈哈。

就是看你的業務對時間要求。

當然也可以從別的角度來看。比如研發階段，如果即使抽30%的資料出來做研發過程中的各種基本驗證每次還要跑幾個小時，那這個研發效率就太低了嘛。一般的嘗試和實驗最好能在半小時內跑完吧，這是我個人的感受，不然工作很不好安排計畫。

儲存方面，就更硬性一些了，如果一張表就幾個TB，不用分布式儲存就真的很不好弄了。

8樓：happy

我覺得這個問題沒有乙個具體答案。光從資料規模方面來說，當達到PB，TB級別時，才被稱為大資料。

hadoop主要是用來對海量資料進行儲存和全量分析的。它本身是乙個分布式系統，核心由分布式檔案系統hdfs，和分布式計算框架mapreduce組成，在儲存和計算時能夠發揮出集群中每台機器的能力。

所以，當單機檔案系統沒法儲存，或者傳統資料處理方式（例如資料庫、shell指令碼等）顯得緩慢、沒法忍受時，就可以考慮大資料方面的一些處理方案（例如nosql、hadoop、stormde）。

當然，並不保證在傳統方法處理不好的情況下，大資料相關的處理方案就能處理得好，這時最需要的是進行深入的特性分析，提出最優的解決方案，包括傳統方法與大資料處理方案進行融合（例如利用關係型資料庫處理公司裡大部分結構化資料，利用hadoop處理公司裡大部分結構化資料）。

9樓：

個人感覺不能單單從資料量來衡量是否該用hadoop.

用什麼技術應該是從實際需求來的，輔以合適的硬體架構。如樓主的case, 只是簡單處理上百G的日誌而且沒有cluster的話, 實在沒有必要用hadoop。如果處理的分析比較複雜，記憶體和CPU會成為瓶頸，這時如果有已經成型的cluster，用hadoop就會好很多。