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

01-04

現在這個概念很火Hadoop等MR的框架也日漸成熟。但究竟到了什麼級別的數據值得用大數據的方式來處理呢？
本身在工作中經常會需要處理一些上百G的數據和日誌，一般隨便寫一個scala的並行腳本單機的處理速度也已經完全可以接受了（硬體是i7 8核 + 16G + SSD），基本不用等太久，做點別的事情回來看看就有結果。
這種情況下如果要寫成用MR的腳本勢必在編程效率，測試和部署上大打折扣（本人沒用過Hadoop，只用過一段時間GAE）。對於目前的數據量顯然並不值得用更多的developer hour來換CPU hour

當然這個數據量比起動輒PB的自然是小巫見大巫，所以才會上來問這個問題。如果數據規模(GB? TB?)並不是唯一的衡量尺度那還有什麼其他標準呢？

建議在處理非結構化數據，or硬體設備無法支持當前數據量時再上。

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

謝邀。

個人覺得，這個問題要從兩個方面回答。

第一，從數據量角度，但是並無確定的答案，一般定性角度來說，你覺得這個數據量單機處理不了，比如內存限制，時間過久等，就用集群，但是要降低時間，你的處理邏輯必須能分散式處理，去mapreduce化，graph化，mpi化等。定量就是一般數據或者未來的數據量會達到PB級別（可能GB）或以上就要用分散式，當然前提也是你的處理邏輯可以進行分散式。

第二，從演算法角度，或者處理邏輯的時間複雜度來說，比如雖然你的數據記錄不是很多，但是你的演算法或者處理邏輯的時間複雜度是n的平方，甚至更高，同時你的演算法可以進行分散式設計，那麼就考慮用分散式，比如你的記錄雖然只有1w, 但是時間複雜度確是n的平方，那麼你想想單機要多久，同是你的演算法可以進行分散式處理，那麼就考慮用分散式。

總而言之，大致如下：

如果你的處理邏輯或者時間演算法複雜度低但是數據量達到PB級別，同時你的處理邏輯可以分散式，那麼請用分散式。

如果你的處理邏輯或者演算法複雜度高，一般是n的平方，甚至更高，並且你的演算法可以分散式設計，數據記錄達到萬以上，就請用分散式。

如果你的數據記錄達到萬以上，並且你的演算法複雜度高，大於等於n平方，那麼你就要想方設法去把你的演算法分散式化，如果實在不能，那麼要麼使用可以分散式的同類演算法代替，要麼去犧牲演算法的準確去降低演算法複雜度。

當然前提是你是用的不是高性能機器。

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

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

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

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

魚缸的啟示：

　　提到Scale-out和Scale-up，初看到可能會有點暈。其實我認為Scale-out和Scale-up的概念可以用一個簡單的例子來解釋。

　　不知您有沒有養過魚?當你只有六七條魚的時候，一個小型魚缸就夠了;可是過一段時間新生了三十多條小魚，這個小缸顯然不夠大了。
　　如果用Scale-up解決方案，那麼你就需要去買一個大缸，把所有沙啊、水草啊、布景啊、加熱棒、溫度計都從小缸里拿出來，重新布置到大缸。這個工程可不簡單哦，不是十分鐘八分鐘能搞得定的，尤其水草，糾在一起很難分開(不過這跟遷移數據的工程複雜度比起來實在是毛毛雨啦，不值一提)。
　　那麼現在換個思路，用Scale-out方案，就相當於是你在這個小缸旁邊接了一個同樣的小缸，兩個缸聯通。魚可以自動分散到兩個缸，你也就省掉了上面提到的那一系列挪沙、水草、布景等的折騰了。
　　回到存儲架構。用戶在採購之初很難準確預測未來數據增長的速度和總量。用戶往往不得不採購比自己目前實際需求容量更大的存儲，這就導致兩個問題，一是預算的浪費，很多存儲空間都是為未來數據增長採購的，花了10TB的錢，但是可能只利用上了5TB，另5TB的資金都白白放在那裡。另一個問題是，隨著時間推移，數據增長，數據量超過了10TB。
　　按照過去Scale-up的理念，解決方案就是購買更大容量的存儲，那麼難免面臨數據遷移的問題，用戶必須停機遷移數據，意味著服務的中斷。而Scale-out架構解決了這個矛盾。用戶按需採購存儲，一旦容量不夠了，再購置一台接到原有存儲上就可以了。
　　這只是我的一點想法，如有不對的地方，歡迎大家批評指正、展開討論。

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

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

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

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

無法用一台機器在需求時間內處理完的任務。

大數據的本質並不是大，而是亂

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

如果都是規則數據，多大都沒有太大問題，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，顯然是牛刀剁小雞

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

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

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

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

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

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

這裡首先要說的是，大小永遠是相對的。

對大數據來說，這條道理同樣適用。

如果你的企業有一萬條數據，那麼這些所有的數據總和就是你企業的大數據，對於分析企業內部的問題就是十分寶貴的數據財富；當然，如果你想要借鑒其他企業的做法，需要採集或者獲取外部數據，對外部數據的量的獲取又是另一種考量。

其實對於數據分析而言，重要的不是數據的「絕對大」，而是「相對大」，更重要的是如何「用」，數據背後的價值需要經過精心的分析才會被開發出來。

數據獲取固然重要，只有用好，才能真正發揮數據的價值。

毛遂自薦我的公眾號：大數據深度分析，歡迎大家一起來討論大數據、數據分析。