EB3基本都是降级的，明年EB2利好 - 未名空间MITBBS历史存档

国际科技财经博客移民网络热点娱乐民生时事公众号

Redian新闻

>未名空间

>EB23 - 劳工卡

EB3基本都是降级的，明年EB2利好

EB3基本都是降级的，明年EB2利好# EB23 - 劳工卡

s*e2016-05-05 07:05

1 楼

经典hadoop例子也就是wordcount之类的一个数据。很好理解mapper和reduce 该写些什
么。但实际上经常要从log文件中析取所有的各种数据：举个例子：要从一套log文件
中析取average height break down into gender, top 10 sites break down into
phone types, top word break down into adults/kids...。
我想不出这些情况mapper和reduce 该怎么写？

f*c2016-05-05 07:05

2 楼

看最近爆率的都是降级的，如果Eb3还是一片降级绿的，那2017财年快速通过Eb2。
是这么个说法吧？

l*n2016-05-05 07:05

3 楼

http://highlyscalable.wordpress.com/2012/02/01/mapreduce-patter

【在 s******e 的大作中提到】

: 经典hadoop例子也就是wordcount之类的一个数据。很好理解mapper和reduce 该写些什
: 么。但实际上经常要从log文件中析取所有的各种数据：举个例子：要从一套log文件
: 中析取average height break down into gender, top 10 sites break down into
: phone types, top word break down into adults/kids...。
: 我想不出这些情况mapper和reduce 该怎么写？

c*y2016-05-05 07:05

4 楼

并不是，你自己搜yoyo的说法他认为EB2 明年没法放水可能要到再下一年才能放
他认为485总是比想象的多

【在 f****c 的大作中提到】

: 看最近爆率的都是降级的，如果Eb3还是一片降级绿的，那2017财年快速通过Eb2。
: 是这么个说法吧？

p*22016-05-05 07:05

5 楼

我觉得现在直接写map reduce的机会其实是很小了。

y*02016-05-05 07:05

6 楼

http://www.mitbbs.com/article_t/EB23/32559743.html

s*e2016-05-05 07:05

7 楼

我就是想着如何把原来的工作和hadoop结合起来。
所要了解一下，原来的工作用hadoop怎么做。
你有答案吗？看了下 icn给的link, 找不到和我相配的design pattern.
难道你们parse log都是为了得到一两类数据吗？
还是我没看懂文章的意思？

【在 p*****2 的大作中提到】

: 我觉得现在直接写map reduce的机会其实是很小了。

y*02016-05-05 07:05

8 楼

还有一个事实，原装报绿少，降级报绿多。去年EB3报绿的90%以上都是降级的来报绿。

s*e2016-05-05 07:05

9 楼

那用大数据的人整天在干嘛？

【在 p*****2 的大作中提到】

: 我觉得现在直接写map reduce的机会其实是很小了。

f*a2016-05-05 07:05

10 楼

同意yoyo,从今以后都是要起码等5年了

m*i2016-05-05 07:05

11 楼

hadoop is just a tool. You need to design a parallel algorithm and then
implement it in hadoop.
First, you need to do paralle reading.
Second, each worker threads needs to computer the to 10 locally.
Then, combine all the results and get the real top 10.

【在 s******e 的大作中提到】

y*02016-05-05 07:05

12 楼

我没说过要等5年啊....T.T

【在 f*****a 的大作中提到】

: 同意yoyo,从今以后都是要起码等5年了

l*n2016-05-05 07:05

13 楼

你这些都是counting & summing problems吧，只不过是写mapper/reducer的时候key/
value可能不是单一的field。比如你的mean height over gender，就是gender vs.
height_ONE，height用来summing,ONE用来counting。mapreduce的灵活性不单只是一个
wordcount那么狭隘的。

【在 s******e 的大作中提到】

: 我就是想着如何把原来的工作和hadoop结合起来。
: 所要了解一下，原来的工作用hadoop怎么做。
: 你有答案吗？看了下 icn给的link, 找不到和我相配的design pattern.
: 难道你们parse log都是为了得到一两类数据吗？
: 还是我没看懂文章的意思？

w*i2016-05-05 07:05

14 楼

你这个大旗被扛过来抗过去阿。哈哈哈

【在 y******0 的大作中提到】

: 我没说过要等5年啊....T.T

p*22016-05-05 07:05

15 楼

hive

【在 s******e 的大作中提到】

: 那用大数据的人整天在干嘛？

h*y2016-05-05 07:05

16 楼

pig/hive很多复杂逻辑不行的。

【在 p*****2 的大作中提到】

:
: hive

s*e2016-05-05 07:05

17 楼

