楼主:
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
推