作者:
dryman (dryman)
2016-07-06 23:04:31我前兩份工作也是用Hadoop。我負責的是data stack tech lead
公司日資料量300TB
「大數據」這名詞真的很模糊
不過這不是台灣的問題，因為美國這邊很多人也都是這麼搞
我自己是這麼觀察啦...
把大數據當做資料科學技術來看的，大都沒有大資料
把大數據當作「大型資料工程」問題來看的，由於問題複雜度太高
所以很難作為資料科學問題來處理
這什麼意思？
大多數的資料科學演算法動輒O(N^2)以上
數據量一大複雜度馬上就飆到上萬台機器都算不動的情況
而一般的「大數據」工程師
就是要解決因應數據量上升而需要重新設計演算法的工程問題
hadoop就是為了解決這樣的工程問題而生
* * *
傳統資料庫提供的是高階的SQL抽象層
你只要處理集合間的連結即可
底層真正的演算法，不論是透過hash table, sort, b-tree
很多人一般根本不需要接觸到
但是當你數據量大到一定程度後
由資料庫引擎自動幫你決定的演算法就再也不適用了
Hadoop 的設計就是讓你可以把資料問題轉換成 sort (map reduce shuffle phase)
sort也是一般資料庫要解決大型資料查詢的最佳演算法
（例如group by, join, or diff）
一些高富雜度的問題，經過使用hadoop來客製演算法，就變得算得動了
我第一份工作就是將一個要算五個小時的PostgreSQL ETL
重寫成map reduce，變得只有二十分鐘
這個效率應該是用hive/pig都做不到的。因為要客製化演算法
這只是在數據量變大後其中一個變困難的問題
資料蒐集、處理（上述的ETL就是問題之一）、儲存、查詢
每件事都變得困難許多
通常資料科學家會拿去作分析的，大都是縮小很多的資料集了
他們的第一步，通常就是怎麼把資料變得更小，不然算不動XD
* * *
我最近試著把一些之前所學知識整理成部落格
不定期更新 :P
https://medium.com/@fchern
其中一篇是
「那些大數據書不會教的資料工程」
http://tinyurl.com/hvrt7s8
主要在講如何進行資料清理
有空可以看看
* * *
最後...不要寄信給我（包含職涯建議之類）
有問題請在版上發問 :)
作者:
now99 (陳在天)
2016-07-06 23:07:00推
推 不過Map Reduce限制真得很大 很多演算法為了可以利用Map Reduce來運算改得面目全非 明明還是用一樣的一樣的名子 Performance跟裡面真正的算法都不一樣了
作者:
psinqoo (零度空間)
2016-07-06 23:14:00使用 Rhadoop SparkR ~~
作者:
dryman (dryman)
2016-07-06 23:23:00包含spark，都無法解決當你的資料集比記憶體還大時該怎麼辦
作者:
htc812 (大帥)
2016-07-06 23:29:00spark 怎麼會不能解決資料集大過記憶體的情況...
至少有好的scalability可以用加機器解決 算不錯了吧?
作者:
SuM0m0 (Part Time Player)
2016-07-06 23:36:00會spill to disk啊
其實現在同時submit多支還是會炸吧? 還是2.0有解決?
作者:
dryman (dryman)
2016-07-06 23:37:00現在spark對於超大資料處理效能我不熟。我還在做data時它在處理超大資料的效能評估一直沒有達到我們的標準
作者:
SuM0m0 (Part Time Player)
2016-07-06 23:39:00這類題目可能得跟storage一起討論 不然case by case落差大
作者:
bowin (盡其在我)
2016-07-07 00:16:00推
作者: laject (hanks) 2016-07-07 00:27:00
推
作者:
h310713 (虎虎虎)
2016-07-07 01:10:00Data pre process 才是重點
作者:
htc812 (大帥)
2016-07-07 01:41:00推
作者:
Argos (Big doge is watching u)
2016-07-07 09:51:00推
作者:
ken9527k (來韓老師這邊)
2016-07-07 12:22:00謝謝分享
作者: PolarGG (PolarGG) 2016-07-07 17:46:00
推