PTT職涯區 / Soft_Job (軟體人)

Re: [討論] 會用Hadoop == 具備大數據處理能力?

看板Soft_Job (軟體人)作者 (dryman)時間9年前 (2016/07/06 23:04), 9年前編輯推噓21(21推 0噓 7→)
留言28則, 19人參與, 最新討論串4/6 (看更多)
我前兩份工作也是用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 主要在講如何進行資料清理 有空可以看看 * * * 最後...不要寄信給我（包含職涯建議之類） 有問題請在版上發問 :) -- ※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 98.248.38.67 ※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1467817474.A.291.html
→
07/06 23:07, , 1F
推
07/06 23:07, 1F
推
07/06 23:10, , 2F
推 不過Map Reduce限制真得很大 很多演算法為了可以
07/06 23:10, 2F
→
07/06 23:10, , 3F
利用Map Reduce來運算改得面目全非 明明還是用一樣的
07/06 23:10, 3F
→
07/06 23:11, , 4F
一樣的名子 Performance跟裡面真正的算法都不一樣了
07/06 23:11, 4F
推
07/06 23:14, , 5F
使用 Rhadoop SparkR ~~
07/06 23:14, 5F
→
07/06 23:23, , 6F
包含spark，都無法解決當你的資料集比記憶體還大時該怎麼
07/06 23:23, 6F
→
07/06 23:23, , 7F
辦
07/06 23:23, 7F
推
07/06 23:29, , 8F
spark 怎麼會不能解決資料集大過記憶體的情況...
07/06 23:29, 8F
我推文沒寫清楚 hadoop, spark 都無法自動替你解決資料大過記憶體的情況 複雜的演算法很多都還是要自己去推敲 不過早期的spark真的會有資料大過記憶體就OOM的情況 因為它們早期不是用sort，而是用hash table來處理shuffle phase..
推
07/06 23:29, , 9F
至少有好的scalability可以用加機器解決 算不錯了吧?
07/06 23:29, 9F
※ 編輯: dryman (98.248.38.67), 07/06/2016 23:33:29
推
07/06 23:36, , 10F
會spill to disk啊
07/06 23:36, 10F
推
07/06 23:36, , 11F
其實現在同時submit多支還是會炸吧? 還是2.0有解決?
07/06 23:36, 11F
→
07/06 23:37, , 12F
現在spark對於超大資料處理效能我不熟。我還在做data時
07/06 23:37, 12F
→
07/06 23:38, , 13F
它在處理超大資料的效能評估一直沒有達到我們的標準
07/06 23:38, 13F
推
07/06 23:39, , 14F
這類題目可能得跟storage一起討論 不然case by case落差大
07/06 23:39, 14F
推
07/06 23:57, , 15F
推 這版真的很多神人
07/06 23:57, 15F
推
07/07 00:16, , 16F
推
07/07 00:16, 16F
推
07/07 00:27, , 17F
推
07/07 00:27, 17F
推
07/07 00:30, , 18F
推 map reduce 不好寫QQ
07/07 00:30, 18F
推
07/07 00:58, , 19F
有神到..
07/07 00:58, 19F
推
07/07 01:10, , 20F
Data pre process 才是重點
07/07 01:10, 20F
推
07/07 01:41, , 21F
推
07/07 01:41, 21F
推
07/07 07:51, , 22F
感謝分享
07/07 07:51, 22F
推
07/07 09:51, , 23F
推
07/07 09:51, 23F
推
07/07 09:56, , 24F
之前就看過分享文了，推
07/07 09:56, 24F
推
07/07 11:56, , 25F
這篇寫的好
07/07 11:56, 25F
推
07/07 12:22, , 26F
謝謝分享
07/07 12:22, 26F
推
07/07 17:46, , 27F
推
07/07 17:46, 27F
推
07/10 01:37, , 28F
推
07/10 01:37, 28F
‣ 更多 dryman 的文章
文章代碼(AID): #1NVHu2AH (Soft_Job)
Soft_Job 近期熱門文章
更多 近期熱門文章 >>
PTT職涯區 即時熱門文章
更多 即時熱門文章 >>
‣ 更多 dryman 的文章
文章代碼(AID): #1NVHu2AH (Soft_Job)