那么我写的mapper到底是去算还是还是<
word: adult>那？
如果我需要写三个mapper分别统计, adult>那不是很重复吗？因为每个mapper都是要把整个log读一遍（我知道大数据会
分成block, 我是指对于每个block来说这三个mapper都要把他从头到尾读一遍为了求自
己的那部分数据）而且如果adult/kid要进一步细分成female/male的话第三个mapper原
本可以建立在第一个mapper的基础上，分开就用不上了。
还有种可能性就是所有东西都放在一个mapper里，那从mapper里输出什么那，反正不是
key:value那样简单了。
Hive 我可以理解。就是用一些象sql那样的语句得到结果。如果逻辑不复杂的话应该可
以考虑。

【在 l*n 的大作中提到】

: 你这些都是counting & summing problems吧，只不过是写mapper/reducer的时候key/
: value可能不是单一的field。比如你的mean height over gender，就是gender vs.
: height_ONE，height用来summing,ONE用来counting。mapreduce的灵活性不单只是一个
: wordcount那么狭隘的。

p*22016-05-05 07:05

18 楼

cascalog

【在 h**********y 的大作中提到】

: pig/hive很多复杂逻辑不行的。

p*22016-05-05 07:05

19 楼

word:
我们可以分开讨论。我觉得就第一个例子来说，
average height break down into gender
mapper:
gender->height
reducer:
gender-> (sum of height, count of people)
mapper:
gender-> average of height

【在 s******e 的大作中提到】

: 那么我写的mapper到底是去算还是还是<
: word: adult>那？
: 如果我需要写三个mapper分别统计, : adult>那不是很重复吗？因为每个mapper都是要把整个log读一遍（我知道大数据会
: 分成block, 我是指对于每个block来说这三个mapper都要把他从头到尾读一遍为了求自
: 己的那部分数据）而且如果adult/kid要进一步细分成female/male的话第三个mapper原
: 本可以建立在第一个mapper的基础上，分开就用不上了。
: 还有种可能性就是所有东西都放在一个mapper里，那从mapper里输出什么那，反正不是
: key:value那样简单了。
: Hive 我可以理解。就是用一些象sql那样的语句得到结果。如果逻辑不复杂的话应该可

k*r2016-05-05 07:05

20 楼

学习学习

l*n2016-05-05 07:05

21 楼

你提的问题的确涉及到mapreduce vs. analysis的核心：hdfs通用的分布式同数据的结
构化之间的矛盾。如果你的三种分析是独立的，那么你确实要分开run 3个MR的任务，
文件IO的确是要重复3次；如果三个分析的信息是结构化的，那么可以只搞一个复杂点
的MR任务，只做一次文件IO。这时候就变成了程序执行效率 vs. 程序编写效率之间的
矛盾了。
目前解决的方向好像都是在借鉴传统SQL的思路，比如是columnar storage，就是把结
构化信息拆开让不同组分分别存储，需要的时候再聚合，另一个是MR执行的推迟，让
engine对MR任务进行优化。Hive就是把query转成MR任务，有人说他慢就是因为生成的
MR方案以及query和query之间的优化还不够好吧。

word:

【在 s******e 的大作中提到】

s*e2016-05-05 07:05

22 楼

嗯越学越不懂了。

【在 l*n 的大作中提到】

: 你提的问题的确涉及到mapreduce vs. analysis的核心：hdfs通用的分布式同数据的结
: 构化之间的矛盾。如果你的三种分析是独立的，那么你确实要分开run 3个MR的任务，
: 文件IO的确是要重复3次；如果三个分析的信息是结构化的，那么可以只搞一个复杂点
: 的MR任务，只做一次文件IO。这时候就变成了程序执行效率 vs. 程序编写效率之间的
: 矛盾了。
: 目前解决的方向好像都是在借鉴传统SQL的思路，比如是columnar storage，就是把结
: 构化信息拆开让不同组分分别存储，需要的时候再聚合，另一个是MR执行的推迟，让
: engine对MR任务进行优化。Hive就是把query转成MR任务，有人说他慢就是因为生成的
: MR方案以及query和query之间的优化还不够好吧。
:

s*e2016-05-05 07:05

23 楼

然后你想说什么？
(不好意思我老延迟)

【在 p*****2 的大作中提到】

:
: word:
: 我们可以分开讨论。我觉得就第一个例子来说，
: average height break down into gender
: mapper:
: gender->height
: reducer:
: gender-> (sum of height, count of people)
: mapper:
: gender-> average of height

c*a2016-05-05 07:05

24 楼

MapReduce Design Patterns by Donald Miner and Adam Shook
你说的，里面都有，我做过类似的东西